Comment auditer les facettes PrestaShop avec un crawler SEO ?

Auditer les facettes d’une boutique PrestaShop avec un crawler semble simple : on lance Screaming Frog, on filtre les URL avec un point d’interrogation, on compte. Sauf qu’un crawl qui respecte le robots.txt vous cache la moitié du problème, parce que les règles de blocage empêchent le crawler de voir des URL qui sont pourtant indexées. La méthode fiable repose sur deux passes de crawl et un croisement avec les URL réellement dans l’index. Voici comment procéder.

Pourquoi une seule passe de crawl ne suffit pas

Soyons précis sur un point que la documentation Google rappelle mais que les guides d’audit oublient : le robots.txt bloque le crawl, pas l’indexation. Une URL de facette interdite par Disallow: /*?q= ne sera plus explorée, mais si Google la connaît déjà, ou la découvre par un lien externe, elle peut rester dans l’index, affichée avec la mention « indexée malgré le blocage par le fichier robots.txt ».

Conséquence directe pour l’audit : si votre crawler respecte le robots.txt de la boutique, il n’ouvrira jamais ces URL et votre rapport conclura « facettes sous contrôle » alors que Google en indexe des milliers. Il faut donc deux passes, et surtout la comparaison entre elles.

Préparer le crawler pour PrestaShop

Que vous utilisiez Screaming Frog, Sitebulb ou un équivalent, quelques réglages sont indispensables avant de lancer quoi que ce soit.

• Rendu JavaScript : activez-le si le module fonctionne en mode AJAX, sinon le crawler ne verra pas les liens de filtres injectés côté client.
• Extraction personnalisée : configurez l’extraction de la balise meta robots et de la balise link rel="canonical" pour chaque URL. C’est ce qui permettra de repérer les incohérences.
• Paramètres à surveiller : sur PrestaShop, les URL de facettes prennent la forme ?q=Attribut-Valeur en URL simplifiées, plus les paramètres ?order= et ?orderby= pour le tri et ?page= pour la pagination. Notez-les, vous filtrerez dessus.
• Limite de profondeur et d’URL : sur un gros catalogue, plafonnez le nombre d’URL de la première passe, sinon le crawl combinatoire n’en finit pas.

Passe 1 : cartographier toute la surface générée

Lancez un crawl en ignorant le robots.txt, en partant de la page d’accueil et des principales catégories, avec le suivi des liens internes activé. Objectif : découvrir toutes les URL que le module et le thème génèrent réellement, y compris celles que le robots.txt masque.

Un ratio parlant : sur un catalogue de 200 produits avec 5 attributs filtrables, la combinatoire dépasse facilement 10 000 URL quasi identiques. Si votre passe 1 en remonte quelques centaines, c’est que le thème lie peu de facettes ; si elle en remonte des milliers, le maillage interne alimente activement le problème.

Passe 2 : voir ce que voit Googlebot

Relancez le même crawl, cette fois en respectant le robots.txt et avec le user-agent Googlebot. Vous obtenez la surface réellement explorable par Google.

Le delta entre la passe 1 et la passe 2 est le coeur de l’audit :

Croiser avec les URL réellement indexées

Le crawl vous dit ce qui est accessible. Il ne vous dit pas ce qui est indexé. Trois sources pour l’index réel :

• Search Console, rapport Indexation des pages : exportez les URL indexées et filtrez sur ?q=, ?order=, ?page=. C’est la source la plus fiable.
• Opérateur site: avec un motif de paramètre, pour une estimation rapide et visuelle.
• Analytics, pages de destination organiques : les URL de facettes qui reçoivent des visites depuis Google sont, par définition, indexées et positionnées.

Importez ces listes dans le même tableur que vos deux passes de crawl. La jointure sur l’URL révèle les cas les plus graves : une facette indexée, qui reçoit du trafic, mais orpheline au crawl parce qu’aucun lien interne ne la pointe. Google la maintient dans l’index sans que vous puissiez la piloter par le maillage.

Les trois pathologies à isoler

1. Facettes indexées malgré le blocage robots.txtPrésentes dans l’export GSC des pages indexées, absentes de la passe 2. Le robots.txt les a coupées du crawl trop tôt, avant que Google n’ait pu lire un éventuel noindex. Elles stagnent dans l’index sans contenu à jour.
2. Facettes crawlables et indexables non maîtriséesVues dans les deux passes, en index,follow, souvent maillées depuis le thème. Elles consomment du budget de crawl, diluent le PageRank interne et créent des quasi-doublons de vos catégories.
3. Combinaisons à zéro résultatURL qui répondent 200 avec une page « aucun produit ». Google recommande explicitement de renvoyer un code 404 dans ce cas. Repérez-les via la passe 1 en croisant code HTTP 200 et absence de bloc produit dans le contenu extrait.

Le livrable d’audit

Cette démarche est le coeur d’un audit SEO technique de boutique PrestaShop. Un audit de facettes exploitable tient sur un onglet de tableur, une ligne par URL, avec les colonnes : URL, motif de paramètre, code HTTP, meta robots, canonical, présente en passe 1, présente en passe 2, indexée (GSC), trafic organique (oui/non), maillée depuis le thème (oui/non), pathologie identifiée, action recommandée. En face, une synthèse chiffrée : nombre d’URL de facettes générées, nombre crawlables, nombre indexées, nombre recevant du trafic, et la liste des facettes à valeur SEO réelle qu’il faudra au contraire conserver et travailler.

Cet inventaire est le préalable à toute décision de traitement. Le choix entre noindex, canonical ou blocage se prend URL par URL à partir de ce tableau, et la question de savoir quelles pages filtrées méritent d’être indexées se tranche sur les données de trafic et d’engagement, pas au doigt mouillé. L’ensemble s’inscrit dans une stratégie SEO des facettes cohérente, et les erreurs de pilotage du budget de crawl liées aux facettes sont détaillées dans notre article dédié aux erreurs de budget de crawl sur PrestaShop.

En pratique

Retenez la séquence : préparer le crawler avec l’extraction du meta robots et de la canonical, passe 1 en ignorant le robots.txt pour voir toute la surface, passe 2 en le respectant pour voir ce que Googlebot voit, export des URL indexées depuis la Search Console, jointure des trois sources dans un seul tableur. Le diagnostic sort du croisement, jamais d’une passe unique. Mener cet audit et prioriser les corrections est un travail d’expertise : je peux vous y aider, le détail est juste en dessous.