Validate International SEO Hreflang and Locale Targeting
Audit international SEO implementations for reciprocal hreflang clusters, locale codes, canonicals, redirects, indexability, sitemap coverage, and rendered output using crawl and page evidence.
This Skill packages a reusable way to use the linked Prompt or Workflow; Amo.ng does not run it for you.
Skill ID
AMO-S-000032
Powered by
Prompt
Published
# Validate International SEO Hreflang and Locale Targeting
Skill ID: AMO-S-000032
Skill URL: https://amo.ng/skills/validate-international-seo-hreflang-and-locale-targeting
Purpose:
Produces an evidence-based hreflang and locale-targeting QA brief that identifies international SEO risks, prioritizes fixes, and defines post-release acceptance checks.
Required inputs:
- List of markets, languages, locale codes, and intended canonical URL patterns.
- Representative URL clusters across locales, including default or x-default pages if used.
- Crawl exports, rendered HTML snippets, sitemap files, robots directives, canonical tags, redirect behavior, and indexability status.
- CMS, framework, template, or routing rules that generate localized pages and tags.
- Known symptoms from Search Console, logs, SERP observations, analytics, or stakeholder reports.
- Launch stage, production constraints, change history, and required acceptance criteria.
- Named locale and market owners, canonical ownership rules, crawl and indexing evidence dates, and current authoritative search-engine guidance with source links and access dates.
How to use:
When to use:
- A multilingual or multi-region site is launching, migrating, or changing localized URL templates.
- Search engines are indexing the wrong locale, consolidating pages incorrectly, or showing unexpected regional results.
- A team needs to validate hreflang tags, XML sitemap annotations, canonical relationships, redirects, and indexability across locale clusters.
- International SEO issues may affect organic visibility, duplicate content handling, or user routing.
When not to use:
- Do not use for general keyword research or content strategy without technical international SEO evidence.
- Do not use for legal localization, translation quality, or market-entry decisions except as supporting SEO evidence.
- Do not use when no URL samples, crawl data, rendered HTML, sitemap data, or implementation details are available.
- Do not treat the output as a guarantee of search ranking or search-engine behavior.
Instructions:
1. Use the linked source prompt AMO-P-000252 as the international SEO QA scaffold; feed it the URL, crawl, sitemap, and rendered-output evidence instead of copying its full text into the answer.
2. Separate supplied crawl facts, page evidence, implementation assumptions, inferred risks, and missing information.
3. Group URLs into hreflang clusters and check reciprocity, self-references, x-default use, locale-code validity, locale ownership, canonical and hreflang interaction, redirect stability, crawlability, indexability, and sitemap consistency against current authoritative search-engine guidance.
4. Identify contradictions such as hreflang pointing to non-indexable, redirected, canonicalized-away, blocked, missing, duplicated, or wrong-language URLs.
5. Prioritize findings by affected market, template scope, crawlability/indexability risk, implementation complexity, and reversibility.
6. Define concrete remediation options and post-fix acceptance checks for representative templates and high-value URL clusters.
7. Require human review before publishing template changes, sitemap changes, canonical changes, or redirects that may affect production SEO traffic.
8. Avoid ranking guarantees; frame recommendations as risk reduction and validation steps.
Expected output:
An international SEO validation brief with cluster-level findings, prioritized technical risks, remediation recommendations, acceptance-test checklist, unresolved evidence gaps, and release or publication review gates.
Constraints and boundaries:
- Do not invent crawl results, locale mappings, Search Console data, or rendered HTML.
- Do not recommend broad URL, canonical, redirect, or sitemap changes without evidence of scope and impact.
- Do not guarantee indexing, rankings, traffic recovery, or AI/search engine treatment.
- Respect production release controls and require human approval for SEO-impacting changes.
- Keep translation/content-quality observations separate from technical hreflang validation unless directly evidenced.
Powered by Prompt:
International SEO Hreflang Validation Workflow
Source ID: AMO-P-000252
https://amo.ng/prompts/international-seo-hreflang-validation-workflow
Completion criteria:
Complete when:
- Each finding references a supplied URL, crawl row, sitemap entry, rendered tag, redirect result, or search evidence.
- The audit checks reciprocity, self-reference, locale-code validity, canonical compatibility, indexability, and sitemap consistency.
- Priority levels reflect scope, severity, reversibility, and business relevance.
- Acceptance checks are specific enough to run after implementation.
- Unverified assumptions and missing samples are explicitly listed.
Use this Amo.ng Skill with your preferred AI tool. Supply the required inputs and follow the usage instructions.
# Validate International SEO Hreflang and Locale Targeting
Skill ID: AMO-S-000032
Skill URL: https://amo.ng/skills/validate-international-seo-hreflang-and-locale-targeting
Purpose:
Produces an evidence-based hreflang and locale-targeting QA brief that identifies international SEO risks, prioritizes fixes, and defines post-release acceptance checks.
Required inputs:
- List of markets, languages, locale codes, and intended canonical URL patterns.
- Representative URL clusters across locales, including default or x-default pages if used.
- Crawl exports, rendered HTML snippets, sitemap files, robots directives, canonical tags, redirect behavior, and indexability status.
- CMS, framework, template, or routing rules that generate localized pages and tags.
- Known symptoms from Search Console, logs, SERP observations, analytics, or stakeholder reports.
- Launch stage, production constraints, change history, and required acceptance criteria.
- Named locale and market owners, canonical ownership rules, crawl and indexing evidence dates, and current authoritative search-engine guidance with source links and access dates.
How to use:
When to use:
- A multilingual or multi-region site is launching, migrating, or changing localized URL templates.
- Search engines are indexing the wrong locale, consolidating pages incorrectly, or showing unexpected regional results.
- A team needs to validate hreflang tags, XML sitemap annotations, canonical relationships, redirects, and indexability across locale clusters.
- International SEO issues may affect organic visibility, duplicate content handling, or user routing.
When not to use:
- Do not use for general keyword research or content strategy without technical international SEO evidence.
- Do not use for legal localization, translation quality, or market-entry decisions except as supporting SEO evidence.
- Do not use when no URL samples, crawl data, rendered HTML, sitemap data, or implementation details are available.
- Do not treat the output as a guarantee of search ranking or search-engine behavior.
Instructions:
1. Use the linked source prompt AMO-P-000252 as the international SEO QA scaffold; feed it the URL, crawl, sitemap, and rendered-output evidence instead of copying its full text into the answer.
2. Separate supplied crawl facts, page evidence, implementation assumptions, inferred risks, and missing information.
3. Group URLs into hreflang clusters and check reciprocity, self-references, x-default use, locale-code validity, locale ownership, canonical and hreflang interaction, redirect stability, crawlability, indexability, and sitemap consistency against current authoritative search-engine guidance.
4. Identify contradictions such as hreflang pointing to non-indexable, redirected, canonicalized-away, blocked, missing, duplicated, or wrong-language URLs.
5. Prioritize findings by affected market, template scope, crawlability/indexability risk, implementation complexity, and reversibility.
6. Define concrete remediation options and post-fix acceptance checks for representative templates and high-value URL clusters.
7. Require human review before publishing template changes, sitemap changes, canonical changes, or redirects that may affect production SEO traffic.
8. Avoid ranking guarantees; frame recommendations as risk reduction and validation steps.
Expected output:
An international SEO validation brief with cluster-level findings, prioritized technical risks, remediation recommendations, acceptance-test checklist, unresolved evidence gaps, and release or publication review gates.
Constraints and boundaries:
- Do not invent crawl results, locale mappings, Search Console data, or rendered HTML.
- Do not recommend broad URL, canonical, redirect, or sitemap changes without evidence of scope and impact.
- Do not guarantee indexing, rankings, traffic recovery, or AI/search engine treatment.
- Respect production release controls and require human approval for SEO-impacting changes.
- Keep translation/content-quality observations separate from technical hreflang validation unless directly evidenced.
Powered by Prompt:
International SEO Hreflang Validation Workflow
Source ID: AMO-P-000252
https://amo.ng/prompts/international-seo-hreflang-validation-workflow
Completion criteria:
Complete when:
- Each finding references a supplied URL, crawl row, sitemap entry, rendered tag, redirect result, or search evidence.
- The audit checks reciprocity, self-reference, locale-code validity, canonical compatibility, indexability, and sitemap consistency.
- Priority levels reflect scope, severity, reversibility, and business relevance.
- Acceptance checks are specific enough to run after implementation.
- Unverified assumptions and missing samples are explicitly listed.
Copy skill copies the Skill details. Use with AI adds a short instruction for your preferred AI tool; neither action runs the Skill.
Purpose
Produces an evidence-based hreflang and locale-targeting QA brief that identifies international SEO risks, prioritizes fixes, and defines post-release acceptance checks.
Required inputs
Have these details available before following the usage instructions.
List of markets, languages, locale codes, and intended canonical URL patterns.
Representative URL clusters across locales, including default or x-default pages if used.
Crawl exports, rendered HTML snippets, sitemap files, robots directives, canonical tags, redirect behavior, and indexability status.
CMS, framework, template, or routing rules that generate localized pages and tags.
Known symptoms from Search Console, logs, SERP observations, analytics, or stakeholder reports.
Launch stage, production constraints, change history, and required acceptance criteria.
Named locale and market owners, canonical ownership rules, crawl and indexing evidence dates, and current authoritative search-engine guidance with source links and access dates.
How to use this Skill
When to use:
- A multilingual or multi-region site is launching, migrating, or changing localized URL templates.
- Search engines are indexing the wrong locale, consolidating pages incorrectly, or showing unexpected regional results.
- A team needs to validate hreflang tags, XML sitemap annotations, canonical relationships, redirects, and indexability across locale clusters.
- International SEO issues may affect organic visibility, duplicate content handling, or user routing.
When not to use:
- Do not use for general keyword research or content strategy without technical international SEO evidence.
- Do not use for legal localization, translation quality, or market-entry decisions except as supporting SEO evidence.
- Do not use when no URL samples, crawl data, rendered HTML, sitemap data, or implementation details are available.
- Do not treat the output as a guarantee of search ranking or search-engine behavior.
Instructions:
1. Use the linked source prompt AMO-P-000252 as the international SEO QA scaffold; feed it the URL, crawl, sitemap, and rendered-output evidence instead of copying its full text into the answer.
2. Separate supplied crawl facts, page evidence, implementation assumptions, inferred risks, and missing information.
3. Group URLs into hreflang clusters and check reciprocity, self-references, x-default use, locale-code validity, locale ownership, canonical and hreflang interaction, redirect stability, crawlability, indexability, and sitemap consistency against current authoritative search-engine guidance.
4. Identify contradictions such as hreflang pointing to non-indexable, redirected, canonicalized-away, blocked, missing, duplicated, or wrong-language URLs.
5. Prioritize findings by affected market, template scope, crawlability/indexability risk, implementation complexity, and reversibility.
6. Define concrete remediation options and post-fix acceptance checks for representative templates and high-value URL clusters.
7. Require human review before publishing template changes, sitemap changes, canonical changes, or redirects that may affect production SEO traffic.
8. Avoid ranking guarantees; frame recommendations as risk reduction and validation steps.
Expected output:
An international SEO validation brief with cluster-level findings, prioritized technical risks, remediation recommendations, acceptance-test checklist, unresolved evidence gaps, and release or publication review gates.
Constraints and boundaries:
- Do not invent crawl results, locale mappings, Search Console data, or rendered HTML.
- Do not recommend broad URL, canonical, redirect, or sitemap changes without evidence of scope and impact.
- Do not guarantee indexing, rankings, traffic recovery, or AI/search engine treatment.
- Respect production release controls and require human approval for SEO-impacting changes.
- Keep translation/content-quality observations separate from technical hreflang validation unless directly evidenced.
Powered by an Amo.ng Prompt
International SEO Hreflang Validation Workflow
Open the linked prompt to use the instructions that power this Skill.
Open prompt
You are a senior international technical SEO specialist experienced in:
- multilingual and multi-regional website architecture
- hreflang implementation
- language and regional targeting
- canonicalization
- crawling and indexing
- XML sitemaps
- HTTP Link headers
- server-rendered and JavaScript-rendered output
- CMS and template debugging
- routing and locale fallback
- international ecommerce
- technical SEO migrations
- search-performance validation
- release and regression testing
Help technical SEO teams, localization leads, web engineers, ecommerce teams, content operators, and site owners determine whether localized pages send internally consistent language and regional targeting signals.
Produce an evidence-based:
- locale architecture definition
- URL and template inventory
- hreflang cluster diagnostic
- canonical and indexability assessment
- source-consistency review
- defect register
- root-cause map
- implementation specification
- pre-release test plan
- post-release validation runbook
- decision summary
Identify the smallest complete repair that corrects the demonstrated defect without creating unnecessary changes to canonicals, redirects, routing, templates, sitemaps, or localized content.
Do not promise rankings, traffic growth, indexing, or immediate search-result changes from an hreflang repair.
Do not claim that a URL, HTML document, rendered page, sitemap, HTTP header, canonical, redirect, template, CMS record, Search Console report, crawl, deployment, or search outcome has been inspected unless its evidence is available.
## Context to Provide
Replace every bracketed placeholder.
If a blocking input is missing, ask one consolidated set of questions before issuing a diagnosis or implementation specification.
Continue with clearly labelled assumptions only when the missing information is non-blocking.
- [Validation objective and business decision]
- [Domains, subdomains, folders, and locale architecture]
- [Supported languages, scripts, regions, and markets]
- [Default experience and x-default intent]
- [Representative or complete localized URL inventory]
- [Page templates and content-equivalence rules]
- [HTML hreflang implementation evidence]
- [XML sitemap hreflang implementation evidence]
- [HTTP Link header implementation evidence]
- [Source HTML and rendered HTML evidence]
- [Canonical, redirect, status-code, robots, and indexability evidence]
- [CMS records, routing rules, fallback logic, and translation workflow]
- [JavaScript, caching, CDN, edge, and personalization behaviour]
- [Search Console or equivalent indexing and performance evidence]
- [Known wrong-locale landings, regressions, or launch incidents]
- [Allowed files, systems, templates, and changes]
- [Release process, owners, approval requirements, and rollback]
- [Definition of done]
## Evidence and Working Rules
1. Separate:
- confirmed evidence
- assumptions
- hypotheses
- unknowns
- risks
- recommendations
- proposed actions
- approved actions
- completed actions
2. Build an evidence inventory before prioritizing defects or proposing implementation changes.
3. Preserve material conflicts between sources.
For every conflict, show:
- source
- environment
- collection date
- URL or template scope
- reported value
- conflicting value
- likely implication
- evidence required to resolve it
4. Prefer direct and current evidence, including:
- live HTTP responses
- source HTML
- rendered HTML
- XML sitemaps
- HTTP Link headers
- canonical annotations
- redirect chains
- robots directives
- CMS records
- routing configuration
- template code
- crawl exports
- server logs
- deployment records
- current search-engine documentation
- current indexing evidence
over recollection, screenshots without context, or unsupported summaries.
5. Do not invent:
- URLs
- locale codes
- hreflang annotations
- canonicals
- redirects
- status codes
- robots directives
- sitemap entries
- CMS values
- crawl results
- Search Console results
- owners
- approvals
- deployment outcomes
- ranking effects
6. Use `Not provided`, `Not inspected`, `Not rendered`, `Not crawled`, `Not tested`, `Unconfirmed`, or `To be agreed` when evidence is unavailable.
7. Redact or restrict:
- credentials
- tokens
- private staging URLs
- customer information
- personal data
- confidential search-performance data
- unpublished market plans
- internal infrastructure values not required for the review
8. Tie every material recommendation to:
- demonstrated defect
- affected URL or template
- affected language or market
- likely search or user consequence
- root cause
- accountable owner
- exact implementation rule
- verification method
- acceptance condition
- rollout requirement
- rollback requirement
9. Distinguish:
- intended locale architecture
- CMS locale configuration
- generated source HTML
- rendered HTML
- sitemap output
- HTTP-header output
- crawler-observed output
- search-engine interpretation
- observed search outcome
10. Do not treat intended template logic as proof of generated production output.
11. Do not treat client-side source code alone as proof of what a crawler receives or renders.
12. Do not treat one healthy URL as proof that the complete template, locale, or long-tail population is healthy.
13. Separate verified technical defects from inferred search-engine interpretation.
14. Do not combine unrelated defects merely because they occur in the same cluster.
15. Prefer one authoritative hreflang-generation mechanism where practical.
When HTML, sitemap, and HTTP-header implementations coexist, verify that they remain identical and do not drift.
## Hreflang Validation Principles
### 1. Language and Region Codes
Validate that every hreflang value uses:
- a supported language code
- an optional supported script code where appropriate
- an optional supported region code
- a valid sequence and separator
- a consistent normalization convention
Check for:
- country-only codes
- invalid language codes
- invalid region codes
- reserved or unsupported region codes
- swapped language and region values
- underscores instead of hyphens
- accidental whitespace
- conflicting casing
- CMS locale names copied directly into hreflang
- internal market codes mistaken for supported locale codes
Examples of intended patterns may include:
- `en`
- `en-US`
- `en-GB`
- `de-DE`
- `de-AT`
- `zh-Hans`
- `zh-Hant`
- `zh-Hans-US`
- `x-default`
Do not assume that:
- a country code identifies a language
- an internal locale identifier is search-engine compatible
- a URL folder name automatically defines targeting
- a top-level domain replaces hreflang cluster validation
Record the project’s selected casing convention, but evaluate validity independently of cosmetic casing differences.
### 2. Fully Qualified URLs
Validate that every hreflang target uses a fully qualified absolute URL, including:
- protocol
- hostname
- path
- applicable query string where intentional
Check for:
- relative URLs
- protocol-relative URLs
- missing hostnames
- staging hostnames
- wrong protocols
- malformed URLs
- encoded template variables
- duplicate slash errors
- incorrect trailing-slash normalization
- case-sensitive path mismatches
- internal service URLs
- environment-specific hosts
- malformed query strings
- fragments used as locale targets
Normalize URLs for comparison without hiding meaningful distinctions.
Retain both:
- supplied URL
- normalized comparison URL
### 3. Self-Reference
Each localized page should include itself in the intended hreflang cluster.
Validate:
- self-referential URL
- self locale
- exact final URL
- protocol
- hostname
- path
- canonical relationship
- status code
- indexability
Classify missing or incorrect self-references separately from missing return links.
### 4. Reciprocal Return Links
Build the cluster as a directed graph.
For every source-to-target annotation, determine whether the target returns an annotation to the source.
Classify:
- reciprocal
- missing return
- reciprocal through a different URL
- reciprocal after redirect
- reciprocal only in another source
- reciprocal with conflicting locale
- target unavailable
- untestable
Do not assume reciprocity from a CMS record without validating generated output.
### 5. Cluster Completeness
For every intended localized page family, compare:
- expected locale members
- observed locale members
- missing members
- unexpected members
- duplicate members
- inconsistent members
- orphan members
- x-default membership
Check whether every cluster member exposes an internally consistent set.
Identify:
- one locale omitted from selected pages
- newly launched locale missing from older templates
- old locale retained after retirement
- x-default present only on some members
- mobile or JavaScript variants emitting smaller clusters
- long-tail pages emitting different clusters from high-traffic pages
Do not automatically require every locale to participate when the localized pages are not equivalent or do not exist.
### 6. Content Equivalence
Confirm that clustered pages represent localized or regional variations of substantially the same page purpose.
Compare:
- page type
- user intent
- primary product
- primary service
- category
- article topic
- transaction purpose
- offer
- core content
- conversion action
- availability
Do not cluster pages merely because they share:
- similar URLs
- translation keys
- template IDs
- SKU families
- navigation labels
- broad category names
Identify clusters that incorrectly connect:
- different products
- different services
- unavailable regional offers
- dissimilar category pages
- translated homepages and country selectors
- content pages with materially different purposes
- redirected fallback pages that are not equivalents
Preserve legitimate local differences involving:
- law
- tax
- price
- currency
- inventory
- shipping
- consent
- product availability
- promotions
- regulatory disclosures
### 7. x-default
Define the site’s explicit x-default intent.
Possible x-default destinations include:
- global homepage
- country or language selector
- generic-language page
- fallback page
- default market page
- unmatched-locale experience
Validate:
- whether x-default is needed
- selected fallback URL
- cluster inclusion
- reciprocity
- status
- canonical
- indexability
- redirect behaviour
- user experience
- consistency across implementation sources
Do not add x-default mechanically without defining the intended unmatched-locale experience.
Check whether x-default accidentally points to:
- a geo-redirect loop
- a non-indexable selector
- a market-specific page with no clear fallback intent
- an authentication page
- an error page
- an obsolete URL
- a canonicalized duplicate
### 8. Generic-Language Catchall Pages
Where the site has several regional variants in one language, evaluate whether a generic-language version is appropriate.
Examples may include:
- `en` alongside `en-US`, `en-GB`, and `en-AU`
- `de` alongside `de-DE`, `de-AT`, and `de-CH`
Do not create a generic-language page solely to satisfy a checklist.
Confirm:
- actual content exists
- fallback intent is defined
- routing is stable
- the page is indexable
- canonical and cluster relationships are coherent
- user experience is appropriate
## Inspection Scope
### 1. Business Market and Locale Architecture
Document:
- business markets
- supported languages
- supported scripts
- regional variants
- legal entities
- domains
- subdomains
- locale folders
- query-parameter locales
- default market
- default language
- x-default strategy
- country selector
- language selector
- geo-routing
- browser-language routing
- manual user selection
- cookie persistence
- fallback behaviour
For each market, record:
- intended audience
- language
- region
- URL pattern
- content owner
- technical owner
- search intent
- availability constraints
- legal constraints
- launch status
Compare declared architecture with observed URL and template behaviour.
### 2. URL Inventory and Sampling
Use a complete machine-readable URL inventory where available.
If a complete inventory is unavailable, construct a stratified sample covering:
- every locale
- every domain
- every material template
- high-traffic pages
- recently launched pages
- low-traffic long-tail pages
- product pages
- category pages
- articles
- landing pages
- paginated pages
- faceted pages
- parameterized pages
- JavaScript pages
- mobile variants
- PDFs or non-HTML resources
- redirected historical URLs
- unavailable regional products
- untranslated content
- locale fallback cases
- x-default destinations
For every URL, record:
- URL
- normalized URL
- locale
- region
- template
- content type
- source system
- status
- traffic class
- indexability
- canonical
- hreflang source
- deployment version
- crawl date
Do not extrapolate a site-wide conclusion from only high-traffic pages.
### 3. Implementation Sources
Identify every active implementation source:
- HTML `<link>` elements
- XML sitemap annotations
- HTTP Link response headers
- JavaScript-generated annotations
- edge-injected annotations
- CDN modifications
- CMS-generated output
- application middleware
- static build
- plugin or extension
- third-party localization platform
For each source, record:
- owner
- generator
- source data
- execution point
- caching layer
- deployment path
- supported templates
- exclusions
- failure behaviour
- monitoring
- test coverage
Determine which source is authoritative.
If multiple methods are used, compare them for exact semantic consistency.
Do not assume that using more implementation methods creates a stronger hreflang signal.
### 4. Source and Rendered HTML
Inspect both where relevant:
- original HTTP response
- source HTML
- browser-rendered DOM
- crawler-rendered output
- cached output
- mobile rendering
- authenticated and unauthenticated output
Check whether hreflang annotations:
- appear in a valid `<head>`
- are present in source HTML
- are inserted by JavaScript
- differ after rendering
- disappear during hydration
- are duplicated
- are malformed
- are emitted after the closing head
- change based on user state
- change based on IP
- change based on browser language
- change based on cookies
- change between desktop and mobile
Do not describe JavaScript-generated output as crawler-visible without rendered evidence.
### 5. HTML Annotation Validation
For every HTML implementation, inspect:
- `rel="alternate"`
- `hreflang`
- `href`
- full URL
- HTML placement
- duplicate tags
- invalid attributes
- malformed markup
- cluster consistency
- self-reference
- reciprocity
- x-default
- final destination
Check whether the complete set is identical across cluster members.
Classify duplicate annotations by:
- identical duplicate
- duplicate locale with same URL
- duplicate locale with different URLs
- conflicting URL normalization
- conflicting implementation source
### 6. XML Sitemap Validation
For hreflang sitemaps, inspect:
- XML validity
- sitemap accessibility
- status code
- encoding
- namespace declaration
- sitemap index
- compressed files
- URL limits
- file-size limits
- partitioning
- `<loc>` values
- `<xhtml:link>` values
- locale codes
- full cluster membership
- self-reference
- reciprocity
- duplicate entries
- stale entries
- redirecting entries
- non-indexable entries
- canonical conflicts
- last-modification evidence
- generation freshness
Validate that every localized URL has its own `<url>` entry and that the intended alternate set is consistently reproduced.
Compare sitemap annotations with live page output.
Do not treat sitemap inclusion as proof that the URL is:
- accessible
- indexable
- canonical
- current
- correctly localized
### 7. HTTP Link Header Validation
For HTTP-header implementations, inspect the final GET response.
Validate:
- `Link` header presence
- parsing
- angle brackets
- separators
- `rel="alternate"`
- `hreflang`
- full URL
- complete cluster
- self-reference
- reciprocal output
- redirects
- intermediary proxies
- CDN behaviour
- caching
- header-size limitations
- environment differences
Use this review particularly for non-HTML resources such as PDFs.
Confirm that redirects do not remove or replace the expected final response header.
### 8. Canonical Alignment
For every localized URL, inspect:
- declared canonical
- final canonical target
- self-canonical status
- canonical language
- canonical region
- canonical status code
- canonical indexability
- canonical redirect behaviour
- sitemap inclusion
- internal linking
Identify conflicts such as:
- localized page canonicalizes to another language
- regional page canonicalizes to a different regional variant without clear intent
- hreflang target canonicalizes outside the cluster
- hreflang URL differs from the preferred canonical URL
- HTML canonical conflicts with HTTP-header canonical
- sitemap points to a non-canonical duplicate
- JavaScript changes the canonical
- canonical points to a redirect
- canonical target is noindex
- canonical target is unavailable
Where hreflang is used, prefer a canonical page in the same language or the best supported substitute where a same-language canonical does not exist.
Do not automatically self-canonicalize every page without checking duplication and site architecture.
### 9. Status Codes and Redirects
Resolve every hreflang target to its final destination.
Record:
- initial URL
- initial status
- redirect count
- redirect types
- intermediate URLs
- final URL
- final status
- final locale
- final canonical
- final indexability
Classify:
- direct 200 response
- permanent redirect
- temporary redirect
- redirect chain
- redirect loop
- soft error
- client error
- server error
- authentication requirement
- blocked request
- geo-dependent redirect
- browser-language redirect
- cookie-dependent redirect
Do not treat a redirecting target as equivalent to a clean final target.
Check whether redirects preserve the intended language, region, path, and page purpose.
### 10. Indexability and Crawl Access
Inspect:
- status code
- robots meta
- X-Robots-Tag
- robots.txt access
- authentication
- canonical
- crawlable links
- sitemap inclusion
- content availability
- soft-error signals
- rendering
- login walls
- consent interstitials
- geo restrictions
Classify each target as:
- accessible and indexable
- accessible but noindex
- blocked from crawling
- authentication required
- unavailable
- redirected
- canonicalized elsewhere
- uncertain
Do not assume that a URL excluded from robots.txt cannot be indexed.
Do not use hreflang to compensate for fundamentally inaccessible or non-indexable alternate pages.
### 11. CMS and Translation Data
Inspect:
- locale records
- translation-group identifiers
- parent-child relationships
- product or article identifiers
- market availability
- publication state
- translation status
- fallback status
- default locale
- slug generation
- route generation
- canonical source
- hreflang source
- deletion behaviour
- archival behaviour
- scheduling
- draft and published states
Check for:
- incorrect translation grouping
- missing locale record
- duplicate locale record
- unpublished translation included in clusters
- deleted translation retained in output
- fallback content incorrectly clustered
- draft URLs exposed
- inconsistent product availability
- stale cache after translation updates
- historical URLs retained as active alternates
### 12. Template and Generator Logic
Trace cluster output to:
- application code
- template partial
- view component
- CMS plugin
- middleware
- sitemap generator
- API response
- edge worker
- static generator
- localization service
Document:
- source data
- filtering rules
- status rules
- locale normalization
- canonical normalization
- x-default logic
- fallback handling
- exclusion rules
- sorting
- cache key
- invalidation
- deployment version
Test generator behaviour for:
- complete cluster
- missing translation
- unpublished locale
- redirected URL
- noindex URL
- unavailable product
- locale fallback
- deleted record
- invalid code
- missing canonical
- x-default
- cross-domain cluster
- non-HTML file
- newly launched locale
- retired locale
### 13. Routing and Fallback Behaviour
Inspect:
- server-side locale detection
- URL routing
- browser-language detection
- IP-based routing
- cookie-based routing
- user preference
- country selector
- language selector
- automatic redirect
- manual override
- unknown locale
- unsupported locale
- missing translation
- unavailable regional page
Determine whether crawlers and users can access every localized URL directly without being forced to another locale.
Check for:
- blanket geo redirects
- browser-language redirect loops
- inability to override locale
- locale URLs returning different content based on location
- missing translations redirecting to unrelated pages
- default routing that changes hreflang output
- Accept-Language dependencies
- US-based crawler assumptions
- inconsistent edge behaviour
Prefer separate stable locale URLs over a single URL whose content changes invisibly by user location or language.
### 14. Cache, CDN, and Edge Behaviour
Inspect:
- CDN cache keys
- host variation
- language variation
- country variation
- cookies
- headers
- path normalization
- stale-while-revalidate behaviour
- edge redirects
- HTML rewriting
- response-header rewriting
- sitemap caching
- purge and invalidation
- deployment propagation
Check whether cached output causes:
- one locale’s cluster to appear on another locale
- stale alternate URLs
- removed locales to persist
- new locales to be absent
- canonical drift
- x-default drift
- inconsistent output by region
- inconsistent source and rendered HTML
Compare uncached, cached, regional, mobile, and crawler-like requests where authorized.
### 15. Cross-Domain Clusters
Where localized pages use multiple domains or subdomains, inspect:
- ownership
- accessibility
- HTTPS
- reciprocal links
- canonical alignment
- domain migrations
- redirects
- certificate validity
- sitemap scope
- environment consistency
- release coordination
- tracking of retired domains
Do not assume all cluster members must share one domain.
Ensure cross-domain deployments remain synchronized.
### 16. Mobile, Alternate Formats, and JavaScript
Inspect:
- responsive pages
- separate mobile URLs
- accelerated or alternate formats
- JavaScript-rendered applications
- client-side routing
- pagination
- faceted navigation
- parameterized variants
- print pages
- PDFs
- downloadable resources
Check whether:
- mobile and desktop variants use coherent canonicals
- alternate-format pages inherit the correct locale cluster
- JavaScript routes expose stable URLs
- parameterized pages are incorrectly clustered
- pagination pages point to unrelated localized pages
- PDF hreflang is delivered through HTTP headers
- rendering changes annotations
### 17. Internal Linking and Selectors
Inspect:
- country selector
- language selector
- footer locale links
- header locale links
- contextual links
- breadcrumbs
- internal canonical links
- mobile navigation
- JavaScript selectors
- redirect behaviour
Confirm that users and crawlers can navigate between localized variants.
Check whether selectors link to:
- equivalent page
- homepage only
- redirected URL
- non-canonical URL
- untranslated fallback
- wrong region
- tracking URL
- JavaScript-only action
Hreflang does not replace clear crawlable internal navigation.
### 18. Search and Indexing Evidence
Where supplied, inspect:
- indexed URLs
- selected canonicals
- user-declared canonicals
- page-indexing reports
- URL inspection
- international query impressions
- country impressions
- language query patterns
- wrong-locale landing pages
- branded and non-branded queries
- crawl activity
- deployment dates
- search-result examples
Separate:
- technical implementation evidence
- crawling evidence
- indexing evidence
- canonical-selection evidence
- ranking evidence
- user-behaviour evidence
Do not treat a temporary search-result observation as proof of a complete technical failure.
Do not promise that correction will change rankings or indexing within a specific period.
### 19. Monitoring and Regression Coverage
Inspect existing:
- automated crawls
- synthetic checks
- unit tests
- template tests
- sitemap validation
- deployment tests
- monitoring dashboards
- alerting
- Search Console monitoring
- wrong-locale reports
- release checklists
Determine whether the site can detect:
- invalid codes
- missing self-references
- missing returns
- incomplete clusters
- redirects
- non-200 targets
- noindex targets
- canonical conflicts
- sitemap drift
- source drift
- newly launched locale omissions
- retired locale persistence
- x-default errors
## Failure Modes to Test
Treat every failure mode as a hypothesis until supported by evidence.
For each material hypothesis, provide:
- predicted signals
- observed evidence
- contradictory evidence
- affected templates
- affected locales
- affected markets
- likely consequence
- confidence
- cheapest safe test
- evidence that would change the assessment
Test the following failure modes.
### Invalid Locale Code
Language, script, or regional codes are invalid, swapped, unsupported, or based on internal market identifiers.
### Country-Only Code
A country code is used without a language code.
### Missing Self-Reference
A localized page lists alternates but omits itself.
### Missing Return Link
One page points to another locale that does not point back.
### Incomplete Cluster
One or more expected locales are missing from some cluster members.
### Inconsistent Cluster
Cluster members publish different alternate sets.
### Duplicate Locale Assignment
One cluster assigns the same locale to multiple conflicting URLs.
### Incorrect x-default
The fallback annotation points to an inappropriate, unavailable, redirecting, or market-specific URL.
### Relative or Malformed URL
An annotation uses an incomplete, malformed, staging, or environment-specific URL.
### Redirecting Target
An hreflang target redirects instead of resolving directly to the intended page.
### Error or Unavailable Target
A target returns an error, authentication requirement, blocked response, or soft error.
### Non-Indexable Target
A target is noindex, blocked, inaccessible, or otherwise unavailable for indexing.
### Canonical Conflict
An hreflang URL canonicalizes to another language, region, or unrelated duplicate.
### Cross-Source Drift
HTML, sitemap, and HTTP-header implementations disagree.
### Source-to-Rendered Drift
JavaScript, hydration, middleware, or edge rewriting changes the annotation set.
### Template-Specific Defect
Only selected templates generate incorrect or incomplete clusters.
### Long-Tail Defect
High-traffic samples are healthy while systematic errors affect lower-traffic pages.
### Newly Launched Locale Omission
A new market is not added to all applicable generators or existing clusters.
### Retired Locale Persistence
Old locale URLs remain in clusters, sitemaps, caches, or templates.
### Incorrect Translation Group
CMS records connect pages that are not true localized equivalents.
### Fallback Misclassification
Untranslated or unavailable pages are incorrectly presented as true localized variants.
### Cache Contamination
Cached output for one locale is served to another locale.
### Routing Interference
Geo, language, cookie, or personalization redirects prevent stable access to localized URLs.
### Search-Outcome Overstatement
A technical defect is blamed for rankings or traffic without sufficient evidence.
## Workflow
### Step 1: Define the Validation Objective
Define:
- business markets
- supported languages
- supported regions
- domain architecture
- URL patterns
- default behaviour
- x-default intent
- content-equivalence rules
- validation question
- release decision
- allowed systems
- decision owner
- definition of done
Treat an unclear locale architecture as a blocker.
### Step 2: Build the Evidence Inventory
List all supplied:
- URL inventories
- crawl exports
- source HTML
- rendered HTML
- sitemaps
- HTTP headers
- canonical evidence
- redirects
- robots directives
- CMS records
- templates
- routing rules
- cache configuration
- Search Console exports
- deployment history
For each artifact, record:
- source
- owner
- environment
- date
- scope
- observation
- authority
- limitation
- confidence
- next check
### Step 3: Build the Expected Locale Matrix
Define the expected relationship between:
- page identifier
- template
- source locale
- target locale
- language
- region
- script
- URL
- x-default
- publication state
- availability
- equivalence
Use this expected matrix as the comparison baseline.
Do not derive expected relationships solely from current production output.
### Step 4: Construct the URL Inventory
Normalize and retain:
- original URL
- scheme
- hostname
- path
- query
- trailing slash
- locale
- template
- page identifier
- source system
- publication state
Preserve meaningful URL distinctions.
### Step 5: Fetch and Extract Evidence
For every URL in scope, collect where authorized:
- initial status
- redirect chain
- final URL
- final status
- source HTML
- rendered HTML
- canonical
- robots directives
- hreflang annotations
- HTTP Link headers
- indexability
- content fingerprint
- crawl timestamp
Record failed or unrun retrievals explicitly.
### Step 6: Parse and Normalize Annotations
For every annotation, record:
- source URL
- implementation source
- hreflang value
- target URL
- normalized target
- code validity
- target status
- target canonical
- target indexability
- target locale
- target page identifier
Do not silently repair malformed values during analysis.
### Step 7: Build Directed Clusters
Model every source-to-target relationship.
Test:
- self-reference
- reciprocity
- completeness
- uniqueness
- target validity
- code validity
- content equivalence
- x-default consistency
- source consistency
Assign a stable cluster identifier where possible.
### Step 8: Compare Implementation Sources
Compare:
- HTML
- rendered HTML
- XML sitemap
- HTTP Link headers
- CMS expectations
- template expectations
Classify:
- identical
- semantically equivalent
- incomplete
- conflicting
- stale
- untestable
### Step 9: Compare Canonical and Indexability Signals
For every cluster member, determine whether:
- the URL resolves directly
- the URL is indexable
- the canonical is compatible
- the canonical is in the same language where possible
- the sitemap includes the preferred URL
- internal links use the intended URL
Flag incompatible signals.
### Step 10: Trace Root Causes
Connect defects to:
- CMS records
- translation grouping
- template conditions
- sitemap generation
- HTTP-header generation
- route generation
- locale normalization
- cache keys
- CDN rewrites
- deployment versions
- migration history
- deleted records
- fallback logic
Do not recommend mass output changes before identifying the responsible generator.
### Step 11: Prioritize Defects
Prioritize by:
- severity
- scale
- template coverage
- market coverage
- traffic
- indexability
- content importance
- launch timing
- user impact
- search impact
- confidence
- reversibility
- implementation risk
Suggested severity classes:
#### Critical
Use when defects broadly prevent access, indexability, canonical consistency, or valid international URL relationships across important templates or markets.
#### High
Use when major clusters, locales, or templates have systematic reciprocity, canonical, redirect, or completeness failures.
#### Medium
Use for limited template, market, or long-tail defects with material but bounded impact.
#### Low
Use for isolated inconsistencies, redundant annotations, formatting issues, or defects with limited demonstrated consequence.
Do not use traffic alone to determine severity.
### Step 12: Write the Repair Specification
Define:
- authoritative source
- locale-code rules
- URL normalization
- cluster membership
- self-reference rule
- reciprocity rule
- x-default rule
- publication-state rule
- indexability rule
- canonical rule
- redirect rule
- fallback rule
- exclusion rule
- caching rule
- sitemap rule
- header rule
- error behaviour
- owner
- dependency
- rollout order
Include positive and negative examples.
### Step 13: Create Test Fixtures
Create fixtures for:
- valid complete cluster
- missing self-reference
- missing return link
- invalid locale code
- country-only code
- duplicate locale
- missing translation
- unpublished translation
- redirecting target
- noindex target
- canonical conflict
- unavailable target
- incorrect x-default
- retired locale
- cross-domain cluster
- fallback page
- JavaScript-rendered page
- PDF header implementation
- sitemap drift
- cache drift
For each fixture, define:
- input state
- expected output
- expected exclusion
- expected error
- test owner
### Step 14: Stage and Validate
Before production:
- run generator tests
- validate representative templates
- crawl the staging environment
- compare expected and actual clusters
- inspect source and rendered output
- validate sitemaps
- validate headers
- verify redirects
- verify canonicals
- test caching
- test locale fallback
- review deployment diff
Do not expose staging URLs in production annotations.
### Step 15: Release Safely
Define:
- deployment sequence
- affected systems
- cache purge
- sitemap regeneration
- rollback artifact
- monitoring owner
- stop conditions
- verification window
- communication
Use staged rollout where template-wide output could affect a large URL population.
### Step 16: Post-Release Recrawl
After release, recrawl the actual production output.
Compare:
- URL count
- valid cluster count
- invalid code count
- missing self-reference count
- missing-return count
- incomplete-cluster count
- duplicate-locale count
- redirect-target count
- error-target count
- noindex-target count
- canonical-conflict count
- cross-source mismatch count
- x-default defect count
Do not declare success from code deployment alone.
### Step 17: Monitor Search Signals
Monitor where available:
- crawling
- indexing
- selected canonicals
- wrong-locale landings
- international query impressions
- locale-specific clicks
- search-result examples
- newly indexed localized URLs
Treat these as follow-up evidence, not guaranteed outcomes.
## Decision and Safety Controls
1. Do not promise ranking, traffic, canonical-selection, or indexing outcomes from hreflang correction.
2. Do not treat source code, template intent, or CMS records as proof of live crawler-visible output.
3. Do not mass-change:
- canonicals
- redirects
- locale routing
- sitemap logic
- page availability
- indexability
from a small or unrepresentative sample.
4. Use current direct search-engine documentation for supported syntax and implementation claims.
5. Preserve local:
- legal requirements
- consent requirements
- currencies
- taxes
- inventory
- availability
- promotions
- regulatory content
- language requirements
when assessing page equivalence.
6. Require accountable approval for:
- site-wide template changes
- redirects
- canonical changes
- routing changes
- indexability changes
- domain migrations
- locale retirements
- sitemap replacement
- cache configuration changes
7. Prefer:
- read-only inspection
- isolated generator tests
- staging crawl
- template-level pilot
- reversible deployment
- staged rollout
before site-wide release.
8. Define stop conditions before production release.
9. Maintain a rollback path for template, sitemap, routing, header, CDN, and cache changes.
10. Do not substitute ChatGPT output for the accountable SEO, engineering, localization, legal, or release owner.
11. Stop and escalate when:
- locale architecture is undefined
- expected clusters cannot be established
- live output cannot be inspected
- staging and production behaviour differ materially
- canonicals are being changed without duplicate-content review
- redirects may affect large URL populations
- legal or market requirements conflict with content-equivalence assumptions
- rollback is unavailable
- search-engine documentation does not support the proposed syntax
## Output Contract
Return the result using the following sections.
Use concise prose for conclusions.
Use tables only where they improve cluster comparison, defect tracking, ownership, sequence, or acceptance testing.
### 1. Executive Validation Summary
Return:
- validation objective
- overall status
- markets and templates reviewed
- strongest confirmed defect
- affected scale
- principal root cause
- highest-priority repair
- confidence
- evidence limitations
- next safe action
### 2. Locale Architecture
Show:
- market
- language
- script
- region
- domain
- URL pattern
- default behaviour
- x-default intent
- content-equivalence rule
- owner
### 3. Evidence Inventory
For each artifact, show:
- source
- owner
- environment
- date
- scope
- observation
- limitation
- confidence
- next check
### 4. URL and Template Coverage
Show:
- template
- locale
- expected URL count
- inspected URL count
- traffic class
- publication state
- implementation source
- sampling limitation
### 5. Cluster Evidence Table
For each relationship, show:
- cluster identifier
- source URL
- source locale
- target locale
- target URL
- self-reference
- reciprocal
- target status
- target indexability
- target canonical
- implementation source
- result
### 6. Source-Consistency Matrix
Compare:
- expected CMS output
- source HTML
- rendered HTML
- XML sitemap
- HTTP Link header
For each cluster or template, show:
- source
- member count
- locale set
- x-default
- difference
- likely cause
- status
### 7. Defect Register
For each defect, show:
- defect identifier
- defect type
- affected URL
- affected template
- affected locale
- affected market
- scale
- evidence
- severity
- confidence
- root cause
- owner
- required repair
- retest
Group defects by:
- invalid code
- missing self-reference
- missing return
- incomplete cluster
- duplicate locale
- redirect
- error
- noindex
- canonical conflict
- x-default
- source drift
- content-equivalence conflict
- template defect
### 8. Root-Cause Map
Show:
- root cause
- generator or system
- affected templates
- affected locales
- defect types
- supporting evidence
- owner
- dependency
- recommended correction
### 9. Repair Specification
Define:
- authoritative generator
- locale normalization
- URL normalization
- membership rule
- self-reference rule
- reciprocity rule
- x-default rule
- canonical rule
- indexability rule
- redirect rule
- fallback rule
- exclusions
- cache rule
- sitemap rule
- HTTP-header rule
- owner
- acceptance condition
### 10. Test Fixture Matrix
For each fixture, show:
- scenario
- input
- expected annotation
- expected exclusion
- expected status
- expected canonical
- test layer
- owner
### 11. Release Plan
Define:
- prerequisite
- change
- owner
- environment
- rollout sequence
- cache action
- sitemap action
- monitoring
- stop condition
- rollback
- approval
### 12. Post-Release Validation Runbook
Specify:
- crawl scope
- crawl date
- user agent
- rendering mode
- data collected
- comparison baseline
- defect thresholds
- acceptance criteria
- owner
- escalation
- rollback trigger
### 13. Search Follow-Up
Define:
- signal
- source
- baseline
- observation period
- expected directional signal
- limitation
- owner
- review date
Do not state guaranteed ranking or indexing outcomes.
### 14. Decision Summary
State:
- confirmed defects
- unconfirmed hypotheses
- assumptions
- approved scope
- recommended repair
- expected technical result
- limitations
- accountable owner
- smallest safe next action
## Verification Checklist
Before finalizing, confirm that:
- intended markets, languages, regions, scripts, and URL patterns are explicit
- each locale uses a supported language and optional regional or script code
- no country-only codes are used
- alternate URLs are fully qualified
- each valid cluster contains an accurate self-reference
- every intended source-to-target relationship has a reciprocal return
- cluster membership is complete and internally consistent
- duplicate locale assignments are identified
- x-default has a defined fallback purpose
- clustered pages have equivalent user and search intent
- all targets resolve to the intended final page
- all targets are accessible and appropriately indexable
- canonical targets are compatible with the hreflang relationship
- canonicals remain in the same language where possible
- HTML, rendered HTML, sitemap, and HTTP-header sources do not contradict one another
- JavaScript and cache behaviour are tested where relevant
- routing and fallback behaviour allow direct access to localized URLs
- CMS and translation records match generated output
- sampling covers every material template and locale
- long-tail and newly launched pages are represented
- generator logic includes valid and negative fixtures
- staging output is validated before production release
- production output is recrawled after release
- defect counts are compared before and after deployment
- rollback and stop conditions are defined
- search impact is monitored without promising ranking or indexing changes
- every major conclusion is supported by evidence or explicitly labelled as an assumption
- no uncrawled URL, unrendered page, unrun test, unapproved action, or unresolved conflict is described as complete
- the final next action is the smallest safe step that materially reduces international targeting uncertainty or implementation risk
Begin by checking the supplied context for blocking gaps.
If none remain, define the expected locale matrix, build the evidence inventory, inspect the implementation sources, construct the directed hreflang clusters, validate canonical and indexability signals, identify root causes, and produce the repair and post-release validation plan.
Completion criteria
Complete when:
- Each finding references a supplied URL, crawl row, sitemap entry, rendered tag, redirect result, or search evidence.
- The audit checks reciprocity, self-reference, locale-code validity, canonical compatibility, indexability, and sitemap consistency.
- Priority levels reflect scope, severity, reversibility, and business relevance.
- Acceptance checks are specific enough to run after implementation.
- Unverified assumptions and missing samples are explicitly listed.
Produce an evidence-led WordPress performance diagnosis and staged optimization roadmap covering Core Web Vitals, themes, plugins, assets, caching, hosting, databases, third parties, regression controls, and validation.