Technical SEO•October 18, 2026•12 min read

Hreflang Audit Checklist: How to Fix Language and Region Targeting

Learn how to audit hreflang tags, validate language and region codes, find missing return links, align canonicals, and fix international SEO targeting.

By Andrii Petlovanyi•2543 words
hreflang audithreflang checkerinternational SEOmultilingual SEOtechnical SEO

Hreflang errors rarely make a page look broken.

The English page still loads. The German translation still works. The Canadian price is still visible on the Canadian URL. Nothing in the layout warns the launch team that search engines may not understand how those pages relate to one another.

The symptoms appear later. A user in France sees the English result. A regional page competes with another version in search. A migrated URL remains inside an old annotation. A translated page is discovered but never connected to the rest of its language cluster.

That is why an hreflang audit needs to happen before launch, after a migration, and whenever a site adds or removes a locale.

This guide explains how to audit page-level hreflang tags, language and region codes, reciprocal relationships, canonicals, indexability, sitemaps, and fallback behavior without treating hreflang as a line of markup that can be checked in isolation.

What hreflang does

Hreflang tells Google that several URLs are localized versions of the same page.

It can distinguish pages by language, such as English and German, or by language and region, such as English for the United States and English for the United Kingdom. This helps Google show the version that best matches a searcher's language or location.

Hreflang does not translate content. It does not force a ranking. It does not replace a canonical tag. It also does not make an inaccessible, blocked, redirected, or non-indexable page eligible for search.

Think of hreflang as a relationship between valid page alternatives. The relationship only becomes useful when the URLs are real, crawlable, indexable, equivalent, and consistently connected.

Know when you need hreflang

Hreflang is useful when a site has separate URLs for localized versions of a page.

Common cases include:

  • a fully translated site with English, Ukrainian, Polish, and German URLs
  • one language with regional differences in price, currency, shipping, legal terms, or availability
  • English pages for the United States, United Kingdom, Canada, and Australia
  • a global language page plus country-specific versions
  • equivalent pages distributed across subdirectories, subdomains, or country domains
  • downloadable files, such as localized PDFs, exposed through separate URLs

You usually do not need hreflang when the site has only one language version, when pages serve different search intents, or when the only difference is a campaign parameter.

If one URL dynamically changes content based on a visitor's IP address or browser language, auditing becomes harder. Google recommends separate URLs for locale versions because a crawler may not discover every variation of a locale-adaptive page.

Build the locale cluster before checking tags

Start with a simple inventory of the pages that should belong together.

For one product page, the intended cluster might contain:

  • `https://example.com/en/product/`
  • `https://example.com/en-gb/product/`
  • `https://example.com/de/produkt/`
  • `https://example.com/fr/produit/`
  • `https://example.com/choose-region/` as the fallback

Write down the expected language or language-region value for each URL. This becomes the source of truth for the audit.

Without an expected cluster, you can confirm that tags exist but still miss the real problem. A technically valid set may omit the French version, point the UK code at the US page, or include a retired German URL.

For a large site, build the inventory by template rather than trying to review every URL manually. Sample the homepage, category pages, product or service pages, editorial content, support pages, and any template with different locale coverage.

Check that every page lists itself

Each localized page should include an hreflang reference to itself as well as references to the other versions in the cluster.

If the English page lists German and French but does not list English, the set is incomplete. The same rule applies to every other page.

A complete cluster of three language versions normally produces three language annotations on each page, plus an optional `x-default` annotation when a fallback URL is useful.

Self-references make the intended mapping explicit. They also help prevent a partial implementation in which developers add links to alternate pages but forget that every page must describe the full group.

Hreflang relationships need return links.

If Page A identifies Page B as its German equivalent, Page B must identify Page A as its English equivalent. When the relationship is not reciprocal, Google may ignore or misinterpret the annotation.

This is one reason a single-page check is not enough. The markup on the English page can look perfect while the German template is missing the English return link.

For every URL in the cluster, verify that:

  • it lists itself
  • it lists every intended alternate
  • every intended alternate lists it back
  • the language-to-URL mapping is identical across the cluster

A useful test is to compare the sets. If four localized URLs belong together, each page should normally expose the same four language or region entries, with the same destination URLs.

Use valid language and region codes

An hreflang value begins with a language code and may add a region code after a hyphen.

Examples include:

  • `en` for English
  • `uk` for Ukrainian
  • `de` for German
  • `en-US` for English in the United States
  • `en-GB` for English in the United Kingdom
  • `fr-CA` for French in Canada

The language comes first. A country code on its own is not valid. `US` does not mean English for the United States; use `en-US`.

Do not use familiar abbreviations without checking the standard. The United Kingdom uses `GB` in this context, not `UK`. Also avoid inventing a regional label because it looks understandable to people. An invalid code can cause the annotation to be ignored.

Hreflang values are case-insensitive, but a consistent convention such as lowercase language and uppercase region makes reviews easier: `en-GB`, `fr-CA`, and `pt-BR`.

Do not confuse language detection with hreflang

Hreflang identifies the intended audience relationship between URLs. It is not the mechanism Google uses to determine the actual language of a page.

The visible content needs to make the language obvious. A page with an English navigation, English product details, and one translated heading is not a strong German version just because it declares `hreflang="de"`.

Review the page itself:

  • Is the main content translated?
  • Are navigation and important interface labels consistent?
  • Are titles and descriptions localized?
  • Are currency, units, addresses, and legal details appropriate for the region?
  • Can the user switch to another version without being forced back?

Hreflang should describe a localization that genuinely exists.

Check for duplicate hreflang values

A page should not declare two different URLs for the same language-region value.

If two tags both use `en-GB` but point to different URLs, the search engine has no clear mapping for that audience. Duplicates often appear when a CMS plugin generates one set and a theme or SEO module generates another.

They also happen during migrations when old annotations remain in a shared header while new annotations are added by the new platform.

Keep one destination for each language or language-region value within a cluster. If two pages compete for the same audience, decide which URL is the real localized equivalent before editing the markup.

Use x-default as a deliberate fallback

The reserved `x-default` value identifies a fallback URL for users whose language or region does not match any listed version.

It is commonly used for:

  • a language or country selector
  • a global homepage
  • a general English page
  • a default market page that invites the user to choose a region

Google recommends `x-default` for this fallback behavior, but the correct destination depends on the site. Do not point it to an arbitrary page simply to remove a warning.

Ask what should happen when none of the defined locales match. The answer should determine the `x-default` URL.

The fallback page should still be useful. A blank redirect gateway, inaccessible modal, or page that immediately forces visitors elsewhere may create a poor experience even if the annotation is technically valid.

Align hreflang with canonical tags

Canonical and hreflang solve different problems, but they must not contradict one another.

The canonical tag identifies the preferred URL for substantially duplicate content. Hreflang connects localized alternatives. In a normal multilingual cluster, each localized page should usually canonicalize to itself while hreflang connects it to the other locale versions.

A common mistake is making every language version canonical to the English page. That tells Google the English URL is preferred while hreflang says the other URLs are valid alternatives. The mixed signals can prevent the localized pages from being treated as intended.

Audit each URL for:

  • a canonical pointing to the final localized URL
  • no canonical chain or redirect between the annotation and the final page
  • the same protocol, hostname, path, and trailing-slash convention used across signals
  • no accidental canonical to staging, a global page, or another language version

There are specialized cases where duplicate regional pages need a preferred canonical, but the decision should be intentional and tested. Do not apply a global cross-language canonical rule as a shortcut.

Confirm every alternate URL is indexable

An hreflang annotation does not rescue a page that search engines cannot use.

Check every destination for:

  • a successful final response
  • no redirect to another locale
  • no `noindex` directive
  • no blocking robots rule that prevents crawling
  • a valid canonical
  • accessible main content
  • no login or consent wall that hides the page

Pay special attention to automatic redirects. A crawler requesting the German URL should be able to access the German URL even if its IP address appears to be in another country.

Visitors should also have a visible way to change language or region. Avoid forcing them back to a detected locale after they make an explicit choice.

Use absolute, final URLs

Google's hreflang documentation requires fully qualified URLs. Each annotation should include the complete protocol and hostname, not only a relative path.

The URL should also resolve directly to the final page. Avoid pointing hreflang at:

  • an HTTP URL that redirects to HTTPS
  • an old hostname
  • a URL with an unnecessary redirect hop
  • a tracking or session parameter
  • a preview or staging environment
  • a non-canonical trailing-slash variant

Redirects may still be followed, but they create ambiguity and maintenance risk. Update the annotation to the final canonical destination.

Choose one maintainable implementation method

Google supports three equivalent ways to declare localized alternatives:

  1. HTML link elements in the document head
  2. HTTP `Link` headers
  3. XML sitemap annotations

HTML is easy to inspect on ordinary pages. HTTP headers are useful for non-HTML files such as PDFs. Sitemaps can be practical for very large sites or platforms where changing page templates is difficult.

Using all three methods does not create an extra search benefit. It creates three places that can disagree. Choose the method your team can generate, validate, and update reliably.

If several methods already exist, compare them during the audit. The language set and URL mapping should not conflict.

Keep large clusters manageable

Every page in an hreflang cluster must list the full set of alternatives. That can become difficult when a site has dozens of locales and uneven content coverage.

Do not add a language to a cluster when the equivalent page does not exist. Sending users from a specific article to a generic homepage is usually not a true alternate relationship.

Instead, define clusters around actual equivalence. One product may exist in twelve markets while another exists in five. Their hreflang sets can differ.

Use templates and structured locale data to generate annotations, but validate the output. Automation can reproduce a mapping error across thousands of pages faster than a person could create it manually.

Audit migrations and removed locales carefully

Hreflang is especially fragile during a migration because every cluster contains many URLs that may change at once.

Before launch, map each old locale URL to its new destination. Update the hreflang set, self-reference, canonical, sitemap entry, internal language selector, and redirect behavior together.

After launch, look for:

  • annotations that still reference the old hostname or path
  • return links missing from the new template
  • a locale that redirects to the global homepage
  • old pages remaining indexable beside new ones
  • canonicals that still use the previous URL structure
  • language selectors that link through redirect chains
  • removed locales that remain in only part of the cluster

A migration is not complete when the page itself redirects correctly. The relationships around the page must also move.

Sample every important template

A homepage check does not prove that product, category, article, and support templates generate correct annotations.

Choose representative pages from each template and from each important locale. Include pages with the maximum locale set, pages available in only a few markets, and pages with region-specific variations in the same language.

For each sample, record:

  • current URL
  • canonical URL
  • declared language or region
  • complete hreflang set
  • `x-default` destination
  • status and indexability of each alternate
  • missing or inconsistent return links

If a pattern fails, investigate the template or locale mapping rather than fixing one page by hand.

A practical Crowra hreflang audit workflow

Open a localized page in Chrome and scan it with Crowra. In the Technical tab, review the detected hreflang entries and destination URLs. Crowra surfaces duplicate language values and flags a missing `x-default` as a low-severity fallback opportunity.

Compare the detected set with your expected locale cluster. Check that the current page lists itself, that each value maps to the right URL, and that all destinations use final production URLs.

Then open representative alternate pages and repeat the scan. This is how you verify reciprocal relationships and find templates that output a different set. A page-level inventory cannot prove that every alternate links back until those alternates are checked too.

Use the canonical, robots, response, and sitemap checks alongside hreflang. Export the hreflang inventory when the mapping needs to be reviewed by localization, SEO, development, or regional teams.

Crowra helps expose the page-level annotations and nearby technical conflicts. For a very large international site, pair the page audit with a crawler or a structured export that can compare complete clusters at scale.

Hreflang audit checklist

Before publishing or migrating localized pages, confirm all of the following:

  • Every locale has a separate, stable URL.
  • Every page in the cluster serves an equivalent purpose.
  • Each page lists itself.
  • Each page lists every intended alternate.
  • Every relationship has a return link.
  • The hreflang set is consistent across the cluster.
  • Language codes are valid.
  • Region codes appear only after a valid language code.
  • No language-region value is duplicated on the same page.
  • The `x-default` destination is intentional and useful when a fallback is needed.
  • Each localized page has an appropriate canonical.
  • Canonical and hreflang signals do not conflict.
  • Every alternate URL returns a successful final response.
  • Alternate pages are crawlable and indexable.
  • Annotations use absolute production URLs.
  • Hreflang URLs do not rely on redirects.
  • Automatic locale redirects do not block crawlers or user choice.
  • HTML, headers, and sitemap annotations do not disagree.
  • Representative pages from every important template were tested.
  • The final production cluster was checked again after deployment.

An hreflang audit is not complete when the tags merely pass a syntax check. The real goal is a clean, reciprocal cluster in which every language or regional page is accessible, indexable, self-canonical, and mapped to the right audience.