Un site Shopify se faisait indexer des URLs de recherche spammy malgré un robots.txt qui les interdisait. John Mueller a répondu sur Reddit, identifié l’erreur dans le fichier, et expliqué la règle de priorité qui piège beaucoup de SEO. Voici ce qu’il faut retenir, et comment s’en protéger.
Le contexte : spam de barre de recherche
Les spammeurs ont une technique simple : ils tapent des requêtes dans ta barre de recherche interne, en y glissant un nom de marque ou un lien. Le moteur génère alors une URL unique pour cette recherche, et cette URL peut être crawlée et indexée par Google.
Résultat : des pages comme /search?q=casino-en-ligne ou /search?q=achat-viagra apparaissent dans ton index Google. C’est mauvais pour ton EEAT, ton budget de crawl, et la perception de ton site.
Le propriétaire du site Shopify concerné avait ajouté /search en Disallow dans son robots.txt. Google continuait quand même à indexer ces pages. Puis le client avait mis en place des redirections vers d’autres collections. La question posée sur Reddit était : faut-il plutôt renvoyer une 404 ?
Mueller a répondu, mais surtout il a identifié la vraie cause du problème, bien plus utile que la question posée.
La règle de priorité robots.txt que tu rates probablement
Voici l’explication de Mueller, rapportée par Search Engine Journal :
« Avec robots.txt, les règles les plus spécifiques l’emportent. Si tu as une section
user-agent: Googlebot, Google utilisera uniquement cette section. Si tu veux appliquer aussi les règles de la sectionuser-agent: *, tu dois les copier. »
Concrètement : si ton fichier robots.txt contient deux blocs distincts, l’un pour user-agent: Googlebot et l’autre pour user-agent: *, Google applique seulement le bloc Googlebot. Il ignore complètement le bloc générique.
C’est exactement ce qui s’était passé. Le Disallow: /search était dans le bloc user-agent: *. Le bloc user-agent: Googlebot, lui, ne contenait pas cette directive. Google a donc suivi ses règles spécifiques, et crawlé les pages /search librement.
La structure qui cause le bug
User-agent: Googlebot
Disallow: /admin
User-agent: *
Disallow: /search
Disallow: /privateDans cet exemple, Google ignore la seconde section entièrement. Il crawle /search et /private sans problème. Seul /admin est bloqué pour Googlebot.
La structure correcte
Deux options :
Option 1 : répliquer les règles dans chaque bloc
User-agent: Googlebot
Disallow: /admin
Disallow: /search
Disallow: /private
User-agent: *
Disallow: /admin
Disallow: /search
Disallow: /privateOption 2 : lister plusieurs user-agents pour un bloc commun
User-agent: Googlebot
User-agent: Bingbot
User-agent: *
Disallow: /search
Disallow: /privateMueller cite explicitement cette deuxième syntaxe. Elle est plus propre et évite les doublons.
C’est une règle documentée dans la spécification officielle du protocole robots.txt, mais elle est souvent oubliée, surtout quand on modifie un fichier existant sans en relire la structure complète.
Ce que ça change pour toi
Si tu as ajouté des règles personnalisées pour Googlebot (pour bloquer un dossier spécifique, gérer le crawl d’images, etc.), et que tu t’appuies sur un bloc user-agent: * pour le reste, toutes tes règles génériques sont probablement ignorées par Google.
Concrètement, ça peut vouloir dire que :
- des pages sensibles que tu croyais bloquées sont crawlées
- ton budget de crawl est gaspillé sur des URLs inutiles
- des pages de recherche interne ou de filtres facettes apparaissent dans l’index
C’est le genre d’erreur qu’on détecte rarement sans audit ciblé. Si tu veux aller plus loin sur la lecture des signaux d’indexation, l’article sur les pages non indexées et la qualité est un bon complément.
Robots.txt ne contrôle pas l’indexation
C’est un point que Mueller et l’équipe Google répètent régulièrement, et qui reste mal compris.
robots.txt contrôle le crawl, pas l’indexation.
Une page bloquée en robots.txt peut quand même apparaître dans l’index Google si elle reçoit des backlinks. Google sait qu’elle existe même s’il ne peut pas la crawler. Il peut donc l’afficher dans les SERP, parfois sans titre ni description.
Pour contrôler l’indexation, la bonne directive est noindex, placée dans la balise <meta name="robots"> du <head> de la page, ou dans l’en-tête HTTP X-Robots-Tag.
Et là, paradoxe : pour que Google lise un noindex, il faut qu’il puisse crawler la page. Si tu bloques la page en robots.txt ET que tu mets un noindex, Google ne verra jamais le noindex.
Donc pour exclure des pages de l’index : ne pas bloquer en robots.txt, mais ajouter noindex directement dans la page.
Solutions concrètes pour le spam de barre de recherche
Sur Shopify
Shopify permet d’ajouter un noindex conditionnel directement dans le fichier theme.liquid. Il suffit de coller ce code dans la section <head> :
{% if template contains 'search' %}
<meta name="robots" content="noindex">
{% endif %}Cette méthode est plus fiable que robots.txt pour les raisons expliquées ci-dessus. Les pages de recherche restent crawlables (Google peut lire le noindex), mais elles ne sont pas indexées.
Sur WordPress
C’est encore plus simple. Les plugins Yoast SEO, Rank Math et AIOSEO appliquent automatiquement noindex sur les pages de résultats de recherche interne. C’est activé par défaut.
Si tu utilises Divi ou certains thèmes équivalents, le moteur de recherche interne peut aussi être configuré pour ne pas générer d’URLs uniques pour les requêtes vides ou sans résultats.
La gestion des canonicalisations et des directives robots est un sujet étroitement lié si tu veux aller plus loin sur les signaux que Google suit vraiment.
Mon avis
L’erreur identifiée par Mueller est réelle et sous-estimée. La plupart des robots.txt de sites avec des règles personnalisées ne sont jamais relus dans leur globalité. On empile des directives sans vérifier les interactions entre blocs. Le résultat : des pages qu’on croyait bloquées sont crawlées librement.
Mon conseil pratique : ouvre ton robots.txt, cherche si tu as à la fois un bloc user-agent: Googlebot et un bloc user-agent: *. Si oui, vérifie que toutes tes directives importantes sont bien dupliquées dans le bloc Googlebot, ou fusionne les blocs. C’est dix minutes de vérification qui peuvent éviter des semaines de nettoyage d’index.
Si tu veux muscler ta pratique SEO technique en 2026, j’ai compilé un guide sur le nouveau stack SEO avec LLM et scripts Python qui peut t’aider à automatiser ce type d’audit. Et si tu cherches un accompagnement plus structuré, c’est aussi ce qu’on fait chez mon agence AskOptimize.
FAQ
Pourquoi Google indexe des pages bloquées dans mon robots.txt ?
Deux raisons possibles. La première : tu as un bloc user-agent: Googlebot dans ton robots.txt, et tes règles génériques user-agent: * sont ignorées par Google. La seconde : robots.txt ne contrôle que le crawl. Google peut connaître l’existence d’une page via des backlinks et l’indexer même sans la crawler.
Quelle est la différence entre robots.txt et noindex ?
robots.txt dit aux robots s’ils peuvent crawler une URL. noindex dit à Google de ne pas inclure cette page dans son index. Pour exclure une page de l’index, noindex est plus fiable. Mais Google doit pouvoir crawler la page pour lire le noindex, donc il ne faut pas la bloquer simultanément en robots.txt.
Comment vérifier que mes règles robots.txt s’appliquent bien à Googlebot ?
Utilise l’outil de test robots.txt dans Google Search Console. Tu peux simuler l’accès d’un user-agent spécifique (Googlebot, Googlebot-Image, etc.) à n’importe quelle URL de ton site et voir quelle règle s’applique.
Mon site WordPress est-il protégé du spam de recherche par défaut ?
Si tu utilises Yoast, Rank Math ou AIOSEO, oui : ces plugins appliquent noindex sur les pages de résultats de recherche interne par défaut. Vérifie quand même dans les paramètres que cette option n’a pas été désactivée manuellement.
Faut-il renvoyer une 404 sur les URLs de recherche spammy déjà indexées ?
Non, pas forcément. Une 404 fera disparaître la page de l’index, mais ce n’est pas la priorité. La priorité est d’empêcher les nouvelles URLs de s’indexer, via noindex. Pour les URLs déjà indexées, une 404 ou un noindex fonctionnent tous les deux. Évite la redirection vers une autre page de collection : ça transfère le problème sans le régler.
