Splitter son sitemap XML : ce que Google recommande vraiment

Un site e-commerce de 28 000 URLs produit. Un seul fichier sitemap.xml de 4,2 Mo. Le crawl rate dans Search Console chute de 30% sur trois semaines sans explication apparente. Première hypothèse de l'équipe SEO : le sitemap est trop gros. Deuxième hypothèse : rien à voir. John Mueller vient de trancher cette question récurrente, et la réponse mérite qu'on s'y attarde bien au-delà du résumé en trois lignes.

Ce que John Mueller a réellement dit — et ce qu'il n'a pas dit

La déclaration de Mueller, relayée par Search Engine Journal, se résume à un point central : splitter un sitemap en plusieurs fichiers n'apporte aucun avantage direct côté crawl ou indexation pour Google. Googlebot traite un sitemap de 50 000 URLs exactement comme cinq sitemaps de 10 000 URLs, tant que les limites du protocole sont respectées.

Ces limites, définies par le protocole sitemaps.org, sont connues :

50 000 URLs maximum par fichier sitemap
50 Mo maximum (non compressé) par fichier
Un sitemap index peut référencer jusqu'à 50 000 fichiers sitemap

Mueller précise que le split est utile dans un contexte bien précis : le debugging et le monitoring. Quand vous segmentez vos sitemaps par type de contenu (produits, catégories, articles de blog, landing pages), vous pouvez exploiter les rapports d'indexation de Search Console par sitemap soumis. Chaque sitemap soumis individuellement dans Search Console génère ses propres statistiques d'indexation.

Ce que Mueller n'a pas dit, et que beaucoup d'articles omettent : cette segmentation ne change rien au comportement du crawler. Googlebot ne priorise pas un sitemap par rapport à un autre. Il ne crawle pas plus vite les URLs d'un sitemap dédié "produits" que celles d'un sitemap fourre-tout. La valeur est exclusivement analytique.

Le vrai bénéfice : l'observabilité

Soumettre un sitemap unique contenant 28 000 URLs, c'est avoir un seul compteur d'indexation dans Search Console. Vous savez que 19 400 pages sont indexées sur 28 000 soumises. Les 8 600 manquantes ? Impossible de savoir si ce sont des fiches produit, des pages catégorie ou des articles blog sans investigation manuelle.

Avec des sitemaps séparés, vous obtenez des métriques segmentées. Si votre sitemap sitemap-products.xml montre 12 000 URLs soumises et seulement 8 000 indexées, vous savez immédiatement que le problème d'indexation touche les fiches produit. Le diagnostic passe de quelques heures à quelques secondes.

Architecture d'un sitemap index avec segmentation par type

Voici l'implémentation concrète pour un site e-commerce tournant sur Next.js avec 28 000 pages réparties en quatre types de contenu.

Le fichier sitemap.xml à la racine devient un sitemap index :

<?xml version="1.0" encoding="UTF-8"?>
<sitemapindex xmlns="http://www.sitemaps.org/schemas/sitemap/0.9">
  <sitemap>
    <loc>https://www.maboutique.fr/sitemaps/sitemap-products.xml</loc>
    <lastmod>2026-04-04T08:30:00+02:00</lastmod>
  </sitemap>
  <sitemap>
    <loc>https://www.maboutique.fr/sitemaps/sitemap-categories.xml</loc>
    <lastmod>2026-04-03T14:00:00+02:00</lastmod>
  </sitemap>
  <sitemap>
    <loc>https://www.maboutique.fr/sitemaps/sitemap-blog.xml</loc>
    <lastmod>2026-04-04T11:15:00+02:00</lastmod>
  </sitemap>
  <sitemap>
    <loc>https://www.maboutique.fr/sitemaps/sitemap-landings.xml</loc>
    <lastmod>2026-03-28T09:00:00+02:00</lastmod>
  </sitemap>
</sitemapindex>

Chaque sous-sitemap contient uniquement les URLs de son type. Les lastmod du sitemap index reflètent la dernière modification effective d'une URL dans le sous-sitemap correspondant — pas la date de génération du fichier. Mentir sur le lastmod est un anti-pattern documenté par Google dans sa documentation officielle sur les sitemaps : si Googlebot détecte que le lastmod ne correspond pas à un changement réel du contenu, il finit par ignorer ce signal.

Génération dynamique en Next.js (App Router)

Pour les sites utilisant Next.js 14+ avec l'App Router, la génération de sitemaps segmentés se fait via des route handlers. Voici un exemple pour le sitemap produits :

// app/sitemaps/sitemap-products.xml/route.ts
import { NextResponse } from 'next/server';
import { getProducts } from '@/lib/db';

export async function GET() {
  const products = await getProducts({
    select: ['slug', 'updatedAt'],
    where: { status: 'published' },
    orderBy: { updatedAt: 'desc' },
  });

  const urls = products.map((product) => `
  <url>
    <loc>https://www.maboutique.fr/produit/${product.slug}</loc>
    <lastmod>${product.updatedAt.toISOString()}</lastmod>
    <changefreq>weekly</changefreq>
    <priority>0.8</priority>
  </url>`).join('');

  const sitemap = `<?xml version="1.0" encoding="UTF-8"?>
<urlset xmlns="http://www.sitemaps.org/schemas/sitemap/0.9">
${urls}
</urlset>`;

  return new NextResponse(sitemap, {
    headers: {
      'Content-Type': 'application/xml',
      'Cache-Control': 'public, max-age=3600, s-maxage=3600',
    },
  });
}

Deux points techniques critiques ici. D'abord, le Cache-Control : servir un sitemap dynamique sans cache sur un site à 20 000+ produits, c'est une requête SQL lourde à chaque fetch de Googlebot. Un TTL d'une heure est un bon compromis entre fraîcheur et charge serveur. Ensuite, la requête getProducts ne récupère que slug et updatedAt — projeter l'ensemble des colonnes produit serait un gaspillage mémoire inutile quand vous générez un fichier qui n'a besoin que de deux champs.

Note sur changefreq et priority : Google ignore officiellement ces deux attributs. Ils restent dans le protocole sitemaps.org mais n'influencent pas le comportement de Googlebot. Les inclure ne nuit pas, mais ne vous fiez pas à eux pour piloter le crawl.

Scénario concret : diagnostiquer un problème d'indexation produit

Prenons un cas réaliste. Vous gérez le SEO de maboutique.fr, un e-commerce de mobilier avec cette répartition :

18 500 fiches produit
1 200 pages catégorie/sous-catégorie
3 800 articles de blog (guides d'achat, inspirations)
450 landing pages SEO (ville + type de meuble)

Avant le split : un seul sitemap.xml de 24 000 URLs. Search Console rapporte 16 200 pages indexées. Taux d'indexation global : 67,5%. L'équipe ne sait pas quelles pages posent problème.

Après le split : quatre sitemaps soumis séparément dans Search Console. Les résultats après 3 semaines de données :

Sitemap	Soumises	Indexées	Taux
sitemap-products.xml	18 500	11 800	63,8%
sitemap-categories.xml	1 200	1 180	98,3%
sitemap-blog.xml	3 800	2 870	75,5%
sitemap-landings.xml	450	350	77,8%

Le diagnostic est immédiat : le problème d'indexation est concentré sur les fiches produit. 6 700 fiches ne sont pas indexées. L'équipe peut maintenant investiguer spécifiquement :

Fiches produit avec du contenu thin (descriptions < 100 mots)
Produits épuisés retournant un soft 404
Fiches sans aucun lien interne (orphan pages)
Fiches avec des canonicals qui pointent vers un autre produit (variantes mal configurées)

Sans la segmentation, l'investigation aurait démarré par un export complet du sitemap, un croisement avec les données d'indexation via l'API Search Console ou un crawl Screaming Frog avec intégration Search Console, puis un tri manuel. Le split transforme une journée de data analysis en un constat de 30 secondes dans l'interface Search Console.

Vérification via l'API Search Console

Pour automatiser le suivi, vous pouvez interroger l'API Search Console pour récupérer les statistiques par sitemap soumis. Voici un script Python minimaliste :

from google.oauth2 import service_account
from googleapiclient.discovery import build

SCOPES = ['https://www.googleapis.com/auth/webmasters.readonly']
SERVICE_ACCOUNT_FILE = 'credentials.json'
SITE_URL = 'https://www.maboutique.fr/'

credentials = service_account.Credentials.from_service_account_file(
    SERVICE_ACCOUNT_FILE, scopes=SCOPES
)
service = build('searchconsole', 'v1', credentials=credentials)

# Lister tous les sitemaps soumis
sitemaps = service.sitemaps().list(siteUrl=SITE_URL).execute()

for sitemap in sitemaps.get('sitemap', []):
    path = sitemap['path']
    contents = sitemap.get('contents', [])
    for content in contents:
        submitted = content.get('submitted', 'N/A')
        indexed = content.get('indexed', 'N/A')
        print(f"{path}: {indexed}/{submitted} indexed")

Ce script, exécuté en cron hebdomadaire, vous donne un tableau de bord d'indexation par type de contenu sans ouvrir Search Console. Couplé à un outil de monitoring comme Seogard, qui détecte les régressions d'indexation en temps réel, vous passez d'un monitoring passif à un système d'alerte proactif.

Les cas où le split est techniquement nécessaire (pas juste utile)

Mueller a insisté sur l'aspect monitoring, mais il existe des cas où le split n'est plus optionnel.

Dépassement des limites du protocole

Un site média qui publie 200 articles par jour depuis 5 ans cumule potentiellement 365 000 URLs. Un seul fichier sitemap est physiquement impossible (limite de 50 000 URLs). Le sitemap index avec pagination temporelle devient obligatoire :

sitemap-articles-2026-q1.xml  (≈ 18 000 URLs)
sitemap-articles-2025-q4.xml  (≈ 18 000 URLs)
sitemap-articles-2025-q3.xml  (≈ 18 000 URLs)
...

Ce pattern par trimestre ou par mois a un avantage supplémentaire : les sitemaps des trimestres passés sont statiques. Ils peuvent être servis depuis un CDN avec un cache long (24h+) sans jamais être régénérés. Seul le sitemap du trimestre en cours est dynamique.

Multi-langue et hreflang

Pour les sites internationaux, le split par langue simplifie considérablement la gestion des hreflang. Un sitemap sitemap-fr.xml contient les URLs françaises avec leurs annotations hreflang, sitemap-de.xml les URLs allemandes. Quand un problème hreflang apparaît sur une langue spécifique, le diagnostic est immédiat.

Sites avec des modes de rendering mixtes

C'est un cas sous-documenté mais fréquent. Un site qui utilise du SSR pour ses pages critiques et du CSR pour d'autres a tout intérêt à segmenter ses sitemaps en conséquence. Si les pages rendues côté client présentent des problèmes d'indexation liés au JavaScript, un sitemap dédié permettra d'identifier immédiatement l'écart de taux d'indexation entre les deux populations de pages.

De même, les sites exploitant différents modes de rendering (ISR, SSR, SSG) peuvent segmenter leurs sitemaps par stratégie de rendu pour monitorer l'impact de chaque approche sur l'indexation.

Les pièges de l'implémentation : ce que personne ne mentionne

Le lastmod menteur

Le piège le plus fréquent : régénérer le sitemap toutes les nuits et mettre la date du jour en lastmod sur toutes les URLs, même celles qui n'ont pas changé. Googlebot apprend vite. Après quelques cycles de crawl où il constate que le contenu n'a pas changé malgré un lastmod récent, il commence à ignorer le signal sur l'ensemble de votre sitemap. Vous perdez alors la capacité de signaler les vraies mises à jour.

La bonne pratique : le lastmod doit refléter la dernière modification substantielle du contenu. Pas la date de build. Pas la date de dernier déploiement. La date à laquelle le contenu visible par l'utilisateur a changé.

Le sitemap orphelin

Vous créez quatre sitemaps segmentés, vous les soumettez dans Search Console, mais vous oubliez de mettre à jour le fichier robots.txt. Résultat : Googlebot découvre votre ancien sitemap.xml monolithique via le robots.txt et vos nouveaux sitemaps uniquement via Search Console. Vous avez maintenant des URLs déclarées en double dans deux systèmes différents.

Le robots.txt doit pointer vers le sitemap index :

User-agent: *
Disallow: /admin/
Disallow: /api/

Sitemap: https://www.maboutique.fr/sitemap-index.xml

Et si vous aviez un ancien sitemap.xml, supprimez-le ou redirigez-le en 301 vers le sitemap index. Ne laissez pas deux déclarations de sitemap coexister dans le robots.txt.

La soumission manuelle dans Search Console

Un détail que beaucoup ignorent : pour bénéficier des statistiques par sitemap dans Search Console, il faut soumettre chaque sous-sitemap individuellement, pas seulement le sitemap index. Soumettre uniquement sitemap-index.xml vous donnera des statistiques agrégées. Soumettre aussi sitemap-products.xml, sitemap-blog.xml, etc. vous donnera les statistiques segmentées. Les deux approches ne sont pas mutuellement exclusives — soumettez le sitemap index ET chaque sous-sitemap.

Audit de sitemap : la checklist technique

Avant de splitter, auditez l'existant. Screaming Frog permet de crawler un sitemap et de croiser les données avec la réalité du site.

Dans Screaming Frog :

Mode > List > Download Sitemap
Collez l'URL de votre sitemap
Lancez le crawl

Vérifiez systématiquement :

URLs dans le sitemap qui retournent autre chose que 200. Des 301, 404, 410, ou 500 dans un sitemap sont du bruit. Googlebot les crawle, constate l'erreur, et perd du temps. Sur un site de 20 000 URLs, 2 000 URLs en erreur dans le sitemap représentent 10% de crawl budget gaspillé — pas anodin quand votre crawl budget est déjà sous pression.

URLs dans le sitemap avec un canonical qui pointe ailleurs. Si /produit/chaise-bleue est dans le sitemap mais porte un <link rel="canonical" href="/produit/chaise-bleu" />, vous envoyez un signal contradictoire à Google : "crawle cette URL" (sitemap) mais "l'URL canonique est une autre" (canonical tag). Le sitemap ne doit contenir que des URLs auto-canoniques.

URLs indexables absentes du sitemap. L'inverse du problème précédent. Utilisez la commande de comparaison dans Screaming Frog (Crawl Analysis > Sitemap) pour identifier les pages orphelines du sitemap.

Taille du fichier non compressé. Vérifiez avec curl :

curl -s -o /dev/null -w '%{size_download}' https://www.maboutique.fr/sitemaps/sitemap-products.xml
# Résultat en bytes. Divisez par 1048576 pour avoir les Mo.
# Doit être < 50 Mo non compressé.

# Si vous servez en gzip, vérifiez la taille décompressée :
curl -s -H "Accept-Encoding: gzip" https://www.maboutique.fr/sitemaps/sitemap-products.xml | gunzip | wc -c

Pour les très gros sitemaps, servir en gzip (.xml.gz) réduit le transfert réseau mais ne change pas la limite de 50 Mo sur le contenu décompressé. C'est le contenu XML décompressé qui est limité, pas le fichier transféré.

Faut-il splitter pour des raisons de performance de crawl ?

Non. Et c'est le point central de la réponse de Mueller. Googlebot ne crawle pas un sitemap de 50 000 URLs plus lentement qu'un sitemap de 5 000 URLs de manière proportionnelle. Le parsing XML d'un fichier de quelques Mo est trivial pour l'infrastructure Google.

Le crawl budget est déterminé par d'autres facteurs : la santé technique du site (temps de réponse serveur, taux d'erreurs), l'autorité perçue, la fréquence de mise à jour du contenu. La structure de vos sitemaps n'entre pas dans cette équation.

En revanche, la performance de votre serveur pour générer le sitemap compte. Un sitemap dynamique qui exécute une requête SQL joignant trois tables sur 50 000 lignes, sans cache, à chaque requête de Googlebot, peut poser problème. Non pas parce que Googlebot est impacté par un temps de réponse de 3 secondes sur le sitemap, mais parce que cette charge serveur dégrade le temps de réponse des pages HTML que Googlebot essaie de crawler en parallèle.

La recommandation : si votre sitemap est généré dynamiquement, mettez un cache HTTP d'au moins une heure. Si votre catalogue change peu (moins de 100 modifications par jour sur 20 000 produits), une régénération quotidienne en fichier statique est préférable.

Au-delà du split : les signaux sitemap que Google utilise vraiment

Puisque changefreq et priority sont ignorés, que reste-t-il comme signal utile dans un sitemap ?

loc : l'URL elle-même. Google découvre des URLs via le sitemap qu'il n'a pas encore trouvées via le crawl du linking interne. C'est le rôle principal du sitemap : un filet de sécurité pour l'exhaustivité de la découverte.

lastmod : quand il est fiable, ce signal influence la fréquence de re-crawl. Google compare le lastmod actuel avec celui qu'il avait lors du dernier fetch. Si la date a changé, il priorise le re-crawl. D'où l'importance de ne pas mentir sur cette date.

Les URLs absentes : retirer une URL du sitemap n'est pas un signal de désindexation (pour ça, il faut un noindex ou un code 410). Mais c'est un signal faible que la page est moins importante. Sur les très gros sites, des URLs présentes uniquement dans le linking interne profond ET absentes du sitemap ont statistiquement moins de chances d'être re-crawlées fréquemment.

Les données remontées par Search Console dans le rapport Sitemaps sont par ailleurs à interpréter avec prudence. Google a récemment corrigé un bug qui gonflait les compteurs d'impressions dans Search Console — un rappel que les données de l'interface ne sont pas toujours fiables à 100%.

Le bon réflexe : monitorer après le split

Splitter son sitemap est un changement structurel. Comme toute modification technique, il faut monitorer les impacts. Vérifiez dans les semaines suivantes :

Que tous les sous-sitemaps sont bien crawlés (Search Console > Sitemaps > colonne "Dernière lecture")
Que le nombre total d'URLs soumises correspond à votre inventaire réel
Qu'aucun sous-sitemap ne retourne d'erreur (403, 500) intermittente
Que le lastmod du sitemap index se met à jour correctement

Un outil de monitoring continu comme Seogard permet de détecter automatiquement une régression : un sous-sitemap qui retourne soudainement une 500, un lastmod qui cesse de se mettre à jour, ou un nombre d'URLs qui chute brutalement suite à un bug de génération. Ce type de problème silencieux peut passer inaperçu pendant des semaines dans Search Console, qui ne rafraîchit ses données qu'avec plusieurs jours de latence.

Le split de sitemap n'est pas une optimisation de crawl. C'est une optimisation d'observabilité. Traitez-le comme vous traitez la segmentation de vos logs serveur ou de vos métriques applicatives : le système fonctionne pareil, mais votre capacité à diagnostiquer un problème change radicalement.