A practitioner-grade hreflang review checklist covering validation logic, common error patterns, and the step-by-step process agencies use to audit multi-regional sites—including bilingual Canadian deployments targeting both English and French audiences.
Most hreflang audits stop at confirming tags exist in the source code. The actual failure modes emerge from logical inconsistencies across the annotation cluster. A French-Canadian page pointing to an English variant must receive a return annotation from that English page, and both need an x-default fallback if the site serves a global audience. Missing any leg of that triangle leaves Google unable to trust the signal.
Validation also breaks down when teams treat hreflang as a one-time setup. Product launches, URL migrations, and CMS template changes introduce new pages that inherit incomplete or contradictory annotations. A disciplined review process treats hreflang as a living configuration layer, not static metadata. Quarterly crawls catch drift before regional rankings degrade, especially on sites managing ten or more language-region combinations where manual oversight becomes impractical.
Hreflang uses ISO 639-1 for language and ISO 3166-1 Alpha-2 for region. A tag like hreflang='en-CA' targets English speakers in Canada; hreflang='fr-CA' targets French speakers in Canada. The most frequent error in Canadian deployments is declaring hreflang='fr' without the region qualifier when the page specifically serves Quebec legal or pricing contexts that differ from France.
Review each tag against the actual content language on the page. A bilingual Canadian site might serve /about-us/ in English and /a-propos/ in French, but if someone hardcoded hreflang='fr-FR' on the French variant, Google may show that page to users in France rather than Montreal. Verify that region codes match your business footprint: if you only operate in Canada, hreflang='en-CA' and hreflang='fr-CA' are precise; adding hreflang='en-US' only makes sense if you actively serve distinct U.S. content or pricing.
Every hreflang annotation is a two-way handshake. If page A declares page B as its French equivalent, page B must declare page A as its English equivalent. Unidirectional tags—where only one side of the pair includes the annotation—cause Google to discard the entire cluster.
Walk through a representative page set and map the declared relationships in both directions. A common pattern: the English homepage correctly lists all language variants, but translated category pages omit the return links because the developer copied an old template. Crawl tools flag these orphans automatically, but manual sampling catches edge cases like soft-404 pages that still carry hreflang or redirected URLs left in the annotation set. Also verify self-referential tags: each page must include an hreflang pointing to itself using its own canonical URL, which anchors the cluster and prevents ambiguity when Google evaluates the group.
The x-default hreflang annotation tells Google which page to serve when none of the specified language-region combinations match the user. For a Canadian business serving English and French audiences, x-default typically points to the English homepage or a language selector interstitial.
Review x-default placement for consistency: it should appear in every hreflang cluster, pointing to the same URL across all variants. Inconsistent x-default declarations—where the English page specifies one fallback and the French page specifies another—fragment the cluster. Also confirm that the x-default target itself carries the full hreflang set; orphaning the fallback page breaks the reciprocal requirement. If your site uses geolocation to redirect users, test that x-default still resolves to a real, crawlable page rather than a redirect loop, because Google follows hreflang annotations at crawl time, not through JavaScript overlays.
Google Search Console's International Targeting report shows which hreflang annotations Google successfully parsed and which it ignored. Export the hreflang error list and compare it against your crawl data to isolate discrepancies. Common issues include pages Google cannot crawl due to robots.txt blocks, canonicalization conflicts where the hreflang points to a non-canonical URL, and missing return tags that only surface in Search Console after Google attempts to validate the cluster.
Pay attention to the volume of errors relative to total annotated pages. A handful of orphaned tags on a 500-page site may reflect acceptable churn from recent updates; hundreds of errors suggest systemic template issues or outdated annotations left over from a migration. Use Search Console's date filters to track whether error counts rise or fall after deploying fixes, and revalidate within two to four weeks as Google re-crawls the affected URLs. This feedback loop closes the gap between what your crawl sees and what Google actually indexes.
Hreflang annotations in the HTML head or HTTP headers are straightforward to validate, but JavaScript frameworks sometimes inject tags client-side, creating a gap between raw source and rendered DOM. Crawl tools that execute JavaScript will catch these, but lighter scrapers miss them entirely. Spot-check priority pages using Chrome DevTools: inspect the final DOM and confirm hreflang tags appear exactly as intended, with no duplication or conflicting declarations from competing scripts.
Also verify HTTP header implementation if your stack uses headers instead of HTML tags. Run a curl command or inspect network traffic to confirm the Link header contains the full hreflang set with correct syntax. Mixing HTML-based and header-based hreflang on the same page is valid—Google merges them—but inconsistencies between the two sources can confuse your audit. Document which method your site uses so future reviews follow the same validation path, and ensure CDN or server-side rendering layers preserve headers across cached responses.
Canonical tags and hreflang serve different purposes: canonical consolidates duplicate content signals, hreflang routes users by language and region. Conflicts arise when a page's canonical URL differs from the URL declared in hreflang annotations. Google honours the canonical, so if page A canonicalizes to page B but hreflang on page A points to page C, the annotation may be ignored.
Review each hreflang cluster to confirm that every variant is self-canonicalized or canonicalizes only to itself. Consolidating regional variants under a single canonical defeats the purpose of hreflang, because you are telling Google the pages are duplicates rather than language alternatives. For Canadian sites, this often surfaces when a shared English template canonicalizes /en-ca/ pages to a U.S. /en-us/ version. The fix is straightforward: ensure each language-region variant carries a self-referential canonical and appears in the hreflang cluster of its peers, with no cross-region canonical chains.
Use a crawler like Screaming Frog, Sitebulb, or DeepCrawl with hreflang validation enabled. These tools parse both HTML and HTTP header annotations, flag missing return links, identify incorrect language or region codes, and highlight orphaned tags. Export the hreflang report and cross-reference it with Google Search Console's International Targeting error list to catch discrepancies between your implementation and what Google successfully parsed.
Hreflang is designed for separate URLs serving different languages or regions. If your site presents English and French in a single-page toggle or sidebar, hreflang is unnecessary because there is no distinct URL per language. Implement hreflang only when you maintain separate paths—like /en/services/ and /fr/services/—so Google can serve the appropriate version to users based on language and location preferences.
Omit the missing language from the hreflang cluster for that specific page. Each URL only needs to declare the variants that actually exist. For example, if a promotional landing page exists in English but has no French equivalent, the English page's hreflang set includes only hreflang='en-CA' (self-referential) and x-default. Do not point to a generic homepage or placeholder; that creates a false equivalence and confuses Google's language-targeting signals.
Yes. You can declare hreflang in XML sitemaps using xhtml:link elements under each URL entry. This centralizes management and reduces on-page bloat, especially for sites with many regional variants. The tradeoff is that sitemap-based hreflang is harder to debug in real time and requires careful maintenance when URLs change. Google treats sitemap and HTML-based hreflang equally, so choose the method that fits your deployment workflow and QA process.
Google interprets hreflang='fr' as targeting all French speakers globally, including France, Belgium, and other Francophone regions. If your content, pricing, or legal disclaimers are specific to Canada, use hreflang='fr-CA' to limit targeting. Without the region qualifier, your Quebec pages may appear in search results for users in France, leading to poor user experience and wasted impressions on audiences you do not serve.
Run a comprehensive crawl quarterly or after any significant site change—migrations, new market launches, CMS upgrades, or template refactors. Spot-check high-traffic clusters monthly by sampling representative pages and comparing them against Search Console data. Hreflang errors accumulate gradually as pages are added or removed, so regular reviews catch drift before regional rankings suffer. Automated monitoring through crawl scheduling or Search Console API alerts shortens the feedback loop.