Definition
Checking hreflang means verifying that language and region alternate annotations correctly connect equivalent pages across locales. Annotations can appear in HTML, HTTP headers, or sitemaps. A sound check confirms codes are valid, URLs are fetchable, self-references exist where expected, and return links are reciprocal between variants.
Hreflang describes relationships among localized versions. It does not create useful content that is missing, and it does not guarantee which language will appear for a query.
Why it matters
Public international targeting documentation exists because sites often publish near-parallel pages in multiple languages. Without clear alternates, systems may treat variants as unrelated duplicates or show the wrong language. People-first localized content still needs crawlable, accurate associations so the intended language version can be understood as part of a set.
B2B teams expanding into new markets sometimes ship machine-translated shells or incomplete locale folders. Hreflang errors then amplify confusion: broken URLs in alternate tags, or English pages claiming Chinese alternates that 404. Checking annotations early keeps market expansion from inventing false association signals.
How to check
- List intended language/region pairs and the URL pattern for each (subdirectory, subdomain, or country domain).
- Sample priority templates and extract hreflang annotations from HTML, headers, or sitemaps—use one consistent method per template family.
- Validate language-region codes and confirm each alternate URL returns an expected success status.
- Verify reciprocity: if EN lists ZH, ZH must list EN (and self) for the same cluster.
- Confirm
x-defaultpoints to the intended fallback when you use it, usually the primary language hub. - Separate “annotation broken” findings from “locale content not built yet” findings before planning translation work.
A concrete example
An equipment manufacturer launches /zh/products/model-x/ alongside the English product page. The English page’s hreflang lists the Chinese URL, but the Chinese page only lists itself—no return link to English—and one annotation still points to a staging host. A hreflang check flags missing reciprocity and an invalid alternate host. Fixing annotations restores a coherent language cluster. Separately, if Chinese buyers need application notes that exist only in English PDFs, that is a growth coverage gap for the Chinese market—not something a correct hreflang tag can invent.
How Mika separates health issues from growth opportunities
Broken, non-reciprocal, or non-fetchable hreflang annotations are health issues: language signals are confused. Missing localized topics or incomplete market coverage are growth opportunities. Mika treats annotation failures as foundation repair, and market content gaps as separate coverage work.
FAQ
Does correct hreflang guarantee the right language will rank?
No. Hreflang helps associate language and region variants. Ranking still depends on relevance, usefulness, and competition. Checking hreflang validates alternate annotations, not position outcomes.
Do we need hreflang if we only have one language?
If you have a single language and no regional variants, hreflang is usually unnecessary. Add it when you publish real alternate language or region URLs that should be associated.
What is the most common hreflang mistake?
Missing return links—page A lists B, but B does not list A—or pointing to non-indexable or wrong-language URLs. Reciprocal, fetchable alternates for real localized pages are the baseline.
Sources
- Google Search Central — Localized versions of your pages (hreflang)
- Google Search Central — How to specify a canonical URL
- Google Search Central — Creating helpful, reliable, people-first content
- Mika method: language-signal health vs market coverage growth — mikaovo.ai
Need a structured audit?
See how Mika maps crawl health and content gaps into next actions.
Talk to Mika