Comment détecter les problèmes de canonicalisation sur Prestashop avec Screaming Frog ?

Sur un catalogue PrestaShop de quelques centaines ou milliers de références, vérifier les canonicals fiche par fiche n’a aucun sens. Screaming Frog fait ce travail en quelques minutes, à condition de savoir quoi chercher : les filtres génériques de l’outil ne connaissent rien des bugs propres à PrestaShop, c’est à vous de les croiser avec ce que la plateforme fait réellement, en coulisses, à votre balise canonical. Ce guide complète notre article sur les URL canoniques PrestaShop côté méthode d’audit outillée.

Configurer Screaming Frog pour un crawl PrestaShop

Avant de lancer le crawl, ouvrez Configuration puis Spider puis l’onglet Extraction, et assurez-vous que l’option Store & Crawl Canonical (activée par défaut) reste cochée : c’est elle qui alimente tout l’onglet Canonicals une fois le crawl terminé.

Deux réglages méritent une attention particulière sur PrestaShop, où le catalogue peut dépasser la limite de la version gratuite (500 URL) et où certains thèmes injectent une partie du contenu produit en JavaScript :

1. Basculer en mode JavaScript si le thème le demandeConfiguration puis Spider puis Rendering, sélectionnez JavaScript si votre thème PrestaShop charge la balise canonical dynamiquement (rare, mais présent sur certains thèmes premium à sélecteur de déclinaison en une page).
2. Exclure les paramètres de tri et de filtre du crawlConfiguration puis Include/Exclude, pour ne pas multiplier le volume crawlé avec des variantes de la même page de catégorie triée différemment, ce qui fausserait la lecture des canonicals à l’échelle du catalogue.

Les six filtres de l’onglet Canonicals

Une fois le crawl terminé, l’onglet Canonicals segmente les résultats en six filtres. Sur un catalogue PrestaShop, voici comment les lire :

Détecter en masse la signature d’un bug PrestaShop connu

Notre article sur les produits à déclinaisons PrestaShop détaille un bug encore ouvert du cœur PrestaShop (issue GitHub #26676, versions 1.7 et 8.0) : les pages catégorie lient vers l’URL de la PREMIÈRE combinaison d’un produit (avec le paramètre id_product_attribute) plutôt que vers l’URL canonique parente. Le moteur qui pose la règle canonical n’est pas toujours celui qui la respecte ailleurs sur le même site.

Exporter et filtrer sur la signature du bug

Sur un catalogue de plusieurs milliers de références avec déclinaisons, vérifier ce point produit par produit est impossible à la main. Screaming Frog le permet en une manipulation : dans le filtre Canonicalised, exportez la colonne Canonical puis appliquez une recherche (Ctrl+F ou export vers un tableur avec un filtre texte) sur la chaîne id_product_attribute. Chaque ligne qui remonte est une signature confirmée du bug, pas une supposition : la balise canonical pointe littéralement vers une URL de déclinaison plutôt que vers la fiche produit de référence.

Mesurer l’impact réel avant de corriger

Un export qui remonte trois lignes sur un catalogue de dix mille produits n’appelle pas la même réponse qu’un export qui en remonte huit cents. Croisez le filtre Canonicalised avec le filtre Multiple pour repérer les catégories les plus concernées, et avec l’export du champ Inlinks pour mesurer combien de liens internes pointent effectivement vers ces URL de déclinaison plutôt que vers l’URL canonique parente : c’est ce volume, pas le simple fait que le bug existe, qui détermine si le problème dilue réellement l’autorité de vos fiches produit ou reste anecdotique sur votre catalogue précis.

Vérifier la version PrestaShop avant de patcher

Avant de développer un correctif maison, vérifiez la version du cœur PrestaShop et l’état de l’issue sur le dépôt officiel : un correctif communautaire ou une prochaine version mineure peut déjà couvrir le cas, ce qui évite une surcouche de code à maintenir indéfiniment sur un module qui finira par être redondant avec le cœur.

Lire les résultats sans se faire piéger par les faux positifs

Toute ligne du filtre Canonicalised n’est pas une erreur. Une page de tri ou de filtre (prix croissant, couleur) qui pointe légitimement vers l’URL de catégorie sans paramètre est un canonical CORRECT, pas un bug : c’est précisément le rôle de cette balise que de consolider ces variantes vers une seule URL de référence.

La distinction se fait en une question : la page cible du canonical couvre-t-elle le même contenu que la page source, en plus large ? Si oui, c’est un canonical légitime. Si la cible est une page différente sur le fond (une autre fiche produit, une autre déclinaison avec un contenu propre), c’est une anomalie à corriger.

Corriger dans l’ordre de priorité

1. Non-Indexable Canonical en premierUn canonical qui pointe vers une 404 ou une redirection ne consolide rien du tout : c’est la correction la plus urgente et la plus simple à isoler.
2. La signature id_product_attribute ensuiteUne fois les URL concernées identifiées, corrigez la balise pour qu’elle pointe vers l’URL produit parente sans paramètre de déclinaison, ou attendez la version corrigée du cœur PrestaShop selon votre capacité de patch.
3. Multiple canonicalsIdentifiez le module tiers responsable du doublon de balise et désactivez sa gestion des canonicals si le cœur PrestaShop ou votre extension SEO principale gère déjà le sujet correctement. Si le doublon vient d’un renommage de catégorie, notre guide pour vérifier les balises canonical sur les fiches produit détaille un bug proche, corrigé en version 8.0.
4. Missing canonicalVérifiez d’abord si le template personnalisé du thème a bien hérité du bloc qui pose la balise, avant de la recréer manuellement.

Pour un audit qui croise systématiquement ces quatre points sur l’ensemble du catalogue plutôt que sur un échantillon, un accompagnement SEO Prestashop permet de prioriser les corrections selon le volume réel de pages concernées plutôt que de traiter chaque anomalie au même niveau d’urgence.

Questions fréquentes

Un audit qui vaut pour tout le catalogue, pas un échantillon

Un audit canonical mené à la main sur dix fiches produit ne dit rien du reste du catalogue. Screaming Frog, correctement configuré et croisé avec les bugs connus de PrestaShop plutôt qu’utilisé en aveugle, transforme une vérification impossible à l’échelle humaine en un export exploitable en une après-midi.