A bilingual Arabic + English website is roughly 1.4× the engineering of a single-language site — not 2×. The extra cost is concentrated in three places: URL strategy, hreflang correctness, and RTL layout debugging. The content translation itself is the smallest part of the bill. This playbook is what we run for every UAE / GCC client who needs to rank in both ar-AE and en-AE Google.

URL strategy — pick one and never change it

Three options exist; only two are sane in 2026.

Option A — subdirectory: example.com/ar/about and example.com/about. Recommended for 95% of sites. Search engines treat both versions as the same domain authority. Easy to set up. Easy hreflang. Works with a single SSL certificate, single CDN config, single CMS.

Option B — subdomain: ar.example.com and www.example.com. Acceptable if Arabic is delivered by a fundamentally different infrastructure (a different CMS, a different hosting region for Saudi compliance). Treated as a separate site by Google, which means you build domain authority twice.

Option C — ccTLD: example.ae (Arabic) and example.com (English). Only correct if you also need country-targeting. Most Dubai businesses don't — they want UAE traffic, not "everyone who speaks Arabic globally" (which would need a generic .com strategy). ccTLD locks you to a country and is the most expensive to maintain.

We default to Option A. If a client is already on Option B for legacy reasons, we don't migrate it — the redirect chains aren't worth the risk.

hreflang — the single most-mistaken thing in international SEO

hreflang tells Google which language and country a page targets. It must be:

Self-referencing — the EN page lists itself as en-AE AND the AR equivalent as ar-AE. The AR page does the inverse.
Bidirectional — both pages link to each other.
Specific to language + region, not just language. Use en-AE and ar-AE for UAE targeting, not bare en / ar.
Plus a x-default for the language Google should fall back to when there's no language/region match.

Example for the EN page:

<link rel="alternate" hreflang="en-AE" href="https://example.com/about">
<link rel="alternate" hreflang="ar-AE" href="https://example.com/ar/about">
<link rel="alternate" hreflang="x-default" href="https://example.com/about">

The AR page must emit the same three tags. Asymmetric hreflang silently breaks the cluster — Google falls back to "use the page that wins on raw signals" and you lose the targeted-locale benefit.

Tooling check. Run Sistrix Hreflang Validator on three pages per locale. Search Console's "International Targeting" report (legacy) also flags asymmetric pairs.

A common UAE mistake: including hreflang="ar-SA" on a Dubai site to "capture Saudi traffic." Don't. If you don't have Saudi-specific content (KSA pricing, KSA contact info, KSA legal disclosures), Google will see the same content under two regional codes and pick one — often not the one you wanted. Better: target ar-AE and let UAE-resident Saudis find you naturally.

RTL is a layout problem, not a translation problem

Switching <html dir="rtl"> is the easy part. The hard parts:

Mirror directional UI. Forward arrows become backward arrows. Carousel "next" buttons reverse. Breadcrumb separators flip. Drop-down chevrons rotate. We use [dir="rtl"] overrides for the dozen or so components that don't auto-mirror.

Logical CSS properties everywhere. Use margin-inline-start not margin-left. Use padding-inline-end not padding-right. Use inset-inline-end: 0 not right: 0. Tailwind 3+ has ms-* / me-* classes. Bootstrap 5 has RTL variants of every utility. Mixing the old physical and new logical properties is where most RTL bugs live.

Number-and-text mixing. "AED 4,400" inside Arabic prose renders correctly with unicode-bidi: isolate on the inline span. Without it, prices appear in random order in long sentences.

Icon fonts. Most icon libraries don't mirror automatically. Bootstrap Icons need manual transform: scaleX(-1) for directional ones.

Form inputs. text-align: start not left. Email fields stay LTR via dir="ltr" on the input — typing user@example.com into an RTL-default field produces a mess.

Content parity — Google penalises mismatches

Google indexes the AR and EN versions independently. They don't need to be word-for-word translations, but they need to be substantially equivalent. Shipping a 2,000-word EN page and a 300-word AR stub on the same canonical relationship is asking for problems — Google flags the AR page as low-quality and may drop the hreflang link entirely.

Practical rule: the AR version must hit at least 60-70% of the EN word count and cover the same H2 sections. Cultural localisation is fine (different examples, different stats) but the topic depth must match.

Headlines and meta: translate, don't transliterate. "AI Automation Services" in Arabic should target real Arabic search demand — that's خدمات الأتمتة بالذكاء الاصطناعي, not أي آي أوتوميشن. Google Keyword Planner with the language switched to Arabic gives genuine UAE search-volume data.

Structured data in two languages

Same schema graph, both languages share the same @id for the Organization (so Google understands they're the same business). Translate name, description, address.addressLocality (yes, even Dubai → دبي). Use inLanguage on Article, Service, and FAQPage to declare locale.

For an FAQPage emitted on both versions, the questions and answers must be translations of each other — different questions on each locale would split the FAQ schema into two unrelated entities, which is technically valid but loses the "this is the same FAQ in two languages" signal.

Sitemap strategy

Two paths:

Single sitemap with xhtml:link alternates — one URL entry per page, hreflang siblings declared inline. Spec-perfect, but most XML sitemap generators don't emit it.

Separate sitemaps per locale — sitemap-en.xml and sitemap-ar.xml, both listed in the sitemap index. Easier to generate, easier to maintain, and Google handles them fine.

We do the latter. It also makes it easier to spot when one locale falls behind in content parity — if sitemap-ar.xml has 40% fewer URLs than sitemap-en.xml, you have a content gap to fill.

Tracking — measure each locale separately

Set up GA4 with two views or two property streams, one per language. Most analytics dashboards default to lumping /about and /ar/about traffic together — useful for total traffic but useless for conversion analysis per locale.

Key segment to watch: Arabic visitors converting on English pages (means your AR content has a gap; they switched to read EN), and the reverse (means your EN page is missing context familiar to UAE audiences).

The 6 things that fail most often

AR page has no canonical to itself — accidentally canonicalises to the EN URL. Result: AR page never indexed.
hreflang on EN page but not on AR page. Asymmetric cluster. Google drops the relationship.
AR page uses LTR layout because the dir="rtl" attribute is conditional on a missing variable. Renders as mirrored mess on first load.
Translated <title> is too long and Google truncates the most important Arabic keyword.
Site speed: AR pages load Arabic font weights synchronously, blocking first paint. CrUX scores AR users worse than EN users.
Anchor text inside AR content links to EN URLs — confuses Google about which version is the "canonical landing" for ar-AE queries.

We test for all six on every launch.

FAQs

Should the Arabic version translate everything literally? No. Translate concepts, not strings. UAE Arabic search vocabulary is distinct — "موقع إلكتروني" outranks "ويب سايت" 12-to-1 in keyword volume.

Do I need a native speaker on the team to do bilingual SEO? For content, yes. For technical SEO (hreflang, schema, RTL), no — a competent engineer can implement it correctly with the playbook above.

Can I machine-translate the AR version to launch faster? You can, but expect lower rankings until you replace it with proper human-authored content. Google has visible quality signals for machine-translated text — it's the most common reason a hreflang cluster doesn't lift in AR results.

Is targeting ar-AE enough, or should I add ar-SA, ar-KW too? Only add other regional codes if you have region-specific content for each. Otherwise stick with ar-AE + x-default.

The fastest way to validate your current bilingual setup is to crawl your own site with Screaming Frog (free up to 500 URLs) and check the hreflang report. If anything's asymmetric, fix it before commissioning any new content. Or submit a brief and we'll audit it.

SEO for Bilingual Arabic + English Websites in 2026: A Technical Playbook from Inside a UAE Studio