Sign in Start free

Multilingual sitemap coverage

A monolingual sitemap on a multilingual site hides most of what you published. Head-level hreflang helps, but discovery is slow and partial. Every locale variant needs its own entry carrying the full alternate set.

CATEGORY
International SEO
FORMAT
multilingual-sitemap-coverage.md
STEPS
6
PRICE
Free - no account
WHEN TO REACH FOR THIS

Use when translated pages exist and are linked but receive no impressions, and the sitemap lists only the default language.

The skill file

multilingual-sitemap-coverage.md 
---
name: multilingual-sitemap-coverage
description: Use when translated pages exist and are linked but receive no impressions, and the sitemap lists only the default language.
---

# Multilingual sitemap coverage

A monolingual sitemap on a multilingual site hides most of what you published. Head-level hreflang helps, but discovery is slow and partial. Every locale variant needs its own entry carrying the full alternate set.

## What you need first

- The sitemap generator
- The canonical URL for one page per template
- The supported locale list

## Method

1. Count the entries in the current sitemap and multiply by the number of locales. That is the target, and the gap is what is currently undiscoverable.
2. Emit one url entry per locale per page, rather than one entry with alternates - each variant needs its own loc to be crawled on its own merits.
3. Give every entry the identical alternate block, including a self-reference and one x-default.
4. Strip query strings from generated alternates. Some localisation libraries append parameters that turn each alternate into a distinct, non-canonical URL.
5. Verify reciprocity mechanically: every loc in the file must also appear as an alternate somewhere, and there must be no duplicate locs.
6. Confirm each alternate matches the canonical the page itself declares, including trailing-slash convention - a mismatch invalidates the cluster.

## What this produces

A sitemap with locale-count times the entries, fully reciprocal, verified against the canonicals the pages actually declare.

## Where this goes wrong

- Emitting one entry with alternates instead of one entry per locale
- Letting a library append query parameters to generated alternate URLs
- Declaring alternates that disagree with the page canonical, which silently discards the whole cluster

---

From the QuQi skill library - https://www.quqi.io/skills/multilingual-sitemap-coverage
Free to download · no account, no email

What you need first

  • The sitemap generator
  • The canonical URL for one page per template
  • The supported locale list

Method

  1. 01 Count the entries in the current sitemap and multiply by the number of locales. That is the target, and the gap is what is currently undiscoverable.
  2. 02 Emit one url entry per locale per page, rather than one entry with alternates - each variant needs its own loc to be crawled on its own merits.
  3. 03 Give every entry the identical alternate block, including a self-reference and one x-default.
  4. 04 Strip query strings from generated alternates. Some localisation libraries append parameters that turn each alternate into a distinct, non-canonical URL.
  5. 05 Verify reciprocity mechanically: every loc in the file must also appear as an alternate somewhere, and there must be no duplicate locs.
  6. 06 Confirm each alternate matches the canonical the page itself declares, including trailing-slash convention - a mismatch invalidates the cluster.

What this produces

A sitemap with locale-count times the entries, fully reciprocal, verified against the canonicals the pages actually declare.

Where this goes wrong

  • Emitting one entry with alternates instead of one entry per locale
  • Letting a library append query parameters to generated alternate URLs
  • Declaring alternates that disagree with the page canonical, which silently discards the whole cluster

Use this skill in your own AI

The download is a plain markdown file with the name and trigger in its frontmatter. Where an assistant supports skills it can load itself, that frontmatter is what it reads to decide this one applies.

Claude Code Save it as ~/.claude/skills/multilingual-sitemap-coverage/SKILL.md and Claude loads it on its own when what you are doing matches the trigger line. Put it in .claude/skills inside a project instead if the whole team should have it.
Claude Upload the file in the skills section of your settings. Once it is there it applies itself in any conversation where the trigger fits, so you do not have to remember it exists.
ChatGPT There is no skills format to install into, so paste the file contents into a Project instruction or a Custom GPT instead. It then applies to every chat in that project rather than only the one you paste it into.
Anything else Paste the markdown into the chat before your question. It works in any assistant, it just has to be pasted again each time.

Questions about this skill

When is this worth doing rather than letting head-level hreflang handle discovery?

When translated pages are published and linked but receive no impressions, and the sitemap lists only the default language. Head tags and internal links do eventually surface variants, but discovery is slow, partial, and gives you no way to see the shortfall. Current entry count multiplied by locale count is the number of pages currently undiscoverable.

What do I need in hand before starting?

The sitemap generator, the canonical URL for one page per template, and the supported locale list. The canonicals are the part people skip. Generate alternates from route helpers alone and they will disagree with what the pages declare, on trailing slash or on an appended parameter, which discards the cluster while the file itself looks complete.

What do I end up with, and which part of it gets used?

A sitemap with locale-count times the entries, every entry carrying the identical alternate block with a self-reference and one x-default. The separate loc per locale is the part doing the work: one entry with alternates attached leaves the variants without a submitted URL of their own, so they are never crawled on their own merits.

What ruins this most often?

Letting the localisation library append query parameters to generated alternates. Each alternate becomes a distinct, non-canonical URL, so the annotation is present and useless, and nothing about the file validates as wrong. Verify reciprocity mechanically instead: every loc must also appear as an alternate somewhere, with no duplicate locs anywhere in the file.

More in International SEO

Hreflang reciprocity repair

Use when translated pages exist and are indexed but never surface for the right country, or when...

Locale redirect trap audit

Use when visitors report being unable to switch back to a language, or when a shared link opens...

Translation key drift guard

Use on any site whose translation keys are the English source text, where editing a headline sil...

RTL layout audit

Use before shipping Arabic, Hebrew, Farsi or Urdu, or when an RTL locale shows overlapping text,...