Vous tapez site:votresite.com dans Google, et là, vous voyez débarquer /search?q=livraison, /recherche?q=prix, /?s=contact. Des dizaines de pages que vous n'avez jamais écrites, jamais relues, et qui se retrouvent indexées comme si c'était du contenu éditorial. Ça m'est arrivé sur un site client il y a deux ans : 214 pages de résultats de recherche internes dans l'index, contre à peine soixante vraies pages. Google avait mangé la moitié du budget de crawl pour archiver des requêtes que personne ne taperait jamais.
Le problème n'est pas cosmétique. Une page de recherche interne, c'est du contenu généré à la volée, souvent dupliqué, parfois vide, et qui n'a aucune raison de ranker. Bloquer ces pages à l'indexation, c'est à la fois de l'hygiène SEO et une question de contrôle sur ce que les moteurs gardent de votre site.
Points clés à retenir
- La directive noindex fonctionne pour les pages de recherche interne, mais à condition que Googlebot puisse toujours les explorer — sinon il ne verra jamais la consigne.
robots.txtempêche l'exploration, pas l'indexation. Un blocage via ce fichier peut au contraire geler une page déjà indexée.- Les paramètres d'URL (
?q=,?s=,?filter=) sont le vrai point de douleur : chaque combinaison crée une URL distincte. - La balise
noindexse place dans le<head>de la page, sous la forme<meta name="robots" content="noindex">. - Un
rel="canonical"mal posé sur une page noindex envoie des signaux contradictoires — évitez de cumuler les deux. - La Search Console offre un outil de suppression temporaire, mais il ne remplace pas une vraie directive.
Pourquoi vos pages de recherche interne polluent l'index (et ce que ça coûte vraiment)
Une page de recherche interne, c'est une URL qui se construit à partir des mots tapés par un visiteur. Vous avez donc autant d'URLs potentielles que de requêtes possibles — soit, en pratique, une infinité.
Sur le site client dont je parlais plus haut, le moteur de recherche interne générait une URL par combinaison de filtres : catégorie, prix, disponibilité, marque. On a compté plus de 4 000 URLs uniques rien qu'en naviguant manuellement pendant vingt minutes. Google n'en avait indexé que 214, mais ces 214 pages tiraient vers le bas la qualité moyenne perçue de tout le domaine.
Un contenu dupliqué et de faible valeur
Prenons une requête classique : /search?q=livraison. La page affiche une liste de résultats dont les titres, extraits et liens proviennent de vos propres pages produits. Le texte visible se résume souvent à « Résultats pour livraison » et à une pagination. Ce n'est pas du contenu, c'est un gabarit. Répété sur des centaines d'URLs, il crée une masse de pages quasi identiques aux yeux d'un moteur.
Le budget de crawl aspiré
Chaque site dispose d'un temps de passage limité de la part des robots. Quand des milliers d'URLs de recherche interne existent, les robots les visitent au détriment des pages que vous voulez réellement faire remonter. Les produits, les articles, les pages de catégorie passent après les résultats de recherche internes. C'est mécanique.
Et pour ceux qui se demandent si ça vaut le coup de s'en occuper : oui, et plutôt deux fois qu'une.
Bloquer l'indexation : la directive noindex, mode d'emploi concret
La méthode la plus fiable pour qu'une page de recherche interne ne se retrouve pas dans les résultats, c'est la directive noindex. Elle dit explicitement aux moteurs : explore la page si tu veux, mais ne la garde pas dans ton index.
Où se trouve la balise noindex ?
Dans le code source de la page, à l'intérieur de la section <head>. La ligne ressemble à ceci :
<meta name="robots" content="noindex, follow">
Le follow est volontaire : il autorise les robots à suivre les liens présents sur la page, ce qui est utile pour que les pages produits listées dans les résultats de recherche restent explorables. Si vous voulez tout couper, vous mettez noindex, nofollow.
Vous pouvez aussi passer par l'en-tête HTTP X-Robots-Tag: noindex, pratique quand vous ne contrôlez pas le HTML de la page — par exemple sur une réponse générée côté serveur. Le résultat est le même.
L'erreur que j'ai commise avec robots.txt
Au début, j'ai bloqué /search dans le robots.txt en pensant régler le problème. Ça n'a rien réglé du tout. Les pages déjà indexées sont restées dans l'index pendant des mois, parce qu'un robot qui ne peut pas explorer une page ne peut pas y lire la consigne noindex. C'est le paradoxe : en bloquant l'accès, on empêche Google de découvrir qu'on ne veut plus de la page.
La règle est simple : noindex d'abord, laissez la page explorable. Une fois la désindexation confirmée, vous pouvez ajouter le blocage robots.txt si vous voulez économiser du crawl. Dans cet ordre, pas l'inverse.
| Méthode | Effet sur l'exploration | Effet sur l'indexation | Quand l'utiliser |
|---|---|---|---|
noindex (balise ou en-tête) | Autorisée | Retrait de l'index | Pages de recherche, filtres, doublons |
robots.txt | Bloquée | Aucun retrait automatique | Uniquement après désindexation confirmée |
rel="canonical" | Autorisée | Consolidation des signaux | Variantes proches d'une même page |
| Suppression Search Console | — | Temporaire (quelques mois) | Urgence, fuite de données |
| Code 404/410 | Autorisée puis suppression | Retrait progressif | Page obsolète qu'on assume de perdre |
Paramètres d'URL : le vrai chantier des recherches à facettes
Le cœur du problème tient dans les paramètres. ?q= pour une recherche simple, ?s= sur WordPress, ?filter=, ?sort=, ?page= — chaque paramètre ajouté multiplie les combinaisons.
Déclarer les paramètres dans la Search Console
La Search Console permet de déclarer les paramètres d'URL que vous considérez comme inutiles. Pour un paramètre comme q, vous indiquez qu'il ne modifie pas le contenu de la page et qu'il sert uniquement à la recherche interne. Google en tient compte pour réduire l'exploration, mais ce n'est pas une garantie de désindexation. C'est un filtre de crawl, pas un interrupteur d'indexation.
Faut-il cumuler canonical et noindex ?
Franchement, non. Un rel="canonical" dit « considère cette page comme la version de référence », tandis qu'un noindex dit « ne garde pas cette page ». Les deux ensemble envoient un message contradictoire. Google choisit alors au cas par cas, et vous perdez le contrôle sur la décision.
Sur une page de recherche interne, partez sur le noindex pur. Le canonical est fait pour les variantes d'une page qui mérite d'exister, pas pour des résultats de requête.
Que faire des pages de recherche sans résultat ?
Une page /search?q=xyz qui ne renvoie rien est encore pire qu'une page pleine : elle est vide, souvent générée avec un message standard, et peut être indexée comme une page normale. Ces URLs sont à surveiller en priorité car les visiteurs les partagent parfois par erreur. Le noindex couvre ce cas, mais une bonne pratique consiste à renvoyer un code 404 ou 410 quand la requête ne produit aucun résultat — la page n'a alors plus de raison d'exister pour personne.
Une page de recherche interne est déjà indexée : comment la retirer
Vous avez mis en place la directive un peu tard, et la page traîne déjà dans l'index. Trois leviers, dans l'ordre.
- Vérifiez que la balise
noindexest bien présente et bien lue — unnoindexplacé après unrel="canonical"vers une autre page peut être ignoré. - Demandez une nouvelle exploration de la page via la Search Console pour accélérer la prise en compte de la directive. Sans nouvelle visite, la consigne reste lettre morte.
- Si c'est urgent, utilisez l'outil de suppression de la Search Console. Il masque temporairement l'URL des résultats pendant une période limitée, le temps que la directive fasse son effet. Ce n'est pas une solution permanente — c'est un pansement.
Sur le site client, la désindexation des 214 pages a pris entre trois et six semaines après la pose des directives. Plus long que ce que j'imaginais. Patience et surveillance dans la section « Pages » de la Search Console.
Comment appliquer ça concrètement sur WordPress et les autres CMS
Deux approches, selon votre niveau de contrôle sur le code.
- Par le thème ou un plugin : insérer
<meta name="robots" content="noindex">dans le<head>uniquement quandis_search()renvoie vrai. Sur WordPress, quelques lignes dans le fichierfunctions.phpsuffisent. - Par le serveur : ajouter une règle qui envoie l'en-tête
X-Robots-Tag: noindexpour toutes les URLs contenant/searchou?s=. Utile si vous ne voulez pas toucher au thème. - Un plugin SEO avec un onglet « Robots » par type de page peut aussi faire le travail, mais vérifiez toujours le rendu dans le code source. J'ai vu plus d'une extension envoyer un
index, followpar défaut qui écrasait la consigne.
Le réflexe à garder : après chaque modification, affichez le code source de la page et cherchez la balise. Si elle n'y est pas, aucune configuration ne sert à rien.
Une fois vos pages de recherche hors index
Le vrai bénéfice ne se voit pas tout de suite. Il apparaît quand vous ouvrez la Search Console trois mois plus tard et que vous constatez que vos vraies pages sont explorées plus souvent, que les rapports de couverture cessent d'afficher des dizaines de lignes « Explorée, non indexée » liées à des requêtes fantômes.
Reste une question à laquelle je n'ai pas de réponse définitive : faut-il vraiment laisser les visiteurs utiliser un moteur de recherche interne qui produit des URLs indexables ? D'autres solutions existent — recherche filtrée côté client, résultats non partageables — mais elles dégradent l'usage. Le compromis entre la qualité d'expérience pour l'utilisateur et la propreté de votre index n'est jamais confortable. C'est à vous de trancher, en fonction de ce que vous êtes prêt à laisser Google voir.
