Your Arabic pages are written for Saudi customers, your prices and delivery terms are Saudi — yet Riyadh searchers keep landing on your UAE or global English version, or the Saudi pages barely appear at all. Before blaming the content, audit the annotation: on Saudi bilingual sites the cause is usually one of five hreflang cluster errors, fixable in a specific order. This is the English technical treatment for the team shipping the fix; Arabic-reading owners have a companion guide to hreflang mistakes on Saudi websites.
The short answer: the five Saudi cluster errors, in the order to check them
One, a single Arabic URL tagged to serve every Arab market, so Saudi intent has no home. Two, broken pairs — missing return tags or self-references — which Google documents as grounds to ignore the annotations. Three, hreflang pointing at redirects, parameter URLs or noindexed pages. Four, canonicals that contradict the cluster, most often an Arabic page canonicalising to its English twin. Five, an x-default that routes Saudi visitors to a global English page.
First decide: does Saudi Arabia need its own pair at all? (ar vs ar-SA, en vs en-SA)
Hreflang values combine an ISO 639-1 language code with an optional ISO 3166-1 Alpha-2 region code — ar-SA means Arabic targeted at Saudi Arabia. Google treats the region code as a targeting choice, not a quality upgrade. Use plain ar and en when one Arabic and one English version serve every market with the same offer. Give Saudi Arabia its own pair — en-SA and ar-SA, each on its own URL — when the Saudi version differs in ways a searcher cares about: pricing, mada and local payments, delivery areas and times, or Saudi-specific legal and service content. If the pages do not differ, regional tags add maintenance without targeting. The wider choices sit in our multilingual website architecture guide.
Error 1 — One Arabic URL asked to serve every Arab market
The symptom: the same /ar/ page ranks weakly in Saudi Arabia, the Emirates and Egypt at once, and Google keeps substituting another version for Saudi queries. The cause is structural — one Arabic URL tagged ar, or worse tagged for several regions at once, is asked to carry different prices, delivery promises and service areas that live nowhere on the page. The fix: publish a genuine Saudi Arabic URL with Saudi content, tag it ar-SA, pair it with its en-SA twin, and keep other-market Arabic pages in their own pairs. Do not simply retag the shared URL ar-SA — that mislabels a generic page as Saudi. For general pair mechanics, our general guide to hreflang mistakes on English-Arabic websites is the reference; this clinic stays on the Saudi layer.
Error 2 — Broken pairs: missing return tags and missing self-references
Google documents two non-negotiable rules: every page in a cluster must reference itself, and every alternate must link back to every other alternate — if page A names page B, page B must name page A, or Google may ignore the pair (the classic return-tag error). On Saudi sites this breaks quietly: a template prints the block on English pages but a translated template omits it, or a new Saudi page joins one version's annotations and nobody updates the others. The fix is mechanical — generate the block from one source of truth (a page-pair map), print it identically on every cluster member including the x-default entry, and re-check after template changes. No page ships unless its own URL appears in its own block.
Error 3 — Hreflang pointing at redirects, parameters and noindexed pages
Every URL named in a hreflang annotation should be a live, crawlable, indexable page returning a 200 status. Saudi clusters routinely violate this after years of edits: annotations naming old URLs that now redirect, campaign URLs with tracking parameters, staging duplicates, and noindexed pages. Google documents that alternates must be fully qualified URLs, and conflicting signals lead it to disregard the annotations. Audit by extracting every hreflang target and testing each: status 200, no redirect chain, self-canonical, indexable. Replace each bad target with the final URL or remove the alternate.
Error 4 — Canonicals that contradict the cluster
A canonical tag tells Google which URL is the master version; hreflang tells it the pages are regional and language peers. When an Arabic page canonicalises to the English original — a common leftover from translation plugins and template defaults — the signals contradict, and Google generally follows the canonical: the Arabic page is treated as a copy and can drop out of the index, leaving the cluster nothing to swap in. The rule from Google's canonicalisation documentation: each version canonicalises to itself, and hreflang targets must be canonical URLs. Audit canonicals across the whole cluster, and check rendered output after platform updates, because plugins regenerate these tags silently. The visible right-to-left layer is covered by our RTL website design checklist.
Error 5 — x-default sending Saudi visitors to the wrong home
The x-default value names the page for searchers whose language and region match none of your alternates. Saudi sites often set it to a global English homepage — defensible for the rest of the world, harmful when it becomes the de facto landing page for unmatched Saudi traffic, or points at a language selector outside the cluster. Decide deliberately: if you run a genuine country/language selector, x-default can point there; otherwise point it at the version you would show a first-time visitor with no detectable preference, and make sure Saudi-matched users are covered by the en-SA and ar-SA alternates so x-default is rarely their outcome. Include the x-default entry in every member's block, at the same URL everywhere.
HTML, sitemap or headers: where your platform should carry the tags
Google accepts three equivalent methods: link elements in the HTML head, an XML sitemap carrying the alternates, or HTTP Link headers — used mainly for non-HTML files such as PDFs. In practice, template-driven sites usually carry tags in the head, generated by the CMS or a multilingual plugin; large catalogues are easier to keep consistent in the sitemap, where one file shows the whole cluster at a glance. What matters is not the method but singularity — pick one method per page set and keep it complete, because two methods that disagree recreate the contradiction problem. On hosted platforms, verify what the platform generates before adding your own layer: some store builders emit their own annotations, and hand-added tags can conflict.
Validate the repair: crawl the cluster and read Search Console like an auditor
Validate in three passes. First, crawl the bilingual sections and export every page's hreflang set: check self-reference, reciprocity, valid codes (language first, hyphen, no country-only values), and that every target passes the Error 3 tests. Second, use Search Console's URL Inspection on representative en-SA and ar-SA pages to confirm Google selected the page itself as canonical and indexed it; Google retired the old dedicated hreflang report, so the crawler export is now your error list. Third, watch the Performance report filtered by page and country: Saudi queries should land on Saudi URLs. A structured technical SEO audit runs this site-wide.
After any migration or platform move: re-check the whole cluster
Migrations regenerate everything hreflang depends on: URLs, templates, canonicals and sitemaps. Moving platforms, switching a translation plugin, or relaunching with new templates can silently revert a correct cluster to plugin defaults — English canonicals everywhere, pairs pointing at pre-move URLs, the Saudi pair dropped entirely. Put the cluster in the migration checklist: freeze the page-pair map before the move, regenerate annotations against the new URLs, and re-run the validation crawl in the first week after launch. The broader programme is covered in our guide to SEO for bilingual Arabic-English websites.
Common mistakes
Beyond the five errors: underscores instead of hyphens in codes; invented codes, such as a country value with no language; tagging pages that are not true equivalents; region codes on pages identical across markets; and assuming the visitor's language switcher relates to the annotations Google reads.
FAQ
Should we use ar or ar-SA for our only Arabic version?
Use plain ar if that single Arabic version serves all markets with the same offer. Reserve ar-SA for a distinct Saudi Arabic URL whose content — pricing, payments, delivery, service terms — genuinely differs. A region code on a generic page promises a Saudi version that does not exist.
What is a return-tag error and why does it matter?
It is the missing half of a pair: page A names page B as its alternate, but page B does not name page A back. Google documents that alternate links must be reciprocal; without the return tag it may ignore the annotation, so the wrong version can keep showing for Saudi searches.
Can hreflang alone fix wrong-language rankings?
No. Hreflang is a hint that connects equivalent pages; Google weighs it alongside the content and other signals on the pages themselves. Thin or machine-translated Arabic will still underperform. The tags decide which version is eligible to be shown — the page still has to deserve the position.
Our Arabic page canonicalises to the English page. What breaks?
Google generally treats the Arabic URL as a duplicate of the English one and may not index it at all. The cluster then has no Arabic member to swap in for Saudi searchers. Fix it by making every version self-canonical and confirming the tags in the rendered output.
Do we need to redo hreflang after moving platforms?
Yes. A platform move changes URLs, templates, canonicals and sitemap output at once, and builders and plugins apply their own defaults. Rebuild the page-pair map on the new URLs and re-validate the whole cluster in the first week after launch.
Get your Saudi cluster audited end to end (CTA)
If your cluster has grown across templates, plugins and a platform move, untangling it page by page is slow work — and every week it stays broken, Saudi searchers keep meeting the wrong version of your business. Our SEO services for Saudi Arabia include a full cluster audit: code decisions, pair integrity, canonical conflicts and validation, fixes sequenced by impact. Sites being rebuilt can align the work with our web development for Saudi Arabia team.
