Blog
Arabic vs English SEO in the UAE
How to structure a bilingual UAE site, why translated pages underperform, how transliterated Arabic defeats keyword tools, and when Arabic is worth the investment.
Short answer
Should a UAE website be in Arabic, English, or both?
It depends on who buys from you, and the honest answer for many UAE businesses is English only — done properly — rather than both done badly. Where Arabic is worth it, it needs its own indexable URLs with a reciprocal hreflang set, and copy written for Arabic search rather than translated from English, because Arabic speakers search using different phrasings, not the same phrasings in a different script. A translated Arabic section built on a language toggle is the most common and least effective implementation.
Updated
Who actually searches in Arabic in the UAE?
The UAE's resident population is majority expatriate, and English functions as the working language across much of the private sector. That is why English-only sites perform adequately for many B2B, technology and expatriate-facing businesses, and why the advice to translate everything into Arabic is often wrong.
Arabic weight rises sharply in specific places: government and semi-government audiences, Emirati consumers, family businesses, healthcare, legal and personal services, and anything aimed at the wider Gulf market rather than UAE residents alone. It is also higher in Abu Dhabi than in Dubai, and higher again in Sharjah. The question to answer before committing budget is not whether Arabic matters in the UAE — it does — but whether it matters for your specific buyers.
How a bilingual site must be structured
Each language needs its own URL, server-rendered, with its own title, meta description and self-referencing canonical. A toggle that swaps text on a single URL leaves exactly one indexable version, which means the Arabic content does not exist as far as search engines are concerned — this is the single most common failure and it silently wastes the entire translation budget.
The two versions are then tied together with a reciprocal hreflang set. Every page references itself and its counterpart, the references point both ways, the URLs are absolute, and an x-default nominates the version to serve when neither matches. Hreflang fails silently: there is no error, the pages simply compete as duplicates and Google picks one. It is worth validating rather than assuming.
The Arabic version sets the language and direction attributes on the page, and the layout mirrors — navigation, directional icons, form fields, tables. Using CSS logical properties keeps one stylesheet working in both directions; bolting on a separate right-to-left stylesheet is where layout stability usually breaks, which shows up in Cumulative Layout Shift. Arabic web fonts should be subset and preloaded so they do not delay rendering.
| Implementation | Indexable in both languages? | Verdict |
|---|---|---|
| Separate server-rendered URLs with reciprocal hreflang | Yes | The only approach that fully works |
| Separate URLs, no hreflang | Yes, but they compete | Partially effective; duplicates risk one being ignored |
| JavaScript language toggle on one URL | No | Arabic content is effectively invisible |
| Automatic redirect by browser language or IP | Unreliable | Can prevent crawling of one version entirely |
| Machine-translated pages, correctly structured | Yes | Indexable but rarely competitive — wrong phrasings |
Why translated Arabic pages underperform
Translation converts your English phrasing into Arabic. Search requires the phrasing Arabic speakers actually type, which is frequently not the translation of what English speakers type. The two diverge on the words chosen, on formality, and on how specific a query tends to be. A translated page can be perfectly accurate Arabic and still target phrases nobody searches.
Modern Standard Arabic and Gulf dialect also pull in different directions. Formal written Arabic is the norm for published content, but queries often use colloquial forms. Content that reads naturally while covering both is a writing problem, not a translation problem, and it needs an Arabic writer doing keyword work in Arabic rather than a translator working from an English brief.
Arabizi: the demand your keyword tool cannot see
A large share of UAE search is conducted in Arabic typed with Latin characters and numerals — Arabizi. It has no standard spelling. The same word is written several ways by different people, and keyword tools either miss the variants entirely or split the volume across spellings so thinly that each one looks negligible. The result is that planning from keyword tools alone systematically under-counts this demand.
There are two practical responses. First, let paid search find it: broad match plus the search terms report surfaces the spellings people actually use, in your categories, with your money — which is the cheapest market research available for this problem. Second, cover the variants naturally in page copy rather than building pages per spelling, since each individual spelling rarely justifies a page.
The paid side of this is covered on PPC and paid search across the UAE, where the search terms report is part of the standard reporting rather than an extra.
What Arabic actually costs, and when to stage it
An Arabic version is not a one-off translation cost. It is a second set of pages to write, maintain, update and measure, and a second set of content decisions every time the business changes something. Teams routinely underestimate the maintenance rather than the build, and the common outcome is an Arabic section that was accurate on launch and is wrong eighteen months later — which damages trust more than having no Arabic at all.
Where the case for Arabic is real but the capacity is not, staging works: start with the pages where Arabic demand is highest and the content changes least — core service pages rather than news or offers — and leave the rest in English with correct hreflang covering only what exists. A partial Arabic site that is accurate beats a complete one that is stale.