How to Audit Language Annotations in XML Sitemaps

A sitemap for a multilingual site tells search engines which URLs are language or regional versions of the same page. The annotations use hreflang, a label that connects a page to its equivalents, such as an English page and a French page. Those relationships are useful only when they match the pages that exist on the site.

Check the XML structure and compare each page’s alternate links. Then confirm that every destination loads the intended page. Google Search Console’s sitemap status shows whether Google fetched and read the file. It does not prove that Google accepted every language relationship or indexed every URL.

How sitemap language annotations work

Each page in the sitemap has a <url> entry. Its <loc> element gives the page’s URL, and its child xhtml:link elements list the page’s language or regional alternatives. The sitemap must declare the XHTML namespace so those elements are recognized.

If an English page and a French page are equivalents, each page should list both URLs, including itself. A language selector or general fallback page can also use the x-default label, which marks it as a fallback. Google describes the required format and reciprocal relationships in its documentation for localized page versions.

These annotations show how pages relate to each other. They do not check translation quality or identify a page’s language. Google says it identifies page language algorithmically, rather than relying on hreflang or the HTML lang attribute to detect it.

Audit each language group

List the pages the site intends to connect, then compare that list with the sitemap. This reveals missing language versions that an XML syntax check would not catch. Link only pages that serve as equivalents. For example, do not link a translated category page to an unrelated landing page just because both use the same language.

For each group, check the following:

1. Validate the XML structure. Make sure the sitemap parses and uses the sitemap and XHTML namespaces. Each page needs a <loc>, and each alternate needs an xhtml:link with rel="alternate", hreflang, and href. Use absolute URLs and escape XML characters correctly.
2. Compare the complete alternate set. Every page in a group should list the same language-and-URL pairs, including its own URL. Check for missing links to itself, links that go only one way, missing versions, duplicate entries, and URLs assigned to the wrong language or region.
3. Check the language and region values. Google documents language codes from ISO 639-1 and region codes from ISO 3166-1 alpha-2. Put the language first, as in en-GB; a region alone does not identify a language. Use x-default for a fallback. Check Google’s supported values because a locale code accepted by your software framework might not work in Search.
4. Fetch every listed URL. Check the sitemap’s <loc> URLs and every alternate href URL. For each one, record whether it loads, where it redirects, which language or region the final page serves, and which canonical URL the page declares. Investigate URLs that redirect or fail, then update the sitemap to point directly to the intended page.
5. Compare the sitemap with other signals. If the page also lists language alternatives in HTML or HTTP headers, make sure those relationships match the sitemap. Google supports all three methods and says using all of them provides no search benefit. Using multiple methods adds work because someone must keep them consistent.

When the XML parses, its structure is valid, but its relationships can still be wrong. For example, a French URL labeled en is valid XML but describes the wrong relationship. A group with a missing reciprocal link is also incomplete, even if every URL loads successfully. Google warns that missing return links can lead to annotations being ignored or misinterpreted.

Check redirects, canonicals, and indexability

Each alternate URL should lead directly to the page for that language or region. If it redirects, update the sitemap to list the final intended URL. Google’s sitemap guidance recommends including the URLs you want crawled rather than redirecting URLs.

Check each destination’s canonical declaration as well. A canonical URL tells search engines which URL a site prefers when pages appear equivalent or duplicate. If the sitemap lists one URL but the page’s canonical points to another, investigate the conflicting signals. Google considers multiple signals when selecting a canonical, so sitemap inclusion alone does not determine the result. Take care with regional pages in the same language. Before pointing them all to one canonical URL, confirm that this matches the site’s intended page relationships. See Google’s explanation of canonical URL selection.

Check whether crawlers can access each target and whether it is eligible for indexing. A page loading from a sitemap URL does not mean Google will index it. Review translation quality and usefulness separately from the technical audit.

Interpret Search Console evidence carefully

The Search Console Sitemaps report shows whether Google could retrieve and parse a submitted sitemap. With Success, Google fetched and read the sitemap without errors, and the URLs are queued for crawling. Has errors reports that Google read at least part of the sitemap but encountered errors. Couldn’t fetch means Google could not retrieve it. The number of discovered URLs does not show how many pages Google indexed. Google says sitemap inclusion does not guarantee that it will crawl or index a URL. Check the Sitemaps report definitions before drawing conclusions from a status.

Use URL Inspection to check an individual page’s current canonical choice or indexing information in Google. Because Search Console has no category for detecting alternate language pages, a successful sitemap report cannot confirm that every hreflang group is valid. The Page indexing report documentation describes what that report covers.

Common failures and what they mean

A group is incomplete if it lacks a return link, a link to a page itself, or a language version. An unsupported language or region value means Google ignores that annotation. A wrong locale-to-URL mapping is a data error, even when the XML is perfectly formed.

Review URLs that redirect or lead to unavailable pages, and check conflicting canonical signals. These issues alone do not show which version Google will display. Compare the sitemap with the page’s final destination, canonical, and intended audience before changing the mapping.

A valid sitemap can still have poor indexing coverage. It helps Google discover URLs, but it does not force Google to crawl or index them or show a particular search result. Google’s sitemap protocol allows up to 50,000 URLs and 50 MB uncompressed per sitemap. If a site exceeds those limits, split the URLs among multiple sitemap files and reference them from a sitemap index.

What this means for AI search

Accurate language annotations help search engines discover URLs and understand how pages relate. The reviewed guidance does not show that sitemap hreflang entries alone increase AI citations or determine which version an AI answer selects.

Bing’s Webmaster Guidelines say sitemaps help Bing discover URLs and keep indexing accurate. The guidelines connect crawling and indexing with eligibility for Bing’s AI experiences. Bing also does not guarantee visibility. Treat sitemap hygiene as part of technical discoverability, not as a citation tactic.

Key Takeaways

• Compare every page in a language group: Every page in a language group should list the same alternate URLs, including its own URL.
• Fetch the destinations: Confirm each URL reaches the intended language or region page without an unexpected redirect or failure.
• Resolve conflicting signals: Investigate differences between sitemap URLs, page canonicals, and any HTML or HTTP-header annotations.
• Read Search Console statuses narrowly: “Success” confirms fetching and parsing, not indexing or valid language relationships.
• Separate SEO evidence from AI outcomes: Sitemap quality supports discoverability, but does not guarantee rankings, indexing, or AI citations.

What I'm building

Delegate tasks. Get software.

Give Vroni a GitHub issue, bug report, spec, or rough idea. It reads the repo, plans the change, writes code, runs checks, and works toward a review-ready pull request.

Take a look at vroni.com