Hreflang for Arabic/English UAE Sites: Implementation Guide

hreflang is an HTML attribute that tells Google which language-and-region version of a page to show to which searcher. On a bilingual UAE site with English (/en/) and Arabic (/ar/) pages, correct implementation means every page lists itself plus every alternate version — using ar-AE and en-AE codes, generic ar/en catchalls, and an x-default fallback — with return links in both directions. Google ignores annotations that break these rules, so a wrong hreflang setup is the same as having none at all.

What hreflang actually does (and what it doesn't)

hreflang connects equivalent pages in different languages or regions. It tells Google "these pages are localized variations of the same content," so Search can point users to the most appropriate version by language or region. Google can sometimes find alternate versions on its own, but explicitly indicating them is the recommended approach.

Just as important is what hreflang does not do:

• It does not translate your content. You still build the real Arabic and English pages; the tags only connect them.
• It does not redirect visitors. An Arabic user who lands on your English page through a direct link stays there — hreflang only influences which version appears in search results.
• It does not guarantee a result. Google treats hreflang as a signal for selecting which version to show, not a binding directive.
• It does not replace canonical tags. Canonical and hreflang serve different purposes and usually work together (more on this in the mistakes checklist).
• It does not detect page language. Google states it does not use hreflang or the HTML lang attribute to detect a page's language — its algorithms determine that independently.

Localized versions are only considered duplicates if the main content remains untranslated. A fully translated Arabic page is not "duplicate content" of its English equivalent — which is why the canonical↔hreflang relationship needs care rather than fear.

Why UAE bilingual sites get this wrong

The typical UAE setup is two versions of every page — /en/ and /ar/ subdirectories, or en. and ar. subdomains. When it breaks, it breaks in two predictable ways:

Failure 1: Google shows the English page to Arabic users. Almost always a return-link problem. The English page points to the Arabic page, the Arabic page points back to nothing — and Google ignores the entire annotation set.

Failure 2: the Arabic page never surfaces at all. Usually a canonical problem. In an effort to "clean up" perceived duplication, someone sets the Arabic page's canonical to the English URL. Google takes that as "this Arabic page isn't worth indexing on its own" — and drops it, leaving the hreflang tags with nothing valid to swap in.

Three Google-documented facts make the UAE case harder than most:

1. URL structure tells Google nothing. The en/ar in your URLs is not used by Google to determine a page's target audience. You must explicitly map it with hreflang.
2. Googlebot mostly crawls from the US, without an Accept-Language header. If your site geo-redirects visitors or hides Arabic content behind language detection, Google may never see your Arabic pages.
3. Don't auto-redirect users either. Google warns that automatic redirection based on perceived language can prevent users and search engines from viewing all versions of your site. Offer a visible language switcher; let people choose.

The correct hreflang code set for a UAE site

The value is built from an ISO 639-1 language code plus an optional ISO 3166-1 Alpha 2 region code. For a UAE bilingual site, the complete set:

Four rules from Google's documentation govern the codes:

• Case doesn't matter to Google, but convention does. ar-AE and ar-ae are both valid; formatting the region in uppercase follows the ISO standard and makes audits easier.
• A language code can stand alone; a region cannot. ar is fine. A region-only value is invalid — and watch out for the trap: ae is a valid ISO 639-1 code, for the Avestan language. Writing hreflang="ae" thinking it targets the UAE tells Google the page is in Avestan.
• Cities are not regions. ar-dubai means nothing to Google — the ISO 3166-1 code is the country (AE), full stop.
• uk is not a country code. The ISO code for the United Kingdom is GB. Reserved codes like EU, UN, and UK are ignored by Google in hreflang annotations.

If you also serve Saudi Arabia or other GCC markets, add their regional variants (ar-SA, en-SA) to the same set — Google explicitly recommends pairing regional pages with a generic language catchall.

The complete HTML block for an AR/EN UAE site

Google supports three equivalent methods — HTML <link> tags, HTTP Link headers, and XML sitemaps. There is no Search benefit to using more than one. For most bilingual UAE sites, HTML tags are the simplest. The identical block goes in the <head> of every version of the page — each version lists itself plus all alternates.

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

Note that the generic ar catchall can point at the same URL as ar-AE — Google's documentation allows the catchall to be one of the specific pages. The tags must sit inside a well-formed <head>; don't combine hreflang with other attributes (like media) in a single link tag. For non-HTML files such as PDFs, use the HTTP header method instead — same values, same bidirectional requirement.

Checklist: 7 common hreflang mistakes on bilingual UAE sites

Work through these in order — each one alone can silently void your entire setup.

• 1. Missing return links. If the English page lists the Arabic page but the Arabic page doesn't list the English one back, Google ignores the annotations. Google names this the first common mistake for a reason: it is the failure we see most on Dubai audits.
• 2. No self-referencing tag. Every page must include an hreflang entry pointing to itself, plus all other versions. A page that lists only its alternates has an incomplete set.
• 3. Using ae (or any region) alone as a language code. Specifying the region without a language is invalid — and ae reads as Avestan, not the UAE. Always pair language + region: ar-AE, en-AE.
• 4. Canonical pointing at the other language's URL. Canonical consolidates duplicates; hreflang differentiates versions. Each language page must canonicalize to itself — pointing the Arabic page's canonical at the English URL tells Google to drop the Arabic page entirely.
• 5. Relative URLs in hreflang. Alternate URLs must be fully qualified: https://example.com/ar/, not /ar/ and not //example.com/ar/. Relative paths are ignored.
• 6. Mixing all three methods with conflicting data. Google says the three implementation methods are equivalent and that using more than one brings no Search benefit. If your sitemap says one thing and your <head> says another, crawlers see conflicts.
• 7. Auto-redirecting visitors by language or location. Geo-redirects hide your Arabic pages from a crawler arriving from the US with no Accept-Language header. Put a clear language switcher in the header instead; our guide to bilingual Arabic/English SEO covers the on-page side of this.

How to verify your hreflang implementation

Google removed the old Search Console International Targeting report (which included hreflang errors) in 2022, so there is no native hreflang report anymore. Verify manually instead:

1. Test a single live page with Merkle's hreflang tag testing tool — Google links to it from its own documentation.
2. Rebuild the block with Aleyda Solis's hreflang tags generator (also linked from Google's docs) and diff it against what's on your site.
3. Crawl the whole site with Screaming Frog or Semrush and flag missing return links, invalid codes, and alternates that redirect or 404 — return-link errors only show up in a full crawl.
4. Inspect each language URL in Search Console — confirm the Arabic and English versions are each actually indexed, not merely annotated.
5. Re-crawl after every site change. hreflang drifts as pages are added, moved, or redirected; stale alternates pointing at redirects are a classic post-redesign failure.
6. Spot-check in a browser with the language set to Arabic, signed out — confirm Google serves the Arabic URL. If it doesn't, work the checklist top-down.

Don't forget the Arabic page itself

hreflang only routes traffic — it doesn't make the Arabic page rank. Pair the tags with <html lang="ar" dir="rtl">, a visible language switcher linking to each alternate, and — critically — separate Arabic keyword research, not translated English keywords. Arabic search demand in the UAE is its own keyword landscape, often less competitive than the English equivalent.

If you're rebuilding rather than patching, build the bilingual structure properly from the start: locale-aware routing, content separation per language, mirrored RTL CSS, and separate SEO metadata per version — the way a specialist website development company in Dubai ships bilingual builds. Our multilingual website architecture guide covers the URL-structure decisions hreflang depends on. And if you'd rather have someone validate the whole thing, a technical SEO audit that checks hreflang bidirectional pairing is the systematic route.

Frequently asked questions

What is the correct hreflang code for Arabic in the UAE?

ar-AE — ISO 639-1 language code ar (Arabic) plus ISO 3166-1 Alpha 2 region code AE (United Arab Emirates). Use a plain ar as the catchall for Arabic speakers outside the UAE. Never use ae on its own: it is not a valid region-only value, and as an ISO 639-1 code it actually means the Avestan language.

Do I need hreflang if my site only has English and Arabic?

Yes, if the two languages live on different URLs — which Google recommends over serving both from one URL via cookies or browser detection. Without hreflang, Google has to guess which version suits each searcher and often guesses wrong. If both languages are served from a single dynamically-switching URL, hreflang can't help — restructure to separate URLs first.

Does hreflang replace the canonical tag?

No — they do different jobs. Canonical consolidates duplicate pages; hreflang differentiates localized versions of the same content. Keep both: each language page should canonicalize to itself while carrying hreflang links to all its alternates. Pointing a language page's canonical at a different language's URL tells Google the page isn't worth indexing on its own.

Why is Google showing my English page to Arabic users?

The usual causes, in order of likelihood: missing return links (the Arabic page doesn't link back, so Google ignores the annotations); a canonical pointing the Arabic page at the English URL (Google drops the Arabic page); hreflang on pages that aren't indexable; tags injected by JavaScript or placed outside the <head>; or no x-default fallback. Work the 7-point checklist above top-down.

Should I add hreflang to every page, or just the homepage?

Every page that has an equivalent in the other language. Annotate page pairs — each Arabic/English URL pair gets the full tag set — not just the homepage. The homepage is the most visible failure, but services, pricing, and contact pages are where mismatched language delivery costs you enquiries.

The bottom line

hreflang is a small tag with an unforgiving spec: self-reference every page, link both directions, use valid ISO codes and fully qualified URLs, and pick one implementation method. Get those right and Google can finally route Arabic searchers to your Arabic pages and English searchers to your English ones — the entire point of building a bilingual site.

Start with one page pair: paste the block above into both <head> sections, confirm both URLs are indexed in Search Console, and run the verification steps. Then roll the pattern across the site — or hand the audit to someone who checks hreflang bidirectional pairing for a living.