Hreflang Tag Complete Guide

Hreflang tells search engines which URL to serve for a given language and region, so a French-speaking visitor in Canada lands on the French-Canadian version of a page instead of the English-US default. Google is explicit that hreflang annotations function as hints, not directives, meaning Google uses them as a strong signal for which version to show but doesn’t guarantee mechanical, exact compliance in every case. This guide covers correct implementation, the most common real-world error, and a monitoring gap that most existing hreflang guides haven’t caught up with: the Search Console report many people rely on to check hreflang no longer exists.

Hints, not directives

It’s worth being precise about what “hint” means in practice, since it changes how much weight to put on hreflang alone. Google has long described hreflang as one of several signals it uses to determine which URL to serve to a given user, alongside things like the user’s location, browser language settings, and the site’s own content in that language. This means a correctly implemented hreflang setup is a strong influence on which version gets served, but it isn’t an absolute override in every single case the way a canonical tag more strictly determines which URL is treated as authoritative. In practice, for a well-implemented hreflang cluster with no conflicting signals, Google honoring the annotation is the overwhelmingly typical outcome; the “hint, not directive” framing mainly matters when hreflang, canonical, and actual content language are pulling in different directions.

Syntax basics

An hreflang annotation combines an ISO 639-1 language code with an optional ISO 3166-1 Alpha-2 region code, separated by a hyphen: en-US, fr-CA, es-MX. The language code is required; the region code is optional and should only be added when you’re genuinely targeting a specific country’s variant of a language, not just the language generally. A common mistake is adding a region code that doesn’t match any real content difference, which creates unnecessary complexity without a corresponding benefit.

x-default is a special value used to point search engines and browsers to a fallback page when none of the specified language or region combinations match a visitor, typically a language-selector page or a default international version.

Three implementation methods

Hreflang can be implemented three ways, and only one is appropriate per page (don’t mix methods on the same URL):

Method	Where it lives	Best for
HTML <!–INLINECODE4–> tags in <!–INLINECODE5–>	Individual page HTML	Standard websites with a reasonable number of pages
HTTP header	Server response header	Non-HTML files (PDFs) or situations where editing the HTML head isn't practical
XML sitemap	Sitemap file, not the page itself	Large sites with many language variants, where centralizing annotations in one file is more maintainable than editing thousands of individual pages

Whichever method is used, every language/region variant of a page needs to reference every other variant, including itself. That self-reference requirement is the most common source of hreflang errors in practice.

A minimal HTML implementation for a page with English and French-Canadian versions, including a self-reference and an x-default fallback, looks like this:

<link rel="alternate" hreflang="en-us" href="https://example.com/en/page" />
<link rel="alternate" hreflang="fr-ca" href="https://example.com/fr-ca/page" />
<link rel="alternate" hreflang="x-default" href="https://example.com/page" />

Each of the three URLs in a cluster like this needs the same three tags present, pointing to the same three destinations, including a tag pointing back to itself. Skipping the self-referencing line on any one of the three is a self-reference error even if the other two tags are correct.

Hreflang and site architecture

Hreflang works the same way regardless of how international content is structured on a domain, but the underlying URL architecture affects how much annotation upkeep is required going forward:

• Subdirectories (example.com/fr/, example.com/es/): the most common and generally easiest to maintain, since everything lives under one domain and one Search Console property.
• Subdomains (fr.example.com, es.example.com): functionally similar to subdirectories for hreflang purposes, but typically requires separate Search Console properties per subdomain, which adds monitoring overhead.
• Country-code top-level domains (example.fr, example.es): carries the strongest country-targeting signal on its own, independent of hreflang, but is the most operationally expensive to maintain since each ccTLD is effectively a separate site requiring its own hosting, SSL, and content management.

None of these architectures is inherently better for hreflang specifically; the choice is usually driven by broader business, branding, and infrastructure considerations, and hreflang is layered on top of whichever structure is already in place.

x-default and the reciprocity rule

Two rules govern correct hreflang implementation, and violating either one is the most common cause of hreflang being ignored or misapplied:

1. Self-reference: each page in a hreflang cluster must include an hreflang tag pointing to itself, not just to its alternate versions.
2. Reciprocity (bidirectional linking): if Page A declares an hreflang relationship to Page B, Page B must declare the same relationship back to Page A. A one-directional hreflang reference is treated as invalid and is commonly ignored.

How common are hreflang errors, really

A study by Dan Taylor (SALT.agency) conducted in partnership with NerdyData and covered by Search Engine Land analyzed 18,786 websites containing hreflang code and found that 31.02% had conflicting hreflang directives, meaning multiple URLs assigned to a single language and region combination (Study: 31% of international websites contain hreflang errors, Search Engine Land). The same study found other error types at different rates: missing self-reference tags at 16.04%, missing x-default at 47.95%, invalid language codes at 8.91%, and invalid region codes at 1.6%.

The 31% figure specifically describes conflicting directives, not “any hreflang mistake” broadly, and it’s specific to hreflang implementation error rates, not a general international-SEO statistic to be reused elsewhere. Given how commonly conflicting directives show up even on sites that clearly invested effort into international SEO, validating hreflang after any template or CMS change is worth treating as routine maintenance rather than a one-time setup task.

Google Search Console’s hreflang report no longer exists

This is the part of hreflang guidance that’s most likely to be out of date across the web: Search Console’s International Targeting report, which used to be the standard way to check hreflang errors and set manual country targeting, was deprecated in September 2022. Google’s own help documentation confirms the report has been discontinued and that manual country targeting through Search Console is no longer available, while noting that hreflang support itself continues; only the dedicated report and the country-targeting feature were removed (The International Targeting report is deprecated, Search Console Help).

If a guide, consultant, or internal process still references “checking the International Targeting report” as a monitoring step, that instruction is no longer actionable, the report simply isn’t there anymore. Practical replacement approach for monitoring hreflang without a dedicated GSC report:

• Third-party crawlers. Tools like Screaming Frog and Sitebulb include hreflang auditing features that flag missing return tags, missing self-references, and conflicting entries across a full site crawl. Specific report counts and menu locations shift between tool versions, so check current documentation for the version you’re running rather than relying on an exact step count from an older guide.
• URL Inspection tool. Useful for spot-checking whether a specific URL’s hreflang tags are being read correctly, though it doesn’t provide a site-wide error summary.
• View-source or rendered-HTML checks. For a quick manual sanity check on a handful of pages, viewing the page source (or rendered DOM, if hreflang is injected via JavaScript) confirms the tags are actually present and correctly formatted.

None of these fully replace what a purpose-built dashboard report offered, but a third-party crawler combined with periodic manual spot checks is currently the realistic way to monitor hreflang health.

This is a meaningful gap for any site that scaled up international content between roughly 2018 and 2022, since that’s the window during which the International Targeting report was a genuinely standard part of the international-SEO workflow. Documentation, training materials, and internal SOPs written during that period frequently still reference it as an active tool. If a process document or a client-facing report template mentions checking that report, it’s worth flagging and updating rather than leaving the instruction in place unquestioned.

Hreflang vs. canonical: where they conflict

Hreflang and canonical tags serve different purposes but can undermine each other if implemented carelessly. A canonical tag says “this is the authoritative version of this content.” Hreflang says “here is the equivalent version for this language and region.” Problems arise when a canonical tag on a translated page points back to the original-language version instead of self-referencing; this effectively tells search engines the translated content isn’t the authoritative version of itself, which can conflict with or undercut the hreflang cluster entirely. Each language/region variant should canonicalize to itself, not to a different-language “original.” The mechanics of canonical tag implementation generally are covered in a dedicated canonical guide; the point relevant here is narrower: within an hreflang cluster, canonical and hreflang need to agree with each other, not contradict.

Validation tools

• Third-party crawlers (Screaming Frog, Sitebulb) for full-site hreflang audits, including reciprocity and self-reference checks
• Google’s URL Inspection tool for confirming what Google actually parsed on a specific URL
• Manual source inspection for quick spot checks, particularly useful right after a deployment

Common mistakes

• Using region codes that don’t correspond to a real content or language difference
• Missing self-reference tags, which the underlying research found in roughly 1 in 6 sites analyzed
• Missing reciprocal (return) tags between paired URLs
• Mixing implementation methods (HTML tags on some pages, sitemap entries for others) for the same URL set, creating conflicting signals
• Relying on Search Console’s International Targeting report for monitoring, a report that has not existed since September 2022
• Canonical tags on translated pages pointing to the original-language version instead of self-referencing

Hreflang is a narrow, syntax-sensitive feature, and the two rules that break most often (self-reference and reciprocity) are also the two that are easiest to check systematically with a crawler. Get those right, keep canonical tags self-referential within each language cluster, and monitor through a third-party crawler rather than a Search Console report that’s no longer there.