Hreflang is an HTML attribute that tells search engines which language and geographic variants of a page exist, preventing duplicate content issues and serving the right version to the right user. Implementation requires precision—most mistakes stem from reciprocal link failures or incorrect locale codes.
Hreflang is an attribute you add to pages that exist in multiple languages or target multiple countries. It tells search engines like Google which version to show based on the searcher's language setting and location. Without it, Google guesses—and often surfaces the wrong variant, diluting click-through rates and confusing users who land on content in the wrong language.
The attribute pairs an ISO 639-1 language code with an optional ISO 3166-1 Alpha-2 country code. For example, hreflang="en-ca" means English content for Canada, while hreflang="fr-ca" targets French speakers in Canada. You can also use language-only codes like hreflang="en" as a fallback for all English speakers not covered by more specific variants.
Every hreflang annotation must be reciprocal: if Page A points to Page B as an alternate, Page B must point back to Page A. Each page must also include a self-referential tag pointing to itself. This redundancy feels excessive but prevents asymmetric signals that engines ignore.
You can declare hreflang in the HTML <head> using link rel="alternate" tags, in the HTTP header for non-HTML files like PDFs, or in an XML sitemap. Most practitioners choose HTML tags for standard pages because they're visible in view-source and easier to audit.
HTTP header implementation makes sense for assets that don't render HTML—PDFs, media files—or headless architectures where injecting tags into markup is cumbersome. You send a Link header with the same syntax: Link: < rel="alternate"; hreflang="en".
XML sitemaps work well at scale, especially for large e-commerce catalogs where managing in-page tags becomes unwieldy. You add xhtml:link elements inside each <url> block, listing all alternates. The downside: debugging requires parsing XML, and some engines crawl sitemaps less frequently than they crawl pages. For most sites under a few thousand pages, HTML tags offer the best balance of transparency and control.
Canadian websites serving both English and French content face a specific hreflang challenge: preventing /en/ and /fr/ versions from cannibalizing each other in search results. Without hreflang, Google may index the French page for an English query or vice versa, especially if content structure is identical and language detection is ambiguous.
Use hreflang="en-ca" for English-Canada pages and hreflang="fr-ca" for French-Canada pages. If you also serve audiences in France or the U.S., add hreflang="fr-fr" or hreflang="en-us" tags pointing to those variants. Include an x-default tag to specify the fallback version for users whose language or location doesn't match any declared alternate—typically your primary market.
Quebec-focused businesses sometimes skip the country code and use hreflang="fr" alone, but this signals the page is for all French speakers globally, which may attract traffic from France or African francophone countries you don't serve. Be explicit about targeting to avoid wasted impressions.
Non-reciprocal links are the most common failure. If your English page points to a French alternate but the French page doesn't point back, Google discards the entire annotation. Always ensure bidirectional links and include a self-referential tag on every page.
Incorrect locale codes render the attribute useless. Using "en-uk" instead of "en-gb" or "fr-qc" instead of "fr-ca" means engines won't recognize the variant. Validate codes against ISO standards before deploying.
Missing or wrong canonical tags create conflicts. If a page's canonical points to a different URL than its hreflang self-reference, engines see contradictory signals and may ignore hreflang entirely. The canonical and the hreflang self-tag must match.
Pointing to noindexed or redirected pages wastes the annotation. Hreflang targets must be indexable, live pages. If a variant is under a noindex directive or redirects to another URL, the signal breaks. Audit your alternates to confirm they return 200 status codes and allow indexing.
Google uses hreflang as a signal, not a directive—it may still rank a different variant if it believes that page better matches the query's intent. Yandex respects hreflang similarly. Bing historically ignored it in favor of content-language meta tags and geotargeting in Search Console, though recent documentation suggests partial support.
When Google encounters hreflang, it attempts to consolidate variants into clusters, showing one version per language-region pair in SERPs. It may also swap URLs in search results: a user in Montreal searching in French sees the fr-ca page; a user in Toronto searching in English sees the en-ca page, even if both queries are identical in structure.
Hreflang does not merge link equity the way canonicals do. Each variant accumulates its own backlinks and authority. This means translating content into multiple languages doesn't dilute SEO value, but it also means you need separate link-building efforts for each major market.
Google Search Console reports hreflang errors under the International Targeting or Enhancements section, flagging missing return links, incorrect codes, and conflicting signals. Check this report after deployment and monthly thereafter—errors accumulate as you publish new pages.
Third-party crawlers like Screaming Frog extract hreflang tags during site audits, letting you visualize reciprocal relationships and spot asymmetries. Export the hreflang report and cross-check that every source-target pair has a matching reverse entry.
Manual spot-checks confirm rendering: view-source the page, locate the link rel="alternate" tags, and verify the href URLs and hreflang values. Use a VPN or Google's URL Inspection tool to simulate requests from different locales and confirm the correct variant appears in results. Hreflang bugs often surface only when testing from the target geography.
Hreflang assumes you've already created distinct language or regional variants of the page—it doesn't trigger translation. Many teams confuse implementation order: you first translate or localize content, then add hreflang to link the variants together.
Machine-translated content with hreflang still works technically but risks poor user experience and thin-content penalties if translations are low quality. If you're automating translation, invest in post-editing by native speakers before deploying hreflang. The attribute won't save a page that users immediately bounce from.
Some CMSs auto-generate hreflang tags based on language-path structures or subdomain setups. Verify the output matches your intent—auto-generated tags often omit x-default, use overly broad language codes, or fail to update when you add new market pages. Treat CMS automation as a starting point, not a final solution.
No, hreflang does not directly influence rankings. It controls which page appears for which audience, preventing the wrong variant from ranking in the wrong country or language. If your French page is stronger than your English page, hreflang ensures French users see the French version, preserving relevance and engagement. Rankings depend on content quality, links, and other traditional signals.
Yes, hreflang works across domains, subdomains, and subdirectories. You can link example.com to example.fr or to fr.example.com using the same syntax. The key is that all variants must include reciprocal annotations pointing to each other and themselves, regardless of domain structure. Cross-domain hreflang is common for global brands with country-specific TLDs.
Use language-only codes like hreflang="en" and hreflang="fr" without country specifiers, then add an x-default tag pointing to your primary version. This tells engines to show the English page to all English speakers and the French page to all French speakers, regardless of country, with x-default catching everyone else. You can layer in country-specific codes later as you create localized variants.
The x-default tag specifies a fallback page for users whose language or location doesn't match any declared alternate. For example, if you serve en-us, en-gb, and fr-ca but a user in Japan searches, x-default determines which version they see. It's not a language code—it's a catch-all directive. Point it to your homepage or most globally relevant variant.
Only if the content differs meaningfully—pricing in different currencies, region-specific legal disclaimers, or localized terminology. If your English content is identical for U.S. and U.K. audiences, a single hreflang="en" suffices. Adding unnecessary country codes complicates maintenance without benefit. Use regional codes when you've genuinely adapted the page for that market.
Google must recrawl the affected pages and process the new annotations, which typically happens within a few days to a couple of weeks depending on crawl frequency. You can request indexing via Search Console to accelerate recognition. Monitor the International Targeting report to see when errors clear and check search results from target locales to confirm the correct variant appears.