Des millions d’URL de tri, de recherche interne, d’anciens produits ou de campagnes continuent parfois à recevoir des visites de Googlebot longtemps après leur perte d’utilité. L’équipe veut agir vite : bloquer un répertoire, ajouter noindex, rediriger tout vers une catégorie ou supprimer les routes. Une mauvaise séquence peut pourtant conserver les URL dans l’inventaire, empêcher Google de voir leur disparition ou déplacer le trafic robot vers une autre famille tout aussi inutile.
Le protocole part d’un inventaire par cause, ferme les liens et générateurs, sert ensuite la réponse HTTP appropriée, observe sa prise en compte, puis utilise robots.txt uniquement comme contrôle durable lorsque le moteur n’a plus besoin de lire la page. Il donne un ordre de livraison, des seuils et un retour arrière à chaque étape.
Le vrai enjeu n’est pas de réduire un compteur global, mais de retirer proprement les chemins sans valeur tout en préservant les contenus utiles. En réalité, ce n’est pas « bloquer davantage », c’est rendre chaque URL cohérente avec son état métier. Contre-intuitivement, laisser temporairement Googlebot accéder à une URL morte peut accélérer sa fermeture, parce que le robot doit recevoir le 404, le 410 ou la directive avant qu’un blocage devienne pertinent.
Concrètement, un accompagnement Tech SEO et performance web relie inventaire, graphe de liens, logs vérifiés, statuts d’origine et règles Nginx ou applicatives. Le résultat attendu est une décision reproductible, pas une promesse de transfert automatique du crawl vers les pages commerciales.
Choisir une séquence plutôt qu’une règle globale
Une URL inutile peut provenir d’un générateur encore actif, d’un ancien lien, d’un paramètre combinatoire, d’un produit retiré, d’une migration ou d’un contenu utile hors recherche. Ces causes appellent des réponses différentes. Une règle globale réduit parfois les hits visibles sans réduire le stock connu, car le robot rencontre encore les URL dans les liens, les sitemaps ou les redirections.
Le chantier possède deux objectifs distincts : réduire la création et la redécouverte d’URL inutiles, puis faire comprendre l’état des URL déjà connues. La première étape travaille le graphe, les formulaires, les facettes, les flux et les sitemaps. La seconde choisit 200, canonicale, 301, 404, 410 ou noindex selon la destination attendue.
Si les URL restent générées, alors une interdiction robots masque le symptôme sans fermer la cause. En revanche, si la génération a cessé et que les statuts de disparition ont été observés pendant une fenêtre suffisante, un blocage durable peut protéger un espace infini résiduel. L’équipe traite donc le producteur plutôt que le seul consommateur.
Inventorier les familles avant toute fermeture
Construire la table de vérité
La table conserve URL brute, URL normalisée, host, gabarit, paramètres, statut public, canonicale, présence sitemap, nombre de liens internes, dernier hit Googlebot vérifié, octets, temps serveur, finalité métier et équivalent éventuel. Chaque règle de normalisation reste visible ; fusionner trop tôt deux URL peut masquer une facette réellement utile.
Les URL sont classées par mécanisme de naissance : liens HTML, navigation à facettes, moteur interne, pagination, anciennes campagnes, flux partenaires, redirections, JavaScript ou backlinks. Le volume brut est complété par la vélocité de création. Dix mille URL stables et un million de nouvelles combinaisons quotidiennes ne demandent pas la même urgence.
Échantillonner les extrêmes et les cas ordinaires
Pour chaque famille, l’analyste ouvre des URL récentes, anciennes, fréquentes, rares et sans hit. Il rejoue aussi un parcours utilisateur. Cette revue révèle les dépendances que le regroupement ne montre pas : un filtre peut être inutile au référencement mais indispensable à une campagne payante ou à l’accessibilité.
Une famille ne passe en correction que si son intention, son propriétaire, sa réponse cible et son mode de découverte sont confirmés. Une inconnue ne devient ni « à supprimer » ni « sans valeur ». Elle reçoit une enquête bornée avec une date, faute de quoi le projet industrialise une supposition.
Associer chaque état à une réponse défendable
Le registre de décision empêche les choix par habitude. Il relie l’état métier, la réponse publique, la découverte autorisée et le signal attendu. Les règles principales sont les suivantes :
- Contenu actif et distinct : réponse 200, canonicale propre, liens HTML et sitemap si l’URL est indexable.
- Doublon réellement équivalent : consolidation de la génération, des liens et des signaux vers une URL canonique, sans considérer la canonicale comme un ordre absolu.
- Contenu déplacé avec équivalent durable : redirection 301 ou 308 directe vers cet équivalent, sans chaîne ni destination générique.
- Contenu disparu sans remplaçant : réponse 404 ou 410, retrait des liens et du sitemap, avec page d’erreur utile pour l’humain.
- Page utile aux utilisateurs mais exclue de Search : réponse 200 et
noindexcrawlable, en acceptant le coût de récupération nécessaire. - Espace infini durablement inutile : fermeture de la génération, nettoyage du graphe, observation des statuts, puis éventuel blocage robots.
Cette table tranche les cas ambigus. Une fiche retirée avec un successeur presque identique peut être redirigée ; une fiche sans équivalent doit disparaître plutôt que renvoyer vers la catégorie. Une recherche interne utile au client reste accessible, mais ses liens explorables et sa directive d’indexation sont conçus consciemment.
Fermer d’abord les sources de découverte internes
Le premier lot supprime les liens depuis menus, facettes, pagination, suggestions, pieds de page, XML, flux et composants. Il corrige également le générateur : une facette non autorisée ne doit pas seulement perdre son lien, elle doit cesser de créer de nouvelles combinaisons dans le DOM, les API ou les scripts.
Le graphe est recrawlé avant livraison puis après déploiement. L’équipe compare le nombre de sources, la profondeur et les nouvelles URL découvertes. Si une famille continue de croître, alors elle recherche la source résiduelle plutôt que d’ajouter immédiatement une règle robots. Un lien absolu caché dans un JSON, une balise de langue ou un flux peut maintenir le problème.
Les sitemaps ne gardent que des URL canoniques, indexables et servies en 200. Leur retrait ne supprime pas une URL déjà connue, mais il cesse de contredire le statut public. Une URL 404 encore soumise chaque nuit envoie un message opérationnel incohérent et rend la mesure de fermeture moins lisible.
Faire observer les statuts de disparition
Une route retirée sans équivalent répond 404 ou 410 de manière stable. Le corps peut proposer une navigation humaine, mais l’en-tête HTTP doit rester celui de la disparition. Un « soft 404 » servi en 200 oblige les systèmes à interpréter la page et entretient une ambiguïté inutile.
Google indique que les 4xx, hors 429, ne sont pas utilisés pour calculer la limitation du crawl du host comme les 5xx. Ils constituent donc la réponse normale pour un contenu absent. Le 410 explicite une disparition intentionnelle ; le 404 suffit souvent. Le choix interne compte moins que la stabilité et l’absence de faux 200.
La fenêtre d’observation dépend de la fréquence passée et de la profondeur. Le registre suit le dernier hit, le statut rendu, le volume d’URL encore demandé et les nouvelles découvertes. Bloquer le répertoire immédiatement empêcherait le robot de recevoir ces statuts sur les URL déjà connues.
Réserver les redirections aux vrais équivalents
Une redirection transmet une relation de déplacement, pas une volonté de conserver artificiellement tous les chemins. Elle est justifiée lorsque la nouvelle URL répond à la même intention et reprend réellement le contenu ou le produit. Rediriger des milliers de fiches distinctes vers la page d’accueil ou une catégorie large peut être traité comme un soft 404.
La table de correspondance est testée avant déploiement : source, destination, statut, nombre de sauts, canonicale finale, code final et absence de boucle. Les liens internes et sitemaps sont mis à jour directement vers la destination plutôt que de dépendre indéfiniment du saut.
Si un remplaçant existe, alors une 301 ou 308 directe est préférable à une chaîne. En revanche, si l’intention n’est pas préservée, un 404 ou 410 est plus honnête qu’une redirection générique. Ce choix réduit les traitements inutiles et protège l’utilisateur contre une arrivée trompeuse.
Comprendre les limites de noindex et robots.txt
La directive noindex demande à Google de ne pas présenter la page, mais le robot doit pouvoir la récupérer pour la lire. Ce n’est donc pas un levier direct d’économie de crawl. Elle convient aux pages qui doivent rester en 200 pour l’utilisateur tout en étant exclues des résultats.
Robots.txt empêche la récupération ; il ne garantit pas la désindexation d’une URL connue par d’autres signaux. Combiner une interdiction avec noindex dans la page est contradictoire : si la page n’est pas crawlée, la directive ne peut pas être observée. La fermeture demande d’abord une réponse lisible.
Le blocage devient pertinent pour un espace sans valeur qu’aucun statut unitaire ne peut raisonnablement épuiser, par exemple une génération combinatoire maîtrisée à la source. Il protège alors la capacité plutôt que de jouer le rôle de mécanisme de suppression. Le fichier est versionné, testé et limité au motif exact.
Mesurer URL distinctes, coût et déplacement
Mesurer la fermeture à la source
Le tableau suit les requêtes et surtout les URL distinctes par famille, leur taux de renouvellement, les réponses, les octets, la latence d’origine et les 5xx ou 429. Une baisse de hits peut venir d’une saisonnalité ; une baisse de nouvelles URL confirme davantage la fermeture du générateur.
La mesure vérifie aussi le déplacement. Les requêtes supprimées sur les tris peuvent réapparaître sur la recherche, une locale ou des redirections. L’équipe compare le domaine entier et les cohortes utiles. Elle ne promet pas qu’un volume libéré sera automatiquement réalloué à des produits.
Les indicateurs business restent séparés. Réduire le coût serveur, la bande passante ou la dette de routes constitue un gain vérifiable. Améliorer la découverte de pages commerciales demande une observation dédiée. Confondre les deux transforme un résultat d’exploitation solide en affirmation SEO fragile.
Arbitrer deux scénarios entièrement simulés
Quatre millions de tris créés par un composant
Scénario simulé. Un catalogue fictif expose 4,2 millions d’URL de tri. Sur vingt-huit jours, 62 % des 18 millions de hits vérifiés visent ces variantes ; 320 000 nouvelles combinaisons apparaissent chaque jour. L’origine reste sous 55 % de capacité et les pages produits utiles conservent un p90 de revisite de six jours.
L’équipe ferme la génération, retire les liens, sert 404 aux variantes sans usage et conserve en 200 quelques filtres utiles. Elle n’annonce aucun transfert de budget. Le seuil d’extension exige moins de 20 000 nouvelles variantes par jour, moins de 0,3 % de parcours cassés et aucune hausse supérieure à 10 % des 5xx.
Soixante mille campagnes anciennes
Deuxième scénario simulé. Soixante mille pages de campagnes reçoivent encore 90 000 hits mensuels. Douze mille possèdent un successeur exact ; les autres n’ont aucun équivalent. Les rediriger toutes vers une catégorie aurait créé une destination fausse. Le lot applique 301 aux correspondances validées et 410 aux autres, après retrait des liens et du flux.
Le suivi dure six semaines, car ces URL étaient rarement revisitées. Le lot est arrêté si plus de 0,5 % des destinations répondent autrement qu’en 200, si une chaîne apparaît ou si plus de 50 URL actives sont classées par erreur. Ces chiffres illustrent un protocole ; ils ne décrivent aucune performance Dawap ou client.
Déployer un canari avec seuils d’arrêt
Le canari choisit une famille homogène et un témoin comparable. Il capture avant livraison le graphe, les sitemaps, les statuts et quatre semaines de logs. La correction est appliquée à cinq ou dix pour cent du volume, assez pour observer le mécanisme sans exposer tout le catalogue.
Les critères de succès sont écrits en valeurs absolues et relatives : réduction d’au moins 60 % des nouvelles URL, statut cible correct sur 99,8 % des sources, zéro boucle, p95 de latence non dégradé de plus de 10 % et absence de rupture utilisateur majeure. Les seuils d’arrêt sont surveillés dès la mise en production.
Plutôt que d’attendre un chiffre parfait, la revue examine les cas résiduels et les sources qui continuent à produire des liens. Si la baisse reste confinée au canari sans contamination négative, alors l’extension suit par paliers. En revanche, une famille utile touchée déclenche le retour arrière avant toute discussion sur le volume de crawl.
Implémenter les règles sans casser les parcours
Relier route, preuve et retour arrière
L’endpoint expose famille et statut cible. La responsabilité produit qualifie l’entrée ; développement possède la sortie HTTP, l’instrumentation et le monitoring de la dépendance sitemap. La QA compare les canonicals avant le seuil de conformité.
La journalisation de release_id assure la traçabilité. Un retry idempotent traite la file ; le runbook définit rollback et repli par feature flag. Si une URL active tombe en 4xx, la règle revient à sa version précédente.
Dans l’application et le reverse proxy
Le routeur applicatif lit l’état métier, renvoie 404 ou 410 sans faux 200, journalise l’identifiant de règle et conserve le bon Cache-Control. Le reverse proxy propage host, schéma et chemin, applique la redirection en un seul saut et expose statut, temps amont et octets dans les logs. Ces marqueurs permettent de relier configuration, réponse HTTP et effet mesuré.
Les règles de paramètres travaillent une liste autorisée, la canonicale, le générateur de liens et les tests de régression. Un test vérifie URL brute, statut final, destination, balise robots et présence sitemap ; un autre rejoue navigation, locale et pagination. L’implémentation ne se limite jamais à une expression régulière isolée.
Dans le pipeline de livraison
La CI compare le manifeste des routes, détecte chaînes et boucles, vérifie les destinations 200 et refuse un sitemap contenant 3xx, 4xx ou noindex. Le déploiement produit un identifiant de version repris dans les logs, le manifeste de cohorte et le tableau avant/après. Trois marqueurs — version, famille, décision — rendent le diagnostic traçable.
Le retour arrière restaure séparément liens, génération, statuts et robots. Cette granularité évite de rouvrir un espace infini pour corriger une seule mauvaise correspondance. Les caches sont purgés de manière ciblée, puis une sonde externe confirme le code public plutôt que le seul comportement interne.
Répartir décisions, preuves et retour arrière
Rendre chaque famille opposable
Produit qualifie l’utilité et les équivalents. SEO définit l’état de recherche et contrôle découverte, canonicales et indexabilité. Développement ferme générateurs et routes. SRE garantit capacité, logs, cache et réponses publiques. Support valide les parcours touchés et remonte les URL encore utilisées.
Chaque famille possède un propriétaire, un volume, une fenêtre, une décision, une preuve, des exclusions et une date de revue. Les exceptions expirent. Une campagne conservée « temporairement » sans échéance deviendrait le prochain stock d’URL orphelines.
Le compte rendu sépare faits, interprétations et hypothèses. « 600 000 variantes ne sont plus générées » est un fait ; « cela améliorera le crawl produit » est une hypothèse à mesurer. Cette discipline protège les décisions techniques de récits commerciaux trop rapides.
Éviter les raccourcis les plus coûteux
Bloquer avant de montrer la disparition. Une interdiction robots immédiate cache le 404, le 410 ou le noindex que le moteur doit lire. Le bon ordre retire les sources, rend le statut, observe, puis bloque seulement un espace résiduel dont la récupération n’apporte plus rien.
Rediriger vers une destination commode. Une catégorie générique n’est pas l’équivalent de chaque fiche. Plutôt que de préserver artificiellement une URL, l’équipe choisit une disparition honnête. Les correspondances exactes restent documentées et testées.
Mesurer uniquement les hits. Un compteur peut baisser alors que le stock continue de croître ailleurs. URL distinctes, nouvelles découvertes, statuts, coût, parcours et cohorte utile sont lus ensemble. La réduction du crawl n’est pas un concours de pourcentage quotidien.
Plan d’action : réduire en trois semaines
- Mesurer budget de crawl, Googlebot, logs serveur et code HTTP avant de fermer une famille d’URL.
- Nettoyer sitemap XML, maillage interne, canonicale et hreflang avant les règles de réponse définitives.
- Choisir robots.txt, noindex ou redirection 301 selon disparition, doublon, équivalent et besoin d’indexation.
- Vérifier cache, données structurées, Search Console et Core Web Vitals après le canari de production.
Fermer les prérequis avant la première semaine
Avant le premier jour, le responsable fixe le dénominateur : familles actives, variantes, anciennes campagnes et routes techniques. Il choisit une fenêtre de vingt-huit jours, valide l’identité des bots et conserve un témoin. Le plan refuse toute suppression si le propriétaire métier, l’équivalent éventuel ou la réponse cible reste inconnu.
La revue finale ne se contente pas de la baisse des hits. Elle exige la fermeture du générateur, moins de 20 000 URL nouvelles par jour dans le scénario simulé, 99,8 % de statuts conformes, aucune boucle et aucun parcours majeur cassé. Si une condition manque, alors l’équipe corrige la famille plutôt que d’élargir robots.txt.
Exécuter les trois semaines par livrable
- Semaine 1 — inventorier : extraire vingt-huit jours de logs, valider les bots, cartographier les producteurs, joindre sitemaps et graphe, puis qualifier chaque famille avec produit et support.
- Semaine 1 — décider : attribuer 200, canonicale, 301, 404, 410,
noindexou contrôle robots ; documenter les équivalents et refuser les inconnues non arbitrées. - Semaine 2 — fermer : retirer liens et flux, corriger le générateur, déployer statuts ou redirections sur un canari, puis tester routes, cache, canonicales et parcours.
- Semaine 3 — observer : mesurer URL nouvelles, hits, réponses, coût et déplacement ; étendre par paliers ou revenir en arrière selon les seuils écrits.
Le plan produit quatre livrables : inventaire versionné, matrice de décision, manifeste du canari et bilan avant/après. Chacun contient source, période, couverture, exclusions et propriétaire. Une autre personne peut ainsi reproduire l’analyse sans dépendre du souvenir de l’équipe.
À la fin, la revue décide famille par famille. Si la cause est fermée et les statuts observés, alors un blocage durable peut compléter le dispositif. Si les URL continuent à naître, le chantier revient au générateur plutôt que d’élargir robots.txt.
Relier le chantier aux paramètres et aux orphelines
Le diagnostic du gaspillage de crawl par paramètres aide à quantifier cardinalité, vélocité et intention avant de fermer une facette. Il protège les filtres utiles contre une règle trop large.
La méthode consacrée aux pages orphelines visibles dans les logs sépare anciennes routes, backlinks et opportunités. Toutes les URL sans lien actuel ne doivent pas être supprimées.
Le travail sur les espaces infinis détectés dans les logs apporte les définitions de coût et de cohorte. Enfin, le protocole sur les facettes e-commerce à indexer, canoniser ou bloquer sécurise la réduction des combinaisons.
Vérifier la doctrine dans les sources primaires
Google documente les leviers de gestion du crawl budget et précise que libérer de la capacité ne garantit pas un transfert automatique vers d’autres URL. La documentation sur noindex rappelle que la page doit rester accessible au robot.
La référence sur les codes HTTP décrit le traitement des 3xx, 4xx, 429 et 5xx. La documentation officielle de la navigation à facettes expose les risques d’espaces combinatoires.
Ces sources cadrent le comportement documenté. Les seuils, durées et volumes présentés ici sont des choix de pilotage ou des simulations, à adapter à l’historique du site.
Vérifier le lot avant sa fermeture
Le responsable extrait cinquante sources et cinquante destinations, contrôle statut final, graphe, sitemap et logs, puis compare la version de règle au manifeste. Il documente les exceptions et confirme que chaque URL active reste accessible avant de retirer le suivi intensif.
La fermeture exige deux fenêtres conformes, zéro boucle, moins de 0,2 % d’erreurs et aucune nouvelle URL produite par le générateur corrigé. Si un seuil échoue, la famille reste ouverte avec un propriétaire plutôt que d’être masquée par un blocage plus large.
Conclusion : fermer une cause avant une URL
Réduire le crawl inutile commence par la source de découverte et la génération, pas par une interdiction globale. L’inventaire relie chaque famille à une intention et à une réponse cible.
Les liens et sitemaps sont nettoyés avant que les 404, 410, redirections ou directives deviennent observables. Robots.txt intervient ensuite pour protéger un espace durablement inutile, jamais pour simuler une désindexation.
Un canari mesure URL distinctes, coût, réponses, déplacement et parcours. Il peut prouver une économie d’exploitation sans prouver encore un gain d’indexation ; nommer cette limite fait partie de l’excellence opérationnelle.
- Fermer le générateur avant de masquer les URL déjà produites.
- Nettoyer liens et sitemaps avant de juger la baisse des requêtes.
- Conserver un témoin et une règle de retour arrière pour chaque famille.
Pour construire l’inventaire, sécuriser les règles et piloter la mise en production, l’accompagnement Tech SEO et performance web de Dawap transforme un nettoyage risqué en séquence mesurable et réversible.
