Table of Contents
Google Search Console International Targeting Report: Complete hreflang Guide (2026)
International SEO gets messy fast. If you run a multilingual site or serve users in multiple countries, Google needs explicit signals to understand which version of your content to serve to which audience. Without those signals, you'll show UK English to American users, French content to German readers, or your Spanish site in Latin America when you're targeting Spain.
The International Targeting report in Google Search Console is where you see how Google is interpreting your hreflang setup — and where you find errors before they silently kill your international traffic.
This guide covers everything: what the International Targeting report shows, how hreflang works, every error type and how to fix it, and how to structure international SEO correctly from the start.
Where to Find the International Targeting Report in GSC
- Log into Google Search Console
- Select your property
- In the left sidebar, scroll to Legacy tools and reports
- Click International targeting
Note: As of 2024, International Targeting is listed under "Legacy tools." Google moved it there as part of a GSC redesign, but the data is still accurate and actively updated. Don't let the "Legacy" label mislead you — this report remains the primary way to monitor hreflang errors at scale.
The report has two tabs: Language and Country.
The Language Tab: hreflang Errors
The Language tab shows your hreflang implementation and flags any errors Google found while processing your hreflang tags.
What is hreflang?
hreflang is an HTML attribute (or HTTP header, or sitemap tag) that tells Google:
- What language a page is written in
- What region it targets (optional)
- What the equivalent page is on alternate-language versions of your site
A standard hreflang implementation looks like this in your page's <head>:
<link rel="alternate" hreflang="en" href="https://example.com/en/about/" />
<link rel="alternate" hreflang="en-gb" href="https://example.com/en-gb/about/" />
<link rel="alternate" hreflang="fr" href="https://example.com/fr/about/" />
<link rel="alternate" hreflang="fr-fr" href="https://example.com/fr-fr/about/" />
<link rel="alternate" hreflang="x-default" href="https://example.com/about/" />
Key rules:
- hreflang values are lowercase BCP 47 language codes —
en,en-US,fr,de, notENorEnglish x-defaultis required — it's the fallback URL for users who don't match any language/region- Hreflang must be reciprocal — every page in the set must link to every other page in the set, including itself
Common hreflang Errors and Fixes
No return tags
This is the most common error. If Page A declares hreflang="fr" pointing to Page B, then Page B must also declare a hreflang tag pointing back to Page A. If it doesn't, Google ignores the entire hreflang set.
Fix: Ensure every page in your hreflang cluster links to every other page in the cluster, including a self-referential tag.
<!-- On your English page -->
<link rel="alternate" hreflang="en" href="https://example.com/en/about/" />
<link rel="alternate" hreflang="fr" href="https://example.com/fr/about/" />
<!-- On your French page — MUST also contain: -->
<link rel="alternate" hreflang="en" href="https://example.com/en/about/" />
<link rel="alternate" hreflang="fr" href="https://example.com/fr/about/" />
Unsupported language codes
Using hreflang="english" or hreflang="en_US" (underscore instead of hyphen) will cause an error. Google only recognizes ISO 639-1 language codes with optional ISO 3166-1 Alpha-2 region codes.
Valid examples: en, en-US, en-GB, fr, fr-FR, fr-CA, zh-Hans, zh-Hant
Invalid examples: english, en_US, FR, Spanish
Multiple values for a page
Each page should have exactly one hreflang value per language-region combination. Having hreflang="en-us" pointing to two different URLs is invalid.
Missing x-default tag
Google recommends (and some implementations require) an x-default tag that points to the default page — typically the homepage or the English-language version. Without it, Google has no fallback for users in unlisted regions.
Pages not in any hreflang set
If you have pages that should be in a hreflang cluster but aren't included in any rel=alternate tags, those pages may compete with each other in search — Google won't know which one to serve to which audience.
How to Implement hreflang: Three Methods
Method 1: HTML <head> Tags (Most Common)
Add <link rel="alternate"> tags to every page's <head>. Every page in the cluster must reference every other page plus itself.
Best for: Smaller sites, CMS platforms (WordPress, Webflow), sites where you control the page templates.
Downside: For large sites with hundreds of language versions, this adds significant HTML bloat to every page.
Method 2: XML Sitemap
Add hreflang information to your XML sitemap using the xhtml:link element:
<?xml version="1.0" encoding="UTF-8"?>
<urlset xmlns="http://www.sitemaps.org/schemas/sitemap/0.9"
xmlns:xhtml="http://www.w3.org/1999/xhtml">
<url>
<loc>https://example.com/en/about/</loc>
<xhtml:link rel="alternate" hreflang="en" href="https://example.com/en/about/"/>
<xhtml:link rel="alternate" hreflang="fr" href="https://example.com/fr/about/"/>
<xhtml:link rel="alternate" hreflang="x-default" href="https://example.com/about/"/>
</url>
<url>
<loc>https://example.com/fr/about/</loc>
<xhtml:link rel="alternate" hreflang="en" href="https://example.com/en/about/"/>
<xhtml:link rel="alternate" hreflang="fr" href="https://example.com/fr/about/"/>
<xhtml:link rel="alternate" hreflang="x-default" href="https://example.com/about/"/>
</url>
</urlset>
Best for: Large sites, sites where you can't easily modify page templates, e-commerce platforms.
Upside: Centralizes all hreflang data in one file, easier to maintain.
Downside: Requires keeping the sitemap in sync with the actual site structure.
Method 3: HTTP Headers
For non-HTML files (PDFs, documents) or server-side implementations:
Link: <https://example.com/en/document.pdf>; rel="alternate"; hreflang="en",
<https://example.com/fr/document.pdf>; rel="alternate"; hreflang="fr"
Rarely used for standard web pages, but useful for international PDF or file downloads.
hreflang URL Structure: Common Approaches
How you structure URLs for international sites affects both hreflang and overall SEO:
| Structure | Example | Pros | Cons |
|-----------|---------|------|------|
| Country subdirectory | example.com/en/ | Most recommended; clear structure; easy CDN targeting | Slightly longer URLs |
| Country subdomain | en.example.com | Clear separation; can set different server locations | Treated as separate sites by Google; authority not shared as easily |
| Country-code TLD | example.co.uk | Strong geotargeting signal for country | Most expensive; requires separate domain maintenance per country |
| URL parameters | example.com?lang=en | Easiest to implement | Google doesn't recommend; crawl budget issues |
For most sites, subdirectories (/en/, /fr/, /de/) are the right choice. They're easy to maintain, share domain authority, and give Google clear signals.
The Country Tab: Geotargeting Settings
The Country tab in the International Targeting report shows whether you've set an explicit geographic target for your site or property.
When to Use Country Targeting
Country targeting tells Google: "This site is primarily for users in [country]." It's most relevant when:
- Your domain is a generic TLD (
.com,.net,.org) but your audience is primarily one country - You have different Search Console properties for different country subdirectories
- You want to give Google a stronger geotargeting signal for country-specific content
How to Set Country Targeting
In the Country tab:
- Click the dropdown menu
- Select your target country
- Click Save
If you're running a truly global site, leave this unset. Forcing geotargeting to "United States" when you have users in the UK, Australia, and Canada will hurt your performance in those other markets.
Country Targeting vs. hreflang
These are complementary, not competing, signals:
- Country targeting in GSC: Site-level or property-level signal. "This entire property targets France."
- hreflang: Page-level signal. "This specific page is for French speakers, and here's the equivalent page for German speakers."
For most international sites, you'll use hreflang at the page level and leave country targeting unset at the site level (unless you have separate GSC properties per country subdirectory).
Diagnosing International SEO Problems
Beyond the International Targeting report, use these signals to diagnose problems:
Check Performance Report by Country
In the Performance report, add a country dimension:
- Click +New under the filters
- Select Country
- Compare impressions and clicks by country
If you expect traffic from Germany but see almost none despite having a German version, check whether your hreflang is set up correctly for that language-region combination.
Check for Cannibalization
When hreflang fails, your English, French, and German pages may all show up for the same queries — competing with each other instead of serving different audiences. In the Performance report, filter by your target keyword and check which URLs are getting impressions. Seeing /en/about/ and /fr/about/ both appearing for English queries indicates hreflang isn't being processed correctly.
Crawl Coverage by Language Version
In the Coverage report, check whether Google is discovering and indexing your alternate-language pages at roughly the same rate as your primary language pages. If your English site has 500 indexed pages but your French version only has 50, Google may not be finding the full French content (possibly because the hreflang links are the only discovery path for those pages, and there are errors in the hreflang implementation).
hreflang at Scale: Large Sites and Automation
Manual hreflang implementation breaks down fast. If you have 5,000 pages and 8 language versions, that's 40,000 pages that all need correct hreflang tags pointing to all 8 versions of every page. Maintaining this by hand is how bugs sneak in.
Automating hreflang with Sitemaps
The sitemap approach scales better than HTML tags for large sites because you maintain hreflang in a single place. The tradeoff: your sitemap generation system needs to be aware of all language relationships for every page.
For most CMS platforms, this means either:
- Using an international SEO plugin that builds hreflang sitemaps automatically (Yoast for WordPress, multilingual plugins for Shopify)
- Generating the sitemap programmatically from your database of page-language relationships
A common architecture: maintain a "page groups" table in your database that maps each page to its equivalents in other languages. Your sitemap generator queries this table to build the correct xhtml:link entries.
Testing hreflang at Scale
Don't rely solely on GSC to catch errors — by the time errors appear there, they've already been serving incorrectly for weeks. Use these additional checks:
hreflang validator tools: Several SEO tools can crawl your site and report hreflang errors before Google does. Screaming Frog with its hreflang module can audit all tags across your full site. Use it after any major site change.
Spot-checking with URL Inspection: Inspect a representative page from each language cluster using the URL Inspection Tool. The rendered page and HTTP response sections will show you whether Google is reading the hreflang tags correctly.
Staging environment checks: If you're deploying new language versions, test hreflang on staging before going live. A missing reciprocal tag on one template can invalidate hundreds of pages.
hreflang Pagination
If you have paginated content in multiple languages (e.g., a product category with pages /en/products/, /en/products/page/2/, etc.), hreflang applies to paginated pages too. Each paginated URL needs hreflang tags pointing to its equivalent in other languages — not just the first page.
One exception: if you use rel=canonical to consolidate paginated pages to page 1, and your alternate language also uses this approach, the hreflang on page 1 can represent the whole paginated series. Be consistent across all language versions.
International Targeting for Single-Language Sites Targeting Multiple Countries
Not every international situation involves multiple languages. If you have a single English site targeting both the US and the UK, you face a different set of decisions:
Option 1: Use en-US and en-GB hreflang tags
Create separate page versions for US and UK audiences (different spelling, pricing, product availability) and use hreflang to distinguish them. Only worth the effort if the content genuinely differs.
Option 2: Use URL-based geotargeting with GSC properties
If your site has /us/ and /uk/ subdirectories, create separate GSC properties for each and set country targeting per property. This is simpler than hreflang for the same-language scenario.
Option 3: Don't target — let Google figure it out
For most generic .com sites with primarily US content, Google correctly serves US content to US users without explicit signals. Only intervene when you're seeing evidence of misrouting (UK users getting US pricing, wrong currency, etc.).
Quick Reference: hreflang Checklist
Use this before launching any international site change:
[ ] All hreflang values use valid BCP 47 language codes (lowercase, hyphen separator)
[ ] Every page in each cluster has a self-referential hreflang tag
[ ] Every page links to every other page in the cluster (reciprocal tags)
[ ] x-default tag present on every page in each cluster
[ ] No duplicate hreflang values (same language-region on same page twice)
[ ] hreflang URLs return 200 status (not 404 or redirect)
[ ] Sitemap updated if using sitemap-based hreflang
[ ] International Targeting report checked after implementation for new errors
[ ] Performance report monitored for country-specific traffic changes (allow 4-8 weeks)
Frequently Asked Questions
Does hreflang affect rankings for the primary language version of my site?
hreflang doesn't directly affect rankings for any specific version. Its job is to ensure the right version appears to the right audience — it doesn't boost or reduce rankings. However, if your hreflang is broken and your English and French pages are competing with each other for the same queries, that cannibalization can indirectly hurt rankings for both.
How long does it take for hreflang changes to take effect?
Google needs to crawl and reprocess every page in the hreflang cluster before the signals take effect. For large sites with thousands of pages, this can take weeks. Check the International Targeting report 4-6 weeks after implementation to see if error counts have dropped. Use URL Inspection to test individual pages sooner.
My site has hreflang errors in GSC but traffic seems fine. Should I still fix them?
Yes. Traffic appearing fine now doesn't mean hreflang is working correctly — it may mean Google is making educated guesses that happen to be right most of the time. Unresolved hreflang errors usually cause problems over time, especially when you expand to new markets. Fix errors proactively.
Can I use hreflang for content that's the same in every language but targets different regions (e.g., US vs. UK English)?
Yes, but consider whether it's worth the implementation complexity. If the only difference is minor spelling variations (colour vs. color), a single page targeting both may rank fine in both countries without any hreflang. Use hreflang for region-specific content when there's genuine difference: pricing, product availability, legal disclosures, or significantly different content.
What's the difference between hreflang and lang attribute on the <html> element?
The lang attribute (<html lang="en">) tells browsers and accessibility tools what language the page is in — it's primarily for screen readers and browser translation prompts. hreflang tells Google about alternate versions for different audiences. Both are useful: lang for accessibility and browser behavior, hreflang for international SEO. They're not interchangeable.
Should I use hreflang if I only have one language but two country versions?
Only if the content genuinely differs between countries. If you have example.com/us/ and example.com/au/ with identical content, use canonical tags to point both to the primary version rather than hreflang. Using hreflang on identical content is unnecessary overhead and can confuse Google's processing.
What happens if I have hreflang in both my HTML and sitemap?
You'll get duplicate hreflang signals. Google may process both, which can cause conflicts if they're not identical. Pick one implementation method and use it exclusively. HTML tags are more reliable for smaller sites; sitemap-based hreflang is better for large sites. Remove the conflicting implementation to avoid errors.
For related GSC topics, see: Google Search Console Coverage Report Guide and How to Use Google Search Console for Keyword Research.