Le point de départ est le formulaire de recherche présent sur presque tous les sites : celui qui permet à un visiteur de chercher un mot dans le contenu du site. Chaque requête produit une URL, généralement de la forme /search?q=fromage, et comme le nombre de requêtes possibles est illimité, le nombre d'URL l'est aussi. L'épisode nomme cela un espace d'exploration infiniZone d'un site où le nombre d'adresses générées est sans limite, chaque page menant à de nouvelles adresses que le robot peut suivre indéfiniment. : Googlebot découvre le formulaire, suit des liens vers des résultats de recherche, y trouve d'autres liens, et engendre « an endless loop of new URLs ».
Le mécanisme qui rend cela coûteux tient à la nature de ces pages. Contrairement à un article servi depuis un cache, une page de résultats interne est calculée à la volée : le serveur interroge la base de données et classe les résultats à chaque appel. L'épisode parle de « constant database lookups and ranking calculations » qui ralentissent le site pour les vrais utilisateurs. Le problème n'est donc pas seulement le budget d'explorationQuantité de pages qu'un robot d'indexation accepte de télécharger sur un site pendant une période donnée. gaspillé sur des URL sans valeur, c'est aussi la charge serveur.
Une partie de l'épisode est consacrée aux fausses solutions, et c'est là que se trouve le contenu le plus concret. L'outil de suppression de la Search ConsoleFonction de l'interface Google qui masque temporairement une adresse des résultats de recherche sans agir sur le téléchargement des pages par le robot. est écarté sans ambiguïté : il ne fait que filtrer temporairement l'affichage dans les résultats et « does not stop Googlebot from hammering your server ». Renvoyer un code 500Réponse par laquelle un serveur signale une erreur interne l'empêchant de fournir la page demandée. sur les URL de recherche pour décourager les robots est présenté comme contre-productif : selon l'épisode, cela « will backfire and reduce Googlebot's crawl rate across your entire website », donc pas uniquement sur les URL concernées.
S'ajoute un angle sécurité rarement mis en avant. Des acteurs malveillants lancent sur votre moteur interne des requêtes pharmaceutiques, pour adultes ou liées aux casinos, afin de profiter de la réputation de votre domaine et de faire apparaître leurs coordonnées dans l'index de Google. La page indexée est la vôtre, le contenu affiché est le leur. C'est un argument supplémentaire pour ne pas laisser ces URL indexables, indépendamment de toute considération d'exploration.
Côté mise en œuvre, la recommandation est d'écrire une règle large plutôt qu'une accumulation de règles fines : une seule directive avec caractère génériqueSymbole utilisé dans une règle pour représenter n'importe quelle suite de caractères et couvrir ainsi de nombreuses adresses d'un coup. dans le fichier robots.txtFichier placé à la racine d'un site qui indique aux robots quelles adresses ils ne doivent pas télécharger., du type /search?, couvrant l'ensemble des paramètres de requête, ce qui garde le fichier lisible. L'épisode oppose par ailleurs le blocage par robots.txt et la balise meta robots ou l'en-tête HTTP noindexInstruction placée dans le code d'une page ou dans la réponse du serveur qui demande à un moteur de ne pas faire figurer cette page dans ses résultats. en évoquant des compromis techniques distincts, mais le texte qui nous a été transmis se limite à mentionner cette opposition sans la développer : il ne permet pas de trancher entre les deux ni de restituer l'arbitrage exposé dans l'épisode.
Dernier point utile, la distinction entre pages de recherche et pages de catégorie. Certains systèmes, Blogger est cité, utilisent des paramètres de recherche pour construire leurs pages de tags. Une règle de blocage trop large peut donc emporter des pages qui ont une vraie valeur. La recommandation est de construire de véritables pages de catégorie, dédiées et à URL propre, au lieu de détourner le moteur interne pour en tenir lieu.
Enfin, l'épisode déconseille de s'en remettre aux systèmes automatiques de Google, qui tentent de reconnaître et de déprioriser les espaces infinis mais restent, selon les deux intervenants, lents et peu fiables. La configuration manuelle est présentée comme le choix sûr.