Skip to main content
NewNMC’s advertising guidelines for doctors are in force from 6 Oct 2026. See what to change, and get a free compliance auditNew NMC advertising rules for doctors: what to change
SEO

Hreflang for India, UAE and Arabic: en-IN, en-AE and ar-AE Without Conflicting Signals

How to set hreflang for a healthcare site serving India and the UAE in English and Arabic: return tags, x-default, canonical conflicts and why Arabic needs its own content.

Hreflang for India, UAE and Arabic: en-IN, en-AE and ar-AE Without Conflicting Signals

This post is for the person responsible for the international setup of a hospital or clinic website that serves patients in India and the UAE, in English and in Arabic. If you have a separate section or domain for the Gulf market and you are not sure whether your hreflang annotations help or hurt, this is a working guide to getting them right.

Hreflang is simple to describe and easy to get wrong in practice. The rules fit in a paragraph. The errors come from large sites, template code, multiple language versions and a content team that treats the Arabic site as a translation of the English one. A hospital group with an English India site, an English UAE site and an Arabic UAE site has three versions of many pages, and every one of them must agree with the others.

We cover the rules from Google's documentation, the specific codes for this market mix, the four most common errors, how to audit an existing setup, and why the Arabic edition should be separate content, not a translated twin. This is guidance on implementation; the clinical, advertising and permit content on each page stays with your compliance owners.

The rules, from Google's documentation

Google's page on localized versions of your pages sets out the rules that matter:

  • Return links. If page A points to page B, page B must point back to page A. Otherwise the annotations may be ignored. The document says that if two pages do not both point to each other, the tags will be ignored.
  • Self-reference. Every version lists itself as well as the others, and the set of annotations is the same on each version.
  • Language and region codes. The first part is a language code (ISO 639-1), optionally followed by a region (ISO 3166-1 Alpha 2). A region on its own is not valid. Codes are case-insensitive.
  • x-default. Use it for a fallback page, such as a language or country selector, for users whose language or region does not match any of your versions.
  • Duplicates. Localized versions count as duplicates only if the main content stays untranslated. Fully translated pages do not.
  • Method. HTML link tags, HTTP headers and sitemap entries are equivalent to Google. Pick one, because using all three adds maintenance with no benefit.
  • Language detection. Google does not rely on hreflang or the HTML lang attribute to detect a page's language. It reads the content.

The codes for this setup

For a site with three live versions, a typical set is:

VersionExample URL pathhreflang value
English for India/in/ or the rooten-IN
English for the UAE/ae/en/en-AE
Arabic for the UAE/ae/ar/ar-AE
Fallback or selector/x-default

Some judgement is needed on each row.

Should you use region codes at all? Use a region code only if the content differs by region. English pages for India and the UAE that differ in doctors, phone numbers, currency, regulatory statements, prices, insurance and permits are legitimately regional versions. If the English content is identical, one English version without a region may be enough. Google notes that language-only codes suit content that is not region-specific, and that regional variants of one language benefit from a generic catch-all.

Is ar-AE the right code? If the Arabic page is written for the UAE audience, yes. If you also serve Saudi Arabia with a different edition, add ar-SA as its own version rather than reusing the UAE page. If you serve a pan-Arabic audience with one page, ar is acceptable. Do not invent codes such as ar-GCC; region must be a country code.

What should x-default be? The page that best handles a visitor you cannot classify. Options: a country and language selector, or the version most users should land on. Do not set x-default to a page that automatically redirects by IP address, because crawlers cannot follow a decision they cannot see. Keep it simple and static.

The four errors we see most

1. Missing or broken return tags

The English page lists the Arabic page, but the Arabic page does not list the English one, or lists a slightly different URL (trailing slash, http versus https, a parameter). Google's rules say the tags are then ignored. The cause is often template code that builds the alternate URLs from a mapping table that is incomplete for new pages.

2. Annotations pointing at non-canonical, redirected or non-200 URLs

Each hreflang target should be the final canonical URL of that version. Pointing it at a URL that redirects, that returns an error, or that canonicalises elsewhere sends mixed signals. Google also says it prefers URLs that belong to reciprocal hreflang clusters, so consistency among hreflang, canonical and sitemap helps.

3. Canonical tags that cancel the hreflang

If the Arabic page declares the English page as its canonical, you have told Google the Arabic page is a duplicate of the English one. Each language version should be self-canonical and listed in hreflang. A cross-language canonical removes the Arabic URL from consideration.

4. Mixed methods that disagree

Hreflang in the HTML for some pages, in the sitemap for others and in HTTP headers for PDFs gives three sources to keep in step. Google treats them equally, so pick one method for the whole site, and apply it by template.

Want this applied to your practice? Get a free seo audit.

Book my free audit

Why Arabic must be its own content

The single most expensive mistake in this market is treating the Arabic site as a translation of the English India site. There are four reasons it fails.

The content belongs to a different market. A UAE patient has different questions, a different regulatory context, different insurance and payment norms, and different hospitals as reference points. An Indian English page translated into Arabic describes a health system the reader is not in.

The search language is not translated English. People search in Gulf Arabic and Modern Standard Arabic, with different vocabulary for symptoms and services. Our post on Arabic SEO for clinics covers keyword research in the dialect rather than from translation, and we do not repeat it here.

Advertising and permit rules differ. UAE healthcare advertising is regulated by the emirate's health authority. For Dubai, the Dubai Health Authority publishes its requirements on advertising and permits through its own channels; check the current rules at dha.gov.ae and see our UAE healthcare marketing compliance page. Statements that are acceptable on an India page may not be acceptable on a UAE page, and the reverse. A translated twin carries the wrong claims across.

Hreflang is a poor way to link pages that are not equivalents. Hreflang says "these URLs are the same content for different audiences". If the Arabic page has different structure, examples and sections, the annotation should only connect true equivalents. Pages with no equivalent in the other language simply get no hreflang partner. It is better to leave the cluster incomplete than to point the English page at an unrelated Arabic page.

Write each Arabic page from its own brief: local search intent, local proof (such as licences and credentials relevant to the UAE), local contact routes and permits where applicable, and review by a native Arabic-speaking editor with healthcare knowledge. Then link equivalents with hreflang only where the pages serve the same purpose.

How to audit an existing setup

This is the method we use. It needs a crawler that extracts hreflang from HTML, headers and sitemaps.

  1. Crawl all versions. Include the English India, English UAE and Arabic UAE sections.
  2. Extract every hreflang annotation with its source page, the declared language-region and the target URL.
  3. Build a matrix of source page by target page. For each annotation A to B, check that B to A exists. List every failure.
  4. Check the targets. For every target URL, record status code, final URL after redirects, canonical URL and meta robots. Flag anything that is not 200, not self-canonical or noindex.
  5. Check self-reference. Each page should list itself.
  6. Check code validity. Look for region-only codes, underscores instead of hyphens, en-UK instead of en-GB, or invented regions.
  7. Check consistency of method. Is the annotation delivered by one method, or several?
  8. Check x-default. Is it set, the same on all versions, and a static page?
  9. Sample by eye. For ten pages, open each version and ask whether the pages are real equivalents.
  10. Read Search Console. Check the page indexing report for each version, and use URL Inspection to compare the user-declared and Google-selected canonical for a sample.

Record the result as an error list with counts by type. Fixes in the template are usually much cheaper than page-by-page edits, so group the errors by cause.

Sitemap implementation

For a large site, sitemap-based hreflang is easier to keep consistent than tags in each page's head. Google's documentation describes adding xhtml:link entries inside each url element, listing every variant including the page itself. Generate them from the same table that maps equivalent pages, and regenerate whenever a page is published, moved or removed. Keep the sitemap in a location that covers the URLs it lists, as the documentation requires.

A short checklist

  • Every version lists itself and every other version, and every pair is reciprocal.
  • Targets are final, canonical, 200 and indexable.
  • Each page is self-canonical.
  • One method of delivery, generated from one mapping table.
  • Region codes only where content differs by region.
  • x-default points to a static selector or default page.
  • Arabic pages written for the UAE audience, not translated from the India page.
  • Pages with no equivalent have no hreflang partner.
  • UAE advertising wording checked against the current regulator rules before publication.

For help with the wider multilingual structure, see our multilingual SEO service, and the post on the multilingual clinic website patient journey. The technical SEO audit includes an international review of the kind described above.

Filed underhreflang UAE India Arabichreflang en-AE ar-AEhreflang x-defaulthreflang return tag errorsArabic English healthcare website SEO

About the author

Co-Founder & CTO · Gurugram, India

Arush builds the systems the rest of the company runs on — the patient-acquisition pipelines, the AI chatbots, the analytics that tie a single click to a booked appointment. If a campaign reports a number, it's because something his team built is tracking it.

Free guide · 17 pages

The Patient Acquisition Blueprint

A 90-day plan from first search to booked appointment.

The Pioneers Brief — one essay, three benchmarks, one teardown, every Thursday. Subscribe free →

Free seo audit

Your next chapter starts with a conversation.

Three quick questions. We come prepared with a plan for your specialty and city.

  • A 30-minute call with a healthcare specialist
  • Your top three growth opportunities, in writing
  • Honest advice — even if that means not hiring us
  • No obligation and no hard sell
You’ll speak with a senior strategist
Consultations are hosted by Arush Thapar’s team.
Step 1 of 3Takes 30 seconds

What do you want to improve first?

Details stay privateNo obligationReply within 1 working day