Bilingual SEO for GCC websites: where Arabic and English sites go wrong

Most Arabic/English websites in the GCC start as an English site with an Arabic version added afterwards — a literal translation dropped into the same template, sometimes without even flipping the layout direction. That approach usually satisfies a language requirement without doing anything for search visibility, and in a market where a meaningful share of commercial searches happen in Arabic, that's a real cost, not a cosmetic one.

In competitive, bilingual markets like Dubai, the sites that rank consistently in both languages treat Arabic as its own strategy from the start, not a translation bolted on afterward.

Getting this right technically is a distinct discipline from getting it right editorially. Both matter; this article focuses on the technical side — the part that decides whether search engines can even tell the two versions of a page apart correctly.

hreflang is an HTML attribute (or sitemap entry) that tells search engines which language, and optionally which region, a page is written for, and which other URLs are its equivalent versions in other languages. Its job isn't to translate anything — it's to stop search engines guessing, and to stop them showing an English result to an Arabic searcher, or the reverse, when a better-matched version exists.

The most common implementation mistake is one-directional tagging: the English page correctly points to the Arabic version, but the Arabic page doesn't point back. hreflang has to be reciprocal — every language version needs to reference every other version, including itself — or search engines are likely to ignore the whole set of annotations rather than partially trust it.

A consistent, predictable URL pattern makes this system easier to maintain and easier for search engines to trust. The common, defensible options are a subdirectory (site.com/ar/...) or a separate subdomain (ar.site.com) — subdirectories are usually the simpler choice for a business without an existing reason to split infrastructure, since they share domain authority automatically rather than needing it rebuilt separately.

What causes real problems is inconsistency: some Arabic pages living under /ar/, others generated through a query parameter, and others detected purely by browser language with no distinct URL at all. If a page's language can't be reached through a stable URL, it can't be indexed, linked to, or referenced by hreflang reliably.

A properly translated Arabic page and its English equivalent are not duplicate content in any meaningful sense — they're different content in different languages serving different searchers, and treating them as interchangeable is a mistake in the other direction. Where real duplication does happen is more mundane: the same Arabic content reachable at two different URLs, with and without a trailing slash or query parameter, or an English page that's Arabic in name only because the translation was skipped and the original English text was left in place under an /ar/ URL. That second case genuinely is thin and unhelpful, and worth fixing before anything else on this list.

The most damaging mistake here is a canonical tag that points across languages — an Arabic page whose canonical points at the English version. That tells search engines the Arabic page isn't the "real" one, and it can quietly remove it from Arabic search results entirely. Each language version should canonicalize to itself; hreflang, not canonical, is the mechanism for describing the relationship between language versions.

These are two different jobs, and a business that only does one usually assumes it's covered both. Translation quality is whether the Arabic reads naturally and accurately. SEO localization is whether that Arabic content is actually built around how Arabic speakers search — which keywords, phrasing and structure they use — rather than a literal translation of English keyword targets that may not reflect real Arabic search behaviour at all.

A page can be translated perfectly and still target the wrong terms, because the English keyword research was never redone in Arabic.

Title tags and meta descriptions in Arabic script often display differently in a search result than the same character count would in Latin script — worth checking in an actual preview rather than assuming English-length guidance carries over exactly. The page itself needs a correct dir="rtl" and lang="ar" declaration, not just visually mirrored styling, so browsers, assistive technology and search engines all interpret the page's structure and language correctly rather than guessing from the visible layout alone.

A language switcher is necessary but not sufficient. Beyond it, internal links inside the Arabic content should point to other Arabic pages, and English content to other English pages, rather than accidentally crossing between languages mid-navigation — every stray cross-language link works against the separation hreflang is trying to establish.

The same discipline that shapes SEO strategy generally — matching content to how people actually search — applies separately in each language, not once for both.

Before treating a bilingual site as done, it's worth checking each of the following directly rather than assuming a CMS or plugin handled it correctly:

For a market where the same customer might search in Arabic on one visit and English on the next, this isn't an edge case worth deprioritising — it's the difference between showing up for half the addressable market or all of it.

Where a site's underlying architecture makes this hard to implement cleanly, that's usually a sign it needs a proper Technical SEO pass before anything else.