If your Arabic page keeps surfacing for English searches, the content is rarely the problem — the annotations are. Hreflang is a signal Google can disregard, usually for one of six reasons: the versions disagree about regions, a return tag went missing, a missing self-reference, a canonical points across languages, an annotation targets an unindexable page, or two tools publish conflicting tag sets. Find yours and fix the workflow that produced it.
The short answer: the six errors that make Google ignore your annotations — and the audit that finds them
Google's documentation sets the contract: every version must list itself and all other versions, alternate URLs must be fully qualified, and pages that do not point to each other are ignored. Break it, and Google chooses the version itself.
The six mistakes below break it most often on EN–AR sites. Work through them against one page pair first; the audit section gives the sequence.
The problem: two versions, one ranking — how conflicting signals split a bilingual site
An English page and its Arabic counterpart share one job: each serves its own searchers, and together they hold the topic's authority. That works only while every signal tells the same story — cluster, canonical and sitemap entry must agree on the versions and the region each serves.
When they disagree, Google disregards the annotations and picks a version, regardless of language. It looks like a ranking problem — the Arabic page appears for English queries, or the pair swaps places — but it is a signals problem, fixed at the annotation layer. For the wider structure, see our guide to SEO for bilingual Arabic–English websites.
Mistake 1 — region codes that disagree across page types (en-AE/ar-AE everywhere, even where they shouldn't be)
Language codes come from ISO 639-1 — ar and en — and region codes from ISO 3166-1 alpha-2 — AE, SA. A region code is a claim: this version is for searchers in that country. The mistake is stamping one pair on every page type regardless of target.
The pattern shows up when parts of a site are built at different times. Blog pairs get annotated en-AE/ar-AE throughout, while landing pages for a Saudi campaign correctly differentiate en-SA/ar-SA — or campaign codes leak into pages written for the UAE. Each page looks fine alone; together they tell Google the site has no consistent regional logic.
How it happens: codes are set per template, per plugin or per campaign, never in one place. The fix is a single code map — one document listing, per page type and market, which codes that pair carries. Where content is identical for all Arabic speakers, plain ar is the more honest code.
Mistake 2 — missing return tags after one version is edited or redesigned
Reciprocity is the rule Google states most bluntly: if page A names page B as its alternate, page B must name page A back, or the annotations are ignored. Return tags rarely break on launch day. They break months later, when one version is redesigned or rebuilt and the new template ships without the full cluster — while the other still points across, one-way.
The trigger is asymmetric maintenance: the English pages get the redesign, the Arabic pages follow later. Nothing looks broken, which is why it survives. The fix is procedural: any change to one version triggers a check of both, and the cluster is regenerated for the pair, not patched.
Mistake 3 — no self-referencing annotation
Each page must include an annotation pointing at itself, alongside every other version's annotations. It feels redundant, so templates drop it — especially on the default-language version.
Google's guidance is explicit: each version must list itself and all other versions. Check each version's source and confirm its URL appears in its own set.
Mistake 4 — canonicals pointing across languages
A canonical tells Google which URL is authoritative. When the Arabic page's canonical points at the English page, it tells Google the Arabic page is a duplicate of the English one. Hreflang says "a separate version for Arabic searchers"; the canonical says "not a separate page at all". Google resolves the contradiction, and the Arabic version can drop from the index.
Each language version should canonicalise to itself, and its self-referencing hreflang URL should be that same canonical URL.
Mistake 5 — annotations pointing at redirects, 404s and noindexed pages
An annotation is a promise that a specific URL is a live, indexable alternate. Annotations pointing at URLs that redirect, return a 404, or carry a noindex break that promise. Stale annotations accumulate quietly: a page is renamed and the redirect works for visitors, so nobody updates the cluster; a version is withdrawn but its partners keep naming it.
Audit the targets, not the tags: load every URL in the cluster directly — it should return success, be the final URL and be indexable. When a version moves, update every member in the same release, and remove annotations for versions that no longer exist.
Mistake 6 — head and sitemap annotations generated by two tools that disagree (plus a missing x-default)
Hreflang can be declared in the HTML head or in the XML sitemap; both are valid. What breaks sites is both at once, from tools that do not know each other: a multilingual plugin writes the head tags while an SEO plugin writes sitemap annotations, and the sets differ — different codes, different URLs, one updated and the other frozen.
Choose one source of truth and disable the other. Then check the fallback: with no x-default, Google guesses which version unmatched searchers see. Point it at the version you want them to land on — commonly the English page or a language selector. The surrounding architecture is covered in our multilingual website architecture guide.
The audit: check a page pair end-to-end in the right order (checklist/table)
Audit one representative pair first, then repeat per page type. Work in this order — each step can invalidate the next:
| Step | Check | Pass looks like |
|---|---|---|
| 1 | Load both URLs directly | Both succeed, no redirect, indexable |
| 2 | Compare the annotation sets on both pages | Identical clusters, same codes, same URLs |
| 3 | Self-reference | Each page names its own URL in its own set |
| 4 | Return tags | Each version names the other, both ways |
| 5 | Region codes | Codes match the code map for that page type and market |
| 6 | Canonicals | Each version canonicalises to itself and matches its hreflang URL |
| 7 | Source of truth | Annotations exist in head or sitemap only, and the sets agree |
| 8 | Fallback | One x-default points at the intended unmatched-searcher page |
If the pair passes, sample one pair per template and record results against the code map. For ongoing search work around the fixes, our SEO services in the UAE page explains what that support covers.
Fixing without recurrence: one annotation source, one code map, one check after every template change
Every mistake above is a recurring workflow with a one-off symptom; fix the tags alone and the errors return after the next redesign. Three habits prevent that. One annotation source: a single process owns hreflang output, and anything else is switched off. One code map: the region decision per page type is written down once, so a new campaign inherits it. One check: the eight-step pair audit runs after every template, plugin or sitemap change. Build-side structure decisions are scoped in our multilingual website development guide, and the Arabic page itself should pass an Arabic RTL website checklist.
Common mistakes (beyond the six: relative URLs, annotations for untranslated pages, IP-forced language redirects)
Three further errors appear regularly. First, relative URLs: annotations must be fully qualified, including the protocol — /ar/page/ is not a valid target. Second, annotations for untranslated pages: an entry for an unwritten version sends Google to a page that cannot serve that searcher — only annotate versions that exist. Third, IP-forced language redirects: redirecting by location prevents each version being reached at its own URL. Offer a language switcher instead.
FAQ
How do I audit hreflang errors in Search Console?
Search Console no longer provides a dedicated hreflang error report, so audit in two layers: use URL Inspection on individual pages to confirm indexability and see the canonical Google selected, then crawl the site or inspect page source to compare annotation sets across each pair, in the order the audit above sets out.
Should I use en-AE and ar-AE, or just en and ar?
Use a region code only where the page genuinely targets that country — a different offer or content for the UAE versus Saudi Arabia. Where one version serves all speakers of the language, the language-only code is the more accurate claim. What matters most is consistency: one decision, from one code map, across every page type.
What should x-default point to on a bilingual website?
Point it at the page you want shown to searchers whose language and region match none of your annotations — often the English version, or a language-selector page. It is a fallback, not a duplicate of a regional version, and every cluster should carry exactly one.
Can hreflang point to a redirected or noindexed page?
No. Every URL named in a cluster should be the final, live URL: it must load successfully without redirecting, and be indexable. Annotations pointing at redirects, error pages or noindexed URLs can cause the whole cluster to be disregarded.
Why does Google show the wrong language version even though my tags look right?
Because hreflang is a signal, not a directive. If any part of the cluster conflicts — a cross-language canonical, a missing return tag, codes that disagree between head and sitemap — Google can disregard the annotations and choose a version itself. Audit the whole pair, not just the page you edited.
Get your bilingual site's annotations and structure audited (CTA)
If your English and Arabic versions are splitting each other's rankings, send us one affected page pair. We will check its annotations end to end and tell you which of the six mistakes you have — and whether the fix is annotation hygiene or a structural rebuild. Where the architecture needs rebuilding, our web development in the UAE team scopes it, with an itemised proposal within 24 business hours.
