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.Sitemaps protocol, maintained jointly by Google, Bing, and others, sets two hard constraints on a single sitemap file: no more than 50,000 URLs, and no larger than 50MB uncompressed. These aren't suggestions. Googlebot will stop parsing the file at whichever limit it hits first.
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) `` sitemap_index.xml ├── sitemap-posts-1.xml (up to 50,000 blog posts) ├── sitemap-posts-2.xml (overflow posts) ├── sitemap-products-1.xml (up to 50,000 products) ├── sitemap-products-2.xml (overflow products) └── sitemap-pages.xml (static pages) ``
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>.<sitemapindex> as the root element instead of <urlset>. Each child is wrapped in a <sitemap> tag with a <loc> pointing to the child file, and optionally a <lastmod> timestamp.
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)
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.sitemap-{type}-{page}.xml . Don't use dates in the filename. I made that mistake on a news site in 2019 and ended up with filenames like sitemap-articles-2019-march.xml that became completely meaningless the moment we needed to regenerate historical content. Stick to numbered pages.
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.<lastmod> element in your child sitemaps should reflect when the content was actually last modified, not when you regenerated the sitemap. I've seen setups where every regeneration stamps every URL with today's date. That trains Googlebot to ignore your lastmod entirely because the signal is noise. Use your CMS's actual modified timestamp. In WordPress, that's post_modified_gmt from the wp_posts table.
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. handles sitemap indexes automatically once you have more than 1,000 URLs per post type. It generates clean, segmented files. But the default batch size is 1,000 URLs per child sitemap, which is conservative. You can filter that up with
wpseo_sitemap_entries_per_page. I usually push it to 5,000 on well-hosted servers. - 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. does the same, with slightly more granular control over which post types and taxonomies get their own child sitemaps. On a recent client site with 80,000 WooCommerce products, Rank Math's segmentation out of the box was cleaner than Yoast's.
- 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. is what I reach for when the site has unusual content types or the plugin-generated sitemaps are too slow to generate. I've written scripts that query the database directly, paginate results in chunks of 10,000, write the XML to disk, and then write the index file last. Runs in under 30 seconds for 200,000 URLs. The key is writing to a temp file and atomically moving it into place so Googlebot never hits a half-written file.
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.Screaming Frog SEO Spider can crawl your site and generate a sitemap index for you, though it's better as a validation tool than a production sitemap generator. For production, generate sitemaps from your data source, not from a crawler. Crawlers miss things.
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.Google Search Console, open the Sitemaps report, and submit your index file URL. One URL. That's it.
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é. The "Discovered URLs" count should be climbing toward your actual URL count. If it plateaus weirdly early, you likely have a crawl budget issue or a malformed child sitemap.
- 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. Search Console will show you each child sitemap and its status. If one child is returning an error, you can isolate it without touching the others. This is the underrated advantage of the index structure.
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. If a URL has a noindex meta tag or X-Robots header, it should not be in your sitemap. Full stop. A sitemap is a recommendation to crawl and index. Including noindexed URLs wastes crawl budget and confuses the signal. I run a quick Screaming Frog crawl against the sitemap URLs and filter for noindex responses before any major site launch.
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. Even worse than noindex: URLs that are disallowed in robots.txt but still listed in the sitemap. Googlebot can see the contradiction. It won't penalise you for it, but it's sloppy and it wastes time.
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. This sounds obvious but it trips up custom implementations. You add a new content type, generate a new child sitemap file, and forget to add the <sitemap> entry to the index. The child file exists on disk but nothing points to it. I've seen this sit unnoticed for months.
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. If you have 12 child sitemaps and you submit all 12 to Search Console separately, you've lost the organisational benefit. Submit the index. Let it 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.Google's documentation on crawl budget is worth reading if you're operating at this scale. The short version: Googlebot has a finite amount of time it'll spend on your site per day, and a well-structured sitemap index helps it spend that time on your highest-priority content first.
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.sitemap-recent.xml that only contains URLs modified in the last 30 days, refreshed hourly. Googlebot recrawls that one aggressively. The older historical sitemap files get crawled less frequently, which is fine because that content isn't changing.
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.need to, but it's worth doing for large files. A 50MB sitemap compresses down to roughly 3-5MB with gzip. Googlebot accepts .xml.gz files without any configuration. Most modern web servers will handle this transparently if you enable gzip compression at the server level. For static-file sitemaps generated to disk, I pre-compress with gzip and serve the .xml.gz directly.
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.