Un sitemap qui liste des milliers d’URL en paramètres finit par ressembler à un plan cadastral posé sur la table du crawl : tout y est, mais rien n’y est classé. La tentation est de fermer la porte en bloc dans le robots.txt, ou de tout laisser passer en espérant que Google se débrouille. Les deux réflexes coûtent cher, parce qu’un budget d’exploration se dépense, il ne se recharge pas. Le vrai travail se joue ailleurs, dans le tri URL par URL à l’intérieur du fichier lui-même.

Un sitemap n’est pas une feuille de route

Beaucoup de webmasters traitent le sitemap comme un inventaire à fournir au moteur, alors qu’il s’agit d’une déclaration de candidats. Un fichier peut contenir jusqu’à 50 000 URL, et un index peut enchaîner jusqu’à 50 000 sitemaps : à cette échelle, chaque entrée pèse dans la file d’attente et certaines n’en sortiront jamais.

Comprendre finement le fonctionnement du crawl aide à voir pourquoi toutes les URL ne se valent pas, loin de là, et pourquoi la dépense reste invisible. Google ne visite pas ce qu’il ne juge pas utile, et un sitemap trop généreux dilue le signal. La ressource de référence sur le SEO technique, chez mystpi.com, insiste justement sur ce point.

La ligne Sitemap: du robots.txt annonce simplement l’emplacement du fichier, pas un droit de passage prioritaire. Google lit, échantillonne, compare, puis décide. Une URL en paramètres qui génère une page correcte mais redondante n’apporte rien au moteur, tandis qu’elle consomme une visite qui aurait pu servir à une page neuve. Le tri se fait donc en amont, dans la composition du fichier.

Repérer les paramètres qui produisent du contenu unique

Tous les paramètres ne se ressemblent pas. Un filtre de couleur sur une catégorie crée une variante de page quasi identique, alors qu’une recherche interne bien construite peut produire des pages réellement différentes selon la requête, ce qui change tout pour le crawl.

Le test le plus simple reste de comparer deux URL paramétrées à l’œil nu. Si le titre, le contenu principal et les liens internes se ressemblent au point qu’on ne saurait pas laquelle choisir, il y a redondance.

Les questions à se poser avant de garder une entrée

Le tri ne demande pas d’outil compliqué, juste un peu de méthode et un tableur ouvert à côté de la Search Console. Chaque entrée passe au crible des mêmes questions, sans exception, avant d’être conservée ou écartée.

• La page répond-elle à une intention de recherche qui n’existe nulle part ailleurs sur le site ?
• Le contenu principal est-il identique à celui d’une autre URL, à quelques blocs près ?
• Combien de clics cette URL a-t-elle réellement reçus sur les derniers mois ?
• Existe-t-il une version canonique propre, sans paramètre, vers laquelle la rediriger ?
• Quel paramètre tire la page : un tri, une pagination, un identifiant de session ?

Les paramètres de session et les identifiants de tracking n’ont rien à faire dans un sitemap : ils fabriquent des URL à l’infini et changent à chaque visite. À l’inverse, une pagination propre ou un filtre qui reflète une vraie demande mérite sa place. La frontière n’est jamais technique, elle est éditoriale. Sur ce point, voir aussi notre article sur anciennes url 200.

Quand lastmod ne vaut rien pour arbitrer

La date de dernière modification semble le critère idéal pour prioriser : on garde les entrées récentes, on laisse filer les vieilles. Sauf que Google ne l’utilise que s’il la juge « de façon cohérente et vérifiable » exacte, et beaucoup de générateurs de sitemap se contentent d’y écrire l’horodatage du moment où le fichier a été produit. Dans une vérification citée par les équipes Google, le sitemap d’actualités d’un grand éditeur de presse attribuait à chaque entrée le même horodatage. La date ne distinguait plus rien.

Autre cas repéré dans la même vérification, une vaste archive documentaire publiait plus de 10 000 URL sans aucun lastmod. Pas de date, donc pas de signal de fraîcheur, et pourtant ces pages existent et méritent parfois d’être explorées. Un lastmod uniforme ou absent transforme le critère en bruit. Il faut alors s’appuyer sur autre chose. La qualité du contenu d’abord, les liens internes qui pointent vers la page ensuite, ou l’historique de clics.

Arbitrer à la main dans le fichier

Le protocole Sitemap accepte plusieurs formats : XML, RSS, mRSS, Atom 1.0 et texte brut. Cette souplesse aide à séparer les fichiers par nature d’URL plutôt que de tout empiler dans un seul gros sitemap. Un fichier pour les pages éditoriales stables, un autre pour les URL paramétrées qui méritent encore un essai, un troisième pour celles qu’on surveille avant de les retirer : la lecture devient plus claire pour l’humain comme pour le robot.

Cette séparation a un autre avantage : elle rend le retrait progressif possible. On sort une famille d’URL paramétrées du sitemap sans toucher au reste, on observe la Search Console pendant quelques semaines, on vérifie si les pages continuent d’être explorées via les liens internes. Si elles disparaissent des résultats de recherche sans perte de trafic, le tri était bon. Dans le cas contraire, on réintègre les entrées les plus utiles.

Il faut accepter une part d’incertitude. Google explore aussi ce qui n’est pas dans le sitemap, à condition qu’un lien pointe quelque part vers la page. Retirer une URL du fichier ne la condamne donc pas : ça revient à retirer un candidat de la liste prioritaire, pas à fermer la porte. L’inverse est plus risqué : garder une entrée inutile, c’est laisser le moteur dépenser du temps sur une page qui ne rapportera rien.

Ce que le tri change vraiment

Le budget d’exploration n’est pas une ressource illimitée, et chaque URL paramétrée laissée dans le sitemap le consomme un peu. Trier ces entrées selon leur valeur réelle, en acceptant que le lastmod ne serve à rien quand il est uniforme ou absent, rend le fichier plus lisible et le crawl plus rentable.

Une équipe qui passe une heure à arbitrer cinquante URL paramétrées gagne souvent plus qu’une équipe qui ajoute mille pages à un sitemap déjà saturé. La question qui reste, et elle vaut pour tout site : combien d’URL de votre sitemap n’ont jamais reçu la moindre visite de Googlebot ?