Technology

Hreflang Setup: Canonical, x-default and Sitemaps

Translated copy and clean URLs are only part of international SEO. Incorrect or missing hreflang annotations can make it harder for search engines to identify the intended localized alternatives.

International SEO requires a page-level map of languages, optional regions and equivalent content. Domain structure also affects ownership, maintenance and reporting. A ccTLD, subdirectory or subdomain can host a localized version, but the URL pattern alone does not complete its hreflang implementation.

This guide covers domain structure, canonical decisions, x-default and the three equivalent implementation methods: HTML, HTTP headers and XML sitemaps. Establish the intended page relationships before generating annotations, then validate the output and actual URL behavior.

What Hreflang Tells Google

Hreflang helps Google identify localized alternatives for the same page and show an appropriate language or regional version. It does not perform a redirect or guarantee rankings. Google determines the language from visible content rather than using hreflang or the HTML lang attribute as its language detector.

Equivalent Pages and Reciprocal Links

An English pricing page for the U.S., an English variant for the U.K. and a Spanish version for Spain can be related alternatives. Differences in prices or available plans do not automatically make them unrelated. Match the page’s purpose; do not connect every product page to a foreign-language home page. Hreflang does not guarantee lower bounce rates or remove competition between pages.

Hreflang relationships must be reciprocal. For a complete implementation, every page should list itself and the other alternates. Missing return links can invalidate the affected relationships without necessarily invalidating the entire set.

Language and Region Codes

Google supports ISO 639-1 language codes and optional ISO 3166-1 alpha-2 regions, such as en, en-GB and en-US. Use en-GB rather than en-UK; a region code alone is insufficient. A less familiar combination can still be valid: tr-DE means Turkish for users in Germany. Supported script forms are described in Google’s localized-versions guide. The BCP 47 reference provides broader language-tag background; not every BCP 47 form is supported by Google hreflang.

Canonical and Hreflang Have Different Jobs

Canonical identifies the preferred URL among duplicates; hreflang identifies language or regional alternatives. Do not consolidate translated main content into one language merely because the pages are translations. Self-referencing canonicals suit distinct localized pages intended for separate indexing. For similar or duplicate regional pages in the same language, Google recommends choosing a preferred version and using canonical with hreflang. Specify a canonical in the same language where possible; “every regional URL must self-canonicalize” is not a universal rule.

ccTLD, Subdirectory, or Subdomain: Picking the Home for Each Locale

A ccTLD such as .fr can provide a strong country signal, subject to Google’s treatment of that TLD; some ccTLDs are treated generically. Registry eligibility, brand goals and domain management matter too. Subdirectories can share a host and administration, while subdomains can separate platforms or hosting. None of these structures guarantees rankings or inherently requires a separate CMS per market.

Choose a structure the responsible teams can maintain. Record domain ownership, content approval, redirects, URL mapping and reporting. Local teams or registry requirements may favor ccTLDs; an existing platform may favor subdirectories or subdomains. The same reciprocal hreflang rules apply across hosts.

Multiple hosts also require a reporting and certificate plan. Cross-domain analytics needs an appropriate configuration and consent model; cookies cannot simply be shared across unrelated domains. Certificate coverage and renewal must be monitored, although a multi-domain certificate may cover several names. These are operational considerations, not hreflang requirements.

The ccTLD versus gTLD and international SEO guide covers related brand and domain governance choices. Use those decisions alongside the page-level locale map.

A hypothetical consolidation scenario

Consider a hypothetical team using ccTLDs for Europe and subdirectories for Asia. If its European sites have separate CMS instances, redirects, and sitemaps, unified campaigns could require extra coordination. Consolidating into subdirectories might simplify operations, while retaining ccTLDs where business or registry requirements warrant them. Separate CMS instances are not inherent to ccTLDs, however, and consolidation would still require migration planning; stable rankings and faster launches are not guaranteed.

x-default: A Fallback for Unmatched Languages

x-default identifies the destination for users whose language settings do not match the declared alternatives. It does not identify first-time visitors, remember preferences or run an application redirect.

x-default is optional. Google allows it on any page, although it was designed for language selectors. An existing U.S. English page can be the intended fallback; neutrality is a usability choice, not an eligibility requirement. Consider whether its currency, shipping and legal information suit unmatched audiences.

Keep a visible language or region selector and allow direct access to localized URLs. Avoid forced language redirects based on IP or inferred preferences. Googlebot usually originates in the U.S. and does not send Accept-Language; Google may not discover all content variations behind location-dependent behavior. Application preference storage is separate from the hreflang annotation.

If you use x-default, include it consistently in the declared set and maintain return relationships. A shared selector must preserve the relevant page context; do not make one generic gateway claim to be the localized equivalent of every unrelated product.

Implement with HTML, HTTP Headers or XML Sitemaps

The three methods are equivalent from Google’s perspective. Choose the method your system can maintain accurately. There is no additional search benefit from implementing all three; if multiple methods exist, keep their outputs consistent.

HTML head tags

The following tags belong inside a well-formed HTML head. This example assumes distinct localized pricing pages intended for separate indexing; the canonical shown belongs to the U.S. page. On each other page, use its appropriate canonical decision and the same complete alternate set. URLs are illustrative and have not been tested as live endpoints.

<link rel="canonical" href="https://www.example.com/en-us/pricing/" />
<link rel="alternate" hreflang="en-US" href="https://www.example.com/en-us/pricing/" />
<link rel="alternate" hreflang="en-GB" href="https://www.example.com/en-gb/pricing/" />
<link rel="alternate" hreflang="es-ES" href="https://www.example.com/es-es/precios/" />
<link rel="alternate" hreflang="x-default" href="https://www.example.com/global/pricing/" />

The alternate set includes the current URL. Do not copy the U.S. canonical onto all pages or treat this example as a rule for same-language regional duplicates. Those require the preferred-version analysis described above.

XML sitemaps

The following is a complete same-host sitemap for the three pricing variants and the x-default destination. It includes the XML declaration, urlset root, sitemap and XHTML namespaces, one loc entry per URL, and the same four alternates in every entry. The example assumes these are the preferred URLs for its distinct pages and that the sitemap is hosted at the site root.

<?xml version="1.0" encoding="UTF-8"?>
<urlset xmlns="http://www.sitemaps.org/schemas/sitemap/0.9"
        xmlns:xhtml="http://www.w3.org/1999/xhtml">
  <url>
    <loc>https://www.example.com/en-us/pricing/</loc>
    <xhtml:link rel="alternate" hreflang="en-US" href="https://www.example.com/en-us/pricing/" />
    <xhtml:link rel="alternate" hreflang="en-GB" href="https://www.example.com/en-gb/pricing/" />
    <xhtml:link rel="alternate" hreflang="es-ES" href="https://www.example.com/es-es/precios/" />
    <xhtml:link rel="alternate" hreflang="x-default" href="https://www.example.com/global/pricing/" />
  </url>
  <url>
    <loc>https://www.example.com/en-gb/pricing/</loc>
    <xhtml:link rel="alternate" hreflang="en-US" href="https://www.example.com/en-us/pricing/" />
    <xhtml:link rel="alternate" hreflang="en-GB" href="https://www.example.com/en-gb/pricing/" />
    <xhtml:link rel="alternate" hreflang="es-ES" href="https://www.example.com/es-es/precios/" />
    <xhtml:link rel="alternate" hreflang="x-default" href="https://www.example.com/global/pricing/" />
  </url>
  <url>
    <loc>https://www.example.com/es-es/precios/</loc>
    <xhtml:link rel="alternate" hreflang="en-US" href="https://www.example.com/en-us/pricing/" />
    <xhtml:link rel="alternate" hreflang="en-GB" href="https://www.example.com/en-gb/pricing/" />
    <xhtml:link rel="alternate" hreflang="es-ES" href="https://www.example.com/es-es/precios/" />
    <xhtml:link rel="alternate" hreflang="x-default" href="https://www.example.com/global/pricing/" />
  </url>
  <url>
    <loc>https://www.example.com/global/pricing/</loc>
    <xhtml:link rel="alternate" hreflang="en-US" href="https://www.example.com/en-us/pricing/" />
    <xhtml:link rel="alternate" hreflang="en-GB" href="https://www.example.com/en-gb/pricing/" />
    <xhtml:link rel="alternate" hreflang="es-ES" href="https://www.example.com/es-es/precios/" />
    <xhtml:link rel="alternate" hreflang="x-default" href="https://www.example.com/global/pricing/" />
  </url>
</urlset>

Keep the sitemap’s loc records distinct from the alternate href links. A loc submits a page URL within the sitemap’s scope; an xhtml:link may refer to a different domain as a localized alternative. That foreign-host reference alone does not require adding every sitemap separately to every Search Console property. Cross-site loc submission or hosting a sitemap away from its site has separate ownership rules.

For cross-site submission, Google supports a Search Console route in which you verify ownership of all covered sites and submit the sitemap or index. Its robots.txt route uses separate sitemaps per site, each containing only that site’s loc URLs; each site’s robots.txt references its own sitemap, even if stored centrally. General sitemap rules still apply. Google’s hreflang documentation explains the alternate extension; the sitemap submission reference below explains ownership and scope.

HTTP headers

A GET response can carry a Link header listing every alternate, including the requested file. This is useful for non-HTML content such as PDFs. Each alternate response should return the same set. Check that the origin, reverse proxy and CDN preserve it; a CDN or rewrite change can alter header output.

Keep One Page-Level Locale Map

Generate annotations from a map of equivalent pages, their language/region codes and intended URLs. Fully qualify URLs with a scheme and host. Different locales may use different path conventions; the requirement is to reference the correct final URL, not force identical spelling everywhere.

Certificates and Host Availability

Every HTTPS host needs suitable certificate coverage and working renewal. If you configure CAA, authorize the intended issuance paths and monitor failures. The CAA and multiple-CA guide and ACME fallback guide give operational context. Certificate automation and multiple providers need validation; they do not guarantee uninterrupted access.

Diagnose Hreflang and URL Mismatches

Check the following implementation patterns when localized pages are not appearing as intended.

The wrong codes

Use “en-GB”, not “en-UK”. Uppercase region codes are conventional, but hreflang values are case-insensitive. Check your codes against a reference and add a build-time test. A shared JSON list of allowed tags can help keep CMS output consistent.

Missing reciprocity

Suppose the U.K. page lists U.S. and Spanish alternates, but the Spanish page omits the U.K. page. That missing return link can cause the affected hreflang relationship to be ignored. Generate reciprocal clusters from a shared locale map consumed by templates and sitemap builders, then validate the output.

Canonicals pointing across locales

If all English regional pages canonicalize to the U.S. version, first check whether they are same-language duplicates with intentional consolidation. If distinct regional pages are intended to be indexed separately, self-canonicals may suit that design. Google recommends a preferred canonical plus hreflang for similar same-language regional content. Do not promise ranking or bounce-rate changes from editing a canonical.

Over-eager geo-redirects

Forced IP or inferred-language redirects can prevent users and crawlers from opening the requested localized URL. Provide direct links and a visible language selector. Do not rely on Google varying crawler location to discover every response variant. If preferences affect application behavior, keep the explicit localized URL accessible and do not treat x-default as the redirect logic.

“Same page” that isn’t the same

Match equivalent page intent. Regional pricing, shipping or plan differences can belong to localized versions of the same pricing page. A pricing page and an unrelated article should not share a hreflang cluster merely because they use different languages. Separately, tr.example.com and www.example.com/tr/ serving the same Turkish content to the same audience are URL duplicates, not two language alternatives; choose the preferred URL and apply the appropriate canonical or permanent-move redirect strategy.

Trailing slash and parameter drift

Check that each alternate references the intended locale URL, including the correct trailing slash and parameters, and that the URL map follows the canonical decisions described above. Different locales can use different URL conventions; the problem is referencing unintended variants. Remove tracking parameters from hreflang URLs without stripping parameters needed to identify the page.

A debugging workflow

Inspect source HTML, actual HTTP responses and XML output for self-references, reciprocal links, language codes and final URLs. Check missing, redirected, blocked or noindex targets. Use Search Console URL Inspection on representative pages to examine crawling, indexing and Google-selected canonical status; that is not a complete hreflang-cluster approval. A syntactically valid XML file does not establish live URL reachability or search behavior.

Maintain the Map as Content and URLs Change

Keep a page-level locale map that identifies equivalent content, codes, URLs and canonical decisions. A list of locale home pages alone is insufficient for products or articles with different paths. Add or remove a locale, redirect or content entry in this map and regenerate the relevant annotations. Validate the rendered output after deployment.

DNS reliability is a separate operating concern. The multi-provider DNS guide with octoDNS covers related change management. Provider redundancy requires consistent zone updates and verification; it is not a ranking guarantee.

Hreflang identifies localized content; it does not choose a serving region or reduce network latency. CDN assets, regional backends and failover can address delivery requirements if the application and data model support them. The multi-region architecture guide provides context for those choices.

Keep host ownership, certificate coverage, redirects and renewal monitoring in the same operating record as the URL map. A failed host can make an otherwise correct alternate unreachable.

Keep Annotations, Canonicals and User Choice Consistent

Choose a maintainable domain structure, map equivalent localized pages and separate canonical decisions from hreflang relationships. Select an appropriate optional fallback and preserve direct access to language versions.

Translated content, similar same-language regional pages and duplicate URL paths are different cases. Treating them all as mandatory self-canonicals or as interchangeable alternates obscures the real URL decision. Review visible content and intended audience alongside technical annotations.

Start with a representative cluster and verify it before expanding. Automated output checks can catch missing or inconsistent entries, while content equivalence and actual indexing still need review. Revisit the ccTLD versus gTLD guide when domain strategy changes, then update the page map and operating responsibilities.

Official Technical References

Frequently Asked Questions

Use HTML head tags, an HTTP Link header on GET responses, or XML sitemaps. Google treats these methods equally; using all three adds no search benefit. Keep self-references and reciprocal alternatives consistent in the chosen output.

No. Do not consolidate translated main content solely because it is translated. Distinct pages intended for separate indexing can self-canonicalize; similar or duplicate same-language regional pages need a preferred-version decision using canonical and hreflang together. Use the same canonical language where possible.

It is optional. It identifies a fallback for unmatched language settings and was designed for selectors, but any suitable page may be used. Country neutrality is not a technical requirement. It does not store preferences or perform application redirects.

An xhtml:link href to a foreign alternate is different from submitting that URL as a loc entry. Cross-site loc submission uses Google’s verified-ownership Search Console route or separate per-site sitemaps referenced by each site’s robots.txt. Submitting every sitemap to every property is not a general requirement.

A ccTLD is not required for a localized site. Consider country targeting, registry rules, ownership and the structure your teams can maintain. Subdirectories can share a host and subdomains can separate platforms. None guarantees rankings; all still need accurate page-level locale relationships.
↑