Ch 11 — International¶

Part V — Site design · The Technical SEO Reference

Playbook coupling: seo-checklist.md covers international in one Phase 1 line (line 93): one hreflang method, self + all alternates fully-qualified, x-default, mandatory return links, valid ISO codes (no "UK"/"EU"). This chapter supplies the full spec behind that line — method mechanics and formal constraints, the code grammar with its silent-failure traps, canonical×hreflang interaction (including a 2026 doc addition the checklist predates), the ccTLD/subdomain/subdirectory decision, geotargeting after the International Targeting report's removal, locale-adaptive crawling, and a debugging workflow for a world where GSC has no hreflang report. Directly relevant to the BM + English + Chinese, MY/SG/ID portfolio work.

hreflang is a serving mechanism, not a ranking input: it tells Google which member of an already-ranking cluster to show a given user. That framing dissolves most international-SEO confusion — hreflang can't lift you, it can only stop the wrong country's URL from appearing. And because ignored annotations produce no error anywhere in Search Console, hreflang fails silently: the only symptom is the wrong URL ranking somewhere.

11.1 What hreflang does — and when you need it¶

🟢 Purpose: annotations "will help Google Search point users to the most appropriate version of your page by language or region" — localized versions doc (last updated 2025-12-22).
🟢 Optional in principle: "even without taking action, Google might still find alternate language versions of your page, but it is usually best for you to explicitly indicate your language- or region-specific pages."
🟢 The three documented scenarios where Google recommends it: translated boilerplate around single-language main content (forums/UGC); small same-language regional variations (en-US/en-GB/en-IE); fully translated sites.
🟡 Ranking: Mueller has repeatedly stated hreflang does not change ranking — it swaps which URL is shown (X reply, Mar 10, 2022, "No. Hreflang does not change ranking"; primary post unavailable — per V0, keep 🟡). Consistent with the docs' serving-only framing. ⚪ Any "hreflang consolidates signals between versions" claim is pure lore — no Google doc describes cross-alternate signal sharing.

11.2 The three implementation methods¶

🟢 "The three methods are equivalent from Google's perspective and you can choose the method that's the most convenient for your site." Choosing is a maintenance decision:

Method	Mechanics	Formal constraints	Scale profile (⚪)
HTML `<link>` tags	One tag per alternate in every page's head	🟢 "must be inside a well-formed `<head>`" — broken markup before the tags can invalidate them; 🟢 (Jun 12, 2024) "don't combine link tags for alternate representations… don't combine hreflang annotations with other attributes such as media in a single `<link>` tag"	N tags on every page; template complexity
HTTP `Link:` headers	Header per response	🟢 "useful for non-HTML files (like PDFs)"	Suits binaries and header-manageable infra
XML sitemap	`xmlns:xhtml` namespace; each `<url>` carries `<xhtml:link rel="alternate">` children listing "every alternate version of the page, including itself"	🟢 "Child elements don't count towards the URL limit for sitemaps" — a 20-locale site doesn't burn its 50k cap on annotations (→ Ch 9)	Centralized; deploys without template changes; O(N²) entries per cluster

All methods: 🟢 "Alternate URLs must be fully-qualified, including the transport method (http/https)" — no relative or protocol-relative URLs; and "Alternate URLs do not need to be in the same domain" — cross-domain hreflang across a ccTLD portfolio is supported.

11.3 Return links and partial clusters¶

🟢 "Each language version must list itself as well as all other language versions" — self-reference is mandatory.
🟢 ⚠️ The famous failure mode: "If two pages don't both point to each other, the tags will be ignored." The handshake exists because anyone can annotate someone else's URL; reciprocity is the proof of ownership.
🟢 ⚠️ The half everyone misses — partial clusters are legal: "If it becomes difficult to maintain a complete set of bidirectional links for every language, you can omit some languages on some pages; Google will still process the ones that point to each other." Ignoring is per-pair, not per-site. An incomplete 30-locale matrix is degraded, not dead — which changes how you architect large matrices: prioritize reciprocity between the pairs that matter commercially.

11.4 Code grammar — valid, invalid, and silently ignored¶

🟢 Grammar: "The first code… is the language code (in ISO 639-1 format) followed by an optional second code that represents the region code (in ISO 3166-1 Alpha 2 format)." The axes are independent: de (German, anywhere), en-GB (English for UK users), even de-ES (German for users in Spain).
🟢 ⚠️ Silent partial ignoring: "If you use codes that are listed as reserved for something else, Google Search ignores that part of the annotation (for example, using EU, UN, or UK in hreflang annotations doesn't have an effect on Google Search)." The UK's ISO code is GB. Because only the region part is dropped, en-UK degrades to bare en — the annotation half-works, which hides the bug from every quick check.
🟢 ⚠️ es-419 is not supported: "other codes that aren't listed in those standards, such as es-419, aren't supported" — Latin-American Spanish has no Google-valid regional code, though localization platforms emit it routinely. 📘 es-419 is a perfectly valid BCP 47 tag (UN M49 region) — Google's support is a subset of BCP 47; validate against Google's rules, not "valid BCP 47."
🟢 "Specifying the region alone is not valid" — hreflang="gb" is meaningless; language is mandatory, region optional, never the reverse.
🟢 Scripts (ISO 15924): "when using zh-TW for users in Taiwan, the language script is automatically derived (… Chinese-Traditional). You can also specify the script itself explicitly… zh-Hant … zh-Hans", with region appendable (zh-Hans-US). Directly relevant to Malaysian portfolios serving Simplified Chinese: zh-Hans (or zh-Hans-MY) is more precise than zh-CN when targeting script, not country.
📘 Case: BCP 47 tags are case-insensitive and Google's doc is silent on casing — en-GB capitalization is readability convention, not a requirement.

11.5 x-default¶

🟢 "The reserved x-default value is used when no other language/region matches the user's browser setting" — the fallback for unmatched users.
🟢 ⚠️ Not required to be the homepage: "While you can use the x-default value for any page, it was designed for language selector pages and so it will work best with those." It needs no language code ("the language of the page is irrelevant") and may coexist with a language annotation on the same URL — a page can be both en and x-default.
🟢 Google recommends it "especially on language/country selectors or auto-redirecting home pages," and for same-language multi-locale sets, "a catchall URL for geographically unspecified users of that language" (a generic /en/ alongside en-US and en-GB).

11.6 Canonical × hreflang¶

From the canonicalization doc (updated 2026-07-10) — the current authority on this interaction (→ Ch 8):

🟢 Same-language canonical rule: "If you're using hreflang elements, make sure to specify a canonical page in the same language, or the best possible substitute language if a canonical page doesn't exist for the same language." Never canonicalize the German page to the English one.
🟢 ⚠️ The little-known 2026-documented mechanic — cluster membership is a canonicalization signal: "For canonicalization purposes Google prefers URLs that are part of hreflang clusters. For example, if example.com/de-de/cats and example.com/de-ch/cats reciprocally point to each other… but not to example.com/de-at/cats, the pages for de-de and de-ch will be preferred as canonicals instead of the /de-at/ page." A page dropped from the cluster loses ground in canonical selection — reciprocity failures can cascade into deindexing-by-canonicalization.
🟢 Same-language regional duplicates get both mechanisms (multi-regional doc): "if both example.de/ and example.com/de/ show similar German language content, pick a preferred version and use the rel=canonical element and hreflang tags."
⚪ Derived (not stated in one sentence by Google, but forced by the rules): annotate only canonical, 200-status, indexable URLs — an annotation pointing at a redirecting, blocked, or non-canonical URL can't complete the handshake.

11.7 hreflang with pagination and parameters¶

🟢 hreflang is page-level with exact fully-qualified URLs — no wildcard, pattern, or site-level declaration exists. Every paginated page that should swap needs its own reciprocal set.
⚪ Derived composition: pair equivalent pages (/en/category?page=2 ↔ /de/category?page=2); annotating every page-2 to the other locale's page-1 breaks reciprocity. Google has published no explicit pagination-hreflang doc — this is derivation from the documented rules, and the book labels it so.
🟢 Component rules: each paginated page keeps its self-canonical (→ Ch 10 §10.6), so paginated clusters must be built on the self-canonical paginated URLs; crawl-blocked or canonicalized-away facet URLs cannot participate in clusters (a blocked URL can't confirm its return link) — annotate the clean category URLs only.

11.8 Site structure: ccTLD vs subdomain vs subdirectory¶

🟢 Google endorses no winner. Its documented tradeoff table (multi-regional doc):

Structure	Documented pros	Documented cons
ccTLD (`example.de`)	"Clear geotargeting; Server location irrelevant; Easy separation of sites"	"Expensive (can have limited availability); Requires more infrastructure; Strict ccTLD requirements"
Subdomain (`de.example.com`)	"Easy to set up; Allows different server locations; Easy separation of sites"	"Users might not recognize geotargeting from the URL alone"
Subdirectory (`example.com/de/`)	"Easy to set up; Low maintenance (same host)"	Recognition con + "Single server location"
URL parameters (`?loc=de`)	—	🟢 "Not recommended"

🟢 ⚠️ Twenty ccTLDs are treated as gTLDs — no country signal: .ad .ai .as .bz .cc .cd .co .dj .fm .io .la .me .ms .nu .sc .sr .su .tv .tk .ws, plus regional .eu and .asia. Picking .ai or .io surrenders ccTLD geotargeting — often exactly right for a global product, but it must be a decision, not an accident.
🟢 New/keyword/city/.BRAND TLDs (2015 Mueller blog post, still Google's only statement): "Keywords in a TLD do not give any advantage or disadvantage in search"; city TLDs "Even if they look region-specific, we will treat them as gTLDs"; most real ccTLDs geotarget by default. ⚠️ This 2015 post still tells readers to "set geotargeting in Search Console where relevant" — an instruction pointing at a dead feature (§11.9); Google's own docs contain the trap.
⚪ The agency absolutes — "ccTLDs rank better locally," "subdirectories inherit domain authority so they always win" — are not in any Google documentation. The general subdomain-vs-subdirectory question → Ch 10 §10.11.

11.9 Geotargeting after the International Targeting report¶

🟢 ⚠️ The report is dead with no replacement (help doc, live and verified Aug 2026): "The International Targeting report has been deprecated." Country targeting "was determined to have little value for the ecosystem, and is no longer supported"; "Google will continue to support and use hreflang tags on your pages." Deprecated Aug 24, 2022; UI removal ~Sep 22, 2022 (🟡 trade press for both dates — the live help doc itself is undated). Its hreflang error counts left GSC with it — nothing replaced them (§11.13). Any audit template saying "set country targeting in Search Console" runs on a dead feature.
🟢 The four documented locale signals: (1) ccTLDs — "a strong signal"; (2) hreflang "whether in tags, headers, or sitemaps"; (3) server location — "can be a signal… it is not a definitive signal"; (4) "Other signals… local addresses and phone numbers on the pages, the use of local language and currency, links from other local sites, or signals from your Business Profile."
🟢 What Google ignores: "Google ignores locational meta tags (like geo.position or distribution) or geotargeting HTML attributes" — SEO plugins still ship these; they do nothing.
🟢 ⚠️ Geotargeting is a trade, not a bonus: "This can improve your page rankings in the target country, but at the expense of results in other locales or languages."

11.10 Locale-adaptive pages and Googlebot's crawl origin¶

🟢 The core warning (locale-adaptive doc): for one-URL geo/language adaptation, "Google might not crawl, index, or rank all your content for different locales. This is because the default IP addresses of the Googlebot crawler appear to be based in the USA. In addition, the crawler sends HTTP requests without setting Accept-Language."
🟢 The recommendation: "We recommend using separate locale URL configurations and annotating them with rel=alternate hreflang annotations."
🟢 Geo-distributed crawling exists, unpromised: "Googlebot crawls with IP addresses based outside the USA, in addition to the US-based IP addresses… when Googlebot appears to come from a certain country, treat it like you would treat any other user from that country" — serving non-US Googlebot local content is expected behavior, not cloaking, provided real users from that country get the same. Verify geo-crawls via reverse DNS (→ Ch 5 §5.4).
🟢 ⚠️ Robots consistency across locales: "robots meta tags and the robots.txt file must specify the same rules in each locale."
The CMP/consent-wall interaction of US-egress crawling → Ch 6 §6.12.

11.11 Serving language variants¶

🟢 Exact wording, correctly weighted: "Avoid automatically redirecting users from one language version of a site to a different language version… don't redirect based on what you think the user's language may be" and "Don't use IP analysis to adapt your content. IP location analysis is difficult and generally not reliable." Strong guidance — not a listed spam policy. If the homepage must auto-redirect or is a selector, x-default is the documented mitigation (§11.5).
🟢 ⚠️ Language detection is visible-content-only: "Google uses the visible content of your page to determine its language. We don't use any code-level language information such as lang attributes, or the URL." lang= serves browsers and accessibility (keep it — the playbook's lang="en-MY" check is a UX/a11y item), but it does not tell Google anything.
🟢 "Google recommends using different URLs for each language version of a page rather than using cookies or browser settings"; add visible links between versions ("users can click to choose a different language version").
🟢 ⚠️ Boilerplate-only translation (common on UGC/forum properties): "can create a bad user experience if the same content appears multiple times in search results with various boilerplate languages" — the hreflang-for-UGC scenario exists precisely to manage this.
⚠️ (Feb 2024) Google deleted its old advice to robots.txt-block all auto-translated pages — the modern framing is quality-based: valueless machine translation falls under scaled content abuse (→ playbook ⛔ list), well-reviewed localization is fine.

11.12 IDN, non-ASCII URLs, currencies, and translated results¶

🟢 IDN: "It's fine to use localized words in the URL, or to use an Internationalized Domain Name (IDN)… use UTF-8 encoding in the URL… and remember to escape the URLs properly" when linking (multi-regional doc). ⚪ Punycode equivalence — treating xn-- and Unicode hostnames as the same host, with no redirect between them needed — is standard practice consistent with IDNA, but the oft-quoted "Google treats the Punycode version as equivalent" sentence appears in no current Google doc (V2 re-check found no primary; do not cite it as Google's). (URL encoding mechanics → Ch 10 §10.1.)
🟢 ⚠️ Multi-currency: merchant listing structured data requires "a distinct URL per currency… if a product is available for sale in Canadian and US dollars, use two distinct URLs, one per currency" (merchant listing doc). JS/cookie currency toggles on one URL forfeit shopping-surface price accuracy. ⚪ The standard architecture — locale pages each showing their market's currency at stable URLs, hreflang across locales — is a composition of Google's rules, not a single documented pattern.
🟢 Translated results (doc): "Google may translate the title link and snippet of a search result for results that aren't in the language of the search query" — 21 languages as of Jul 2024, no opt-in, opt out via notranslate. ⚠️ Diagnostic confounder: a traffic spike from an unlocalized-language country may be translated results, not an hreflang effect — check before debugging phantom hreflang problems.

11.13 Debugging hreflang with no GSC report¶

GSC has no native hreflang error surface (§11.9). 🟢 Google officially outsources debugging: "There are many third-party tools available that you can use to debug hreflang annotations… These tools are not maintained or checked by Google" (naming Aleyda Solis's generator and Merkle's tester). ⚪ The working stack:

Crawler audit (Screaming Frog/Ahrefs/Semrush hreflang reports): reciprocity matrix, invalid codes, non-canonical/redirecting targets, head validity — at scale.
GSC Performance filtered by country: which URL actually ranks per market — the ground truth the report used to hint at.
URL Inspection on each variant: the Google-selected canonical. ⚠️ A variant folded into another locale's canonical is the classic cluster failure (§11.6) — check same-language canonicals and content differentiation.
Symptom taxonomy: wrong-country URL ranking → annotation ignored (reciprocity, codes, head validity); variants deindexed → cross-locale canonicalization; annotations to redirecting/blocked URLs → handshake broken.

Symptoms & diagnosis¶

Symptom	Likely cause	Where
Wrong country's URL ranks in a market	Ignored annotations: missing return link, reserved code (UK/EU), region-only value, broken head	§11.3, §11.4, §11.2
`en-UK` annotations "mostly working"	Silent partial ignore — degrades to bare `en`	§11.4
A locale variant vanished from the index	Canonicalized into a sibling locale (same-language rule violated; dropped from cluster)	§11.6
Non-US content variants never indexed	Locale-adaptive single-URL serving; US-egress cookieless crawling	§11.10
es-419 annotations doing nothing	Valid BCP 47, unsupported by Google	§11.4
Traffic from languages you never localized	Translated results, not hreflang	§11.12
Audit says "set GSC country targeting"	Dead feature (removed 2022, no replacement)	§11.9
Homepage auto-redirects by IP; inconsistent indexing	Missing x-default; IP-adaptation against guidance	§11.5, §11.11
Shopping surfaces show wrong currency	Currency toggle on one URL — needs distinct URL per currency	§11.12
Paginated locale pages cross-canonicalizing	Clusters not built on self-canonical paginated URLs	§11.7

Sources¶

All fetched 2026-08-04 (V2 audit 2026-08-04 re-verified the localized-versions, multi-regional, locale-adaptive, consolidate-duplicate-urls, targeting-deprecation, translated-results, and merchant-listing quotes live; TLD-blog quotes confirmed via SEL relay after the primary rendered without body text): - Tell Google about localized versions of your page (2025-12-22) - Managing multi-regional and multilingual sites (2025-12-10) - How Google crawls locale-adaptive pages (2025-12-10) - Consolidate duplicate URLs (2026-07-10) - International Targeting report deprecation (no date shown) - Google's handling of new top level domains (2015-07) - Translated results (2025-12-10) - Merchant listing structured data (no date shown) - Documentation changelog (hreflang link-tag clarification Jun 12, 2024; translated-results expansion Jul 10, 2024; multilingual spring-cleaning Feb 2024) - 🟡 Mueller on hreflang & ranking (X reply Mar 10, 2022 — primary unavailable, per V0); 🟡 report UI-removal date (trade press, Sep 2022)