Quelles pages PrestaShop doivent être indexées, désindexées ou bloquées ?

Une boutique PrestaShop génère toujours plus d’URLs que de pages utiles : catégories, produits, variantes, filtres, recherche interne, panier. Faut-il tout indexer, tout bloquer, ou faire le tri ? La réponse dépend du TYPE de page, pas d’une règle unique, et un cas précis change tout dans un catalogue qui bouge : que faire d’une fiche produit qui n’existe plus.

La règle de base : ce que Google doit voir, ce qu’il ne doit jamais voir

Soyons précis avant d’entrer dans le détail.

Indexer et bloquer : deux leviers différents

Indexer, c’est autoriser Google à afficher la page dans ses résultats. Bloquer (via robots.txt), c’est lui interdire de l’explorer. Ce sont deux leviers différents, souvent confondus, et leur combinaison mal maîtrisée produit le statut le plus fréquent en Search Console sur PrestaShop : « Indexée, bien que bloquée par le fichier robots.txt ».

Le principe général

Google doit voir et indexer tout ce qui a une valeur commerciale ou éditoriale réelle pour un visiteur qui arrive depuis une recherche (catégories, produits, pages CMS) ; il ne doit ni indexer ni, dans la plupart des cas, explorer ce qui n’est qu’un artefact technique du moteur PrestaShop (tri, pagination avancée, recherche interne, comparateur, panier).

Le tableau de décision, page par page

Ce tableau synthétise l’arbitrage sur les types de page qu’une boutique PrestaShop génère. Il sert de fil conducteur au reste de l’article.

Catégories et fiches produit actives : indexables par défaut

Catégories : un signal de structure

Google construit sa compréhension d’une boutique d’abord par les catégories, qui structurent le catalogue, avant de descendre au niveau produit. Une catégorie vide ou avec un seul produit reste un signal faible : mieux vaut la fusionner ou la masquer temporairement du menu plutôt que de la laisser indexée sans contenu.

Fiches produit : l’enjeu du contenu dupliqué

Sur les fiches produit, l’enjeu numéro un reste le contenu dupliqué entre références proches (même produit, déclinaison de couleur) : c’est le sujet développé en détail dans l’article sur les causes de non-indexation des fiches produit, avec la question spécifique des variantes traitée à part.

Rupture de stock ou produit discontinué : deux décisions différentes

C’est le point que les guides génériques PrestaShop n’isolent presque jamais, alors qu’il concerne potentiellement des centaines de références sur un catalogue actif : une fiche produit qui n’est plus disponible n’appelle pas UNE réponse, mais deux réponses opposées selon la nature de l’indisponibilité.

Rupture de stock temporaire : ne touchez à rien

Si le produit sera réapprovisionné, la page ne doit ni disparaître, ni passer en noindex, ni rediriger. Désindexer une page qui va redevenir active fait perdre l’historique de positionnement acquis, et Google la retraite alors comme une page neuve au retour du stock. La bonne pratique consiste à garder la page en ligne, indexée, avec une mention claire de la date de retour si elle est connue, et idéalement des produits similaires suggérés pour ne pas perdre le visiteur qui arrive dessus.

Discontinuation définitive : l’arbitrage se joue sur le trafic et les backlinks

Quand le produit ne reviendra jamais, la question devient : la page a-t-elle une valeur SEO acquise (trafic organique réel, backlinks externes) ? Si oui, une redirection 301 vers la catégorie parente ou vers un produit de remplacement direct transmet cette valeur ; si non, un code 410 (Gone) est préférable à un simple 404, car il indique explicitement à Google que la suppression est définitive et accélère la désindexation, alors qu’un 404 seul peut laisser l’URL trainer en index pendant plusieurs mois. Le piège à éviter absolument : rediriger en masse tous les produits supprimés vers la page d’accueil ou une catégorie sans rapport. Google traite ces redirections non pertinentes comme des soft 404 et cesse de transmettre le moindre poids SEO à travers elles.

Pages filtrées et navigation à facettes : bloquer ou noindex ?

La navigation à facettes (filtrer par couleur, taille, prix, marque) est la première cause d’explosion du nombre d’URLs sur PrestaShop : quelques milliers de produits peuvent générer plusieurs centaines de milliers de combinaisons théoriques. La règle : ces pages ne doivent JAMAIS être indexées, mais leur exploration ne doit pas non plus être bloquée sans discernement, car Google a besoin de les crawler au moins une fois pour lire la balise noindex qu’elles portent. Bloquer trop tôt via robots.txt produit exactement la contradiction déjà documentée sur ce blog : robots.txt et noindex qui se neutralisent mutuellement. La méthode qui fonctionne dans la durée est en deux temps, détaillée dans l’article sur la gestion du noindex sans bloquer l’exploration : noindex seul jusqu’à confirmation de la désindexation en Search Console, robots.txt en relais seulement ensuite. Sur un catalogue volumineux, l’ampleur réelle de cette combinatoire se mesure avec la méthode exposée dans l’analyse du budget de crawl sur gros catalogue.

Recherche interne, panier, compte : bloquer systématiquement

Ces pages n’ont aucune valeur pour un visiteur qui arrive depuis une recherche Google : résultats de recherche interne, panier, tunnel de commande, compte client, comparateur de produits. Elles doivent être exclues du crawl via un fichier robots.txt correctement configuré, sans quoi elles consomment un budget de crawl qui devrait aller aux pages commerciales. Attention à la formulation des règles : un `Disallow` trop large sur `/recherche` ou `/panier` peut, selon la structure d’URL de votre thème, capturer par erreur des pages légitimes ; testez chaque règle avec l’outil de test robots.txt de Search Console avant de la mettre en production.

Comment vérifier vos choix dans Search Console

Une fois les règles posées, la vérification se fait en trois temps.

1. Le rapport Pages de Search Console

Il permet de confirmer que les catégories et produits actifs sont bien dans « Indexée ».

2. L’outil d’inspection d’URL

Il sert à tester ponctuellement une page filtrée ou un produit discontinué.

3. Le contrôle du sitemap XML

Il permet de s’assurer que le sitemap ne contient que des URLs indexables. Un sitemap qui liste encore des pages filtrées ou des produits en 410 envoie un signal contradictoire à Google. Sur PrestaShop, la structure et la mise à jour de ce fichier sont couvertes dans l’article dédié au sitemap XML.

Si des pages qui devraient être indexées apparaissent en « Découverte, actuellement non indexée », le diagnostic complet est détaillé dans l’article sur ce statut spécifique de Search Console.

En résumé

La question « indexer, désindexer ou bloquer » n’a pas une seule réponse sur PrestaShop : elle dépend du type de page, et surtout de sa situation réelle plutôt que de son apparence. Le cas le plus mal traité reste la distinction entre rupture temporaire (on ne touche à rien) et discontinuation définitive (301 ou 410 selon le trafic et les backlinks) : deux décisions opposées pour deux situations qui se ressemblent en surface mais n’ont rien à voir sur le plan SEO.