Arabic & RTL Technical SEO: A Practical Guide

RTL SEO is the technical work that lets an Arabic, right-to-left version of your site rank beside the English one: a same-domain /ar/ subfolder, reciprocal ar-AE and en-AE hreflang, correct lang and dir attributes on every template, layouts mirrored with CSS logical properties, and Arabic fonts that load without shifting the page.

Most Arabic versions we audit in Dubai, Abu Dhabi and Sharjah do not fail on the writing. They fail on plumbing: a canonical tag that still points to English, hreflang that only runs in one direction, a breadcrumb that reads backwards, or a font file heavy enough to drag the mobile experience down. This guide covers that plumbing, decision by decision.

Subfolder, subdomain or ccTLD: where should the Arabic version live?

For most UAE businesses the Arabic version belongs in a subfolder on the same domain, such as example.ae/ar/ beside example.ae/en/ or an English root. Both versions serve the same country, so the split you are signalling is language, not market, and a subfolder keeps authority, crawl budget and reporting in one place.

Law firms are a clear case for getting Arabic right, because onshore proceedings run in Arabic and clients search in both languages. See legal SEO in the UAE for how practice-area pages should handle the two.

Arabic pages matter beyond Google: an assistant answering in Arabic can only draw on Arabic sources. Our guide to how UAE businesses get cited by ChatGPT and other AI assistants looks at usage data and what makes a page citable.

The three options behave differently once you run them for a year. A subfolder inherits every link the domain already has, shares one CMS release cycle with the English site and sits inside one Search Console property, so a template fix ships to both languages at once. A subdomain such as ar.example.ae is technically valid, and Google handles it well enough, but in practice it tends to become a separate installation with its own plugins, its own sitemap and its own backlog, and the Arabic side drifts behind. A second ccTLD for Arabic alone is the weakest choice: a country-code domain signals a country, and your Arabic and English audiences are in the same country.

• Subfolder (/ar/): shared authority, one deployment, one property; the default recommendation.
• Subdomain (ar.): acceptable when the Arabic site genuinely runs on different infrastructure, such as a separate commerce platform; budget for keeping parity.
• Separate domain: only when a legal entity or brand is truly separate; never as a way to “target Arabic”.
• Query-string or cookie switching: avoid; Google needs a distinct, crawlable URL for each language version.

Two edge cases come up often. If you already trade on a .ae domain, keep it and add /ar/; the country signal is already correct. If you also sell into Saudi Arabia or wider GCC markets, decide whether your Arabic pages are UAE-specific (prices in AED, UAE delivery, emirate-level service areas) or pan-Arab before you choose the folder name, because that choice drives the hreflang values in the next section. The market-level architecture is covered on our UAE SEO hub; here we stay at template level.

Hreflang for ar-AE, en-AE and x-default: the rules that break most often

Hreflang tells Google which language and regional version to show each searcher, and it only works when every version lists itself and every alternate, and every alternate lists it back. For a bilingual UAE site that means each page carries ar-AE, en-AE and an x-default, with matching return tags on the other side.

Google Search Central’s guide to localized versions of your pages is precise about three things. Each version must include a self-referencing annotation as well as the alternates. If two pages do not point to each other, the annotations are ignored. And the language code comes first: ar-AE is valid, ae on its own is not, because a region cannot be specified without a language. The same page also notes that Google does not use hreflang or the HTML lang attribute to detect a page’s language; it works that out from the content. Hreflang chooses between versions, it does not make a page count as Arabic.

• Self-reference: the Arabic page lists ar-AE pointing to its own URL, not only the English alternate.
• Return tags: if the English page lists the Arabic URL, the Arabic page must list the English URL, exactly as it appears in the canonical.
• x-default: point it to the version you want unmatched visitors to see, usually English or a language selector.
• Canonical alignment: every URL referenced in hreflang must be the canonical, indexable, 200-status version of itself.
• One method per site: HTML head, XML sitemap or HTTP headers; mixing them multiplies the ways they can disagree.

The most damaging mistake is not hreflang at all but the canonical beside it. When the Arabic page carries a canonical pointing to the English URL, Google is being told the Arabic page is a duplicate, and the hreflang pair collapses. Each language version should be canonical to itself. If you want Arabic speakers outside the UAE to reach the same pages, you can add a broad ar value to the same Arabic URL alongside ar-AE, but only when the content genuinely makes sense for them.

dir, lang and CSS logical properties: building a layout that mirrors

An Arabic page needs <html lang="ar" dir="rtl"> on the root element, and a stylesheet written with logical properties so the layout mirrors from that one attribute. Hard-coded left and right values are what produce half-mirrored pages, where the text runs right to left but the icons, gutters and menus still behave as English.

The W3C Internationalization guidance on structural markup and right-to-left text recommends declaring direction in markup with the dir attribute rather than relying on the CSS direction property, because direction is a property of the content, not of its styling, and must survive if a stylesheet fails to load. The same principle applies to the CSS unicode-bidi property: leave it alone unless you know exactly why you need it. A stray unicode-bidi: bidi-override copied from an old theme will force characters into visual order and scramble Arabic words.

Logical properties do the mirroring for you. Replace margin-left with margin-inline-start, padding-right with padding-inline-end, left: 0 with inset-inline-start: 0 and text-align: left with text-align: start. Flexbox and grid already follow the writing direction, so most of the remaining work is in absolutely positioned elements, background images and icons.

Mixed-direction strings need their own treatment. A price such as AED 1,250, a Latin-script brand name inside an Arabic sentence, or a phone number starting +971 can jump to the wrong side or pull punctuation with it. Wrap each of these in the bdi (bidirectional isolate) element, or a span with its own dir, so the browser lays it out independently of the text around it.

Arabic web fonts without the performance penalty

Arabic fonts are heavier than Latin ones because each letter has several contextual forms and the font carries the shaping rules that join them, so an unoptimised Arabic webfont is often the largest asset on the page. Subset it carefully, choose a font-display strategy deliberately, and match fallback metrics so the swap does not shift the layout.

The web.dev best practices for fonts cover the core techniques: serve WOFF2, limit the number of weights, preload only the font used above the fold, and use font-display to control what happens while the file downloads. For Arabic, two refinements matter. First, subset by script with unicode-range, so English pages never download Arabic glyphs and Arabic pages load the Latin subset only when they need it, but never strip the OpenType shaping tables; a subset that loses them renders letters unjoined, which is unreadable. Second, Arabic typefaces usually have taller ascenders and deeper descenders than the system fallback, so a late swap changes line heights across the whole page. The descriptors size-adjust, ascent-override and descent-override on the fallback @font-face close most of that gap.

Measure the Arabic templates separately. A site whose English pages pass Core Web Vitals can have Arabic pages that fail, purely because of font weight and layout shift, and the two templates often share one report in analytics. Our technical SEO services for UAE businesses treat each language version as its own performance baseline for exactly this reason.

Arabic slugs, structured data and the search signals around them

Use readable Arabic slugs for Arabic pages when your CMS, analytics and sharing workflows handle them cleanly, and transliterated or English slugs when they do not. Google accepts both; what hurts is inconsistency, broken encoding, and structured data that describes a different language from the visible page.

Google’s URL structure guidance uses an Arabic example and recommends percent-encoding non-ASCII characters in the links you publish. Browsers display the decoded Arabic, but analytics exports, CRM fields, spreadsheets and some messaging previews show the long encoded string, which makes reports hard to read and links hard to share. Our recommendation for most UAE businesses is Arabic slugs on editorial and category pages, where the words help searchers recognise the result, and short stable identifiers on product and system URLs. Whatever you choose, never change slug style after launch without redirects.

Structured data should agree with the page it sits on. Set inLanguage to ar-AE on the Arabic WebPage or Article entity, write breadcrumb names in the same Arabic the visible breadcrumb shows, and keep the Organization entity identical across languages, using alternateName for the Arabic trading name rather than creating a second organisation. Mismatched names across language versions weaken the entity signals you want Google to consolidate.

A brief note on search behaviour, which a separate article will cover in depth. Arabic words take many forms through prefixes and attached pronouns, searchers rarely type diacritics, and UAE queries mix Modern Standard Arabic with Gulf (Khaleeji) vocabulary and English loanwords. For the technical layer, the implications are simple: do not rely on diacritics in titles or slugs, make on-site search normalise letter variants, and give your Arabic writers keyword research built from Arabic queries rather than translated English ones.

Decisions at a glance, and the RTL launch sequence

An Arabic launch goes smoothly when the architectural decisions are made once, written down and applied to every template before content goes in. The table summarises the recommendations above; the sequence below is the order we use to put them live without exposing half-built pages to Google.

1. 1
   Freeze the architecture

   Confirm the folder, hreflang values, x-default target and slug policy in one document signed off by marketing and development.
2. 2
   Refactor templates to logical properties

   Convert left and right values, add the dir and lang switch to the root element, and build the mirroring list for components.
3. 3
   Stage with noindex and real Arabic copy

   Load content from your Arabic writers into staging, never placeholder or machine-translated text, and review every template in both directions.
4. 4
   Wire hreflang, canonicals and sitemaps

   Generate annotations from the CMS relationship between pages, not by hand, so each pair stays reciprocal as pages are added.
5. 5
   Launch in sections and inspect

   Release section by section, remove noindex, submit the sitemap and inspect a sample of Arabic URLs in Search Console before the next release.

Testing checklist and the failures we see most

Test an Arabic version in both directions, on real devices, with the same rigour as the English launch, and keep testing after launch because CMS updates regularly undo RTL fixes. The checks below cover markup, rendering, indexing and performance; most take minutes once they are part of release routine.

• ✓
  Lighthouse on Arabic templates

  Run it on mobile for each Arabic template; the accessibility audits confirm a valid lang attribute, and the performance audit exposes font weight and layout shift.
• ✓
  URL Inspection on sample pages

  Check that Google sees the Arabic page as canonical to itself and renders it as users see it.
• ✓
  Hreflang reciprocity crawl

  Crawl both language versions and flag any annotation without a return tag, a non-200 target or a non-canonical URL. The legacy International Targeting report in Search Console has been retired, so a crawler does this job now.
• ✓
  Visual review in both directions

  Check headers, menus, breadcrumbs, forms, carousels and checkout on a phone and a desktop, in Arabic and English.
• ✓
  Mixed-string spot checks

  Prices, phone numbers, emails, model numbers and Latin brand names inside Arabic sentences.

The failures repeat across sectors. Auto-translated pages, generated by a plugin on the fly, publish text no native reader would write, and Google’s spam policies name automated translation used to mass-produce pages as scaled content abuse. Machine-translated duplicates, where the Arabic URL carries English text or a partial translation, compete with the English page instead of complementing it. Mixed-direction breadcrumbs, with Arabic labels but left-pointing separators in English order, confuse users and the breadcrumb markup alike. And the canonical to English, covered above, silently removes whole sections.

For the wider technical foundations these checks sit on, from crawlability to Core Web Vitals, work through our technical SEO checklist for UAE websites, and see how structured fixes have translated into results on our UAE case studies page.

Frequently asked questions