Technical SEO checklist for Arabic and Persian sites
The technical SEO items most often missed on RTL sites: dir and lang, logical CSS, percent-encoded slug length, ZWNJ and numeral formats.
By Roozbeh Nazari · CEO
On most projects the Arabic and Persian versions are the last layer added and the least audited. They look as though they work, because the browser handles laying text out right to left on its own. The problems accumulate not in the visual layer but in the markup and on the URL side, and they are usually noticed weeks after going live. This article lists the technical items most often missed on RTL versions.
We set out the general audit flow in our technical SEO audit checklist; this article is its RTL-specific supplement. On the commercial side the subject as a whole sits on our technical SEO service page.
dir and lang: not solved with CSS
The most common mistake is supplying the direction information only on the style side. The W3C's dedicated guidance is definite on this point: do not use CSS to apply base direction in HTML pages. The reason is semantic rather than technical; because directional information can affect the meaning of content, it should be part of the markup.
The practical equivalent is two lines. If the overall direction of the document is right to left, dir="rtl" is added to the html tag. The same guidance recommends writing dir on lower-level structural elements only where you need to change the base direction of that block; because direction is inherited down from html, most pages need no extra markup.
On the lang side the distinction gets missed: ar for Arabic, fa for Persian. Because the two languages use the same alphabet, setups that fudge this with a single value are common. That breaks both the accessibility layer and language targeting.
Mixed-direction text
When a left-to-right brand name, unit of measure or URL is dropped into a right-to-left sentence, the ordering can break in unexpected ways. In titles and meta descriptions this shows up as words visibly changing places. A punctuation mark landing on the wrong side when a Latin-script fragment falls at the end of a line is the classic symptom.
The check is simple: open three titles containing an English brand name, a number and punctuation together on a real device and read them. You will see the problem in the real rendering, not in browser developer tools.
Slugs: six characters per letter
This is the hardest limit on RTL projects. Arabic and Persian letters are represented in URLs with percent encoding, and each letter takes up to six characters. A length that looks comfortable in a Latin-script slug pushes against the limit in the Arabic equivalent of the same content. Slugs exceeding two hundred and forty characters when encoded cause build-time problems on our side.
As a rule, do not leave the slug to the natural length of the translation; generate it from the title and shorten it by hand. The check needs automating before publication, because a slug that looks short by eye may be over the limit once encoded.
On the Persian side there is one more item: a ZWNJ character can leak into the slug. Because it is invisible it goes unnoticed, it takes up space once encoded, and it produces two different URLs. Replacing ZWNJ with a hyphen or a space during slug generation is cheaper than writing redirects afterwards.
Code point consistency
The Persian ye and kaf are different code points from their Arabic counterparts and are indistinguishable by eye. If content arrives from different sources, two different code points can sit together on the same page. The result: the same word fails to match in on-site search, slugs silently diverge, and comparisons do not hold.
Applying a one-way normalisation at import, and doing it at the moment of saving, is the right place. Correcting it at publication time is too late.
Logical CSS properties
The W3C guidance recommends using logical equivalents rather than left and right for margins and alignment, so that styles adapt on their own during localisation. In practice this keeps fixed left padding and left-aligned icons from ending up on the wrong side in the RTL version. It does not look like an SEO item, but when the layout breaks the user leaves the page, and that has a measurable equivalent.
Numerals and dates
In Arabic and Persian content, numerals can be written with Eastern Arabic or Persian digits. That is a matter of preference, but mixing the two forms on the same page, and using local digits in structured data, are separate problems. Numeric fields in structured data will be read by a machine and should stay in the standard form; using the local form in the visible text is free.
On the Persian side the calendar is a further heading: if the Solar Hijri date is used in the text, the date fields need to stay separate and consistent on the machine side.
Fonts, shaping and truncation
The visual layer produces silent errors on RTL versions too. Because the Arabic alphabet is written joined, letters change form according to their position; a font that does not fully support shaping renders the text legibly but wrongly. Persian additionally needs a font containing the correct forms of ye and kaf; a font chosen for Arabic does not always give the right result in Persian.
The second issue is truncation. Cuts made by character limit in title and description fields can split a word in the middle in joined script, producing an unreadable string. Cutting on a word boundary rather than a character is more critical on the RTL side than on the Latin side.
The third is line height. In Arabic and Persian the ascenders and descenders take up more room than in Latin script; a tight line height tuned for Latin makes letters overlap in these languages. It looks like an aesthetic problem, but text that is not read is not read.
There is only one way to audit these three: open the page on a real device with real content. Checks done with placeholder text show none of these errors.
hreflang and reciprocity
When linking language versions, the basic rule in Google's localized versions documentation does not change: every version should point to all versions including itself, and the links should be reciprocal. The additional risk on the RTL side is percent-encoded URLs being written half-encoded in the tags; the same address encoded in one place and not in another silently breaks reciprocity.
For the detailed version of this heading see hreflang errors and how to detect them.
A short pre-publication list
- Is dir correct on the html tag, and is the lang value separated into ar and fa?
- Do titles containing a Latin-script fragment read correctly on a real device?
- Is the percent-encoded length of the slug under the limit?
- Has a ZWNJ been left in the slug?
- Are Arabic and Persian code points mixed in the content?
- Are numerals in structured data in the standard form?
- Are the hreflang links reciprocal and in the same encoding?
Adding these seven items to the publication checklist heads off most of the work that otherwise surfaces later on RTL versions. Most of the items can be automated; the read-on-a-real-device step cannot, and has to be done by hand before every release.