Arabic-English websites: multilingual SEO done right in the GCC

In the GCC, the same person often searches one way in the morning and another way at night. They look up a service in English on a desktop at the office, then research the same brand in Arabic on a phone over dinner. If your website treats Arabic as a translation layer bolted onto an English original, you are quietly losing half of that journey — in rankings, in trust, and in conversions.

Building a genuinely bilingual site for the UAE and the wider Gulf is not a localisation checkbox. It is two first-class experiences that share one content model, one performance budget, and one search strategy. Here is how we approach it at Karve.

Start with the content model, not the translation

Most multilingual SEO problems trace back to a content model that was never designed to be bilingual. A single document with an Arabic toggle slapped on top forces every page to share slugs, metadata, and editorial state across languages. The result: Arabic pages that inherit English URLs, missing or duplicated meta descriptions, and content that cannot be reviewed or published independently.

The fix is field-level internationalisation. Each translatable field carries its own per-language value, so Arabic and English can have independent titles, descriptions, slugs, and publish states while still living in one connected graph. That structure is what makes everything downstream — hreflang, sitemaps, analytics — reliable instead of hopeful. This is exactly why we lean on a structured, localisation-aware CMS for these builds.

A well-modelled headless CMS such as Sanity lets editors manage both languages from one place without flattening them into a single string, which keeps the bilingual graph honest as the site grows.

hreflang, done so the errors are impossible

hreflang is where good intentions go to die. The classic failures are predictable, and every one of them is structural rather than accidental:

• One-directional annotations — the English page points to Arabic, but Arabic never points back.
• Alternates that resolve to redirects instead of the final URL.
• hreflang tags sitting on pages that are also set to noindex.
• Missing x-default, so search engines guess which version to show first-time visitors.

When alternates are generated from the content graph rather than hand-authored per page, these mistakes stop being likely and start being impossible. If the Arabic version exists in the model, the reciprocal tags are emitted automatically; if it does not, no broken promise is made.

URL strategy that crawlers and analysts both like

Use explicit path prefixes — /en/ and /ar/ — rather than cookies, IP sniffing, or query strings. Path prefixes are crawlable, shareable, cacheable, and trivially segmentable in analytics. They also map cleanly onto an x-default at the root, which is the behaviour search engines expect.

RTL is design, not a mirrored stylesheet

Right-to-left support is where teams most often confuse “it renders” with “it works.” Flipping a layout is the easy 20 percent. The craft is in the rest:

1. Type scale: Arabic script generally needs larger sizes and looser line heights than Latin at the same hierarchy level to stay legible.
2. Direction-aware assets: icons, arrows, and imagery carry directional meaning and must mirror intentionally — not all of them should.
3. Numerals and code: digits, phone numbers, and inline code stay left-to-right even inside RTL text.
4. Mixed content: brand names and English terms embedded in Arabic copy need careful bidirectional handling so punctuation lands correctly.

Modern CSS logical properties let one codebase serve both directions properly, and a logical-utility approach to styling keeps it maintainable as the design evolves rather than accumulating one-off direction hacks.

Performance is a ranking and trust signal in both languages

Core Web Vitals do not care which language a page is in, and neither does a user on a mid-range phone over a congested mobile network. Server-rendering both locales, shipping only the fonts each language needs, and serving from the edge keeps both experiences fast. A framework like Next.js on a global edge platform gives you per-locale rendering and caching without maintaining two separate sites.

Arabic web fonts are heavy. Subset them, load only the weights you use, and never block first paint on a font that only the Arabic version needs. The payoff is real: faster pages rank better and convert better in both markets.

Treat each language as its own search market

Arabic and English are not mirror keyword sets. Search intent, phrasing, and even the questions people ask differ between the two. Direct translation of an English keyword list produces Arabic copy that reads like a machine wrote it and ranks for nothing. Do dedicated Arabic keyword research, write natively in Arabic, and let a strong content and SEO practice shape each language on its own terms.

That is the difference between a site that is technically bilingual and one that actually earns traffic in both languages — and it is the core of how our SEO and content and web development teams build for the Gulf.

The short version

A bilingual GCC site that ranks is not an English site with Arabic added. It is a deliberately bilingual content model, hreflang and URLs generated from that model, RTL treated as design rather than a flip, performance budgeted for both scripts, and search treated as two distinct markets. Get the structure right once, and every page you publish after that is correct by default.