Hreflang Checker by Traffsite

An hreflang checker validates the annotations that describe language and region variants of a page. The Traffsite hreflang checker reads three implementations: link tags in the HTML head, Link HTTP headers and xhtml:link entries in an XML sitemap. It groups the versions into a cluster and checks the relationships between them.

Each annotation has two parts. The hreflang value names a language, optionally followed by a region, such as en, en-GB or de-CH. The href value is the fully qualified URL of that version. Within the hreflang value, x-default is a special option that names the fallback for users whose language does not match any version.

Language codes follow ISO 639-1, and region codes follow ISO 3166-1 Alpha 2. A region on its own is not valid, and codes such as UK, EU or UN have no effect. Only values listed in those standards are supported.

Use it whenever a site serves more than one language or region:

• Launching a new market. A new subfolder or subdomain needs links from the existing versions, not only links to them.
• After a URL change. A migration can leave the old address in the annotations while the new page is live.
• When the wrong language appears in search. The cluster may be broken, incomplete or contradicted by a canonical.
• Before a regional campaign. The landing page should match the audience, not a default page.
• After adding a language selector. The selector should be named in x-default.
• During a quarterly audit. Large clusters drift as pages are added, retired or translated.

The first gain is a complete cluster. Each language version must list itself and all other versions, and if page X points to page Y, page Y must point back. Without the return link, the annotations may be ignored. The checker makes missing links visible, which is hard to spot by reading two pages side by side.

The second gain is accurate codes. A writer may use be for Belgium when be is the Belarusian language code, or use a region code the standard does not assign. The checker compares each value against supported patterns and flags the ones Google will not read.

The third gain is canonical alignment. A fully translated page is not a duplicate of its English counterpart, so each version should normally name itself as canonical. If every version points at the English page, the signals disagree, and Google may consolidate the versions.

The report presents the cluster as a table: each version, its hreflang code, its URL, whether it links back and whether its canonical matches. Problems are labelled as errors or warnings, so you can fix the blockers first and review the rest after.

Hreflang is a hint, not a ranking factor. Google uses it to choose which version suits a searcher. The checker helps you give a clear hint, not a stronger ranking signal.

The aim is a cluster where every version is reachable, correctly labelled and pointed at by its peers: valid codes, absolute URLs, a working x-default and canonicals that agree with the annotations. In practice that means:

• The right language version reaches the right audience more often.
• Fewer pages compete with each other in markets where one version should lead.
• Visitors whose language is not covered get a clear fallback.
• New market launches inherit a pattern that is already correct.
• Translators and regional editors can see exactly which URLs to use.

Hreflang will not make a page rank in a country by itself. Content, links and the rest of the page still carry that work.

Why use a checker rather than a template and a careful eye?

• Tests reciprocity in both directions. A page can point out ten versions and receive links back from only five.
• Validates codes against the standard. A plausible-looking code can still be invalid.
• Reads all three methods. Sites often use HTML on some templates and sitemaps on others.
• Spots relative URLs. Annotations need a full URL with the protocol, not a path.
• Surfaces canonical conflicts. A canonical that looks right alone can undermine the whole cluster.
• Scales. A cluster with dozens of markets is too large to verify by hand.

The result is a short list of specific fixes: add a return link, change a code, replace a path with a full URL or point a canonical back at its own version.

1. Enter the URL of one version in the cluster.
2. Let the tool detect the implementation, or choose HTML, HTTP header or sitemap.
3. Read the cluster view and confirm every expected language and region appears.
4. Check that the page lists itself, and then that every other version links back.
5. Review the codes. Each should use a supported language code with an optional supported region code.
6. Confirm every href is a full URL, including https://.
7. Check that x-default points at the fallback you intend.
8. Compare each version's canonical with its own URL, fix the source and run the Traffsite hreflang checker again.

• International SEO specialists: own the cluster and its performance.
• Developers: add annotations to templates, headers or sitemaps.
• Content teams: publish translations and need the right URLs to reference.
• Ecommerce teams: run country stores on subfolders or subdomains.
• Site owners: entering a second language or region for the first time.
• Agencies: inherit a global site and need to verify the setup.

You do not need to memorise ISO codes. The checker names the invalid value and its version, and the fix is usually a small template or sitemap edit.