returntag - hreflang checker

Free, no signup. A page can declare its hreflang alternates perfectly and still get ignored — because the page on the other end never links back. The returntag - hreflang checker crawls the whole cluster from one URL (or a sitemap) and checks return tags, self-references, x-default, redirects, and language codes across all three declaration methods, flagging any disagreement between them — the reciprocity check Search Console's old International Targeting report used to run.

Built by Patrick Stox

Notes: pages are fetched as Googlebot Smartphone by default (switchable, or bring your own user-agent) — some sites' bot management may challenge or block these fetches. Raw HTML only: hreflang or content injected by JavaScript needs a rendering browser and is not seen. Content-language detection covers ~30 major languages; pages in other languages simply aren't language-checked.

Example data — replace with your own, then press Validate cluster

Crawls this page's whole hreflang cluster (head tags + Link headers), then also reads the site's XML sitemaps from robots.txt and cross-checks all three sources.

Checks run from our server; we fetch the URL you enter and don't keep the results. Anonymous aggregate outcomes feed our research posts; checked domains are counted once via an anonymized hash, never stored in the clear. Anonymous run-level outcome counters may be used for aggregate research; URLs, domains, IPs, and identifiers are never included, and no statistic is released below 100 runs.

Feedback
Report a bug

Found something broken in Returntag? Let us know what happened — this goes straight to a private triage queue, not a public list.

What will be sent 
 No tool inputs, uploads, pasted source, complete results, query parameters, or URL fragments are attached automatically. You can edit or remove the selected passage above. Browser and anti-abuse metadata is processed for spam prevention. 
  
 
  
 
 
  
 
 
   
 
 
Sample report Illustrative example — worked by hand from the rules below, not a live crawl
 

Say your English homepage, French page, and German page all declare each other, but the
          French page is missing its return tag pointing back to English. You enter the French URL,
          whose <head> contains:

 
 
<!-- in the <head> of https://example.com/fr/ -->
<link rel="alternate" hreflang="en" href="https://example.com/" />
<link rel="alternate" hreflang="fr" href="https://example.com/fr/" />
<link rel="alternate" hreflang="de" href="https://example.com/de/" />
<link rel="alternate" hreflang="x-default" href="https://example.com/" />
 
 
…and returns this:
  
     
  • Two of three pairs are reciprocal (green ✓) — those pairings are valid; see
what reciprocal / missing / broken mean.
    •  
  • One pairing is one-directional. English lists French, but French doesn't list
            English back — the matrix shows a yellow ▲ and the issue below names the exact
            page and the exact tag to add.
    •  
  • One missing tag breaks the whole pairing, not just half of it — Google drops
            English↔French entirely until the return tag exists, which is why a map across the whole cluster
            matters more than checking one page at a time.
    •  
  • Building the fix? The Hreflang Cluster Generator
writes a self-referencing, bidirectional set so this can't happen in the first place.
    •  
 
 
 
How to use it
 
     
  1. Pick a mode. Page URL crawls a live page's whole hreflang
            cluster; Sitemap URL validates the xhtml:link
declarations in an XML sitemap on their own.
    2.  
  2. Paste one URL — in Page mode, any page in the cluster (e.g.
https://example.com/fr/); in Sitemap mode, the sitemap or sitemap-index URL.
    3.  
  3. Optionally change the user-agent pages are fetched as (Googlebot
            Smartphone by default), or in Page mode add a sitemap URL to cross-check.
    4.  
  4. Press Validate cluster. The tool follows every alternate, fetches
            each page, and cross-checks head tags, Link headers, and sitemaps.
    5.  
  5. Read the stat strip, then switch between the graph and
matrix views and open the Issues list — export it as CSV.
    6.  
 
 
 
     
     
 
     What this result means ↓  
 
What the results mean
 
The stat strip counts the cluster; each pairing (edge) resolves to one of three states:
 
     
  • Reciprocal pair (green ✓) — both pages list each other. This pairing
            is valid; Google will honour it. Redirected-but-still-reciprocal pairs count here with a note.
    •  
  • Missing return (yellow ▲) — page A declares B, but B does not link
            back to A. The pairing is ignored until the return tag is added.
    •  
  • Broken target (red ✕) — an alternate points at a URL that returns a
            non-200 or can't be fetched, so every hreflang aimed at it is dead.
    •  
 
Issues below the map carry one of three severities:
 
     
  • error — breaks
            the cluster: an invalid or region-only language code, a relative href, two
            conflicting x-default targets, or the same locale declared twice.
    •  
  • error — a
            missing return tag, a broken alternate, or a sitemap/head/header disagreement.
    •  
  • warning — a
            canonical/noindex conflict or another non-fatal inconsistency. Missing self-references are notes.
            The validator does not require x-default; it is optional.
    •  
  • note —
            informational: a reciprocal pair that resolves through a redirect, a cross-domain cluster,
            a deprecated-but-tolerated code, or a language that doesn't match the page's detected text.
    •  
 
How it works
 

Fetching is the only server-side part. Your browser calls a small endpoint
          (/api/hreflang-check) that requests one URL as the chosen crawler user-agent,
          follows redirects, and returns just the extracted facts — status, self-reference,
          annotations, <html lang>, Content-Language, canonical. The browser then
          drives the crawl: it seeds with your URL and queues every newly referenced alternate,
          fetching up to six at a time until the whole connected cluster is mapped (capped at 500 URLs).

 

All the validation runs client-side. Once the pages are in, it builds the cluster graph,
          resolves each declared href (accounting for redirects), marks every edge
          reciprocal / missing-return / broken, then layers on self-reference, x-default, language-code,
          and three-source-agreement checks. In Page mode it also pulls the site's sitemaps and merges
          their xhtml:link annotations so head, header, and sitemap declarations are
          cross-checked against each other.

 
Features
 
     
  • Full-cluster crawl from a single URL — follows alternates up to 500 pages, six concurrent fetches.
    •  
  • Return-tag reciprocity across all three declaration methods (head tags, Link headers, sitemap xhtml:link), flagging any disagreement between them.
    •  
  • Interactive graph and matrix views, with a picker when the crawl finds several separate clusters.
    •  
  • Self-reference, conflicting x-default, redirect-through-alternate, and separate mobile-URL (m-dot) checks. x-default itself remains optional.
    •  
  • ISO 639-1 / 3166-1 language-code validation, plus content-language detection for ~30 major languages.
    •  
  • Choice of crawler user-agent (Googlebot, Bingbot, YandexBot, and more) or your own; SVG/PNG graph export and CSV issue export.
    •  
  • Sitemap-only mode for validating an XML sitemap's declarations without fetching pages.
    •  
 
Limitations
 

Pages are fetched as raw HTML — hreflang or content injected by JavaScript
          is not seen and will be reported as missing. Bot management on some sites may challenge or
          block the fetches. Content-language detection covers ~30 major languages; pages in other
          languages simply aren't language-checked. The crawl caps at 500 URLs and reads the first
          20 child sitemaps, and Sitemap mode validates only what the sitemap declares (it doesn't
          fetch the pages, so an on-page return tag will still read as missing there).

 
Frequently asked questions
 
What is an hreflang return tag?
A return tag is the reciprocal hreflang linkIf page A lists page B as an alternate, B must list A back — or Google ignores the pair.. If page A lists page B as an alternate, page B must list page A back — otherwise Google ignores the pairing entirely. The returntag - hreflang checker crawls every page in the cluster and checks that each declared alternate links back, so a missing return tag on any single page shows up on the map instead of silently breaking the whole set.
Does this replace Search Console’s International Targeting report?
It replaces the "no return tags" errors that report used to surface. Google retired the International Targeting report in 2022, so there is no longer a first-party place to see missing hreflang return tags. The returntag - hreflang checker runs the same reciprocity check against a live crawl of the cluster, plus x-defaultx-default is the reserved hreflang value that points to a fallback URL — the page Google shows when a user's locale doesn't match any of your other hreflang tags. It is optional and does not mean "English.", self-reference, redirect, and language-code validation on top.
Why does the tool crawl other pages instead of just the one I entered?
Reciprocity can only be verified by reading both ends of every pair. When you enter one URL, the returntag - hreflang checker follows its hreflang annotationsHreflang is an annotation (in HTML, HTTP headers, or XML sitemaps) that tells search engines which language and optional region a page targets, and which alternate versions exist. It only works when every page in the cluster references all the others. to each alternate, fetches those pages too, and keeps expanding until the whole connected cluster is mapped (up to 500 URLs). That is the only way to know whether the return tags actually exist on the other pages.
Can it check hreflang declared in an XML sitemap?
Yes. In Page URL mode it also reads the site’s sitemaps (from robots.txtA plain-text file at the root of a host that tells crawlers which URLs they may and may not request. It controls crawling, not indexing — a blocked URL can still be indexed if it's linked from elsewhere., or one you supply) and cross-checks all three declaration methods — head tags, HTTP Link headers, and sitemap xhtml:link — flagging any disagreement. Sitemap URL mode validates the sitemap’s declarations on their own without fetching the pages.
Does it see hreflang added by JavaScript?
No. Pages are fetched as raw HTML (as Googlebot Smartphone by default), so hreflang tags or content injected client-side by JavaScript are not seen. If your alternates are rendered by JS, this tool will report them as missing — validate the rendered HTML separately.
 
 
 
     
Next stepSEO Incident Simulator — practice the same investigation on labeled fixtures.

Explore more
Toolhreflang Generator + LinterToolLocal SERP GeneratorToolGoogle Index CheckerArticlex-default HreflangArticleHreflangArticleTechnical International SEO
 
 
 
Feature requests for Returntag
 

Upvote what you want most. New ideas can be submitted from the floating Feedback menu;
      requests appear here once approved, and the most-wanted rise to the top.

   
Loading…
  
  ➕ Request a feature   
New requests are reviewed before they appear here.
 
     
  
  
 
 
 
 
   
        
 
Common issues & how to fix them
 
 
 
 
 
returntag - hreflang checker · one finding
 
Alternate target canonicalizes elsewhere
 
Recommended action: Align the alternate’s canonical with its own hreflang URL, or remove that alternate if it is intentionally canonicalized to another page.
 
Fix principle: Align every canonical signal for a page — the HTML <link rel=canonical>, an HTTP Link header, the post-render DOM, and each page's self-reference inside an hreflang cluster — on one confirmed intended URL; a conflict anywhere in that chain is resolved at its owning layer, never papered over by adding another canonical downstream.
 
 
 
 Implementation for your setup 
 
Confirm first: The page emits zero, more than one, or mutually disagreeing canonical signals across its HTML head, HTTP response header, or post-render DOM. A present canonical signal is relative, points to a URL that does not return a live 200 response, sits outside <head> where crawlers may not honor it, or only appears after client-side JavaScript runs.
 
Do not apply when: Exactly one absolute canonical URL is declared consistently across the HTML head, any HTTP header, and the rendered DOM, and that target itself returns 200. The apparent second reference is a distinct, valid annotation — an hreflang alternate, a pagination rel=next/prev, or another non-canonical link — not a competing canonical claim for the same page.
 
Likely control points: cms-app · server · edge-cdn
 
   
Choose the layer that owns the final response.
 
 
 
Generic HTTP / HTML
 
Status: supported · Location: Origin template, application server, or the layer that emits the HTTP Link header
 
Steps
  1. Enumerate every canonical signal for the URL — the HTML <link rel="canonical">, any HTTP Link: rel="canonical" response header, and the post-render DOM — and identify which layer emits each one.
  2. Choose exactly one intended absolute canonical URL per page and make every signal reproduce it verbatim; never declare a relative canonical, and never let a sitemap entry, redirect target, or hreflang alternate imply a different URL than the declared canonical.
  3. Correct or remove the emitting layer for any conflicting or duplicate signal at its source. Do not add a second, "corrective" canonical on top of an existing one.
  4. Confirm the canonical target itself returns a live 200 response on the protocol and host the site actually serves, not a redirect or error.
  
Verify on this platform
 
  • Fetch the raw response and inspect <head> for exactly one absolute canonical link, then check response headers for at most one agreeing Link: rel="canonical".
  • Confirm the canonical target itself returns 200 without redirecting, then use Search Console URL Inspection to compare the user-declared canonical against the Google-selected canonical.
 
Rollback
  1. Restore the previous canonical annotation or header if the correction points crawlers away from a URL that needs to stay indexed, then re-diagnose the true conflicting layer before trying again.
 
Caveats
  • A declared canonical is a hint, not a directive: Google may select a different URL as canonical for various reasons even when every signal you control agrees.
  • Don't specify different canonical URLs for the same page using different mechanisms (for example, one URL in a sitemap and a different one via rel=canonical) — the conflict itself is the defect, not the presence of any one mechanism.
  • If the page belongs to an hreflang cluster, each localized URL must canonicalize to itself (or its own best-language substitute), not to the primary-language version.
 
Official sources
 
 
WordPress
 
Status: supported · Location: Theme output via the wp_head hook, or the single plugin/theme layer that has taken over the canonical tag
 
Steps
  1. Confirm WordPress core's native rel_canonical() output — hooked on wp_head — is the only source of the canonical tag, or that exactly one SEO plugin or theme has deliberately taken over that responsibility. Never leave two layers emitting a tag for the same page.
  2. If a plugin, theme, or manual template edit adds a second <link rel="canonical"> or a conflicting header, correct or remove it at that specific owning layer; do not add a third tag to compensate.
  3. Confirm the intended canonical target is the live, indexable URL the site actually wants, not a query-parameter, paginated, or otherwise non-canonical variant.
  
Verify on this platform
 
  • While logged out, view the public HTML source once and confirm a single <link rel="canonical"> matching the intended URL, then confirm no HTTP Link header contradicts it.
 
Rollback
  1. Restore the previous theme or plugin canonical configuration if removing a tag causes an unintended page to lose its canonical reference, then correct the true conflicting layer before trying again.
 
Caveats
  • Do not invent a specific SEO plugin's settings path: WordPress core exposes wp_get_canonical_url() and rel_canonical() on wp_head, but which plugin or theme, if any, has overridden that output is not verified here.
  • A page builder or headless WordPress frontend is owner-managed; use that system's own verified workflow instead of assuming core theme output controls the response.
 
Official sources
 
 
Next.js / Vercel
 
Status: supported · Location: metadata.alternates.canonical / generateMetadata in the App Router, or next/head output in the Pages Router
 
Steps
  1. Set metadata.alternates.canonical (or the equivalent value returned from generateMetadata) to one absolute intended URL per App Router route; in the Pages Router, emit exactly one canonical <link> via next/head.
  2. Set metadataBase once at the root layout so relative canonical values resolve against the correct production host, instead of leaving canonical relative or inconsistent between preview and production domains.
  3. Do not also emit a second canonical tag from a component, a custom document, or an edge Proxy/Middleware response header once the metadata API owns the output.
  4. If the route belongs to an hreflang cluster, pair alternates.canonical with alternates.languages so each localized route canonicalizes to itself.
  
Verify on this platform
 
  • Fetch the deployed production route without executing JavaScript, confirm exactly one <link rel="canonical"> with the intended absolute URL, then rerun Canonicalization Checker or Render Gap on the same URL.
 
Rollback
  1. Revert the metadata export or route segment if the deployment changes the canonical for a route that needs to keep its prior target, then correct the actual conflicting layer before redeploying.
 
Caveats
  • metadataBase only fills in relative values; an already-absolute canonical value is used as-is and ignores metadataBase.
  • Confirm the production deployment domain matches the intended canonical host — a Preview Deployment URL is never the intended canonical target.
 
Official sources
 
 
Shopify
 
Status: supported · Location: Online Store theme.liquid head output via the canonical_url Liquid object
 
Steps
  1. Duplicate the active theme and confirm theme.liquid emits exactly one <link rel="canonical" href="{{ canonical_url }}" /> in the head; Shopify's canonical_url object already resolves to the platform's intended canonical for standard product, collection, and content pages.
  2. If a second canonical tag is present — added by an app embed, a theme customization, or a duplicated snippet — remove it at that specific source rather than editing canonical_url itself.
  3. Preview representative product, collection, and content routes before publishing the corrected duplicate theme.
  
Verify on this platform
 
  • Inspect the published storefront response without browser execution and confirm a single canonical tag reflecting canonical_url on each route type.
 
Rollback
  1. Republish the previous theme if the corrected theme regresses canonical output or storefront functionality.
 
Caveats
  • These steps apply only to Shopify Online Store Liquid/JSON themes using the canonical_url object.
  • An app-owned storefront, a Hydrogen implementation, or an app that injects its own canonical tag is owner-managed; verify that system's own workflow rather than assuming theme.liquid is the only emitter.
 
Official sources
 
 
Platform-managed / ask the vendor
 
Status: platform-managed · Location: Vendor-owned page builder, headless frontend, or hosted platform template
 
Implementation is controlled by the platform or vendor.
  
Verify on this platform
 
  • Ask the vendor to confirm which single layer emits the canonical tag and header for the URL, then compare the user-declared and Google-selected canonical in Search Console URL Inspection.
  
Caveats
  • Escalate when the vendor cannot identify or expose the layer that emits a conflicting or duplicate canonical signal.
  • Do not accept a claim that the canonical is correct without one production-URL response showing a single agreeing signal.
 
Official sources
 
 
 
 
 How to verify 
 
  1. Fetch the raw response and confirm exactly one canonical signal (the HTML tag and, if present, the HTTP header) names the same absolute, live URL.
  2. Confirm the canonical target itself returns 200 without redirecting.
  3. Compare the user-declared canonical against Google's selected canonical in Search Console URL Inspection.
  4. Rerun the finding's originating tool (Canonicalization Checker, On-Page SEO Checker, SEO Site Audit Crawler, Render Gap, Google Index Checker, or HTTP Header Checker) on the same production URL.
 
Escalate when
 
Escalate when ownership of the emitting layer is unclear, more than one system claims to own the canonical output, or Google's selected canonical keeps diverging from the declared canonical after every signal you control has been made consistent.
 
 
 
 
 
 
 
returntag - hreflang checker · one finding
 
Alternate page is missing its reciprocal return tag
 
Recommended action: Add the source page to the target page’s hreflang set with the matching locale so the alternate relationship is reciprocal.
 
Fix principle: hreflang is a cluster property, not a per-page one: Google's own guidance states that if two pages don't both point to each other the annotations are ignored, and that every language version must list itself plus every other version identically. A unilateral edit on one page cannot fix a cluster — the reciprocal return tag, the self-reference, and the complete alternate set must all be corrected together, on every member, in the same change.
 
 
 
 Implementation for your setup 
 
Confirm first: An alternate page listed in the cluster does not itself list the source page back (the return/reciprocal tag is missing), so Google ignores the relationship for that pair. A page in the cluster has no self-referencing hreflang entry for its own locale and URL. An alternate target does not return a live 2xx response, redirects, or canonicalizes to a different URL than the one declared in hreflang — none of which Google will follow as the intended localized page. Pages in the same intended cluster disagree on membership: they do not all publish the same complete set of alternate URLs and locale codes. The cluster has no x-default entry despite serving a language selector, root domain, or otherwise ambiguous default experience.
 
Do not apply when: Every page in the cluster publishes an identical, reciprocal set of hreflang alternates — each page lists itself and every sibling, every sibling lists it back, and each declared target returns a live 200 response without redirecting or canonicalizing elsewhere. The cluster deliberately has no x-default because there is no ambiguous entry point (for example, every visitor arrives at an already-localized URL with no shared root or selector page).
 
Likely control points: cms-app · server · edge-cdn · managed-vendor
 
   
Choose the layer that owns the final response.
 
 
 
Generic HTTP / HTML
 
Status: supported · Location: Every page in the language cluster — origin template, application server, XML sitemap, or HTTP Link header, whichever layer emits hreflang for that site
 
Steps
  1. List every URL that is supposed to belong to the cluster, then fetch each one and record its complete hreflang set (from the HTML head, or the sitemap/Link-header equivalent, whichever the site uses).
  2. Build one target alternate set: every locale in the cluster paired with its live URL, plus a self-reference for each page's own locale, plus x-default if the cluster has an ambiguous default entry point.
  3. Publish that identical, complete set on every page in the cluster in the same change — a return tag added to only the target page while the source page stays unedited is still a broken pair.
  4. Confirm every alternate target itself returns a live 200 response on the URL declared in hreflang, without redirecting and without canonicalizing to a different URL.
  
Verify on this platform
 
  • Fetch each cluster member and confirm it lists itself plus every sibling, that every sibling lists it back, and that the set is byte-for-byte the same set of locale/URL pairs across all members.
  • Fetch each declared alternate target directly and confirm it returns 200 without redirecting, then confirm its own canonical tag matches its own URL rather than another page in or out of the cluster.
  • Rerun the returntag - hreflang checker on the full cluster (a URL or sitemap) and confirm no missing-return, missing-self, target-non-200, redirected-target, canonical-conflict, cluster-split, or x-default-gap findings remain.
 
Rollback
  1. Restore the previous hreflang set on any page where the correction removed a locale or URL still needed by another part of the site, then re-diagnose the true cluster membership before republishing.
 
Caveats
  • hreflang is a signal Google uses to select which localized URL to show, not a guarantee that the localized page will be served or ranked for that locale.
  • If two pages don't reciprocally reference each other, Google ignores the annotation for that pair entirely — a one-directional fix is not a partial fix.
  • Do not add an alternate target that is itself blocked from indexing or that never returns a 2xx response; that produces a new target-non-200 finding on the corrected cluster.
 
Official sources
 
 
WordPress
 
Status: supported · Location: Theme output via the wp_head hook, or the single plugin taking over hreflang output for a multilingual WordPress site
 
Steps
  1. Identify the one system that emits hreflang for the site — most multilingual WordPress sites use a dedicated multilingual plugin rather than manual theme code; confirm which single layer owns the output before changing anything.
  2. If hreflang is emitted manually via a theme template, build the alternate set from the site's own registered language/translation relationships so it can never drift from what the CMS itself considers the cluster, and output it identically on every member via wp_head.
  3. Whichever layer owns hreflang, treat cluster-membership drift (a page missing from the set, or a stale/removed translation still listed) as a content-management defect to fix in that system's translation-linking, not by hand-patching one page's markup.
  
Verify on this platform
 
  • While logged out, view the public HTML source of every page in the cluster and confirm each lists itself and every sibling reciprocally, then fetch each alternate target to confirm it is live and self-canonicalizing.
 
Rollback
  1. Restore the previous translation linkage or template output if the correction drops a locale relationship still needed elsewhere, then re-diagnose the true cluster membership before republishing.
 
Caveats
  • A dedicated multilingual plugin's own settings screen was not verified in this recipe — the exact admin path was not confirmed against current plugin documentation, so no specific menu or option is named here. Treat that plugin's hreflang output as platform-managed and use its own support documentation to correct translation relationships; only the fully manual, theme-emitted path above is verified.
  • If the plugin's hreflang output is itself broken (not merely a content-linking gap), that is a defect in a third-party layer this recipe cannot verify a fix for; escalate to the plugin's own support channel.
 
Official sources
 
 
Next.js / Vercel
 
Status: supported · Location: metadata.alternates.languages alongside alternates.canonical in the App Router, or the equivalent next/head output in the Pages Router
 
Steps
  1. For every route that belongs to a language cluster, set metadata.alternates.languages to the full, identical set of locale-to-URL pairs on every member route, paired with alternates.canonical set to that route's own URL.
  2. Set metadataBase once at the root layout so relative alternates.languages values resolve to the correct production host on every route rather than a preview domain.
  3. Add x-default to alternates.languages only where the cluster has an ambiguous default entry point (for example a locale-selector or root route).
  4. Do not let a route-level override replace alternates.languages with a partial set; merging in Next.js metadata replaces nested fields wholesale rather than merging them, so a child segment that sets alternates at all must set the complete set.
  
Verify on this platform
 
  • Fetch each deployed production route without executing JavaScript, confirm the emitted hreflang links are identical in membership across every cluster route and each pairs with that route's own canonical, then rerun the returntag - hreflang checker on the cluster.
 
Rollback
  1. Revert the metadata export for the affected route segment if the deployment drops a locale relationship still needed elsewhere, then correct the true cluster membership before redeploying.
 
Caveats
  • Confirm the production deployment domain matches metadataBase — a Preview Deployment URL served under a different host will not match the alternates it declares.
  • Metadata objects are merged shallowly per field across nested layouts and pages: a page that defines its own alternates.languages replaces the parent's set entirely rather than adding to it.
 
Official sources
 
 
Shopify
 
Status: supported · Location: Shopify Markets configuration, or the layout/theme.liquid content_for_header output for Markets-driven storefronts
 
Steps
  1. Confirm the storefront uses Shopify Markets: Shopify automatically adds hreflang tags built from each market's configured languages and regions via content_for_header, and keeps them in sync with each page's own canonical URL and with market changes.
  2. If the Markets configuration is missing a language, region, or domain that should be in the cluster, add it in Markets rather than hand-editing hreflang output — the automatic tags are generated from that configuration.
  3. If hreflang is emitted manually instead of through content_for_header, build the tag set dynamically from the localization object rather than hardcoding domains or resource handles, because a handle can differ per language and the head partial renders on every page.
  4. Either way, confirm each localized URL still references itself as its own canonical URL — Shopify's guidance calls this out as a prerequisite for the automatic tags to behave correctly.
  
Verify on this platform
 
  • View source on a representative page in each market/language and confirm the emitted hreflang set is complete and reciprocal, then confirm each localized URL's own canonical tag matches its own URL.
 
Rollback
  1. Revert the Markets configuration change or the manual theme edit if it drops a market or language still needed, then re-diagnose the true cluster membership before republishing.
 
Caveats
  • This applies to Shopify Markets storefronts on Online Store themes using the standard content_for_header output; a storefront that overrides this partial, uses Hydrogen, or manages locales outside Markets is not covered — verify that system's own workflow instead.
  • Shopify's own hreflang documentation does not address x-default; do not assume Shopify emits one automatically.
 
Official sources
 
 
Platform-managed / ask the vendor
 
Status: platform-managed · Location: Vendor-owned page builder, headless frontend, or hosted platform template
 
Implementation is controlled by the platform or vendor.
  
Verify on this platform
 
  • Ask the vendor to confirm which single layer emits hreflang for the cluster and how cluster membership is kept in sync across pages, then fetch every cluster member directly to confirm reciprocal, self-referencing, live-target hreflang.
  
Caveats
  • Escalate when the vendor cannot identify the layer emitting hreflang, cannot explain how it keeps membership in sync across pages, or when fetched pages keep disagreeing after every input you control has been made consistent.
  • Do not accept a claim that hreflang is correct without directly fetching each cluster member and each alternate target.
 
Official sources
 
 
 
 
 How to verify 
 
  1. Fetch every page believed to be in the cluster and record its complete hreflang set.
  2. Confirm the set is identical across every member, that every member lists itself, and that every pair is reciprocal.
  3. Confirm every declared alternate target returns a live 200 response without redirecting, and that its own canonical points to itself rather than elsewhere.
  4. Rerun the returntag - hreflang checker (and, for pages diagnosed via Raw vs. Rendered HTML Checker, confirm the same hreflang set survives rendering) on the same cluster.
 
Escalate when
 
Escalate when the system responsible for cluster membership cannot be identified, more than one system claims to manage hreflang for the same pages, or fetched pages keep disagreeing on membership after every input you control has been made consistent.
 
 
 
 
 
 
 
returntag - hreflang checker · one finding
 
Page is missing a self-referencing hreflang
 
Recommended action: Add a self-referencing hreflang entry using the page’s own locale and canonical URL.
 
Fix principle: hreflang is a cluster property, not a per-page one: Google's own guidance states that if two pages don't both point to each other the annotations are ignored, and that every language version must list itself plus every other version identically. A unilateral edit on one page cannot fix a cluster — the reciprocal return tag, the self-reference, and the complete alternate set must all be corrected together, on every member, in the same change.
 
 
 
 Implementation for your setup 
 
Confirm first: An alternate page listed in the cluster does not itself list the source page back (the return/reciprocal tag is missing), so Google ignores the relationship for that pair. A page in the cluster has no self-referencing hreflang entry for its own locale and URL. An alternate target does not return a live 2xx response, redirects, or canonicalizes to a different URL than the one declared in hreflang — none of which Google will follow as the intended localized page. Pages in the same intended cluster disagree on membership: they do not all publish the same complete set of alternate URLs and locale codes. The cluster has no x-default entry despite serving a language selector, root domain, or otherwise ambiguous default experience.
 
Do not apply when: Every page in the cluster publishes an identical, reciprocal set of hreflang alternates — each page lists itself and every sibling, every sibling lists it back, and each declared target returns a live 200 response without redirecting or canonicalizing elsewhere. The cluster deliberately has no x-default because there is no ambiguous entry point (for example, every visitor arrives at an already-localized URL with no shared root or selector page).
 
Likely control points: cms-app · server · edge-cdn · managed-vendor
 
   
Choose the layer that owns the final response.
 
 
 
Generic HTTP / HTML
 
Status: supported · Location: Every page in the language cluster — origin template, application server, XML sitemap, or HTTP Link header, whichever layer emits hreflang for that site
 
Steps
  1. List every URL that is supposed to belong to the cluster, then fetch each one and record its complete hreflang set (from the HTML head, or the sitemap/Link-header equivalent, whichever the site uses).
  2. Build one target alternate set: every locale in the cluster paired with its live URL, plus a self-reference for each page's own locale, plus x-default if the cluster has an ambiguous default entry point.
  3. Publish that identical, complete set on every page in the cluster in the same change — a return tag added to only the target page while the source page stays unedited is still a broken pair.
  4. Confirm every alternate target itself returns a live 200 response on the URL declared in hreflang, without redirecting and without canonicalizing to a different URL.
  
Verify on this platform
 
  • Fetch each cluster member and confirm it lists itself plus every sibling, that every sibling lists it back, and that the set is byte-for-byte the same set of locale/URL pairs across all members.
  • Fetch each declared alternate target directly and confirm it returns 200 without redirecting, then confirm its own canonical tag matches its own URL rather than another page in or out of the cluster.
  • Rerun the returntag - hreflang checker on the full cluster (a URL or sitemap) and confirm no missing-return, missing-self, target-non-200, redirected-target, canonical-conflict, cluster-split, or x-default-gap findings remain.
 
Rollback
  1. Restore the previous hreflang set on any page where the correction removed a locale or URL still needed by another part of the site, then re-diagnose the true cluster membership before republishing.
 
Caveats
  • hreflang is a signal Google uses to select which localized URL to show, not a guarantee that the localized page will be served or ranked for that locale.
  • If two pages don't reciprocally reference each other, Google ignores the annotation for that pair entirely — a one-directional fix is not a partial fix.
  • Do not add an alternate target that is itself blocked from indexing or that never returns a 2xx response; that produces a new target-non-200 finding on the corrected cluster.
 
Official sources
 
 
WordPress
 
Status: supported · Location: Theme output via the wp_head hook, or the single plugin taking over hreflang output for a multilingual WordPress site
 
Steps
  1. Identify the one system that emits hreflang for the site — most multilingual WordPress sites use a dedicated multilingual plugin rather than manual theme code; confirm which single layer owns the output before changing anything.
  2. If hreflang is emitted manually via a theme template, build the alternate set from the site's own registered language/translation relationships so it can never drift from what the CMS itself considers the cluster, and output it identically on every member via wp_head.
  3. Whichever layer owns hreflang, treat cluster-membership drift (a page missing from the set, or a stale/removed translation still listed) as a content-management defect to fix in that system's translation-linking, not by hand-patching one page's markup.
  
Verify on this platform
 
  • While logged out, view the public HTML source of every page in the cluster and confirm each lists itself and every sibling reciprocally, then fetch each alternate target to confirm it is live and self-canonicalizing.
 
Rollback
  1. Restore the previous translation linkage or template output if the correction drops a locale relationship still needed elsewhere, then re-diagnose the true cluster membership before republishing.
 
Caveats
  • A dedicated multilingual plugin's own settings screen was not verified in this recipe — the exact admin path was not confirmed against current plugin documentation, so no specific menu or option is named here. Treat that plugin's hreflang output as platform-managed and use its own support documentation to correct translation relationships; only the fully manual, theme-emitted path above is verified.
  • If the plugin's hreflang output is itself broken (not merely a content-linking gap), that is a defect in a third-party layer this recipe cannot verify a fix for; escalate to the plugin's own support channel.
 
Official sources
 
 
Next.js / Vercel
 
Status: supported · Location: metadata.alternates.languages alongside alternates.canonical in the App Router, or the equivalent next/head output in the Pages Router
 
Steps
  1. For every route that belongs to a language cluster, set metadata.alternates.languages to the full, identical set of locale-to-URL pairs on every member route, paired with alternates.canonical set to that route's own URL.
  2. Set metadataBase once at the root layout so relative alternates.languages values resolve to the correct production host on every route rather than a preview domain.
  3. Add x-default to alternates.languages only where the cluster has an ambiguous default entry point (for example a locale-selector or root route).
  4. Do not let a route-level override replace alternates.languages with a partial set; merging in Next.js metadata replaces nested fields wholesale rather than merging them, so a child segment that sets alternates at all must set the complete set.
  
Verify on this platform
 
  • Fetch each deployed production route without executing JavaScript, confirm the emitted hreflang links are identical in membership across every cluster route and each pairs with that route's own canonical, then rerun the returntag - hreflang checker on the cluster.
 
Rollback
  1. Revert the metadata export for the affected route segment if the deployment drops a locale relationship still needed elsewhere, then correct the true cluster membership before redeploying.
 
Caveats
  • Confirm the production deployment domain matches metadataBase — a Preview Deployment URL served under a different host will not match the alternates it declares.
  • Metadata objects are merged shallowly per field across nested layouts and pages: a page that defines its own alternates.languages replaces the parent's set entirely rather than adding to it.
 
Official sources
 
 
Shopify
 
Status: supported · Location: Shopify Markets configuration, or the layout/theme.liquid content_for_header output for Markets-driven storefronts
 
Steps
  1. Confirm the storefront uses Shopify Markets: Shopify automatically adds hreflang tags built from each market's configured languages and regions via content_for_header, and keeps them in sync with each page's own canonical URL and with market changes.
  2. If the Markets configuration is missing a language, region, or domain that should be in the cluster, add it in Markets rather than hand-editing hreflang output — the automatic tags are generated from that configuration.
  3. If hreflang is emitted manually instead of through content_for_header, build the tag set dynamically from the localization object rather than hardcoding domains or resource handles, because a handle can differ per language and the head partial renders on every page.
  4. Either way, confirm each localized URL still references itself as its own canonical URL — Shopify's guidance calls this out as a prerequisite for the automatic tags to behave correctly.
  
Verify on this platform
 
  • View source on a representative page in each market/language and confirm the emitted hreflang set is complete and reciprocal, then confirm each localized URL's own canonical tag matches its own URL.
 
Rollback
  1. Revert the Markets configuration change or the manual theme edit if it drops a market or language still needed, then re-diagnose the true cluster membership before republishing.
 
Caveats
  • This applies to Shopify Markets storefronts on Online Store themes using the standard content_for_header output; a storefront that overrides this partial, uses Hydrogen, or manages locales outside Markets is not covered — verify that system's own workflow instead.
  • Shopify's own hreflang documentation does not address x-default; do not assume Shopify emits one automatically.
 
Official sources
 
 
Platform-managed / ask the vendor
 
Status: platform-managed · Location: Vendor-owned page builder, headless frontend, or hosted platform template
 
Implementation is controlled by the platform or vendor.
  
Verify on this platform
 
  • Ask the vendor to confirm which single layer emits hreflang for the cluster and how cluster membership is kept in sync across pages, then fetch every cluster member directly to confirm reciprocal, self-referencing, live-target hreflang.
  
Caveats
  • Escalate when the vendor cannot identify the layer emitting hreflang, cannot explain how it keeps membership in sync across pages, or when fetched pages keep disagreeing after every input you control has been made consistent.
  • Do not accept a claim that hreflang is correct without directly fetching each cluster member and each alternate target.
 
Official sources
 
 
 
 
 How to verify 
 
  1. Fetch every page believed to be in the cluster and record its complete hreflang set.
  2. Confirm the set is identical across every member, that every member lists itself, and that every pair is reciprocal.
  3. Confirm every declared alternate target returns a live 200 response without redirecting, and that its own canonical points to itself rather than elsewhere.
  4. Rerun the returntag - hreflang checker (and, for pages diagnosed via Raw vs. Rendered HTML Checker, confirm the same hreflang set survives rendering) on the same cluster.
 
Escalate when
 
Escalate when the system responsible for cluster membership cannot be identified, more than one system claims to manage hreflang for the same pages, or fetched pages keep disagreeing on membership after every input you control has been made consistent.
 
 
 
 
 
 
 
returntag - hreflang checker · one finding
 
Alternate target is not a live 2xx page
 
Recommended action: Restore the alternate URL to a crawlable 2xx response or replace it everywhere in the cluster with a live localized page.
 
Fix principle: hreflang is a cluster property, not a per-page one: Google's own guidance states that if two pages don't both point to each other the annotations are ignored, and that every language version must list itself plus every other version identically. A unilateral edit on one page cannot fix a cluster — the reciprocal return tag, the self-reference, and the complete alternate set must all be corrected together, on every member, in the same change.
 
 
 
 Implementation for your setup 
 
Confirm first: An alternate page listed in the cluster does not itself list the source page back (the return/reciprocal tag is missing), so Google ignores the relationship for that pair. A page in the cluster has no self-referencing hreflang entry for its own locale and URL. An alternate target does not return a live 2xx response, redirects, or canonicalizes to a different URL than the one declared in hreflang — none of which Google will follow as the intended localized page. Pages in the same intended cluster disagree on membership: they do not all publish the same complete set of alternate URLs and locale codes. The cluster has no x-default entry despite serving a language selector, root domain, or otherwise ambiguous default experience.
 
Do not apply when: Every page in the cluster publishes an identical, reciprocal set of hreflang alternates — each page lists itself and every sibling, every sibling lists it back, and each declared target returns a live 200 response without redirecting or canonicalizing elsewhere. The cluster deliberately has no x-default because there is no ambiguous entry point (for example, every visitor arrives at an already-localized URL with no shared root or selector page).
 
Likely control points: cms-app · server · edge-cdn · managed-vendor
 
   
Choose the layer that owns the final response.
 
 
 
Generic HTTP / HTML
 
Status: supported · Location: Every page in the language cluster — origin template, application server, XML sitemap, or HTTP Link header, whichever layer emits hreflang for that site
 
Steps
  1. List every URL that is supposed to belong to the cluster, then fetch each one and record its complete hreflang set (from the HTML head, or the sitemap/Link-header equivalent, whichever the site uses).
  2. Build one target alternate set: every locale in the cluster paired with its live URL, plus a self-reference for each page's own locale, plus x-default if the cluster has an ambiguous default entry point.
  3. Publish that identical, complete set on every page in the cluster in the same change — a return tag added to only the target page while the source page stays unedited is still a broken pair.
  4. Confirm every alternate target itself returns a live 200 response on the URL declared in hreflang, without redirecting and without canonicalizing to a different URL.
  
Verify on this platform
 
  • Fetch each cluster member and confirm it lists itself plus every sibling, that every sibling lists it back, and that the set is byte-for-byte the same set of locale/URL pairs across all members.
  • Fetch each declared alternate target directly and confirm it returns 200 without redirecting, then confirm its own canonical tag matches its own URL rather than another page in or out of the cluster.
  • Rerun the returntag - hreflang checker on the full cluster (a URL or sitemap) and confirm no missing-return, missing-self, target-non-200, redirected-target, canonical-conflict, cluster-split, or x-default-gap findings remain.
 
Rollback
  1. Restore the previous hreflang set on any page where the correction removed a locale or URL still needed by another part of the site, then re-diagnose the true cluster membership before republishing.
 
Caveats
  • hreflang is a signal Google uses to select which localized URL to show, not a guarantee that the localized page will be served or ranked for that locale.
  • If two pages don't reciprocally reference each other, Google ignores the annotation for that pair entirely — a one-directional fix is not a partial fix.
  • Do not add an alternate target that is itself blocked from indexing or that never returns a 2xx response; that produces a new target-non-200 finding on the corrected cluster.
 
Official sources
 
 
WordPress
 
Status: supported · Location: Theme output via the wp_head hook, or the single plugin taking over hreflang output for a multilingual WordPress site
 
Steps
  1. Identify the one system that emits hreflang for the site — most multilingual WordPress sites use a dedicated multilingual plugin rather than manual theme code; confirm which single layer owns the output before changing anything.
  2. If hreflang is emitted manually via a theme template, build the alternate set from the site's own registered language/translation relationships so it can never drift from what the CMS itself considers the cluster, and output it identically on every member via wp_head.
  3. Whichever layer owns hreflang, treat cluster-membership drift (a page missing from the set, or a stale/removed translation still listed) as a content-management defect to fix in that system's translation-linking, not by hand-patching one page's markup.
  
Verify on this platform
 
  • While logged out, view the public HTML source of every page in the cluster and confirm each lists itself and every sibling reciprocally, then fetch each alternate target to confirm it is live and self-canonicalizing.
 
Rollback
  1. Restore the previous translation linkage or template output if the correction drops a locale relationship still needed elsewhere, then re-diagnose the true cluster membership before republishing.
 
Caveats
  • A dedicated multilingual plugin's own settings screen was not verified in this recipe — the exact admin path was not confirmed against current plugin documentation, so no specific menu or option is named here. Treat that plugin's hreflang output as platform-managed and use its own support documentation to correct translation relationships; only the fully manual, theme-emitted path above is verified.
  • If the plugin's hreflang output is itself broken (not merely a content-linking gap), that is a defect in a third-party layer this recipe cannot verify a fix for; escalate to the plugin's own support channel.
 
Official sources
 
 
Next.js / Vercel
 
Status: supported · Location: metadata.alternates.languages alongside alternates.canonical in the App Router, or the equivalent next/head output in the Pages Router
 
Steps
  1. For every route that belongs to a language cluster, set metadata.alternates.languages to the full, identical set of locale-to-URL pairs on every member route, paired with alternates.canonical set to that route's own URL.
  2. Set metadataBase once at the root layout so relative alternates.languages values resolve to the correct production host on every route rather than a preview domain.
  3. Add x-default to alternates.languages only where the cluster has an ambiguous default entry point (for example a locale-selector or root route).
  4. Do not let a route-level override replace alternates.languages with a partial set; merging in Next.js metadata replaces nested fields wholesale rather than merging them, so a child segment that sets alternates at all must set the complete set.
  
Verify on this platform
 
  • Fetch each deployed production route without executing JavaScript, confirm the emitted hreflang links are identical in membership across every cluster route and each pairs with that route's own canonical, then rerun the returntag - hreflang checker on the cluster.
 
Rollback
  1. Revert the metadata export for the affected route segment if the deployment drops a locale relationship still needed elsewhere, then correct the true cluster membership before redeploying.
 
Caveats
  • Confirm the production deployment domain matches metadataBase — a Preview Deployment URL served under a different host will not match the alternates it declares.
  • Metadata objects are merged shallowly per field across nested layouts and pages: a page that defines its own alternates.languages replaces the parent's set entirely rather than adding to it.
 
Official sources
 
 
Shopify
 
Status: supported · Location: Shopify Markets configuration, or the layout/theme.liquid content_for_header output for Markets-driven storefronts
 
Steps
  1. Confirm the storefront uses Shopify Markets: Shopify automatically adds hreflang tags built from each market's configured languages and regions via content_for_header, and keeps them in sync with each page's own canonical URL and with market changes.
  2. If the Markets configuration is missing a language, region, or domain that should be in the cluster, add it in Markets rather than hand-editing hreflang output — the automatic tags are generated from that configuration.
  3. If hreflang is emitted manually instead of through content_for_header, build the tag set dynamically from the localization object rather than hardcoding domains or resource handles, because a handle can differ per language and the head partial renders on every page.
  4. Either way, confirm each localized URL still references itself as its own canonical URL — Shopify's guidance calls this out as a prerequisite for the automatic tags to behave correctly.
  
Verify on this platform
 
  • View source on a representative page in each market/language and confirm the emitted hreflang set is complete and reciprocal, then confirm each localized URL's own canonical tag matches its own URL.
 
Rollback
  1. Revert the Markets configuration change or the manual theme edit if it drops a market or language still needed, then re-diagnose the true cluster membership before republishing.
 
Caveats
  • This applies to Shopify Markets storefronts on Online Store themes using the standard content_for_header output; a storefront that overrides this partial, uses Hydrogen, or manages locales outside Markets is not covered — verify that system's own workflow instead.
  • Shopify's own hreflang documentation does not address x-default; do not assume Shopify emits one automatically.
 
Official sources
 
 
Platform-managed / ask the vendor
 
Status: platform-managed · Location: Vendor-owned page builder, headless frontend, or hosted platform template
 
Implementation is controlled by the platform or vendor.
  
Verify on this platform
 
  • Ask the vendor to confirm which single layer emits hreflang for the cluster and how cluster membership is kept in sync across pages, then fetch every cluster member directly to confirm reciprocal, self-referencing, live-target hreflang.
  
Caveats
  • Escalate when the vendor cannot identify the layer emitting hreflang, cannot explain how it keeps membership in sync across pages, or when fetched pages keep disagreeing after every input you control has been made consistent.
  • Do not accept a claim that hreflang is correct without directly fetching each cluster member and each alternate target.
 
Official sources
 
 
 
 
 How to verify 
 
  1. Fetch every page believed to be in the cluster and record its complete hreflang set.
  2. Confirm the set is identical across every member, that every member lists itself, and that every pair is reciprocal.
  3. Confirm every declared alternate target returns a live 200 response without redirecting, and that its own canonical points to itself rather than elsewhere.
  4. Rerun the returntag - hreflang checker (and, for pages diagnosed via Raw vs. Rendered HTML Checker, confirm the same hreflang set survives rendering) on the same cluster.
 
Escalate when
 
Escalate when the system responsible for cluster membership cannot be identified, more than one system claims to manage hreflang for the same pages, or fetched pages keep disagreeing on membership after every input you control has been made consistent.
 
 
 
 
 
 
 
returntag - hreflang checker · one finding
 
Alternate target redirects
 
Recommended action: Update every hreflang reference to the redirect’s final 2xx URL and make that final URL self-reference.
 
Fix principle: hreflang is a cluster property, not a per-page one: Google's own guidance states that if two pages don't both point to each other the annotations are ignored, and that every language version must list itself plus every other version identically. A unilateral edit on one page cannot fix a cluster — the reciprocal return tag, the self-reference, and the complete alternate set must all be corrected together, on every member, in the same change.
 
 
 
 Implementation for your setup 
 
Confirm first: An alternate page listed in the cluster does not itself list the source page back (the return/reciprocal tag is missing), so Google ignores the relationship for that pair. A page in the cluster has no self-referencing hreflang entry for its own locale and URL. An alternate target does not return a live 2xx response, redirects, or canonicalizes to a different URL than the one declared in hreflang — none of which Google will follow as the intended localized page. Pages in the same intended cluster disagree on membership: they do not all publish the same complete set of alternate URLs and locale codes. The cluster has no x-default entry despite serving a language selector, root domain, or otherwise ambiguous default experience.
 
Do not apply when: Every page in the cluster publishes an identical, reciprocal set of hreflang alternates — each page lists itself and every sibling, every sibling lists it back, and each declared target returns a live 200 response without redirecting or canonicalizing elsewhere. The cluster deliberately has no x-default because there is no ambiguous entry point (for example, every visitor arrives at an already-localized URL with no shared root or selector page).
 
Likely control points: cms-app · server · edge-cdn · managed-vendor
 
   
Choose the layer that owns the final response.
 
 
 
Generic HTTP / HTML
 
Status: supported · Location: Every page in the language cluster — origin template, application server, XML sitemap, or HTTP Link header, whichever layer emits hreflang for that site
 
Steps
  1. List every URL that is supposed to belong to the cluster, then fetch each one and record its complete hreflang set (from the HTML head, or the sitemap/Link-header equivalent, whichever the site uses).
  2. Build one target alternate set: every locale in the cluster paired with its live URL, plus a self-reference for each page's own locale, plus x-default if the cluster has an ambiguous default entry point.
  3. Publish that identical, complete set on every page in the cluster in the same change — a return tag added to only the target page while the source page stays unedited is still a broken pair.
  4. Confirm every alternate target itself returns a live 200 response on the URL declared in hreflang, without redirecting and without canonicalizing to a different URL.
  
Verify on this platform
 
  • Fetch each cluster member and confirm it lists itself plus every sibling, that every sibling lists it back, and that the set is byte-for-byte the same set of locale/URL pairs across all members.
  • Fetch each declared alternate target directly and confirm it returns 200 without redirecting, then confirm its own canonical tag matches its own URL rather than another page in or out of the cluster.
  • Rerun the returntag - hreflang checker on the full cluster (a URL or sitemap) and confirm no missing-return, missing-self, target-non-200, redirected-target, canonical-conflict, cluster-split, or x-default-gap findings remain.
 
Rollback
  1. Restore the previous hreflang set on any page where the correction removed a locale or URL still needed by another part of the site, then re-diagnose the true cluster membership before republishing.
 
Caveats
  • hreflang is a signal Google uses to select which localized URL to show, not a guarantee that the localized page will be served or ranked for that locale.
  • If two pages don't reciprocally reference each other, Google ignores the annotation for that pair entirely — a one-directional fix is not a partial fix.
  • Do not add an alternate target that is itself blocked from indexing or that never returns a 2xx response; that produces a new target-non-200 finding on the corrected cluster.
 
Official sources
 
 
WordPress
 
Status: supported · Location: Theme output via the wp_head hook, or the single plugin taking over hreflang output for a multilingual WordPress site
 
Steps
  1. Identify the one system that emits hreflang for the site — most multilingual WordPress sites use a dedicated multilingual plugin rather than manual theme code; confirm which single layer owns the output before changing anything.
  2. If hreflang is emitted manually via a theme template, build the alternate set from the site's own registered language/translation relationships so it can never drift from what the CMS itself considers the cluster, and output it identically on every member via wp_head.
  3. Whichever layer owns hreflang, treat cluster-membership drift (a page missing from the set, or a stale/removed translation still listed) as a content-management defect to fix in that system's translation-linking, not by hand-patching one page's markup.
  
Verify on this platform
 
  • While logged out, view the public HTML source of every page in the cluster and confirm each lists itself and every sibling reciprocally, then fetch each alternate target to confirm it is live and self-canonicalizing.
 
Rollback
  1. Restore the previous translation linkage or template output if the correction drops a locale relationship still needed elsewhere, then re-diagnose the true cluster membership before republishing.
 
Caveats
  • A dedicated multilingual plugin's own settings screen was not verified in this recipe — the exact admin path was not confirmed against current plugin documentation, so no specific menu or option is named here. Treat that plugin's hreflang output as platform-managed and use its own support documentation to correct translation relationships; only the fully manual, theme-emitted path above is verified.
  • If the plugin's hreflang output is itself broken (not merely a content-linking gap), that is a defect in a third-party layer this recipe cannot verify a fix for; escalate to the plugin's own support channel.
 
Official sources
 
 
Next.js / Vercel
 
Status: supported · Location: metadata.alternates.languages alongside alternates.canonical in the App Router, or the equivalent next/head output in the Pages Router
 
Steps
  1. For every route that belongs to a language cluster, set metadata.alternates.languages to the full, identical set of locale-to-URL pairs on every member route, paired with alternates.canonical set to that route's own URL.
  2. Set metadataBase once at the root layout so relative alternates.languages values resolve to the correct production host on every route rather than a preview domain.
  3. Add x-default to alternates.languages only where the cluster has an ambiguous default entry point (for example a locale-selector or root route).
  4. Do not let a route-level override replace alternates.languages with a partial set; merging in Next.js metadata replaces nested fields wholesale rather than merging them, so a child segment that sets alternates at all must set the complete set.
  
Verify on this platform
 
  • Fetch each deployed production route without executing JavaScript, confirm the emitted hreflang links are identical in membership across every cluster route and each pairs with that route's own canonical, then rerun the returntag - hreflang checker on the cluster.
 
Rollback
  1. Revert the metadata export for the affected route segment if the deployment drops a locale relationship still needed elsewhere, then correct the true cluster membership before redeploying.
 
Caveats
  • Confirm the production deployment domain matches metadataBase — a Preview Deployment URL served under a different host will not match the alternates it declares.
  • Metadata objects are merged shallowly per field across nested layouts and pages: a page that defines its own alternates.languages replaces the parent's set entirely rather than adding to it.
 
Official sources
 
 
Shopify
 
Status: supported · Location: Shopify Markets configuration, or the layout/theme.liquid content_for_header output for Markets-driven storefronts
 
Steps
  1. Confirm the storefront uses Shopify Markets: Shopify automatically adds hreflang tags built from each market's configured languages and regions via content_for_header, and keeps them in sync with each page's own canonical URL and with market changes.
  2. If the Markets configuration is missing a language, region, or domain that should be in the cluster, add it in Markets rather than hand-editing hreflang output — the automatic tags are generated from that configuration.
  3. If hreflang is emitted manually instead of through content_for_header, build the tag set dynamically from the localization object rather than hardcoding domains or resource handles, because a handle can differ per language and the head partial renders on every page.
  4. Either way, confirm each localized URL still references itself as its own canonical URL — Shopify's guidance calls this out as a prerequisite for the automatic tags to behave correctly.
  
Verify on this platform
 
  • View source on a representative page in each market/language and confirm the emitted hreflang set is complete and reciprocal, then confirm each localized URL's own canonical tag matches its own URL.
 
Rollback
  1. Revert the Markets configuration change or the manual theme edit if it drops a market or language still needed, then re-diagnose the true cluster membership before republishing.
 
Caveats
  • This applies to Shopify Markets storefronts on Online Store themes using the standard content_for_header output; a storefront that overrides this partial, uses Hydrogen, or manages locales outside Markets is not covered — verify that system's own workflow instead.
  • Shopify's own hreflang documentation does not address x-default; do not assume Shopify emits one automatically.
 
Official sources
 
 
Platform-managed / ask the vendor
 
Status: platform-managed · Location: Vendor-owned page builder, headless frontend, or hosted platform template
 
Implementation is controlled by the platform or vendor.
  
Verify on this platform
 
  • Ask the vendor to confirm which single layer emits hreflang for the cluster and how cluster membership is kept in sync across pages, then fetch every cluster member directly to confirm reciprocal, self-referencing, live-target hreflang.
  
Caveats
  • Escalate when the vendor cannot identify the layer emitting hreflang, cannot explain how it keeps membership in sync across pages, or when fetched pages keep disagreeing after every input you control has been made consistent.
  • Do not accept a claim that hreflang is correct without directly fetching each cluster member and each alternate target.
 
Official sources
 
 
 
 
 How to verify 
 
  1. Fetch every page believed to be in the cluster and record its complete hreflang set.
  2. Confirm the set is identical across every member, that every member lists itself, and that every pair is reciprocal.
  3. Confirm every declared alternate target returns a live 200 response without redirecting, and that its own canonical points to itself rather than elsewhere.
  4. Rerun the returntag - hreflang checker (and, for pages diagnosed via Raw vs. Rendered HTML Checker, confirm the same hreflang set survives rendering) on the same cluster.
 
Escalate when
 
Escalate when the system responsible for cluster membership cannot be identified, more than one system claims to manage hreflang for the same pages, or fetched pages keep disagreeing on membership after every input you control has been made consistent.
 
 
 
 
 
 
 
returntag - hreflang checker · one finding
 
Pages disagree on cluster membership
 
Recommended action: Make every page in the intended language cluster publish the same complete set of alternate URLs and reciprocal locale codes.
 
Fix principle: hreflang is a cluster property, not a per-page one: Google's own guidance states that if two pages don't both point to each other the annotations are ignored, and that every language version must list itself plus every other version identically. A unilateral edit on one page cannot fix a cluster — the reciprocal return tag, the self-reference, and the complete alternate set must all be corrected together, on every member, in the same change.
 
 
 
 Implementation for your setup 
 
Confirm first: An alternate page listed in the cluster does not itself list the source page back (the return/reciprocal tag is missing), so Google ignores the relationship for that pair. A page in the cluster has no self-referencing hreflang entry for its own locale and URL. An alternate target does not return a live 2xx response, redirects, or canonicalizes to a different URL than the one declared in hreflang — none of which Google will follow as the intended localized page. Pages in the same intended cluster disagree on membership: they do not all publish the same complete set of alternate URLs and locale codes. The cluster has no x-default entry despite serving a language selector, root domain, or otherwise ambiguous default experience.
 
Do not apply when: Every page in the cluster publishes an identical, reciprocal set of hreflang alternates — each page lists itself and every sibling, every sibling lists it back, and each declared target returns a live 200 response without redirecting or canonicalizing elsewhere. The cluster deliberately has no x-default because there is no ambiguous entry point (for example, every visitor arrives at an already-localized URL with no shared root or selector page).
 
Likely control points: cms-app · server · edge-cdn · managed-vendor
 
   
Choose the layer that owns the final response.
 
 
 
Generic HTTP / HTML
 
Status: supported · Location: Every page in the language cluster — origin template, application server, XML sitemap, or HTTP Link header, whichever layer emits hreflang for that site
 
Steps
  1. List every URL that is supposed to belong to the cluster, then fetch each one and record its complete hreflang set (from the HTML head, or the sitemap/Link-header equivalent, whichever the site uses).
  2. Build one target alternate set: every locale in the cluster paired with its live URL, plus a self-reference for each page's own locale, plus x-default if the cluster has an ambiguous default entry point.
  3. Publish that identical, complete set on every page in the cluster in the same change — a return tag added to only the target page while the source page stays unedited is still a broken pair.
  4. Confirm every alternate target itself returns a live 200 response on the URL declared in hreflang, without redirecting and without canonicalizing to a different URL.
  
Verify on this platform
 
  • Fetch each cluster member and confirm it lists itself plus every sibling, that every sibling lists it back, and that the set is byte-for-byte the same set of locale/URL pairs across all members.
  • Fetch each declared alternate target directly and confirm it returns 200 without redirecting, then confirm its own canonical tag matches its own URL rather than another page in or out of the cluster.
  • Rerun the returntag - hreflang checker on the full cluster (a URL or sitemap) and confirm no missing-return, missing-self, target-non-200, redirected-target, canonical-conflict, cluster-split, or x-default-gap findings remain.
 
Rollback
  1. Restore the previous hreflang set on any page where the correction removed a locale or URL still needed by another part of the site, then re-diagnose the true cluster membership before republishing.
 
Caveats
  • hreflang is a signal Google uses to select which localized URL to show, not a guarantee that the localized page will be served or ranked for that locale.
  • If two pages don't reciprocally reference each other, Google ignores the annotation for that pair entirely — a one-directional fix is not a partial fix.
  • Do not add an alternate target that is itself blocked from indexing or that never returns a 2xx response; that produces a new target-non-200 finding on the corrected cluster.
 
Official sources
 
 
WordPress
 
Status: supported · Location: Theme output via the wp_head hook, or the single plugin taking over hreflang output for a multilingual WordPress site
 
Steps
  1. Identify the one system that emits hreflang for the site — most multilingual WordPress sites use a dedicated multilingual plugin rather than manual theme code; confirm which single layer owns the output before changing anything.
  2. If hreflang is emitted manually via a theme template, build the alternate set from the site's own registered language/translation relationships so it can never drift from what the CMS itself considers the cluster, and output it identically on every member via wp_head.
  3. Whichever layer owns hreflang, treat cluster-membership drift (a page missing from the set, or a stale/removed translation still listed) as a content-management defect to fix in that system's translation-linking, not by hand-patching one page's markup.
  
Verify on this platform
 
  • While logged out, view the public HTML source of every page in the cluster and confirm each lists itself and every sibling reciprocally, then fetch each alternate target to confirm it is live and self-canonicalizing.
 
Rollback
  1. Restore the previous translation linkage or template output if the correction drops a locale relationship still needed elsewhere, then re-diagnose the true cluster membership before republishing.
 
Caveats
  • A dedicated multilingual plugin's own settings screen was not verified in this recipe — the exact admin path was not confirmed against current plugin documentation, so no specific menu or option is named here. Treat that plugin's hreflang output as platform-managed and use its own support documentation to correct translation relationships; only the fully manual, theme-emitted path above is verified.
  • If the plugin's hreflang output is itself broken (not merely a content-linking gap), that is a defect in a third-party layer this recipe cannot verify a fix for; escalate to the plugin's own support channel.
 
Official sources
 
 
Next.js / Vercel
 
Status: supported · Location: metadata.alternates.languages alongside alternates.canonical in the App Router, or the equivalent next/head output in the Pages Router
 
Steps
  1. For every route that belongs to a language cluster, set metadata.alternates.languages to the full, identical set of locale-to-URL pairs on every member route, paired with alternates.canonical set to that route's own URL.
  2. Set metadataBase once at the root layout so relative alternates.languages values resolve to the correct production host on every route rather than a preview domain.
  3. Add x-default to alternates.languages only where the cluster has an ambiguous default entry point (for example a locale-selector or root route).
  4. Do not let a route-level override replace alternates.languages with a partial set; merging in Next.js metadata replaces nested fields wholesale rather than merging them, so a child segment that sets alternates at all must set the complete set.
  
Verify on this platform
 
  • Fetch each deployed production route without executing JavaScript, confirm the emitted hreflang links are identical in membership across every cluster route and each pairs with that route's own canonical, then rerun the returntag - hreflang checker on the cluster.
 
Rollback
  1. Revert the metadata export for the affected route segment if the deployment drops a locale relationship still needed elsewhere, then correct the true cluster membership before redeploying.
 
Caveats
  • Confirm the production deployment domain matches metadataBase — a Preview Deployment URL served under a different host will not match the alternates it declares.
  • Metadata objects are merged shallowly per field across nested layouts and pages: a page that defines its own alternates.languages replaces the parent's set entirely rather than adding to it.
 
Official sources
 
 
Shopify
 
Status: supported · Location: Shopify Markets configuration, or the layout/theme.liquid content_for_header output for Markets-driven storefronts
 
Steps
  1. Confirm the storefront uses Shopify Markets: Shopify automatically adds hreflang tags built from each market's configured languages and regions via content_for_header, and keeps them in sync with each page's own canonical URL and with market changes.
  2. If the Markets configuration is missing a language, region, or domain that should be in the cluster, add it in Markets rather than hand-editing hreflang output — the automatic tags are generated from that configuration.
  3. If hreflang is emitted manually instead of through content_for_header, build the tag set dynamically from the localization object rather than hardcoding domains or resource handles, because a handle can differ per language and the head partial renders on every page.
  4. Either way, confirm each localized URL still references itself as its own canonical URL — Shopify's guidance calls this out as a prerequisite for the automatic tags to behave correctly.
  
Verify on this platform
 
  • View source on a representative page in each market/language and confirm the emitted hreflang set is complete and reciprocal, then confirm each localized URL's own canonical tag matches its own URL.
 
Rollback
  1. Revert the Markets configuration change or the manual theme edit if it drops a market or language still needed, then re-diagnose the true cluster membership before republishing.
 
Caveats
  • This applies to Shopify Markets storefronts on Online Store themes using the standard content_for_header output; a storefront that overrides this partial, uses Hydrogen, or manages locales outside Markets is not covered — verify that system's own workflow instead.
  • Shopify's own hreflang documentation does not address x-default; do not assume Shopify emits one automatically.
 
Official sources
 
 
Platform-managed / ask the vendor
 
Status: platform-managed · Location: Vendor-owned page builder, headless frontend, or hosted platform template
 
Implementation is controlled by the platform or vendor.
  
Verify on this platform
 
  • Ask the vendor to confirm which single layer emits hreflang for the cluster and how cluster membership is kept in sync across pages, then fetch every cluster member directly to confirm reciprocal, self-referencing, live-target hreflang.
  
Caveats
  • Escalate when the vendor cannot identify the layer emitting hreflang, cannot explain how it keeps membership in sync across pages, or when fetched pages keep disagreeing after every input you control has been made consistent.
  • Do not accept a claim that hreflang is correct without directly fetching each cluster member and each alternate target.
 
Official sources
 
 
 
 
 How to verify 
 
  1. Fetch every page believed to be in the cluster and record its complete hreflang set.
  2. Confirm the set is identical across every member, that every member lists itself, and that every pair is reciprocal.
  3. Confirm every declared alternate target returns a live 200 response without redirecting, and that its own canonical points to itself rather than elsewhere.
  4. Rerun the returntag - hreflang checker (and, for pages diagnosed via Raw vs. Rendered HTML Checker, confirm the same hreflang set survives rendering) on the same cluster.
 
Escalate when
 
Escalate when the system responsible for cluster membership cannot be identified, more than one system claims to manage hreflang for the same pages, or fetched pages keep disagreeing on membership after every input you control has been made consistent.
 
 
 
 
 
 
 
returntag - hreflang checker · one finding
 
Cluster has no x-default page
 
Recommended action: Add the same x-default URL to every member of the cluster, usually pointing to a locale selector or global default.
 
Fix principle: hreflang is a cluster property, not a per-page one: Google's own guidance states that if two pages don't both point to each other the annotations are ignored, and that every language version must list itself plus every other version identically. A unilateral edit on one page cannot fix a cluster — the reciprocal return tag, the self-reference, and the complete alternate set must all be corrected together, on every member, in the same change.
 
 
 
 Implementation for your setup 
 
Confirm first: An alternate page listed in the cluster does not itself list the source page back (the return/reciprocal tag is missing), so Google ignores the relationship for that pair. A page in the cluster has no self-referencing hreflang entry for its own locale and URL. An alternate target does not return a live 2xx response, redirects, or canonicalizes to a different URL than the one declared in hreflang — none of which Google will follow as the intended localized page. Pages in the same intended cluster disagree on membership: they do not all publish the same complete set of alternate URLs and locale codes. The cluster has no x-default entry despite serving a language selector, root domain, or otherwise ambiguous default experience.
 
Do not apply when: Every page in the cluster publishes an identical, reciprocal set of hreflang alternates — each page lists itself and every sibling, every sibling lists it back, and each declared target returns a live 200 response without redirecting or canonicalizing elsewhere. The cluster deliberately has no x-default because there is no ambiguous entry point (for example, every visitor arrives at an already-localized URL with no shared root or selector page).
 
Likely control points: cms-app · server · edge-cdn · managed-vendor
 
   
Choose the layer that owns the final response.
 
 
 
Generic HTTP / HTML
 
Status: supported · Location: Every page in the language cluster — origin template, application server, XML sitemap, or HTTP Link header, whichever layer emits hreflang for that site
 
Steps
  1. List every URL that is supposed to belong to the cluster, then fetch each one and record its complete hreflang set (from the HTML head, or the sitemap/Link-header equivalent, whichever the site uses).
  2. Build one target alternate set: every locale in the cluster paired with its live URL, plus a self-reference for each page's own locale, plus x-default if the cluster has an ambiguous default entry point.
  3. Publish that identical, complete set on every page in the cluster in the same change — a return tag added to only the target page while the source page stays unedited is still a broken pair.
  4. Confirm every alternate target itself returns a live 200 response on the URL declared in hreflang, without redirecting and without canonicalizing to a different URL.
  
Verify on this platform
 
  • Fetch each cluster member and confirm it lists itself plus every sibling, that every sibling lists it back, and that the set is byte-for-byte the same set of locale/URL pairs across all members.
  • Fetch each declared alternate target directly and confirm it returns 200 without redirecting, then confirm its own canonical tag matches its own URL rather than another page in or out of the cluster.
  • Rerun the returntag - hreflang checker on the full cluster (a URL or sitemap) and confirm no missing-return, missing-self, target-non-200, redirected-target, canonical-conflict, cluster-split, or x-default-gap findings remain.
 
Rollback
  1. Restore the previous hreflang set on any page where the correction removed a locale or URL still needed by another part of the site, then re-diagnose the true cluster membership before republishing.
 
Caveats
  • hreflang is a signal Google uses to select which localized URL to show, not a guarantee that the localized page will be served or ranked for that locale.
  • If two pages don't reciprocally reference each other, Google ignores the annotation for that pair entirely — a one-directional fix is not a partial fix.
  • Do not add an alternate target that is itself blocked from indexing or that never returns a 2xx response; that produces a new target-non-200 finding on the corrected cluster.
 
Official sources
 
 
WordPress
 
Status: supported · Location: Theme output via the wp_head hook, or the single plugin taking over hreflang output for a multilingual WordPress site
 
Steps
  1. Identify the one system that emits hreflang for the site — most multilingual WordPress sites use a dedicated multilingual plugin rather than manual theme code; confirm which single layer owns the output before changing anything.
  2. If hreflang is emitted manually via a theme template, build the alternate set from the site's own registered language/translation relationships so it can never drift from what the CMS itself considers the cluster, and output it identically on every member via wp_head.
  3. Whichever layer owns hreflang, treat cluster-membership drift (a page missing from the set, or a stale/removed translation still listed) as a content-management defect to fix in that system's translation-linking, not by hand-patching one page's markup.
  
Verify on this platform
 
  • While logged out, view the public HTML source of every page in the cluster and confirm each lists itself and every sibling reciprocally, then fetch each alternate target to confirm it is live and self-canonicalizing.
 
Rollback
  1. Restore the previous translation linkage or template output if the correction drops a locale relationship still needed elsewhere, then re-diagnose the true cluster membership before republishing.
 
Caveats
  • A dedicated multilingual plugin's own settings screen was not verified in this recipe — the exact admin path was not confirmed against current plugin documentation, so no specific menu or option is named here. Treat that plugin's hreflang output as platform-managed and use its own support documentation to correct translation relationships; only the fully manual, theme-emitted path above is verified.
  • If the plugin's hreflang output is itself broken (not merely a content-linking gap), that is a defect in a third-party layer this recipe cannot verify a fix for; escalate to the plugin's own support channel.
 
Official sources
 
 
Next.js / Vercel
 
Status: supported · Location: metadata.alternates.languages alongside alternates.canonical in the App Router, or the equivalent next/head output in the Pages Router
 
Steps
  1. For every route that belongs to a language cluster, set metadata.alternates.languages to the full, identical set of locale-to-URL pairs on every member route, paired with alternates.canonical set to that route's own URL.
  2. Set metadataBase once at the root layout so relative alternates.languages values resolve to the correct production host on every route rather than a preview domain.
  3. Add x-default to alternates.languages only where the cluster has an ambiguous default entry point (for example a locale-selector or root route).
  4. Do not let a route-level override replace alternates.languages with a partial set; merging in Next.js metadata replaces nested fields wholesale rather than merging them, so a child segment that sets alternates at all must set the complete set.
  
Verify on this platform
 
  • Fetch each deployed production route without executing JavaScript, confirm the emitted hreflang links are identical in membership across every cluster route and each pairs with that route's own canonical, then rerun the returntag - hreflang checker on the cluster.
 
Rollback
  1. Revert the metadata export for the affected route segment if the deployment drops a locale relationship still needed elsewhere, then correct the true cluster membership before redeploying.
 
Caveats
  • Confirm the production deployment domain matches metadataBase — a Preview Deployment URL served under a different host will not match the alternates it declares.
  • Metadata objects are merged shallowly per field across nested layouts and pages: a page that defines its own alternates.languages replaces the parent's set entirely rather than adding to it.
 
Official sources
 
 
Shopify
 
Status: supported · Location: Shopify Markets configuration, or the layout/theme.liquid content_for_header output for Markets-driven storefronts
 
Steps
  1. Confirm the storefront uses Shopify Markets: Shopify automatically adds hreflang tags built from each market's configured languages and regions via content_for_header, and keeps them in sync with each page's own canonical URL and with market changes.
  2. If the Markets configuration is missing a language, region, or domain that should be in the cluster, add it in Markets rather than hand-editing hreflang output — the automatic tags are generated from that configuration.
  3. If hreflang is emitted manually instead of through content_for_header, build the tag set dynamically from the localization object rather than hardcoding domains or resource handles, because a handle can differ per language and the head partial renders on every page.
  4. Either way, confirm each localized URL still references itself as its own canonical URL — Shopify's guidance calls this out as a prerequisite for the automatic tags to behave correctly.
  
Verify on this platform
 
  • View source on a representative page in each market/language and confirm the emitted hreflang set is complete and reciprocal, then confirm each localized URL's own canonical tag matches its own URL.
 
Rollback
  1. Revert the Markets configuration change or the manual theme edit if it drops a market or language still needed, then re-diagnose the true cluster membership before republishing.
 
Caveats
  • This applies to Shopify Markets storefronts on Online Store themes using the standard content_for_header output; a storefront that overrides this partial, uses Hydrogen, or manages locales outside Markets is not covered — verify that system's own workflow instead.
  • Shopify's own hreflang documentation does not address x-default; do not assume Shopify emits one automatically.
 
Official sources
 
 
Platform-managed / ask the vendor
 
Status: platform-managed · Location: Vendor-owned page builder, headless frontend, or hosted platform template
 
Implementation is controlled by the platform or vendor.
  
Verify on this platform
 
  • Ask the vendor to confirm which single layer emits hreflang for the cluster and how cluster membership is kept in sync across pages, then fetch every cluster member directly to confirm reciprocal, self-referencing, live-target hreflang.
  
Caveats
  • Escalate when the vendor cannot identify the layer emitting hreflang, cannot explain how it keeps membership in sync across pages, or when fetched pages keep disagreeing after every input you control has been made consistent.
  • Do not accept a claim that hreflang is correct without directly fetching each cluster member and each alternate target.
 
Official sources
 
 
 
 
 How to verify 
 
  1. Fetch every page believed to be in the cluster and record its complete hreflang set.
  2. Confirm the set is identical across every member, that every member lists itself, and that every pair is reciprocal.
  3. Confirm every declared alternate target returns a live 200 response without redirecting, and that its own canonical points to itself rather than elsewhere.
  4. Rerun the returntag - hreflang checker (and, for pages diagnosed via Raw vs. Rendered HTML Checker, confirm the same hreflang set survives rendering) on the same cluster.
 
Escalate when
 
Escalate when the system responsible for cluster membership cannot be identified, more than one system claims to manage hreflang for the same pages, or fetched pages keep disagreeing on membership after every input you control has been made consistent.
 
 
 
 
  
 
 
     
  •  Errors hreflang code is invalid Fix: Replace the hreflang value with a valid language code, optionally followed by a valid region using a hyphen, or use x-default. 
  •  Warnings Page declares the same locale more than once Fix: Keep one canonical alternate URL for the locale on that page and remove the duplicate declaration. 
    •