Hreflang Return Links Audit: Self References, CSV Examples and Checks

Use hreflang for actual equivalent versions

Begin with pages that offer equivalent content to different language or regional audiences. An English product page and its German translation can form a cluster. An English calculator and an unrelated German category page should not be paired merely because both exist. Record each page’s purpose and intended audience before producing markup. Google’s hreflang guidance describes annotations that help identify localized versions; it is not a promise of higher rankings. A global English site does not need fabricated language alternatives. Build and maintain genuinely useful versions before adding a relationship between them.

Make the language map explicit

Use the generator’s url,language CSV for one equivalent cluster. Its sample contains https://example.com/en/product as en, https://example.com/de/product as de and https://example.com/product as x-default. The tool reports three language mappings, three pages requiring the block and three tags per page. It generates the same complete set for each page. The x-default entry provides a fallback destination; decide what that page actually offers before adding it. Keep the distinction between a language code and a country code visible in your source spreadsheet, and give every mapping an absolute destination URL.

Install the whole set and verify self references

Each equivalent page should identify itself and the other versions in the chosen annotation method. For an HTML implementation, the generator supplies link elements for the head of every listed page. Copying only a link to the other language omits the self reference and makes the intended set harder to maintain. Google supports HTML, HTTP headers and sitemap annotations; using one well-maintained method is a practical starting point. Our generator outputs HTML blocks, so it does not create response headers or update a sitemap. Check the chosen implementation against the current Google guidance before deployment.

Reproduce a missing-return example

The consistency checker uses a different CSV shape: source,target,language, with one row per actual annotation. Its sample has an English page pointing to itself as en and to the German page as de. The German page points only to itself as de. The three rows describe two supplied source pages. The tool flags one mapping: the English-to-German relationship lacks a supplied return reference, and the alternate sets differ. Add a fourth row, https://example.com/de,https://example.com/en,en, and the sample reports zero mappings to review. This is verified CSV consistency, without inspecting either deployed page.

Treat a partial export as missing evidence

If a target URL does not appear as a source anywhere in your CSV, the checker cannot inspect its return or self reference. That warning does not prove the live page is broken. Export the full cluster before deciding what needs repair. The checker also identifies duplicate mappings, conflicting targets for one language and different alternate sets. Its language check covers supported syntax, rather than a complete registry of assigned codes. Use the generator and primary documentation to review code choices, then inspect the deployed annotations. A clean spreadsheet and a clean published implementation are separate pieces of evidence.

Keep canonical, availability and language checks separate

The offline audit cannot establish whether a target responds successfully, redirects elsewhere, is blocked from crawling or points to an unsuitable canonical destination. Open the actual pages and inspect their responses and delivered markup. Confirm that a German link reaches the German equivalent rather than a generic language selector or the English original. Google’s documentation requires reciprocal relationships for the annotations to be interpreted as intended. A redirect or mismatched canonical is a reason to review the cluster, but this CSV tool does not choose a canonical strategy or simulate Google’s eventual selection.

Review page-specific metadata without forcing identical wording

Titles and descriptions should describe each actual version in its language and context. A bulk metadata export can reveal empty fields, copied placeholders and repeated titles that merit review. The metadata tool counts Unicode code points and applies the review ranges you choose; it does not measure search-result pixel width or apply official Google character limits. Inspect titles alongside their page content instead of rewriting every flagged row automatically. For a multilingual cluster, keep a record of who maintains each version, which content change prompted the review and whether localized details such as units or service availability changed.

Audit again when destinations or templates change

A template update can affect all annotations, while a renamed URL can leave an otherwise correct set pointing at the old destination. Keep the intended map under the same revision process as the pages. After publishing a change, extract the actual annotations again, run the consistency check and compare the output with your saved baseline. Verify representative pages in the browser as well. The aim is to maintain a reproducible relationship between real equivalent versions. A zero-warning CSV result is useful within that process; it is not proof of indexing, a measured traffic increase or a substitute for reviewing the content itself.

Sources and further reading

• Google: localized versions, language codes and return links
• Google: consolidating duplicate URLs and canonical signals
• Google: title links and descriptive page titles

Our editorial standards explain how we check sources, examples and assumptions. Suggest a correction to this article.