Recherche interne : Google n’exige plus de bloquer ces pages, mais le conseille toujours

Google ne demande plus de bloquer les pages de résultats du moteur de recherche interne d’un site, mais John Mueller le conseille toujours. Il l’a expliqué à Martin Splitt dans l’épisode 113 du podcast Search Off the Record, mis en ligne le 30 juillet 2026. Search Engine Roundtable a relevé ce passage le 31 juillet.

L’essentiel

• Les règles actuelles de Google ne demandent plus de bloquer les pages de recherche interne, alors que les anciennes Webmaster Guidelines le faisaient.
• Pour Google, laisser indexer ces pages n’est pas du spam, seulement un manque d’efficacité.
• Une recherche interne indexable expose le site au spam, jusqu’à un possible signalement « piraté » dans la Search Console.
• John Mueller juge le robots.txt plus simple et le noindex « presque plus propre » (traduction).

Une consigne des Webmaster Guidelines disparue des règles actuelles

Selon Search Engine Roundtable, Google avait ajouté cette consigne en 2007. John Mueller s’en souvient avec quelques précautions : à l’époque des Webmaster Guidelines, ces pages étaient rangées, « je crois » (traduction), parmi les contenus générés automatiquement ou les « espaces infinis », et Google recommandait de les bloquer. Aujourd’hui, « nous ne l’avons plus dans nos règles de recherche » (traduction), constate-t-il. Search Engine Roundtable y voit les Search Essentials, qui ont pris la suite des anciennes consignes. La page des règles de Google sur le spam ne cite d’ailleurs ni la recherche interne ni les espaces infinis. La date du retrait, elle, n’est connue ni par Google ni par Search Engine Roundtable.

Le retrait a une portée limitée. Google ne considère pas un site comme du spam parce que ses pages de résultats internes sont indexées. « Vous êtes simplement très inefficace » (traduction), résume John Mueller. Il fait le parallèle avec les calendriers : aucune règle de qualité n’interdit d’en publier un consultable jusqu’en 2099. Le choix revient au site.

Charge serveur : un nombre infini d’URL à explorer

Il conseille malgré tout de bloquer ces pages, « purement pour des raisons techniques » (traduction). Un moteur interne peut produire une URL par requête, et certaines pages de résultats renvoient vers 10 ou 20 autres requêtes suggérées. En suivant ces liens, Googlebot tombe dans un espace sans fin. Le budget de crawl y passe, et le serveur encaisse la charge. Ces pages sont rarement mises en cache, rappelle John Mueller : à chaque visite, le site doit interroger sa base de données puis classer les résultats. Martin Splitt ajoute que le site peut alors ralentir pour les vrais visiteurs.

Google essaie de repérer ces motifs pour les explorer en priorité plus basse. Aucun message de la Search Console ne prévient pourtant le site, et la détection automatique peut prendre un certain temps.

Spam : le site fabrique lui-même les pages

Le second risque touche la qualité. N’importe qui peut taper une requête sans rapport avec le site. Si la page de résultats reprend ces mots, par exemple dans un grand titre, et reste indexable, le site se retrouve avec des pages sur des casinos, des médicaments ou des contenus pour adultes, souvent avec un numéro de téléphone. Personne n’a piraté le site, souligne John Mueller : il produit ces pages tout seul, « librement » (traduction).

Des spammeurs exploitent la faille à grande échelle. Ils repèrent les CMS courants dont les pages de recherche ne sont pas bloquées, puis placent des liens vers des milliers de sites et des millions de pages. Google peut alors signaler le site comme piraté dans la Search Console. Ses algorithmes peuvent aussi écarter une partie de ces requêtes, sans les attraper toutes. Et la détection n’a rien d’immédiat : « peut-être que ça prend un mois » (traduction), dit John Mueller.

Un cas proche a été traité ici le 25 juillet. Un marchand Shopify voyait des URL de recherche spammées dans l’index malgré une règle Disallow: /search. En examinant un site comparable, John Mueller avait trouvé une section dédiée à Googlebot dans le robots.txt, qui annulait les règles générales.

robots.txt ou noindex : deux méthodes, deux limites

La première méthode est une règle Disallow dans le robots.txt. John Mueller la juge « probablement la plus simple » (traduction), d’autant qu’un fichier robots.txt se modifie facilement sur WordPress, Drupal ou Joomla. Il recommande une seule règle large, qui couvre tout le motif (le chemin de recherche suivi d’un paramètre d’URL), plutôt qu’une série de règles fines, plus difficiles à maintenir. La seconde méthode est une directive noindex, dans une balise meta robots ou dans un en-tête HTTP. Elle évite qu’une URL bloquée par le robots.txt apparaisse quand même dans les résultats, un cas qu’il juge très improbable. En contrepartie, Google continue d’explorer la page pour lire la directive.

Trois autres pistes sont écartées. L’outil de suppression de la Search Console masque les URL dans les résultats, mais n’empêche pas Google de les explorer. Un code 404 reste possible, sans être très propre selon lui, car il peut poser des problèmes de cache à certains utilisateurs. Renvoyer une erreur 500 est à proscrire : Google en déduit que le serveur sature et réduit l’exploration du site entier.

John Mueller cite enfin Blogger, qui sert ses pages de libellés à partir de pages de recherche. Il suggère de trouver un motif d’URL qui distingue les deux, pour bloquer les vraies recherches et garder les pages de catégorie, qu’il considère comme très utiles à l’exploration. Plutôt que d’ouvrir quelques recherches à l’indexation par une exception dans le robots.txt, il conseille de créer de vraies pages de catégorie.

Ce que j’en retiens

Pour moi, ce retrait ne change rien à la pratique : une recherche interne indexable reste une faille, consigne écrite ou pas. Le point à respecter, c’est l’ordre des opérations. Une règle Disallow empêche Googlebot de lire le noindex des pages bloquées, donc poser les deux en même temps sur des URL déjà indexées ne sert à rien. Si des pages de recherche spammées remontent déjà dans une requête site:, je commencerais par le noindex, puis je suivrais la sortie de ces URL dans le rapport d’indexation de la Search Console. Une fois l’index nettoyé, la règle robots.txt arrête le crawl.

Sur un site neuf, une règle Disallow dès la mise en ligne suffit, et John Mueller conseille justement de la mettre par défaut. Dans tous les cas, vérifiez que la règle figure dans chaque groupe user-agent, y compris une éventuelle section Googlebot, et que le chemin de recherche n’a pas changé après l’installation d’un service de recherche tiers.