How to Check Hreflang Tags and Return Links

In international SEO, hreflang tags are labels that tell Google which URLs serve language or regional versions of the same page. A return link is the matching tag on an alternate page. If the U.S. page points to the U.K. page, the U.K. page should point back to the U.S. page.

To check a site’s hreflang tags, compare them across each group of equivalent pages, then confirm that every linked URL opens the intended page. A checker can show whether the tags appear consistent, but it cannot prove that Google has crawled, indexed, or selected the intended version.

Check each page group in both directions

Start by identifying URLs for the same page in different languages or regions. Do not assume pages are related just because their URL paths look alike. Translated pages can use different paths, and some pages have no equivalent in every locale.

For each group, inspect every version. Each page should list its own URL and the URLs for the other versions in the group. Follow each tag to its destination and confirm that the destination lists the original page. Google says it may not interpret tags correctly when two pages do not point to each other. Its localized-page guidance describes this requirement.

For example, if a page for English-speaking U.S. visitors lists a U.K. English page as an alternate, check that the U.K. page also lists the U.S. page. If the site connects three versions, check the whole set rather than confirming just one pair. The result tells you whether the published relationships are reciprocal; it does not establish that Google has processed them.

Inspect the method your site publishes

Google supports hreflang annotations in HTML, HTTP response headers, and XML sitemaps. It treats the methods as equivalent, so a site does not need to maintain all three. Check the method the site actually uses.

For HTML, inspect the page’s source and look for <link rel="alternate" hreflang="..." href="..."> elements in the document head. If JavaScript generates or changes those elements, compare the initial source with the rendered page. Google’s JavaScript SEO documentation explains how Google processes JavaScript pages.

For HTTP headers, inspect the response headers for each relevant file. This method is useful for files such as PDFs, which do not have an HTML head. For a sitemap implementation, inspect the XML entries and confirm that each page in a group includes the corresponding alternate links.

A check that reads only HTML cannot verify annotations published only in headers or a sitemap. Record which method you checked so a clean result does not give a false sense of coverage.

Verify the destinations, codes, and canonicals

A reciprocal link can still point to the wrong page. Open each destination and confirm that it resolves to the intended language or regional version. Check for redirects to another locale, error pages, or URLs that no longer represent the page named in the annotation. Use the final preferred URL in the hreflang entry rather than a redirecting alias.

Check each language and region value as well. Google expects a language code using ISO 639-1; an optional region code uses ISO 3166-1 Alpha 2. The value en-GB, for example, identifies English for Great Britain. A region without a language does not provide the intended language-region value.

Then compare each hreflang destination with its canonical URL. A canonical is the URL a page declares as its preferred version for indexing. Google recommends that a localized page’s canonical point to a page in the same language, or to the best substitute language when no same-language page exists. The canonicalization guidance explains that Google treats a declared canonical as a signal, not a binding instruction. If hreflang points to one URL while that URL redirects or declares a different locale as canonical, review whether the signals reflect the intended page relationship.

An optional x-default entry identifies a fallback page for users whose language or region is not covered. It often points to a language selector. It does not replace the entries for the localized pages.

Interpret a failed check carefully

A failed check for return links shows that the pages do not publish the expected two-way relationship. A broken or redirected destination shows that the tag does not lead directly to the intended page. An invalid code shows that Google may not read the language or region value as intended. These findings identify issues to fix, but they do not prove that a URL is absent from Google’s index.

A passing check confirms that the pages and annotations inspected appear consistent at that time. It does not prove that Google can crawl every destination, has accepted the annotations, or will show a particular regional version in search results. Hreflang helps Google understand relationships among localized pages; it does not guarantee indexing, rankings, or display.

Use Search Console’s URL Inspection tool on a small sample of important pages to review Google’s indexed view and test the live page. Google describes these options in its page debugging guidance. URL Inspection helps investigate an individual page, but it does not audit every return link across a large site. After a fix, an older Search Console report can remain until Google crawls the page again, so compare the report with the current live implementation.

For a large site, export the declarations into a table with the source URL, language or region value, destination URL, destination status, and whether the destination links back. This makes it easier to spot pages that do not list themselves, missing return links, inconsistent page groups, and destinations that redirect. Run the check against the actual publishing method, including headers or sitemap entries when the site uses them.

Key Takeaways

• Check both directions: Each localized page should list itself and its related versions, and each destination should link back.
• Inspect the actual implementation: Check HTML, HTTP headers, or sitemap entries according to the method the site publishes.
• Verify every destination: Confirm that URLs resolve to the intended locale and that language-region values and canonical URLs make sense.
• Treat results as implementation evidence: A passing check does not prove Google has crawled, indexed, or selected the intended page.

What I'm building

Delegate tasks. Get software.

Give Vroni a GitHub issue, bug report, spec, or rough idea. It reads the repo, plans the change, writes code, runs checks, and works toward a review-ready pull request.

Take a look at vroni.com