XML sitemaps for multilingual websites

Separate URL inventory from language relationships

A multilingual XML sitemap can list intended public URLs and describe relationships between corresponding language or regional editions. These are separate responsibilities. An ordinary sitemap containing French and English addresses is multilingual as an inventory, but it does not express their equivalence unless it also includes the relevant alternate annotations.

Choose whether XML will be the authoritative hreflang delivery method. Google also supports HTML elements and HTTP headers, and treats the methods as equivalent. Repeating relationships in several places adds maintenance work without an inherent Search benefit. If HTML already provides reliable annotations, an ordinary sitemap may be sufficient for the inventory role.

The hreflang implementation guide covers the shared relationship rules. A sitemap supports discovery and communicates intended URLs; it does not force crawling, index inclusion or a particular result. Its value depends on accurate publication data, consistent generation and checks that establish whether each listed resource still exists and serves the intended audience.

Generate from approved resource and locale data

Use a registry keyed by resource identifier, with locale, final URL, publication state and equivalence group. Join this with the intended searchable inventory. Exclude drafts and withdrawn translations deliberately, and avoid generating alternate destinations by replacing a path prefix. Different slugs, regional catalogue gaps and renamed resources make string substitution unreliable.

Resolve duplicate aliases before creating the intended loc inventory. Use the preferred public addresses appropriate to the content policy, rather than including every parameter and historical route. Review same-language regional duplicate decisions explicitly; the sitemap generator should implement the agreed policy, not invent it. Keep the raw source records for reconciliation and error reporting.

Publish only relationships approved as equivalents. A missing translation is not a reason to substitute that language's homepage for a deep article. Record missing coverage separately so editorial teams can decide whether to commission it. The generator should distinguish absence, withdrawal and data failure instead of silently filling all three with the same fallback URL.

Use the XHTML namespace and repeat each alternate set

For XML hreflang annotations, declare the XHTML namespace and place xhtml:link elements inside each relevant url entry. Each published edition needs its own loc entry and the alternate set, including itself. The example below illustrates one entry for an English guide; a corresponding French loc entry must carry the same two alternate relationships.

<urlset xmlns="http://www.sitemaps.org/schemas/sitemap/0.9" xmlns:xhtml="http://www.w3.org/1999/xhtml">
  <url>
    <loc>https://example.com/en/guide/</loc>
    <xhtml:link rel="alternate" hreflang="en" href="https://example.com/en/guide/" />
    <xhtml:link rel="alternate" hreflang="fr" href="https://example.com/fr/guide/" />
  </url>
</urlset>

This is an illustrative fragment, not a complete two-edition sitemap. Generate the second entry from the same registry rather than copying it manually. Use fully qualified addresses and XML-escape reserved characters, especially ampersands in parameter values. Ensure the file is UTF-8 encoded.

Validate with an XML parser before semantic checks. A file can be well formed yet connect the wrong resources, so parser success is only the first release gate.

Partition for size, ownership and observable failures

Google's sitemap limits are 50,000 URLs or 50 MB uncompressed per sitemap. Alternate child elements do not add to the URL count, but their bytes still contribute to file size. Large alternate sets can therefore hit the size limit before the loc count reaches its ceiling. Measure the actual generated output rather than relying on a record estimate.

Split files using a stable strategy, such as locale, content type or publication shard. A sitemap index can reference the parts. Locale-based files can help isolate publishing problems, but the alternate set for a resource still needs the correct corresponding relationships. It is not necessary to put every edition of a resource in the same physical file.

Host and submission arrangements matter, particularly across domains. Follow Google's cross-site submission requirements rather than assuming a central file automatically grants authority over every regional host. Root-level hosting is generally straightforward. Document ownership, submission access and file locations so a platform move does not leave technically valid XML on an inaccessible or obsolete endpoint.

Coordinate publication, renames and retirement

Generate a consistent snapshot of publication data. A job that reads English records before a rename and French records afterwards can emit a mixed relationship set even when each individual source is valid. Version the input snapshot and record its generation time. Publish completed files atomically where possible rather than exposing partially written output.

On a slug change, update the resource registry, internal references and alternate relationships in coordination with the route. On withdrawal, remove inappropriate relationships and apply the agreed content response. Do not keep an obsolete edition in XML indefinitely just because the generator cannot distinguish a retired record from a temporarily missing translation.

Use lastmod only when it accurately represents a significant change to the listed page. Do not stamp every URL with the generation time on each run. The general sitemap workflow explains inventory hygiene; multilingual generation adds a dependency on the publication state of related resources, including editions maintained by separate teams.

Apply an evidence checklist beyond XML validity

Use a concrete evidence checklist: file URL and fetch status; generation version; uncompressed size; loc count; namespace declarations; absolute addresses; supported locale values; expected resource identifier; target response; canonical policy; self-inclusion; reciprocal relationships; and agreement with current publication state. Check a sample of delivered content for actual language and resource suitability.

Compare the sitemap inventory with independently exported published records and normal internal discovery. A sitemap and navigation generator can share the same faulty filter, so their agreement alone does not establish completeness. The orphan-page reconciliation workflow shows how to preserve that independence and distinguish discovery gaps from omitted publications.

Inspect submission and processing observations without treating a successful fetch as semantic approval. Search Console can help reveal file access or processing problems, while your registry comparison establishes whether the declared equivalence is correct. Retain dated examples and error categories so a later audit can reproduce the mismatch rather than relying on a historical warning total.

Test competing explanations for missing or stale entries

If a translation is absent, competing hypotheses include unpublished content, generator filtering, a failed export and a sitemap index that no longer references the relevant shard. Check each boundary in order: source registry, generator input, completed file, public file and submitted index. The first mismatch identifies a useful repair point.

If alternates point to old slugs, compare snapshot versions and route history. If only one regional host fails, inspect access and publication ownership before changing the XML schema. If the file parses but addresses are wrong, investigate resource mapping rather than encoding. A parser cannot detect that a French spare-parts page was mapped to a different product family.

Use hreflang error investigation for cross-method comparisons when HTML or HTTP annotations also exist. A correct sitemap may coexist with stale HTML, and an old crawler export may misrepresent a corrected deployment. Record collection dates and exact response evidence before attributing the discrepancy to Google's processing.

Illustrative worked example: a partially published snapshot

Illustrative worked example: a fictional documentation platform publishes 900 resource groups in English and German. After a batch of German slug changes, XML remains well formed but 80 English entries still reference the old German addresses. The German loc entries already use the new routes. The team considers an escaping error and a mixed publication snapshot.

Parser tests pass, while comparison with the registry identifies the same 80 mismatches. Job logs show that English shards used a cached export and German shards used the new registry version. The proposed fix pins every shard to one immutable input version and publishes the sitemap index only after all referenced files complete validation.

Acceptance compares every expected locale-to-URL pair for the affected groups, checks final responses and verifies the public index references only the completed snapshot. A sample of unchanged groups protects against collateral omissions. These invented counts illustrate a consistency failure and its repair; they do not represent client results or predict crawling, rankings or index inclusion.

Define release gates, rollback and ongoing limits

Acceptance should require parser success, size compliance, approved loc inventory, correct alternate sets and agreement with one publication snapshot. Include fixtures for incomplete translations, regional variants, renamed slugs, withdrawals and escaped URL characters. Require a useful error report identifying the resource and faulty relationship, rather than silently dropping problematic records to make the build pass.

Rollback risks include restoring obsolete addresses, omitting newly published editions and leaving an index that references removed shards. Retain the last complete generation and its registry version. Reverse the entire affected snapshot coherently, then reconcile publications made since that version. Check cache expiry and the public fetch path after reversal; a successful local file restore is insufficient.

The international audit method can review coverage independently over time. XML cannot establish translation quality, replace useful navigation or guarantee Search processing. Maintain ownership of both inventory and relationships, and monitor generation failures as publication incidents. The lasting objective is a faithful, current declaration of the editions the site actually intends to serve.