Arabic and localization
Why your Arabic version brings no traffic, and how to fix it
The short answer
Your Arabic version brings no traffic usually because it was translated rather than written for search. Translation carries over the words you chose in English, not the words your customer types into a search box in Arabic, and the two rarely match. Add three common technical faults: incomplete or non-reciprocal hreflang that makes Google pick one version and ignore the other, RTL implemented as a flipped layout rather than logical properties, and a page-for-page mirrored structure even though the Arabic market may need pages that do not exist in English.
Search Arabic is not brochure Arabic
A user may type your term in three different forms: Modern Standard Arabic, Gulf colloquial, or Latin letters. A professional translator will give you the first only, because it is linguistically correct, though it is often not the most searched form.
Add common misspellings, dropped hamzas and diacritics, and the same product being named differently across Gulf countries. These are not small details: search volume on an “incorrect” form is frequently many times that of the correct one.
The fix is not retranslation. It is doing genuine Arabic keyword research first, then writing pages around what you find. The order is the whole issue: translating and then “optimising” means the words were chosen before anyone looked at the data.
hreflang: the most common technical error I see
A bilingual site without correct hreflang leaves Google guessing which version to show. The usual outcome is that it picks English and ignores Arabic, or shows Arabic to an English audience and the bounce rate climbs.
The condition always forgotten is reciprocity: every page must point at its counterpart and at itself. A pointer from Arabic to English without one coming back is ignored by Google entirely. And add x-default so it knows what to show users matching neither language.
The good news is that fixing hreflang usually improves both versions, because Google stops conflating them. It is one of the rare cases where a single technical fix produces a visible result quickly.
RTL is not a flipped layout
Adding direction: rtl to a site built in English gives you half a solution and half a new problem. Directional icons point the wrong way, numerals and Latin names inside Arabic text reorder themselves, and form fields lose their alignment.
The answer is building on logical properties from the start: margin-inline instead of margin-left, inset-inline-start instead of left, so one stylesheet serves both directions. Pair that with bidi isolation for numerals, URLs and Latin names inside Arabic paragraphs.
And a detail always neglected: the typeface. If you do not load a real Arabic font, the browser falls back to a system default and your site looks markedly cheaper than it is to an Arabic reader, a judgement made within the first two seconds.
The Arabic version is not a mirror copy
The common assumption is that every English page needs an Arabic counterpart and vice versa. In practice the Arabic market may ask entirely different questions and need pages the English version does not have, while other English pages are not worth translating at all.
Start from Arabic search data rather than from your English page list. Ask what your Arabic audience is looking for, then build the pages that answer it. You may end up with two structurally different versions, and that is correct, not a mistake.
Knowing which of these four is actually strangling your Arabic traffic takes measurement on your own site, not working through all four fixes and hoping one sticks. That is exactly what the Digital Presence Audit settles: where the Arabic traffic is actually leaking, and in what order to fix it.