A multilingual XML sitemap lists each language or region version of a URL and its alternates using the xhtml namespace. Google's documentation states that the three delivery methods are equivalent from Google's perspective and that using all three adds no Search benefit, so you only need one method. The check that matters: every alternate must point back to the page that lists it, and every listed URL must be absolute and canonical.
What exactly is a multilingual XML sitemap?
It is a standard XML sitemap that adds the xhtml namespace so each <url> entry can carry <xhtml:link rel="alternate" hreflang="..." href="..."/> elements. Google documents this format in its guide to building a sitemap, which notes that XML sitemaps are the most versatile format and can supply localized versions of pages. The same page confirms the hard limits: 50MB uncompressed or 50,000 URLs per file, with a sitemap index for larger sites.
The hreflang values themselves follow the language and optional region pattern, such as en-GB, en-US, fr-FR or de-CH. Google's documentation on telling Google about localized versions states that the three delivery methods are equivalent from Google's perspective and that using all three adds no Search benefit.
Why do return links matter more than the alternate list?
Because an alternate entry is a claim, and the return link is the confirmation. If page A lists page B as its French version, page B should list page A as its English version. Google's guidance describes hreflang as a way to indicate localized versions of a page, and notes that if two pages don't both point to each other, the tags will be ignored.
A one-way link is the most common silent failure. It usually happens when a CMS generates alternates from a translation table but only writes them into the sitemap for the source locale.
Which of the three hreflang methods should you actually use?
Pick one. Google's localized-versions page describes three methods for indicating alternate pages and notes that if it becomes difficult to maintain a complete set of bidirectional links, you can omit some languages on some pages. The practical decision table below is our own reasoning, not a Google rule.
| Situation | Sensible method | Why |
|---|---|---|
| Small site, templates you control | HTML head tags | Visible in page source, easy to spot-check |
| Large catalogue, many locales | XML sitemap | Scales with generated files, avoids editing every template |
| Non-HTML files such as PDFs | HTTP headers | No head section to edit |
| Mixed CMS and legacy pages | One primary method, documented | Prevents conflicting signals |
If you inherit all three, do not delete blindly. First map which method each URL group relies on, then retire the redundant ones in stages.
How do you run a return-link check without special tools?
This is a verification method, not a product feature.
- Export every
<url>block that contains at least onexhtml:linkelement into a two-column list: page URL, alternate URL. - Build the reverse list: alternate URL, page URL.
- Compare. Every pair should appear in both directions. Any pair appearing once is a broken return link.
- Separately confirm each URL is fully qualified and absolute. Google's sitemap guidance says to use fully-qualified, absolute URLs in your sitemaps and that Google will attempt to crawl your URLs exactly as listed.
- Confirm each URL resolves to a canonical page. The same guidance recommends pointing to only one version in a sitemap when you have different URLs for mobile and desktop versions of a page.
Example (hypothetical, illustrative only): a retailer has example.com/en-gb/boots and example.com/fr-fr/bottes. The sitemap lists the French URL as an alternate of the English one, but the French entry omits the English alternate. The pair appears once in the comparison, so it is flagged. This is a structural example, not a measured result.
What about x-default and unmatched languages?
Google's documentation describes methods for indicating alternate pages and notes that localized versions are only considered duplicates if the main content remains untranslated. In a sitemap this appears as another xhtml:link element with hreflang="x-default".
Two cautions. First, x-default is a fallback, not a language code, so it should not be used to represent a specific market. Second, it still needs a return link like any other alternate.
Do you need separate sitemaps per country?
No. A single sitemap can carry many locales, and splitting by country is an organisational choice rather than a requirement. What matters is that each URL appears with its complete alternate set. If you do split files, keep the sitemap index accurate so crawlers can find every file.
Which errors are genuinely uncertain?
Google does not publish a complete list of how it resolves every conflicting hreflang signal, and it does not guarantee that correct markup will produce a particular search result. The documentation says Google might find alternate language versions even without action, and that explicitly indicating them is usually best. Treat hreflang as a signal, not a switch. Where sources are silent, verify behaviour in your own Search Console international targeting reporting rather than assuming a rule.
What should you check first?
Start with return links, because they are binary and cheap to test. Then absolute URLs, then canonical alignment, then x-default.
Follow-up questions
Can I use hreflang in the sitemap and in HTML at the same time?
Yes, Google says all three methods can be used simultaneously, but there is no Search benefit and three implementations are harder to maintain. Choose one and document it.
Does hreflang replace canonical tags?
No. They do different jobs. Canonical tags indicate the preferred URL for a piece of content; hreflang indicates language and region variants. A localized page should generally be self-canonical, not canonicalised to another language.