En 2021, j'ai repris un site WooCommerce avec 140 000 URL de produits, un seul sitemap.xml plafonné à exactement 50 000 entrées, et un client qui ne comprenait pas pourquoi Google Search Console affichait seulement une fraction de ses pages indexées. Le fichier sitemap s'arrêtait simplement. Pas d'erreur. Pas d'avertissement. Juste une troncature silencieuse. C'est le genre de chose qui vous coûte du classement sans jamais envoyer de signal visible que quelque chose ne va pas.
Si votre site dépasse 50 000 URL, cet article est celui que vous devez lire avant de heurter ce mur.
Pourquoi la limite de 50 000 URL existe
Le protocole Sitemaps, maintenu conjointement par Google, Bing et d'autres, impose deux contraintes strictes à un fichier sitemap unique : pas plus de 50 000 URL, et pas plus de 50 Mo non compressés. Ce ne sont pas des suggestions. Googlebot arrêtera d'analyser le fichier à la première limite qu'il atteindra.
Honnêtement, le plafond de 50 Mo n'est rarement un problème. La plupart des URL sont assez courtes pour que vous ayez besoin de chemins ridiculement longs pour atteindre la limite de taille de fichier avant la limite du nombre d'URL. C'est la limite de 50 000 URL qui gêne les gens.
Alors, que faites-vous quand votre catalogue, vos archives de blog, votre section de contenu généré par les utilisateurs dépasse ce seuil ? Vous utilisez un fichier d'index de sitemap.
Ce qu'est réellement un fichier d'index de sitemap
Concept simple. Au lieu d'un sitemap unique contenant des URL, vous créez un fichier XML parent qui pointe vers plusieurs sitemaps enfants. Chaque sitemap enfant peut contenir jusqu'à 50 000 URL. Le fichier d'index lui-même peut référencer jusqu'à 50 000 sitemaps enfants. Le plafond théorique est donc de 2,5 milliards d'URL. Vous ne l'atteindrez pas.
La structure ressemble à ceci :
`` sitemap_index.xml ├── sitemap-posts-1.xml (jusqu'à 50 000 articles de blog) ├── sitemap-posts-2.xml (articles en excédent) ├── sitemap-products-1.xml (jusqu'à 50 000 produits) ├── sitemap-products-2.xml (produits en excédent) └── sitemap-pages.xml (pages statiques) ``
Le fichier d'index utilise <sitemapindex> comme élément racine au lieu de <urlset>. Chaque enfant est enveloppé dans une balise <sitemap> avec une <loc> pointant vers le fichier enfant, et optionnellement un horodatage <lastmod>.
Ce que vous soumettez à Google Search Console, c'est l'URL du fichier d'index, non chaque enfant individuel. Une seule soumission, une seule source de vérité.
Comment diviser vos URL de manière intelligente
C'est là que la plupart des tutoriels se trompent. Ils disent « il suffit de diviser vos URL en groupes de 50 000 » et s'arrêtent là. Mais les limites des groupes comptent pour la maintenabilité et pour la logique de crawl de Googlebot.
Je divise par type de contenu, pas par nombre arbitraire. Toujours. À chaque fois.
Divisez d'abord par type de contenu
- Les produits dans leur propre série de sitemaps (sitemap-products-1.xml,
sitemap-products-2.xml) - Les articles de blog dans leur propre série
- Les pages de catégories et tags ensemble (ce sont des pages de navigation, traitez-les comme un seul groupe)
- Les pages statiques (À propos, Contact, landing pages) dans un seul fichier, généralement bien en dessous de 1 000 URLs
Pourquoi cela compte ? Parce que quand une base de données de produits subit une mise à jour en masse, seuls les sitemaps de produits ont besoin d'être régénérés. Vous n'invalidez pas et ne régénérez pas un fichier monolithique qui mélange les produits et les articles de blog. Googlebot a aussi tendance à parcourir les sitemaps de manière séquentielle, donc regrouper par type lui donne un signal plus clair sur le type de contenu qu'il va trouver.
Puis paginez dans chaque type
Une fois qu'un type de contenu dépasse 50 000 URLs, paginez-le. Utilisez une convention de nommage cohérente dès le départ. J'utilise sitemap-{type}-{page}.xml. N'utilisez pas de dates dans le nom du fichier. J'ai commis cette erreur sur un site d'actualités en 2019 et j'ai fini avec des noms de fichiers comme sitemap-articles-2019-march.xml qui sont devenus complètement insignifiants dès que nous avons eu besoin de régénérer du contenu historique. Restez sur des pages numérotées.
Gardez lastmod honnête
L'élément <lastmod> dans vos sitemaps enfants doit refléter quand le contenu a été réellement modifié pour la dernière fois, pas quand vous avez régénéré le sitemap. J'ai vu des configurations où chaque régénération horodate chaque URL avec la date d'aujourd'hui. Cela entraîne Googlebot à ignorer complètement votre lastmod parce que le signal n'est que du bruit. Utilisez l'horodatage réel de modification de votre CMS. Dans WordPress, c'est post_modified_gmt de la table wp_posts.
Outils : ce qui fonctionne vraiment à grande échelle
Pour les sites WordPress (ce que nous construisons majoritairement chez Seahawk), les options que j'utilise réellement sont :
- Yoast SEO gère automatiquement les index de sitemaps une fois que vous avez plus de 1 000 URLs par type de contenu. Il génère des fichiers propres et segmentés. Mais la taille de lot par défaut est de 1 000 URLs par sitemap enfant, ce qui est conservateur. Vous pouvez l'augmenter avec
wpseo_sitemap_entries_per_page. Je la pousse généralement à 5 000 sur les serveurs bien hébergés. - Rank Math fait la même chose, avec un contrôle légèrement plus granulaire sur les types de contenu et taxonomies qui obtiennent leurs propres sitemaps enfants. Sur un site client récent avec 80 000 produits WooCommerce, la segmentation de Rank Math d'office était plus propre que celle de Yoast.
- La génération personnalisée avec WP-CLI est ce que j'utilise quand le site a des types de contenu inhabituels ou que les sitemaps générés par plugin sont trop lents à générer. J'ai écrit des scripts qui interrogent la base de données directement, paginant les résultats par chunks de 10 000, écrivant le XML sur disque, puis écrivant le fichier index en dernier. Fonctionne en moins de 30 secondes pour 200 000 URLs. La clé est d'écrire dans un fichier temporaire et de le déplacer atomiquement à sa place pour que Googlebot ne trouve jamais un fichier à moitié écrit.
Pour les stacks non-WordPress, Screaming Frog SEO Spider peut crawler votre site et générer un index de sitemap pour vous, bien qu'il soit meilleur comme outil de validation qu'en tant que générateur de sitemap en production. En production, générez les sitemaps depuis votre source de données, pas depuis un crawler. Les crawlers oublient des choses.
Soumettre et valider dans Search Console
Allez à Google Search Console, ouvrez le rapport Sitemaps, et soumettez l'URL de votre fichier index. Une seule URL. C'est tout.
Après la soumission, attendez 24-48 heures, puis vérifiez deux choses :
- Soumis vs Découverts. Le compte « URLs découvertes » devrait monter vers votre nombre réel d'URLs. S'il plafonne bizarrement tôt, vous avez probablement un problème de budget de crawl ou un sitemap enfant mal formé.
- Statut des sitemaps enfants individuels. Search Console vous affichera chaque sitemap enfant et son statut. Si un enfant retourne une erreur, vous pouvez l'isoler sans toucher aux autres. C'est l'avantage sous-estimé de la structure d'index.
Bing Webmaster Tools fonctionne de la même manière. Soumettez le fichier d'index, pas les enfants. Ça prend deux minutes.
Erreurs courantes que je vois régulièrement
Seahawk effectue des audits de sites pour des agences assez régulièrement. Les mêmes erreurs de sitemap reviennent encore et encore.
URLs noindexées dans le sitemap. Si une URL a une balise meta noindex ou un en-tête X-Robots, elle ne devrait pas être dans votre sitemap. Un point c'est tout. Un sitemap est une recommandation pour l'exploration et l'indexation. Inclure des URLs noindexées gaspille le budget de crawl et brouille le signal. J'effectue un crawl rapide Screaming Frog contre les URLs du sitemap et je filtre les réponses noindex avant tout lancement de site majeur.
URLs bloquées dans le sitemap. Encore pire que noindex : des URLs qui sont disallowées dans robots.txt mais qui figurent toujours dans le sitemap. Googlebot voit la contradiction. Ça ne vous pénalisera pas, mais c'est mal fait et c'est une perte de temps.
Ne pas mettre à jour le fichier d'index après avoir ajouté un enfant. Ça semble évident mais ça piège les implémentations personnalisées. Vous ajoutez un nouveau type de contenu, générez un nouveau fichier sitemap enfant, et oubliez d'ajouter l'entrée <sitemap> à l'index. Le fichier enfant existe sur le disque mais rien ne le pointe. Je l'ai vu rester inaperçu pendant des mois.
Soumettre les sitemaps enfants individuellement au lieu de l'index. Si vous avez 12 sitemaps enfants et que vous les soumettez tous les 12 à Search Console séparément, vous avez perdu le bénéfice organisationnel. Soumettez l'index. Laissez-le en cascade.
Budget de crawl : Le contexte plus large
Les fichiers d'index sitemap se connectent directement à la gestion du budget de crawl. La documentation de Google sur le budget de crawl vaut le coup d'être lue si vous opérez à cette échelle. En bref : Googlebot a une quantité finie de temps qu'il passera sur votre site par jour, et un sitemap index bien structuré l'aide à dépenser ce temps sur votre contenu de plus haute priorité en premier.
Sur les gros sites, je place le contenu fraîchement mis à jour dans son propre sitemap enfant. Certaines de mes implémentations utilisent un sitemap-recent.xml qui ne contient que les URLs modifiées dans les 30 derniers jours, rafraîchi toutes les heures. Googlebot recrawl celui-ci de façon agressive. Les anciens fichiers de sitemaps historiques sont crawlés moins fréquemment, ce qui est correct puisque ce contenu ne change pas.
Ce n'est pas une astuce. C'est simplement faire correspondre le signal de crawl à la réalité du contenu.
FAQ
Combien de sitemaps enfants un fichier d'index de sitemap peut-il contenir ?
Le protocole autorise jusqu'à 50 000 sitemaps enfants dans un seul fichier d'index. En pratique, si vous approchez ce nombre, vous avez des centaines de millions d'URLs et vous faites face à des problèmes que la plupart des sites ne connaîtront jamais. Pour la grande majorité des gros sites, vous aurez entre 5 et 50 sitemaps enfants.
Dois-je compresser mes fichiers sitemap avec gzip ?
Vous n'êtes pas obligé, mais ça vaut le coup pour les gros fichiers. Un sitemap de 50MB se compresse à environ 3-5MB avec gzip. Googlebot accepte les fichiers .xml.gz sans aucune configuration. La plupart des serveurs web modernes gèrent cela de façon transparente si vous activez la compression gzip au niveau du serveur. Pour les sitemaps de fichiers statiques générés sur disque, je pré-compresse avec gzip et je serve le .xml.gz directement.
Dois-je inclure les sitemaps d'images ou de vidéos dans l'index ?
Oui. Si vous utilisez des extensions de sitemap d'images ou des sitemaps vidéo, ils peuvent être inclus comme sitemaps enfants dans le même fichier d'index. Gardez-les dans leurs propres fichiers enfants plutôt que de mélanger les données d'images dans vos sitemaps d'URLs standard. Ça garde les fichiers plus petits et rend plus facile la régénération du seul sitemap d'images quand votre bibliothèque média se met à jour.
Que se passe-t-il si un sitemap enfant retourne un 404 ?
Search Console signalera cet enfant comme erroné dans le rapport Sitemaps. Googlebot traitera quand même les autres sitemaps enfants de l'index. Cela n'invalidera pas tout l'index, mais les URLs uniquement listées dans cet enfant 404 ne seront pas découvertes via le sitemap. Corrigez-le rapidement. L'erreur persiste dans le rapport de Search Console pendant des semaines même après que vous l'ayez corrigée, ce qui est agaçant mais inoffensif.
Puis-je utiliser un index de sitemap sur un petit site ?
Techniquement oui, mais il n'y a aucune raison de le faire. La complexité ajoutée n'en vaut pas la peine en dessous de 10 000 URLs. Un simple sitemap.xml est plus facile à maintenir, plus facile à déboguer, et fait exactement le même travail. Utilisez un fichier index quand vous en avez besoin, pas avant.
---
La limite de 50 000 URLs surprend tout le monde à chaque fois, généralement au pire moment possible, juste avant un lancement de produit. Bien configurer la structure de l'index une fois signifie que vous n'aurez plus jamais à y penser à mesure que le site grandit. Cela vaut une heure de configuration.
Lectures connexes : Recherche de mots-clés par IA en 2026 : ce que c'est, pourquoi traditionnel, Recherche IA, et SEO multilingue.