Un sitemap XML de 1,2 million d'URL envoyé à la Search Console, et Google n'en indexe que 8 000. J'ai vécu ça il y a deux ans sur un site e-commerce. Le fichier était valide, propre, bien généré. Et pourtant, il sabotait l'indexation sans que personne ne comprenne pourquoi. Le problème ne venait pas du sitemap lui-même, mais de ce qu'on y avait mis.
Un plan de site XML bien configuré reste l'un des rares leviers techniques où vous gardez le contrôle total. Pas d'algorithme capricieux, pas de mise à jour surprise. Juste un fichier que vous écrivez et que Google lit. Mal écrit, il fait perdre des mois. Bien écrit, il accélère la découverte des pages qui comptent vraiment.
Ce guide n'est pas une traduction de la documentation officielle. C'est ce que j'ai appris en cassant des sitemaps, en les réparant, et en mesurant l'écart entre les deux.
Points clés à retenir
- Un sitemap ne sert pas à faire indexer, mais à faire découvrir : la nuance change tout
- La balise lastmod est la seule vraiment utile ; priority et changefreq sont ignorées depuis des années
- Un sitemap de plus de 50 000 URL ou 50 Mo doit être découpé et déclaré dans un index
- Ne déclarez que des URL canoniques, en 200, indexables
- La soumission dans la Search Console ne remplace jamais un maillage interne correct
Le rôle réel d'un sitemap XML (et ce qu'il ne fait pas)
La croyance la plus répandue : un sitemap ferait indexer les pages. Faux. Un sitemap indique à Google qu'une URL existe. Il ne dit rien sur sa qualité, sa pertinence, ni sur la probabilité qu'elle apparaisse dans les résultats. J'ai eu un client persuadé que son sitemap était cassé parce que ses fiches produits n'apparaissaient pas. En réalité, elles étaient en noindex à cause d'un plugin mal configuré.
Ce que le sitemap fait vraiment, c'est réduire le temps de découverte. Sur un site de 500 pages avec un bon maillage, l'utilité est marginale. Sur un site de 200 000 pages avec des sections profondes ou mal liées, c'est la différence entre trois jours et trois semaines avant que Google ne voie une nouvelle page.
Quand un sitemap devient vraiment indispensable
Trois situations justifient un sitemap soigné :
- Un catalogue volumineux dont les pages profondes ne sont pas atteignables en trois clics
- Des pages orphelines ou récentes qu'aucun lien interne ne pointe encore
- Un site dont les fichiers JavaScript masquent les liens au crawl (fréquent sur les SPA)
À l'inverse, un blog de 40 articles correctement liés n'a pas besoin d'un sitemap pour être indexé. Il en a un parce que c'est la norme, pas parce que ça change quelque chose.
Sitemap et robots.txt : deux fichiers qui ne font pas le même travail
Confusion classique. Le robots.txt contrôle ce que Google a le droit de crawler. Le sitemap propose ce qu'il devrait crawler. Si vous bloquez une section dans le robots.txt et que vous la mettez quand même dans le sitemap, vous envoyez un signal contradictoire. Google le détecte et le signale dans la Search Console, mais beaucoup l'ignorent. J'ai déjà vu une section entière d'un site bloquée au crawl et présente dans le sitemap pendant huit mois. Résultat : zéro indexation, zéro alerte lue.
Pour comprendre l'interaction entre ces directives et le comportement du robot, l'article sur les balises meta robots détaille les cas où un blocage volontaire produit l'effet inverse.
La structure d'un fichier qui tient la route
Un sitemap XML valide respecte un schéma précis. Voici le squelette minimal :
<?xml version="1.0" encoding="UTF-8"?>
<urlset xmlns="http://www.sitemaps.org/schemas/sitemap/0.9">
<url>
<loc>https://exemple.fr/page-a</loc>
<lastmod>2026-03-14</lastmod>
</url>
</urlset>Trois règles à ne jamais enfreindre. Les URL doivent être absolues (avec le protocole et le domaine). Elles doivent être encodées correctement (les esperluettes en &). Et elles doivent renvoyer un code HTTP 200.
Les limites techniques à connaître
Un fichier ne peut pas dépasser 50 000 URL ni 50 Mo non compressés. Au-delà, on découpe. Un fichier d'index pointe alors vers les sitemaps enfants :
- sitemap-produits.xml
- sitemap-categories.xml
- sitemap-blog.xml
- sitemap-images.xml (avec le namespace image)
Le découpage par type de contenu est meilleur que le découpage purement numérique. Il permet de suivre séparément le taux d'indexation de chaque section dans la Search Console, ce qui devient vite précieux quand une seule partie du site pose problème.
Pourquoi la structure d'URL conditionne la qualité du sitemap
Un sitemap ne peut pas rattraper une structure d'URL chaotique. Si vos URL contiennent des paramètres de session, des identifiants de tracking ou des variantes de tri, votre sitemap se remplit de doublons que Google traitera comme du bruit. J'ai récupéré un site dont le sitemap contenait 340 000 URL pour 12 000 produits réels. Le reste : des filtres à facettes générés automatiquement. Après nettoyage et passage en canonique, le taux d'indexation est monté de 22 % à 67 % en six semaines.
Balises, priorités et le mythe des indications obsolètes
Il faut le dire clairement : priority et changefreq ne servent plus à rien. Google l'a confirmé publiquement, et ça fait des années que c'est le cas. Beaucoup d'outils les génèrent encore par défaut, ce qui donne l'illusion qu'elles comptent. Elles ne comptent pas.
| Balise | Utilité réelle en 2026 | Recommandation |
|---|---|---|
| <loc> | Obligatoire, cœur du fichier | Toujours présente, URL absolue et canonique |
| <lastmod> | Utile si fiable | À conditionner aux vraies modifications de contenu |
| <priority> | Ignorée | Omettre |
| <changefreq> | Ignorée | Omettre |
| <image:image> | Utile pour la découverte d'images | À inclure sur les pages visuelles |
La balise lastmod : utile seulement si elle dit la vérité
Un lastmod qui change à chaque déploiement, même quand le contenu n'a pas bougé, est pire que pas de lastmod du tout. Google apprend à ignorer une balise qu'il juge peu fiable. Sur un site que j'ai audité, le lastmod affichait la date du jour pour toutes les pages, tous les jours. Le générateur mettait à jour l'horodatage à chaque exécution du cron. Résultat : Google a cessé de s'y fier, et la découverte des vraies mises à jour a ralenti.
La règle : le lastmod doit refléter une modification réelle et significative du contenu. Pas un changement de template, pas une correction typographique dans le footer.
Faut-il ajouter les images et les vidéos ?
Oui, si votre contenu en dépend. Une page produit avec dix visuels a tout intérêt à déclarer ses images dans le sitemap. Une page texte sans visuel n'a rien à y gagner. Ne gonflez pas le fichier avec des balises inutiles : chaque octet compte quand vous approchez des limites.
Soumission et suivi dans la Search Console
La soumission sitemap Search Console est l'étape que tout le monde connaît. Ce que peu de gens font, c'est le suivi. Une fois soumis, le sitemap vit sa vie. Il faut le surveiller.
Dans la Search Console, la section « Sitemaps » affiche le statut, la date de lecture et le nombre d'URL découvertes. La section « Pages » croise ces données avec l'indexation réelle. C'est là que se joue le vrai diagnostic.
Comment lire le rapport d'indexation sans se tromper
Un écart entre URL découvertes et URL indexées n'est pas toujours un problème. Sur un site e-commerce, 30 à 50 % d'écart est fréquent et souvent normal (pages de filtres, pages de recherche interne, paginations). Ce qui doit alerter :
- Une chute brutale du nombre d'URL indexées en quelques jours
- Des pages importantes classées en « Explorée, non indexée » depuis des semaines
- Des URL du sitemap marquées « Exclue par une balise noindex »
Ce dernier cas est le plus fréquent et le plus bête. Un plugin SEO ajoute un noindex par défaut, personne ne le voit, et le sitemap envoie consciencieusement des pages que Google refuse d'indexer.
À quelle fréquence faut-il resoumettre ?
Une seule fois, en général. Google relit le sitemap automatiquement quand il change. Resoumettre tous les jours ne sert à rien et peut même être contre-productif. La seule exception : après un changement majeur de structure, où une resoumission manuelle accélère la prise en compte.
Les erreurs que je vois le plus souvent (et comment les corriger)
Sur les vingt derniers sitemaps que j'ai audités, dix-huit contenaient au moins une erreur bloquante. Voici les plus fréquentes, classées par gravité.
Erreur n°1 : déclarer des pages en noindex
C'est l'erreur la plus répandue et la plus coûteuse. Un sitemap doit contenir uniquement des URL indexables. Si une page porte un noindex, elle n'a rien à faire dans le fichier. Le corriger demande de croiser le sitemap avec le code source de chaque page, ou d'utiliser un crawler.
Erreur n°2 : ignorer les canoniques
Une URL qui pointe vers une autre via une balise canonique n'a pas sa place dans le sitemap. Vous devez déclarer la version canonique, pas la version dupliquée. Sinon vous demandez à Google de crawler des pages que vous lui dites d'ignorer. Signal contradictoire, budget de crawl gaspillé.
Erreur n°3 : laisser les redirections
Une URL en 301 dans le sitemap est une perte de temps pour tout le monde. Google la suit, arrive sur la cible, et se demande pourquoi vous l'avez déclarée. Nettoyez régulièrement. J'ai vu un sitemap contenir 1 800 redirections héritées d'une refonte. Après suppression, la fréquence de crawl des pages importantes a augmenté de manière visible dans les logs serveur.
Le conseil que je donnerais à mon ancien moi
Automatisez la vérification. Un script qui crawle le sitemap, vérifie chaque URL et sort un rapport des codes HTTP, des canoniques et des noindex vaut mieux que n'importe quel plugin. Je l'ai écrit en une après-midi il y a trois ans, et il m'a évité des heures de diagnostic depuis. Le contrôle manuel d'un sitemap de 10 000 URL est illusoire.
Et vérifiez aussi les erreurs 404 qui traînent dans vos anciens sitemaps : corriger les erreurs 404 régulièrement évite que des URL mortes ne polluent la découverte.
Ce qu'il faut retenir avant de toucher à votre sitemap
Un sitemap parfait n'est pas un fichier complexe. C'est un fichier honnête. Il contient les URL que vous voulez voir indexées, avec des dates de modification qui disent la vérité, et rien d'autre. Pas de priorités décoratives, pas de pages en noindex, pas de redirections oubliées.
La prochaine action, concrète : ouvrez votre sitemap actuel dans un navigateur, puis comparez les URL qu'il contient avec celles que la Search Console signale comme non indexées. L'écart vous dira tout de suite si votre fichier travaille pour vous ou contre vous. Si vous trouvez plus de 5 % d'URL problématiques, vous avez votre chantier de la semaine.
Un sitemap bien configuré ne fait pas grimper un site dans les résultats. Il arrête juste de le freiner. Et parfois, arrêter de freiner suffit.
Questions fréquentes
Un sitemap XML est-il obligatoire pour être bien indexé ?
Non. Google indexe très bien des sites sans sitemap, à condition que le maillage interne soit solide. Le sitemap devient utile quand les pages sont nombreuses, profondes ou difficiles à découvrir par les liens. Sur un petit site bien structuré, son impact est marginal.
Faut-il encore remplir les balises priority et changefreq ?
Non. Google les ignore depuis des années. Les générer ne fait pas de mal, mais ne sert à rien et alourdit le fichier. Concentrez-vous sur la balise lastmod, à condition qu'elle reflète de vraies modifications de contenu.
Combien de temps faut-il pour que Google prenne en compte un nouveau sitemap ?
En général quelques jours pour la première lecture, mais l'indexation complète des URL peut prendre des semaines selon la taille du site et son autorité. La Search Console affiche la date de dernière lecture, ce qui permet de suivre. Un site récent ou peu crawlé mettra plus longtemps.
Peut-on mettre plusieurs sitemaps dans un seul fichier ?
Oui, via un fichier d'index (sitemapindex) qui pointe vers plusieurs sitemaps enfants. C'est la méthode recommandée dès que vous dépassez 50 000 URL ou 50 Mo, ou simplement pour séparer les types de contenu et suivre leur indexation séparément.
Que faire si mon sitemap contient des URL en erreur 404 ?
Il faut les retirer. Une URL morte dans un sitemap gaspille du budget de crawl et envoie un signal de mauvaise qualité. Automatisez un contrôle régulier et nettoyez le fichier à chaque déploiement. C'est un entretien continu, pas une tâche ponctuelle.
