Comment empêcher l’indexation des pages de recherche interne PrestaShop ?

La page de recherche interne PrestaShop (`/recherche?controller=search`) génère une URL par requête tapée par vos visiteurs, sans jamais apporter de contenu utile à un moteur de recherche. La bloquer semble simple. C’est là que la plupart des guides, y compris certains bien intentionnés, posent un piège technique qui produit l’effet inverse de celui recherché.

Pourquoi la page de recherche interne pose problème

Chaque fois qu’un visiteur tape un mot dans la barre de recherche de votre boutique PrestaShop, le moteur génère une URL du type /recherche?controller=search&s=motclé. Sur un site avec un trafic conséquent, ça représente potentiellement des milliers d’URLs différentes, une par requête distincte, sans aucun contenu éditorial stable derrière.

Deux conséquences directes pour le référencement :

• Dilution du budget de crawl : Google passe du temps à explorer des pages qui ne méritent pas d’être indexées, au lieu de consacrer ce temps à vos fiches produit et vos catégories.
• Risque de contenu de faible qualité indexé : une page de résultats de recherche sans résultat, ou avec un contenu généré dynamiquement et peu structuré, n’a rien à faire dans l’index de Google.

Le piège qui rend le noindex inefficace

C’est le point que la plupart des tutoriels et des fils de forum n’expliquent jamais clairement, alors qu’il rend une bonne partie des configurations inefficaces sans que le propriétaire du site s’en rende compte.

La solution la plus recommandée dans les communautés PrestaShop consiste à bloquer /recherche dans le fichier robots.txt avec une ligne Disallow: /recherche. C’est intuitif, ça semble logique, et ça part d’une bonne intention. Le problème, c’est que cette méthode entre en contradiction directe avec la façon dont fonctionne réellement la balise noindex.

Concrètement, si vous bloquez /recherche dans le robots.txt ET que vous avez ajouté une balise noindex sur ces mêmes pages, vous obtenez le pire des deux mondes : Google ne peut plus lire votre balise noindex parce qu’il ne peut plus crawler la page. Si des liens externes (partages sur les réseaux sociaux, un autre site qui a linké une recherche par erreur) pointent vers une de ces URLs, Google peut malgré tout l’indexer à partir de ces signaux externes, sans jamais visiter la page elle-même. Résultat dans Google Search Console : le statut caractéristique « Indexée, bien que bloquée par le fichier robots.txt », qui laisse le propriétaire du site convaincu que son blocage fonctionne alors que c’est l’inverse qui se produit.

La méthode qui fonctionne réellement

Pour désindexer proprement une page déjà connue de Google, ou empêcher son indexation future, une seule règle compte : ne jamais bloquer via robots.txt une URL sur laquelle vous comptez sur le noindex. Les deux méthodes ne se combinent pas, elles s’excluent.

1. Ajouter la balise noindex directement dans le template

   Dans header.tpl du thème actif, une condition sur l’URL de la page (présence du paramètre de recherche, du tri, de la pagination, des filtres) permet d’injecter <meta name="robots" content="noindex, follow"> uniquement sur les pages concernées, sans toucher au reste du site.

2. Laisser la page accessible au crawl

   Ne pas ajouter de ligne Disallow correspondante dans le robots.txt tant que la désindexation n’est pas confirmée dans Search Console. C’est contre-intuitif, mais c’est la condition pour que Google voie et respecte la balise.

3. Utiliser « follow » et non « nofollow »

   La directive follow permet à Google de continuer à suivre les liens présents sur la page (vers vos fiches produit, par exemple), tout en excluant la page elle-même de l’index. Un nofollow couperait inutilement la transmission de ce maillage.

4. Bloquer le crawl seulement après confirmation

   Une fois que Search Console confirme que les pages sont sorties de l’index (statut « Exclue, balise noindex » pour chaque URL), il devient possible, mais pas obligatoire, d’ajouter un Disallow pour économiser du budget de crawl sur ces URLs à faible valeur.

Le rôle exact du robots.txt

Le robots.txt et le noindex ne servent pas le même objectif, et les confondre est à l’origine de la plupart des erreurs de configuration observées sur les boutiques PrestaShop :

Un dernier détail technique qui a son importance sur PrestaShop : ce blocage doit tenir compte des URLs réécrites. Si les URLs simplifiées (Préférences > SEO & URLs) ne sont pas activées, les motifs de reconnaissance des pages de recherche dans le template ou le robots.txt ne correspondront pas à la structure réelle des URLs générées, et le blocage ne s’appliquera tout simplement pas.

Comment vérifier que ça a marché

• Utiliser l’outil d’inspection d’URL de Google Search Console sur une page de recherche connue, et vérifier que Google y voit bien la directive noindex.
• Une extension de navigateur type « SEO Meta in 1 click » permet de vérifier en un clic la présence de la balise sur n’importe quelle page en navigation.
• Dans Search Console, la section « Pages » doit progressivement faire apparaître ces URLs sous le motif « Exclue par la balise noindex », pas sous « Bloquée par le fichier robots.txt » (ce second statut signale justement le piège décrit plus haut).

Le cas voisin des URLs à facettes

Le même mécanisme touche un problème cousin, souvent traité en même temps sur les boutiques PrestaShop : les URLs générées par les filtres à facettes (couleur, taille, prix, marque). Sur un catalogue de quelques centaines de produits avec seulement cinq attributs de filtre, le nombre de combinaisons possibles peut dépasser 10 000 URLs distinctes, presque toutes avec un contenu quasi identique à la page catégorie d’origine.

La différence de traitement recommandée : pour les facettes, une balise canonical pointant vers l’URL de catégorie propre est souvent préférable au noindex pur, parce qu’elle consolide la popularité de ces pages vers une seule URL de référence au lieu de simplement les exclure. Le noindex reste réservé aux combinaisons de filtres qui n’ont aucune valeur de recherche (tri par prix croissant, par exemple), tandis que les combinaisons avec un volume de recherche réel identifié (une couleur et une catégorie précises très recherchées) méritent parfois leur propre page statique optimisée plutôt qu’un simple canonical.

Questions fréquentes

En résumé

Empêcher l’indexation des pages de recherche interne PrestaShop n’est pas qu’une question d’ajouter une ligne dans un fichier : c’est une question d’ordre et de compatibilité entre deux mécanismes qui, combinés au mauvais moment, s’annulent mutuellement. La balise noindex doit être posée sur des pages restées accessibles au crawl, et le blocage robots.txt ne vient qu’après, une fois la désindexation confirmée dans Search Console.