Complete reciprocal clusters built only from eligible, genuinely equivalent pages, published by one approved emitter, and verified in the rendered result.

Hreflang breaks down when teams connect pages that are not equivalent, annotate ineligible URLs, omit return links, or allow several systems to publish different clusters. Adding more tags will not fix an unclear locale model.

We build complete reciprocal clusters from eligible, equivalent pages, publish them through one controlled source, and verify the rendered result without overriding canonical rules or user choice.

Discuss hreflang with Zeo International SEO

Some of the 500+ brands we've worked with

See all references

We resolve eligibility and equivalence before working on tags, because even a fully reciprocal cluster is wrong when its pages should not be connected.

Define the supported locale matrix
We record every language, region, catch-all, excluded combination, fallback, and owner. A locale enters the matrix only when the business supports the page and can maintain its content and offer.
An approved coverage matrix with valid codes, market ownership, intentional gaps, and no inferred market promises.
AI assist
Validate proposed language-region codes against the ISO code lists and flag unsupported or malformed combinations before they enter the matrix.
Human gate
The market owner confirms that the business genuinely supports and can maintain each locale before it joins the coverage matrix. Locale enters the matrix only with a real owner.
Audit URL eligibility
We join the localized URL inventory with rendered status, redirect, canonical, robots, noindex, sitemap, and protocol evidence. Pages that redirect, canonicalize elsewhere, or cannot be indexed are removed from annotation until the underlying issue is fixed.
An eligibility ledger that shows which URLs may enter a cluster and why excluded URLs must wait.
AI assist
AI joins rendered status, canonical target, and indexability signal across thousands of localized URLs to flag ineligible pages in one pass.
Human gate
The technical owner confirms a flagged page's underlying issue is actually fixed before it re-enters eligibility. URL re-enters eligibility only once the defect is fixed.
Build exact reciprocal clusters
We pair pages only when their purpose, language or region, offer, and canonical ownership are genuinely equivalent. Every member lists itself and the same complete alternate set. Uncertain pairs go to the relevant content or market owner.
A versioned hreflang cluster map with explicit membership, catch-alls, exclusions, and unresolved equivalence decisions.
AI assist
Compare proposed cluster versions and surface missing reciprocal returns or inconsistent member lists across a large site.
Human gate
The content or market owner decides whether two similar pages are genuinely equivalent before they are paired in a cluster. Pages join a cluster only when equivalence is confirmed.
Implement through one source
We choose HTML, HTTP headers, or XML sitemaps based on the platform and prevent competing systems from publishing different versions. The specification covers generation rules, exception handling, release grouping, and rollback.
A single-emitter implementation specification that engineering can test against the approved cluster map.
AI assist
AI compares the approved cluster map against what each candidate emitter, HTML tags, HTTP headers, XML sitemap, renders in production.
Human gate
The technical owner picks the single approved emitter and confirms no competing system still publishes an older version before release. Cutover approved once no competing emitter remains live.

AI validates codes and compares what is rendered; people decide eligibility and equivalence.

AI validates proposed language-region codes against the ISO code lists, joins rendered status, canonical target, and indexability signal across thousands of localized URLs to flag ineligible pages in one pass, compares proposed cluster versions to surface missing reciprocal returns or inconsistent member lists, and checks the approved cluster map against what each candidate emitter renders in production. Equivalence is not something it can judge. We do not use IP or Accept-Language redirects that stop users or crawlers from selecting another reachable locale, we do not connect pages whose purpose, offer, or content is not genuinely equivalent, and we do not present automatic translation as a supported native-market page.

These outputs make hreflang a traceable relationship between URLs, so every failure can be traced to eligibility, equivalence, data, or delivery.

Decision matrix
Hreflang cluster map
Accepted when
Every row identifies the locale code, canonical URL, exact equivalents, self-reference, catch-all, exclusion, content or market owner, evidence date, and cluster version.
Policy document
Exception and fallback policy
Accepted when
Unsupported, absent, redirected, retired, shared, and temporarily blocked variants each have an explicit treatment and owner. Approximation is never used to fill a missing page.
Architecture map
Single-source implementation specification
Accepted when
The approved clusters, emitter, generation rules, data source, release groups, parsing tests, monitoring, and rollback path are aligned in one implementable package.
Audit report
Reciprocity validation report
Accepted when
Rendered URL-level evidence includes passing and failing examples for self-reference, complete returns, valid codes, canonical agreement, indexability, and the published cluster version.

We call it done when: The cluster map, exception policy, implementation specification, and reciprocity report are done when every row names its locale code, canonical URL, exact equivalents, self-reference, exclusions, owner, evidence date, and cluster version, every unsupported, absent, redirected, retired, shared, or blocked variant has an explicit treatment and owner instead of an approximation, the approved clusters, emitter, generation rules, data source, release groups, parsing tests, monitoring, and rollback path sit in one implementable package, and the rendered evidence shows passing and failing examples per URL.

Use this work when localized pages need a dependable decision on cluster membership and proof that the published signals agree.

A good fit when

Search engines often choose the wrong language or market page, while current hreflang clusters contain missing returns, invalid codes, inconsistent membership, or unclear ownership.
A CMS, sitemap process, edge layer, or application generates annotations across many locale pairs, and manual reviews no longer catch the drift.
A migration, redesign, domain change, or locale expansion will affect canonicals, indexability, URLs, or cluster membership and requires evidence before release.

Better handled as other work when

The target market or language does not have a genuinely equivalent page, and the plan is to use hreflang instead of creating suitable local content.
Canonical, indexability, redirects, and annotations cannot be changed and tested together across the affected cluster.

If one of these is closer to your situation, start here instead: International SEO

We call it done when: Every supported language-region code has an owner. Each participating URL is indexable, self-canonical, and equivalent to its alternates. All members return the same complete set through one approved system, and failed production clusters have a repair or rollback decision.

Zeo's SEO work goes back to 2006, when we started what we call the first SEO blog in the MENA region. The consultants shown here are doing that work today, matched to what this page covers.

Content we've produced on this topic

Articleby Samet ÖzsüleymanThe Overlooked Report: Search Console Country Analyses

Semrush
samples international site issues across hosts and locale folders
Screaming Frog
builds URL-level hreflang, canonical, status, and reciprocity evidence
Sitebulb
groups invalid codes, missing returns, and conflicting locale signals
Lumar
monitors reciprocal clusters after locale releases and migrations
Google Search Console
checks indexing and canonical outcomes for localized landing pages
Bing Webmaster Tools
checks localized URL discovery outside the primary search console

Send the URL inventory, the locale policy, the annotations, and any wrong-market landings you already know about. The first eligibility and cluster checks follow from those.

Discuss hreflang with Zeo

Does hreflang replace canonical tags?

No. A canonical identifies the preferred URL, while hreflang describes eligible language or regional alternatives. Participating pages should be indexable, self-canonical, genuinely equivalent, and included in the same reciprocal set.

Can one missing reciprocal return be ignored?

We keep the relationship under review until the complete cluster is restored. A missing return may reveal stale source data, faulty generation, a mixed release version, or an ineligible page, so the affected URLs and repair owner remain visible.

Should hreflang annotations use the HTML head, HTTP headers, or an XML sitemap?

Choose the method your platform can generate and maintain consistently, then use only that source. Running two methods at once commonly creates conflicting clusters rather than providing extra coverage.

What happens to the existing cluster when we launch a new locale?

Every existing member's alternate list must include the new locale before the new page can join the reciprocal set. A locale stays outside the cluster until every existing return includes it, even when its own page links out correctly.

By team

By industry

By tool

Hreflang & Geo-Targeting

How we do it

Define the supported locale matrix

Audit URL eligibility

Build exact reciprocal clusters

Implement through one source

What you get

Hreflang cluster map

Exception and fallback policy

Single-source implementation specification

Reciprocity validation report