Category: SEO | Reading time: 11 minutes | Last updated: April 2026
Hreflang tags are HTML annotations that tell search engines which language and regional version of a page should be served to which users. They exist to solve a specific problem: when you have multiple versions of the same content in different languages or for different regions, search engines need explicit guidance about which version to show in each market. Without hreflang tags, Google makes a best guess, and that guess is wrong surprisingly often. Surveys of large international sites consistently find that a significant majority have hreflang errors severe enough to cause the wrong language version to appear in search results. Getting hreflang right is not optional for any business operating in more than one language or country.
How hreflang tags work
A hreflang tag uses two standardized code systems to identify language and region. The language component uses ISO 639-1 two-letter codes: en for English, fr for French, de for German, ja for Japanese, pt for Portuguese. The optional region component uses ISO 3166-1 alpha-2 country codes: US for United States, GB for Great Britain, DE for Germany, BR for Brazil. Combined, “en-US” means English for the United States, and “pt-BR” means Portuguese for Brazil. The language code is always required. The country code is optional but becomes essential when the same language targets different countries (English for the US versus the UK, Spanish for Spain versus Mexico).
Each hreflang annotation must reference every alternate version of the page including itself. This bidirectional requirement is the single most violated rule in hreflang implementation. If your English page declares a French alternate, the French page must declare the English page as an alternate and also declare itself. An incomplete reciprocity graph causes Google to ignore the hreflang signals entirely, which results in the wrong language pages ranking in the wrong markets. The auditing pattern that catches this: build a matrix of every page in every language, with one row per source page and one column per target language, then verify every cell is populated symmetrically. The work is tedious; it is also the difference between hreflang that works and hreflang that silently breaks rankings.
Code-format errors are the second most common failure mode. Three-letter ISO 639-2 codes (eng, fre/fra, ger/deu, por, tur) are not valid hreflang codes. Hreflang requires two-letter ISO 639-1 codes (en, fr, de, pt, tr). Sites that have used three-letter codes for years discover, on audit, that Google has been ignoring their hreflang implementation entirely the whole time. Correcting the codes restores Google’s ability to respect the language targeting and produces visible ranking shifts in every market within weeks.
The three implementation methods
Hreflang can be implemented in three places: the HTML head section of each page, HTTP response headers, or the XML sitemap. The HTML head method places <link rel="alternate" hreflang="..." href="..."> tags directly in the head of each page. This is the most straightforward approach for smaller sites with fewer than around fifty pages per language. The downside is that it adds code to every page, which adds size and can slow rendering. For a site with five language versions, each page needs five additional link tags in the head, which is manageable. For a site with twenty language versions, the head section becomes bloated.
The XML sitemap method defines hreflang relationships within sitemap files. Each URL entry includes xhtml:link elements pointing to all alternate language versions. This method keeps the HTML clean and works well for large sites with hundreds or thousands of pages. The benefit beyond performance: sitemap-based hreflang centralizes all relationships in a few files rather than scattering them across thousands of pages, which makes auditing dramatically easier. Most international sites at scale use sitemap-based hreflang for exactly this maintainability reason.
HTTP response headers are the third option, used primarily for non-HTML documents. PDFs, downloadable files, and other non-HTML content cannot carry HTML head tags. For document libraries that ship in multiple languages, HTTP headers are how you attach hreflang annotations. For most websites, the choice comes down to HTML head for small sites and XML sitemap for large sites. HTTP headers are a niche solution for specific document types.
The x-default tag
The x-default hreflang value tells search engines which page to show when no other hreflang match exists for the user’s language or region. It is the fallback. If a user in Thailand searches and your site has English, French, and German versions but no Thai version, the x-default page is what Google should serve. Without x-default, Google guesses based on signals like content quality, link authority, and crawl patterns. The guess is often wrong, and the failure mode is users from non-targeted markets getting served arbitrary language versions instead of the cleanest fallback.
Most international websites should set x-default to their English version, or to a language selector page that helps the user pick the best available option. The selector pattern works particularly well for sites with many language versions because it gives users from non-targeted markets a clear path forward instead of dropping them into a random language version. The simpler pattern (x-default to the English site) works well for sites where English is the natural global fallback.
Debugging hreflang
Google Search Console reports hreflang errors under the International Targeting section. Common errors include missing return tags, unknown language codes, and hreflang tags pointing to non-existent pages. Search Console catches the most obvious issues but does not provide a complete picture. Screaming Frog (or Sitebulb) provides more detailed hreflang analysis. It can crawl the entire site, identify every hreflang relationship, flag missing return tags, detect broken URLs, and validate language codes. The right cadence is a monthly Screaming Frog audit specifically targeted at hreflang, plus on-demand audits after any URL migration, CMS update, or significant content release in any language version.
The most common drift pattern: a CMS update introduces a new hreflang generation behavior, and the development team is not aware of the existing hreflang configuration. The new release ships with conflicting tags between the HTML head (CMS-generated) and the sitemap (manually maintained), and Google sees contradictory signals. Schedule the audits, build hreflang validation into the deployment pipeline, and treat hreflang errors with the same urgency as broken pages or missing canonical tags. Our Screaming Frog audit guide covers the configuration that surfaces hreflang errors automatically.
Hreflang for e-commerce
E-commerce sites face unique hreflang challenges because product availability varies by market. A product available in the US might not be available in Germany. If the German version of that product page returns a 404 or redirects to the homepage, the hreflang annotation becomes invalid, and Google starts distrusting hreflang signals across the entire site after enough invalid annotations accumulate. The right pattern is conditional hreflang generation: only emit annotations for markets where the product is actually available. The CMS must check product availability per market before generating hreflang tags, which is more work than the naive “always emit all alternates” pattern but produces a clean signal that Google can rely on.
Seasonal products and price differences add complexity. Hreflang annotations between regions where the product is in different lifecycle states (in-season vs out-of-season, full price vs sale) can produce mismatches between what the user expects and what the destination page shows. The cleanest pattern is to keep regional content fully maintained even during off-seasons (Australian ski pages stay active during the Southern Hemisphere winter), so the hreflang destinations always render the appropriate market-specific content rather than confusing off-season messaging from a different hemisphere.
Common hreflang mistakes that destroy rankings
Using incorrect language codes (three-letter ISO 639-2 instead of two-letter ISO 639-1).
Pointing hreflang tags to redirected URLs. If the destination URL 301-redirects to another URL, Google may ignore the signal entirely. Always update hreflang annotations as part of any URL migration plan, and verify the changes with a Screaming Frog crawl before and after the migration.
Missing return tags. Every alternate must reference back to the source page, and every variant must reference itself. Incomplete reciprocity is the most common reason hreflang implementations stop working over time.
Conflicting implementations. HTML head and XML sitemap implementations active simultaneously, with different content, force Google to choose which to trust and the choice is rarely the one you intended.
Cross-language canonicals. A canonical tag from a French page to the English version tells Google the French page is a duplicate, which makes the hreflang annotation irrelevant because the canonical signal overrides it. Each language version’s canonical tag should point to itself, not to the original-language page.
Hreflang for same-language regional variants
One of the trickiest aspects is handling the same language across different countries. English for the US, UK, Australia, Canada. Spanish for Spain, Mexico, Argentina, Colombia. Portuguese for Portugal and Brazil. German for Germany, Austria, Switzerland. Each variant requires its own hreflang annotation with the country code appended. Without country codes, Google has no way to distinguish between the regional pages, and merges them into a single index showing the most authoritative version (typically the largest market) in every country. Adding country codes (en-US, en-GB, en-AU, en-CA) is the fix that lets each regional page rank in its intended market.
For languages with significant variation between national variants (Portuguese in Portugal vs Brazil, Spanish across Spain and Latin America), explicit country-coded annotations are essential. Without them, the larger market typically dominates the smaller market in search results because Google’s authority signals favor the larger version when it cannot distinguish them. Adding both country-coded annotations and an x-default for the language-only fallback (es x-default for Spanish-speaking countries you do not specifically target) resolves both the regional ranking issue and the fallback problem.
Automated hreflang via CMS plugins
Most modern CMS platforms offer plugins or built-in features for generating hreflang tags automatically. WordPress users can implement hreflang through plugins like WPML, Polylang, or TranslatePress. Shopify generates hreflang tags automatically for stores using Shopify Markets. Automated generation is not the same as error-free generation. The most common automated-hreflang failure mode: the plugin generates annotations for draft pages that are not yet published, or for language versions with only a handful of translated pages out of hundreds, which Google interprets as thin content. Always audit the output of automated generators rather than trusting them blindly. The plugin handles the mechanical work; you still need to verify the result.
For headless CMS setups (Contentful, Strapi, Sanity), hreflang generation typically lives in the frontend build pipeline. The implementation is custom code that pulls language relationships from the CMS’s localization API and injects the correct tags during static site generation. The right pattern is to build hreflang validation into the CI/CD pipeline so every pull request that modifies a page in any language automatically triggers a check that compares the new page against all existing language versions for complete bidirectional annotations. Pull requests that fail the check should not merge until the errors are resolved.
Hreflang and canonical tags: how they interact
Hreflang and canonical tags serve different purposes but interact in ways that confuse many SEO practitioners. A canonical tag tells Google which URL is the preferred version when duplicate or near-duplicate pages exist. A hreflang tag tells Google which language version to show to which users. The problem arises when the two signals contradict each other. If your French page has a canonical tag pointing to the English page, Google interprets this as the French page being a duplicate of the English page and does not index it as a separate language version. The hreflang tag becomes irrelevant because the canonical signal overrides it. The fix is consistent across all the cases: each language version’s canonical tag should point to itself, never to the original-language page.
Cross-language canonicals are appropriate in one specific scenario: when two language versions have truly identical content (the same English page targeted at the US and Canada with no differences beyond the URL path). Even then, the better pattern is usually to add enough unique content to each regional variant to justify separate indexing rather than canonicalizing one to the other. The canonicalization approach saves development time but prevents the canonicalized version from building its own ranking signals, which means it never ranks independently in its intended market.
Conclusion
Hreflang implementation is one of the technical SEO elements that requires precision, ongoing maintenance, and regular auditing. The initial setup is important, but the long-term maintenance is what separates international sites that perform well from those that slowly deteriorate. Every CMS update, URL change, new product addition, and market expansion requires hreflang attention. Build hreflang checks into the deployment pipeline so every release is validated automatically. Treat hreflang errors with the same urgency as broken pages or missing canonical tags. In international SEO, hreflang is one of the most impactful technical elements, and getting it right gives you a significant competitive advantage over the majority of international sites that get it wrong. Start with a complete audit of your existing implementation using Screaming Frog, fix every error you find, standardize on a single implementation method, and build ongoing monitoring into your development workflow.
LaFactory implements and audits hreflang at scale for international websites. Contact us for a hreflang audit and implementation plan that holds up across CMS updates and URL migrations.