Un sitemap XML qui liste des URL redirigées, des pages en noindex ou des adresses canonisées vers d’autres ressources envoie des signaux contradictoires aux moteurs de recherche. On le constate régulièrement après une refonte : le fichier est techniquement valide, mais il pointe vers des pages que Google ne devrait pas explorer. Optimiser la structure d’un site avec un sitemap efficace commence par ce nettoyage, pas par la génération automatique du fichier.
Sitemap XML après une refonte : les signaux contradictoires à corriger
Quand on migre un site ou qu’on réorganise l’arborescence, le CMS régénère souvent le sitemap sans vérifier l’état réel des URL. On se retrouve avec un fichier qui contient des anciennes adresses redirigées en 301, des pages passées en noindex depuis la refonte, et parfois des URL qui renvoient une erreur 404 ou 410.
Le problème concret : Google reçoit une liste d’URL présentées comme valides et découvre ensuite qu’elles ne le sont pas. Le crawl budget est gaspillé, et l’indexation des nouvelles pages prend du retard.
La vérification post-refonte devrait suivre une logique simple. On extrait toutes les URL du sitemap, on les passe dans un crawler (Screaming Frog, Sitebulb ou équivalent), et on croise trois colonnes : code HTTP, directive d’indexation, URL canonique déclarée.
Toute URL qui ne renvoie pas un 200, qui porte un noindex, ou dont la balise canonical pointe ailleurs, doit sortir du fichier. On peut observer comment le site yvazur.ch structure son propre sitemap pour illustrer une approche propre de ce tri.
Balise lastmod dans le sitemap : quand la supprimer vaut mieux que la garder
La balise lastmod est le principal signal exploitable par Google dans un sitemap XML. Mais cette utilité repose sur une condition stricte : la date doit correspondre à une modification réelle et significative du contenu, des données structurées ou des liens internes de la page.
En pratique, beaucoup de CMS mettent à jour cette date à chaque déploiement, même quand rien n’a changé sur la page. Un simple changement de pied de page, une mise à jour de l’année de copyright, un rebuild du cache – et toutes les dates passent à la date du jour.
Le réflexe terrain qui évite le piège
Si votre CMS ne peut pas fournir une date fiable, liée à une vraie modification de contenu, il vaut mieux supprimer complètement la balise lastmod plutôt que de la conserver avec des valeurs trompeuses. Google finit par ignorer les dates incohérentes, et dans ce cas, leur présence ne fait qu’ajouter du bruit.
À l’inverse, sur un site éditorial où chaque article est réellement mis à jour (ajout de paragraphes, actualisation de données), une lastmod fiable accélère la prise en compte des modifications. C’est un levier concret pour les pages qui évoluent régulièrement.
Balises priority et changefreq : ce que le sitemap XML ne fait plus
On trouve encore des sitemaps bourrés de balises priority et changefreq, parfois configurées avec soin. Google ignore ces deux éléments. Leur présence n’apporte aucun bénéfice côté référencement.
Plutôt que de perdre du temps à calibrer des priorités que personne ne lit, on gagne à concentrer l’effort sur la cohérence entre quatre éléments :
- L’URL présente dans le sitemap doit être la version canonique déclarée dans le code source de la page
- Cette même URL doit être accessible (code 200), sans redirection intermédiaire
- Le maillage interne du site doit pointer vers cette URL, pas vers une variante avec ou sans slash final, avec ou sans www
- La page ne doit porter aucune directive noindex si elle figure dans le sitemap
Un sitemap cohérent avec le maillage interne et les balises canonical fait plus pour l’indexation que n’importe quel réglage de priority.
Sitemap et pages orphelines : un cas d’usage souvent négligé
Le sitemap ne remplace pas le maillage interne, mais il joue un rôle spécifique pour les pages qui ne reçoivent aucun lien depuis le reste du site. On parle de pages orphelines : elles existent, elles sont indexables, mais aucun chemin de navigation ne permet d’y accéder.
Ce cas se produit fréquemment sur les sites e-commerce (fiches produits retirées du catalogue mais toujours en ligne), les blogs avec des archives profondes, ou les sites qui ont subi plusieurs refontes successives sans audit de liens.
Comment traiter les pages orphelines dans le sitemap
La première question est de savoir si ces pages méritent d’être indexées. Si oui, deux actions parallèles :
- Les inclure dans le sitemap XML pour que les moteurs les découvrent
- Créer au moins un lien interne pertinent vers chacune, depuis une page thématiquement proche
- Vérifier que la balise canonical de chaque page orpheline pointe bien sur elle-même
Si ces pages n’ont plus de valeur (contenu obsolète, produit disparu), mieux vaut les retirer du sitemap et les désindexer proprement avec un noindex ou une redirection 410.
Soumission du sitemap XML : robots.txt et Search Console
Générer un sitemap propre ne suffit pas si les moteurs ne savent pas où le trouver. Deux canaux de soumission fonctionnent en parallèle.
Le premier est le fichier robots.txt. On y ajoute une ligne Sitemap: suivi de l’URL absolue du fichier. Cette déclaration est lue par tous les moteurs compatibles, pas uniquement Google. C’est le canal passif, qui fonctionne sans intervention manuelle après la mise en place.
Le second est la Google Search Console (et son équivalent Bing Webmaster Tools). La soumission via ces outils permet de suivre l’état d’indexation des URL listées, de repérer les erreurs de crawl, et de vérifier que le fichier est bien lu. Les retours varient sur la fréquence de recrawl du sitemap après soumission, mais la prise en compte initiale est généralement rapide.
Le point à ne pas négliger : si votre site dépasse la limite de volume d’un seul fichier sitemap, un sitemap index qui regroupe plusieurs fichiers segmentés (par catégorie, par type de contenu) reste la solution technique standard. Chaque fichier enfant suit les mêmes règles de propreté que le fichier principal.
Un sitemap bien structuré n’améliore pas directement le classement d’une page. Son rôle est de garantir que les moteurs trouvent, explorent et comprennent les bonnes URL. Le gain se mesure en taux d’indexation et en rapidité de prise en compte des modifications, deux métriques que la Search Console permet de suivre concrètement.
