Un catalogue PrestaShop peut compter plusieurs dizaines de milliers d’URLs entre les fiches produit, les catégories, les filtres et les variantes. Google n’en explore et n’en indexe qu’une fraction, et c’est rarement la bonne. Voici comment reprendre la main sur le crawl et l’indexation de votre boutique, avec les réglages natifs et les vérifications qui font vraiment la différence.
Sommaire
- Pourquoi l’indexation pose un problème spécifique sur PrestaShop
- Le crawl budget : ce que Google alloue réellement à votre catalogue
- Facettes, tris, pagination : dompter les paramètres d’URL
- Sitemap XML et réglages natifs « SEO & URLs »
- Lire le rapport de couverture de Search Console comme un diagnostic
- Produits hors stock, désactivés, supprimés : éviter les soft 404
- Questions fréquentes
Pourquoi l’indexation pose un problème spécifique sur PrestaShop
Un site vitrine génère quelques centaines d’URLs. Une boutique PrestaShop en génère des dizaines de milliers dès qu’on additionne les combinaisons de filtres, les déclinaisons produit, les pages de tri et les URLs multi-boutiques ou multilingues. Le CMS n’a pas été pensé nativement pour limiter cette explosion : il la produit par défaut, et c’est à vous de la canaliser.
La conséquence directe : Googlebot passe une partie de son temps de crawl sur des URLs sans valeur (variantes de filtre, pages vides, doublons de fiche produit) au lieu de vos pages stratégiques. Résultat classique dans le rapport de couverture : des milliers de pages « détectées, actuellement non indexées » alors que vos meilleures fiches produit stagnent en indexation partielle. Ce n’est pas une fatalité du CMS, c’est un chantier de configuration précis.
Donnée fraîche
Aucun des guides généralistes PrestaShop ne traite en profondeur le sujet de l’indexation propre à ce CMS : la majorité des ressources publiques couvrent les balises, les URLs et la vitesse, mais laissent de côté le crawl budget, les paramètres d’URL et la lecture du rapport de couverture. C’est précisément là que se jouent la plupart des pertes de trafic sur les catalogues volumineux.
Le crawl budget : ce que Google alloue réellement à votre catalogue
Le crawl budget, c’est le nombre de pages que Googlebot accepte d’explorer sur votre domaine dans un laps de temps donné. Il dépend de deux facteurs : la limite de capacité de crawl (votre serveur répond-il vite et sans erreur) et la demande de crawl (Google juge-t-il vos pages suffisamment intéressantes pour y revenir). Sur une boutique de quelques centaines de références, le sujet est secondaire. Sur un catalogue de plusieurs milliers de produits avec déclinaisons, il devient central.
Trois leviers concrets pour ne pas gaspiller ce budget sur PrestaShop :
- Limiter la profondeur d’arborescenceGardez vos catégories et sous-catégories à trois niveaux maximum depuis la page d’accueil. Au-delà, les fiches produit deviennent difficiles à atteindre pour le crawl et perdent en fréquence de visite.
- Bloquer les zones sans valeur SEOPanier, tunnel de commande, recherche interne, compte client : ces URLs n’ont rien à faire dans l’index. Un `robots.txt` propre et des balises `noindex` sur les pages concernées évitent qu’elles consomment du crawl.
- Prioriser les pages qui convertissentRenforcez le maillage interne vers vos catégories et produits les plus rentables : plus une page reçoit de liens internes, plus elle est visitée souvent par Googlebot.
Facettes, tris, pagination : dompter les paramètres d’URL
C’est le piège le plus fréquent sur PrestaShop, et le moins bien traité dans la documentation grand public. Chaque combinaison de filtre (couleur, taille, prix, marque) génère une URL potentiellement crawlable. Sur un catalogue de 2 000 produits avec 5 filtres actifs, le nombre de combinaisons théoriques dépasse largement la centaine de milliers d’URLs. Sans contrôle, Google explore une partie de ce bruit au détriment de vos pages utiles.
| Type de paramètre | Exemple d’URL | Traitement recommandé |
|---|---|---|
| Filtre attribut (couleur, taille) | ?couleur=rouge | Bloquer via robots.txt ou noindex si combinaison à faible volume de recherche |
| Filtre prix | ?prix-min=10&prix-max=50 | Exclure du crawl, canonical vers la page catégorie mère |
| Tri (popularité, prix croissant) | ?orderby=price&orderway=asc | Canonical vers l’URL sans tri, jamais d’indexation propre |
| Pagination | ?p=3 | Laisser crawlable mais non indexé, lier proprement en rel next/prev logique |
La configuration se fait à trois niveaux complémentaires : le module de navigation à facettes en back-office (choisissez pour chaque attribut s’il doit être « suivi et indexé », « suivi non indexé » ou « bloqué »), le `robots.txt` pour les paramètres qui ne doivent jamais être explorés, et l’outil « Paramètres d’URL » de Search Console en dernier recours pour les cas résiduels. Ne comptez pas sur la seule balise canonical pour absorber le problème : elle indique une préférence, elle ne garantit pas que Google respecte le signal, surtout si le maillage interne pointe massivement vers les URLs filtrées.
Sitemap XML et réglages natifs « SEO & URLs »
PrestaShop dispose d’un module natif (Réglages SEO & URLs) qui reste sous-exploité sur la majorité des boutiques que j’audite. Trois réglages à vérifier en priorité :
Les URLs doivent être lisibles (nom du produit, pas d’identifiant numérique brut) et cohérentes entre boutiques si vous êtes en multi-boutique.
Après un changement de nom de catégorie ou de règle d’URL, utilisez la fonction « Générer un fichier d’URLs » puis réindexez pour éviter les 404 en cascade.
Le sitemap doit exclure les URLs de filtre, de tri et les fiches produit désactivées, et être régénéré à chaque ajout ou retrait significatif de références.
Sur une boutique multi-boutique ou multilingue, chaque vitrine doit avoir son propre sitemap soumis séparément dans Search Console, avec des hreflang cohérents si les langues partagent le même catalogue. Un sitemap unique mélangeant plusieurs boutiques ou langues brouille le signal envoyé à Google et complique le diagnostic en cas de problème.
Lire le rapport de couverture de Search Console comme un diagnostic
Le rapport de couverture (menu Indexation > Pages) est l’endroit où se révèlent les vrais problèmes d’un catalogue PrestaShop. Trois lignes méritent une attention particulière :
Points de vigilance
« Détectée, actuellement non indexée » en grand nombre signale souvent un excès de pages à faible contenu (fiches produit vides, variantes redondantes) plutôt qu’un problème technique. « Dupliquée, Google a choisi une URL canonique différente de celle de l’utilisateur » indique que vos balises canonical ne sont pas respectées, généralement à cause d’un maillage interne qui contredit le signal. « Explorée, actuellement non indexée » sur des pages produit stratégiques doit déclencher un audit de contenu et de maillage en priorité.
Ne vous arrêtez pas au chiffre global. Segmentez par type de page (catégories, produits, pages CMS) via le filtre d’URL de Search Console : un taux d’indexation correct sur les catégories peut masquer un taux catastrophique sur les fiches produit, qui sont pourtant vos pages de conversion.
Produits hors stock, désactivés, supprimés : éviter les soft 404
C’est un point structurellement mal géré par défaut sur PrestaShop. Un produit désactivé ou en rupture prolongée continue souvent de répondre en HTTP 200 avec une page quasi vide, ce que Google interprète comme un soft 404 : la page reste techniquement accessible mais n’a plus de contenu utile à indexer.
- Rupture temporaireGardez la fiche en ligne avec une date de réassort si possible, et proposez des produits similaires : ne désactivez pas une page qui continue de recevoir du trafic et des liens externes.
- Arrêt définitifRedirigez en 301 vers la catégorie parente ou un produit de remplacement pertinent. Une suppression sèche sans redirection fait perdre le jus SEO accumulé par la fiche.
- Produit jamais destiné à revenirRenvoyez un vrai 410 (Gone) plutôt qu’un 404 générique : le signal est plus net pour Google et accélère la désindexation propre.
Vérifiez également les pages CMS et catégories vides créées automatiquement par certains modules ou thèmes : elles s’accumulent silencieusement et diluent votre budget de crawl sans jamais générer de trafic.
Indexation PrestaShop : un chantier de configuration, pas de contenu
La plupart des recommandations SEO génériques pour PrestaShop portent sur les balises, les images et le contenu des fiches produit. C’est utile, mais insuffisant si le crawl et l’indexation ne sont pas maîtrisés en amont : un contenu parfait sur une page que Google n’explore jamais ne sert à rien. Reprendre la main passe par la configuration native du module SEO & URLs, un traitement rigoureux des paramètres de filtre, un sitemap propre et une lecture régulière du rapport de couverture.
Sur un catalogue de plusieurs milliers de références, ce travail demande du temps et une méthode outillée : c’est exactement ce que je mets en place lors d’un audit SEO PrestaShop complet, avant de passer à la phase de correctifs priorisés.
Pourquoi mes fiches produit PrestaShop restent-elles « non indexées » sur Search Console ?
Le plus souvent parce qu’elles sont jugées trop proches de variantes déjà indexées (contenu dupliqué) ou que le maillage interne ne leur envoie pas assez de signaux de priorité. Un excès de pages à faible contenu dans le même lot peut aussi entraîner Google à ignorer des pages valables par association.
Faut-il bloquer toutes les URLs de filtre au crawl ?
Non par défaut. Une combinaison de filtre à fort volume de recherche (par exemple une couleur très demandée) peut mériter d’être indexable et optimisée comme une vraie page. Le blocage systématique doit viser les combinaisons à faible ou nul volume de recherche, qui ne servent qu’à générer du bruit.
Combien de temps Google met-il à refléter une correction d’indexation sur PrestaShop ?
Comptez plusieurs semaines pour un site au budget de crawl limité, parfois plus vite si le domaine a une bonne fréquence de visite de Googlebot. La demande d’indexation manuelle via Search Console accélère le traitement d’URLs isolées, mais ne remplace pas une correction structurelle sur un catalogue entier.
Le sitemap XML natif de PrestaShop suffit-il tel quel ?
Rarement sans ajustement. Par défaut, il peut inclure des URLs de filtre, des produits désactivés ou des doublons multi-boutique. Il doit être vérifié et nettoyé régulièrement, en particulier après une opération de merchandising importante (soldes, nouvelle collection).
Un audit de crawl est-il vraiment nécessaire pour une petite boutique PrestaShop ?
Moins urgent en dessous de quelques centaines de références sans navigation à facettes complexe. Le sujet devient prioritaire dès que le catalogue dépasse le millier de produits ou que plusieurs filtres attributs sont actifs simultanément.
À propos de l’auteur
Aymeric Maingé
Consultant SEO senior avec plus de 10 ans d’expérience, côté agence et annonceur. J’accompagne des boutiques PrestaShop et des sites e-commerce sur des problématiques de crawl, d’indexation, de navigation à facettes et de structuration technique du catalogue. Mon approche croise audit terrain, priorisation métier et recommandations actionnables pour les équipes marketing et IT. Découvrez mon profil de consultant SEO Prestashop.
Méthodologie utilisée
Cette analyse s’appuie sur l’observation de rapports de couverture Search Console réels de boutiques PrestaShop, sur la documentation officielle du module SEO & URLs et sur les retours de terrain issus d’audits menés sur des catalogues de tailles variées. Les recommandations privilégient systématiquement les réglages natifs du CMS avant tout module tiers, pour limiter la dette technique.