Hreflang for UAE Websites: The Arabic–English Implementation Guide

Hreflang tells Google which language version of a page to put in front of each searcher. For most UAE websites, that means linking Arabic and English versions with `ar-AE`, `en-AE` and `x-default` values. This guide walks through the exact implementation: codes, placement options, code samples, validation, and the errors that quietly break the whole thing.

This guide comes from the RATH Infotech team, led by founders Sumeet Mehta and Manish Doshi. We work with businesses across Dubai and the wider UAE, and hreflang is one piece of the broader work covered on our technical SEO services page. Still, you can put it into practice yourself using the samples and checks below.

What hreflang is: and what it is not

Hreflang is a `rel="alternate"` annotation, placed in the HTML head, an HTTP header, or an XML sitemap, that names the language and region variants of a page so Google can serve the right one to each searcher. Each URL declares all of its alternates, including itself, and the annotations must point back at each other. Google treats it as a signal, not an absolute directive.

Here is the honest part most tutorials skip: hreflang is not a ranking boost. It does not lift a page higher in the results. What it does is make sure the correct language version appears for the right user, so your Arabic page shows to Arabic searchers instead of the English one ranking in its place. That improves click-through and user experience and prevents wrong-language pages competing with each other, but if you are hoping it will move you up the page on its own, it will not. Treat it as a targeting tool, not a growth lever.

Does your UAE website need hreflang?

Not every UAE site needs hreflang. Here's the test: do you have more than one language or country version of the same page? If not, skip it.

• Single language, single country (an English-only Dubai site, say): skip hreflang. Adding it to a one-version site just creates extra work and error risk, with nothing to show for it.
• Arabic and English versions of the same pages: use it. This is the standard UAE case, and the rest of this guide is written for it.
• Same language across more than one country (an English UAE site and a separate English Saudi site, for instance): you need hreflang here too, so each country gets served the right version.

If what you are actually deciding is whether to publish in Arabic, English or both, that strategy question is answered in our English vs Arabic SEO guide. This page assumes the bilingual decision is made and covers how to wire it up correctly.

Choosing the right codes: ar, ar-AE, en-AE and x-default

Hreflang values draw on two separate standards. There's the ISO 639-1 language code, things like `en` or `ar`, and then, optionally, an ISO 3166-1 alpha-2 country code such as `AE` for the United Arab Emirates. You can target just a language, or narrow it down to that language within a particular country.

The decision that matters most on a UAE site comes down to bare `ar`/`en` versus `ar-AE`/`en-AE`. Go with bare `ar` and `en` when each version needs to serve all Arabic or English speakers worldwide. Choose `ar-AE` and `en-AE` when the versions are built specifically for the UAE market, with other countries planned for later. Most UAE businesses that operate only in the Emirates are better off with the country-qualified set. It's the safer default, and it leaves room to expand across the GCC without reworking everything.

X-default is the fallback. It names the version shown to searchers who don't match any of your declared language/region pairs. It's optional, but recommended, on a typical UAE site, point it at the English version as the broadest catch-all.

Invalid codes are silent killers. `en-uae`, `en-dubai`, or a bare `ae`, none of these count as valid hreflang. The region unit has to be the country, written as a two-letter ISO code (`AE`). Not a three-letter name. Not a city, either. Google simply ignores anything invalid, and that quietly kills your targeting. You won't see an error in the browser to warn you.

Three ways to implement hreflang

There are three places hreflang can live: HTML `<link>` tags in the page head, HTTP response headers, or annotations inside your XML sitemap. Google treats all three as equally valid. What matters is this: pick exactly one method and don't mix conflicting sources. Contradictory annotations across methods are a common source of errors.

HTML head tags are the simplest route for a small bilingual site. A large catalogue calls for something else: the sitemap keeps every page light and gathers all the annotations in one spot. The HTTP header's only real use is hreflang on non-HTML files, like PDFs.

Content management systems don't all handle this the same way. Platforms like WordPress and Shopify, through their multilingual extensions, generate the tags automatically on some setups; on others, you're expected to add them yourself. Check what your particular stack actually outputs before assuming it's correct. Whichever way they're generated, the annotations still have to follow every rule below.

HTML head sample, an `en-AE` / `ar-AE` / `x-default` trio on the English page:

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

The Arabic page (`/ar/page/`) needs to carry those same three lines. That way the pair points back at each other, and each page references itself.

XML sitemap sample, the same pair, using `xhtml:link` entries:

<url>
  <loc>https://www.example.ae/page/</loc>
  <xhtml:link rel="alternate" hreflang="en-AE" href="https://www.example.ae/page/" />
  <xhtml:link rel="alternate" hreflang="ar-AE" href="https://www.example.ae/ar/page/" />
  <xhtml:link rel="alternate" hreflang="x-default" href="https://www.example.ae/page/" />
</url>
<url>
  <loc>https://www.example.ae/ar/page/</loc>
  <xhtml:link rel="alternate" hreflang="en-AE" href="https://www.example.ae/page/" />
  <xhtml:link rel="alternate" hreflang="ar-AE" href="https://www.example.ae/ar/page/" />
  <xhtml:link rel="alternate" hreflang="x-default" href="https://www.example.ae/page/" />
</url>

Note both URLs turn up as separate `<url>` entries, and each one carries the full set of alternates. That reciprocity is what makes the annotation valid.

Step-by-step: hreflang for a bilingual Arabic–English UAE site

This is the full process for the standard UAE setup: an English site paired with an Arabic version. The example uses an English URL alongside its Arabic counterpart, filed under an `/ar/` subfolder. That's the exact structure our Arabic SEO guide walks through in full.

The two spots where this usually breaks are step 4, where people forget the self-reference, and step 5, where the return tags go missing. Nail those two and everything after is just mechanical.

The rules that make or break it: return tags, self-reference, canonicals

Three rules decide whether Google honours your annotations at all.

Return tags must be bidirectional. Point the English page at the Arabic page, and the Arabic page has to point back. Skip that, and Google treats the annotation as broken, often ignoring the whole pairing. It's the single most common hreflang error you'll see reported: "no return tags."

Every page has to point back to itself. Each URL needs to list all of its alternates, and that list has to include the page's own address. Skip the self-reference and the cluster falls apart, it can't be trusted.

Canonicals have to stay within the same language. Each version points to itself: the English page's canonical is the English URL, and the Arabic page's canonical is the Arabic URL. Don't point one language's canonical at another language's URL. Do that, and you're telling Google to drop that version from the index entirely, which defeats the purpose of publishing it in the first place. Hreflang and canonical only work together when each sticks to its own job. Hreflang says here are the alternates. Canonical says this is the definitive version of this page.

Last, set `x-default` to point at whichever version best serves users who don't match any of your pairs. For a UAE site, that's usually the English page.

Beyond the UAE: hreflang across the GCC

Hreflang is also the tool to reach for when you're rolling the same language out across more than one GCC country. Say you launch an English page for Saudi Arabia to sit alongside your English UAE page, declare them as alternates of each other, `en-AE` and `en-SA`, and let each page's canonical point back to itself. That pattern holds as you add more markets: Qatar gets `en-QA`, Kuwait gets its own tag, and so does whatever GCC country comes next.

This is exactly the case where people reach for a canonical tag and get it wrong. Canonicalise the Saudi page to the UAE page, and the Saudi version drops out of search. Hreflang exists for precisely this reason: it lets near-identical country pages coexist, each one served to its own market.

A word of caution here: variants multiply fast. Pages times languages times countries grows combinatorially, and each new variant means more annotations you have to keep reciprocal and error-free. Only create a country variant when the content genuinely differs, different currency, offers, contact details or regulation. If two country pages would end up identical, you probably don't need the second one.

Common hreflang errors and how to fix them

Most hreflang problems don't show up on screen. The page looks fine in a browser, but the targeting fails without anyone noticing. Below are the errors that turn up in crawler reports, along with how to fix each one.

If a page isn't showing up in search results at all, rather than showing up with the wrong language, that points to an indexing problem, not hreflang. To sort that out, see our guide on why Google isn't indexing your site.

How to test and validate hreflang

Hreflang tags are easy to get subtly wrong, so check them rather than assume they worked. We use the full industry-standard stack to do it.

• Crawl the site. Screaming Frog reports hreflang clusters and flags missing return tags, invalid codes and non-reciprocal pairs. Ahrefs and Semrush site audits run the same hreflang checks and catch those same error classes on large sites.
• Check the live pages. Pull up view-source on a rendered page to confirm the head tags are there and correct. Or fetch your XML sitemap directly and confirm the `xhtml:link` entries resolve.
• Monitor in Search Console. Watch performance by country and query, and use that to sanity-check that the right versions are reaching the right audiences over time. Search Console's old International Targeting report was retired, so don't go looking for it. Validation now runs through crawlers and the performance reports, not a dedicated hreflang panel.

For crawl-and-index health checks beyond hreflang, see our technical SEO checklist.

Hreflang implementation checklist

Run this ten-point checklist before you consider a hreflang setup finished.

FAQ

Reviewed by the RATH Infotech team, led by founders Sumeet Mehta and Manish Doshi.