PS PrestaShop Intermédiaire

SEO Cannibalization Detector — Guide complet PrestaShop 8 & 9

Détectez et résolvez la cannibalisation SEO de votre boutique PrestaShop via Google Search Console : installation, configuration, scans et redirections 301.

Mis à jour Version du module 1.0.0

SEO Cannibalization Detector se connecte en lecture seule à votre propriété Google Search Console, identifie chaque requête où plusieurs URLs de votre boutique PrestaShop se cannibalisent, et propose une action concrète : consolider, rediriger en 301, différencier ou surveiller. Cette documentation couvre l’installation, la configuration du service account Google, le lancement de votre premier scan, la lecture du rapport et la gestion des redirections.

Prérequis

  • PrestaShop 8.0 à 9.x
  • PHP 8.1 ou supérieur, avec les extensions openssl, curl et json
  • Un projet Google Cloud (compte gratuit suffit, aucun crédit requis)
  • Une propriété Google Search Console déjà vérifiée pour le domaine de votre boutique
Vérifier OpenSSL : sur la plupart des hébergements (o2switch, OVH, Hetzner, Infomaniak), OpenSSL est activé par défaut. Pour vérifier, ajoutez temporairement echo extension_loaded('openssl') ? 'OK' : 'KO'; dans un fichier PHP de test.

Installation

  1. Téléchargez le ZIP dfcannibalization-1.0.0.zip depuis votre espace client DataFirefly.
  2. Dans le back-office PrestaShop, allez dans Modules → Module Manager.
  3. Cliquez sur Charger un module et sélectionnez le ZIP.
  4. Une fois l’installation terminée, cliquez sur Configurer.

Le module crée 4 tables SQL (scan, query, page, action), un onglet d’admin « DataFirefly Cannibalization » sous IMPROVE, et un token unique pour les scans planifiés.

Créer un service account Google

Un service account est un compte technique Google qui permet à votre boutique de lire les données Search Console sans demander d’authentification interactive. C’est gratuit et limité à du lecture seule.

1. Activer l’API Search Console

  1. Ouvrez console.cloud.google.com.
  2. Créez un nouveau projet (ex. « DataFirefly SEO ») ou sélectionnez un projet existant.
  3. Dans le menu de navigation, allez dans APIs et services → Bibliothèque.
  4. Recherchez Google Search Console API et cliquez sur Activer.

2. Créer le service account

  1. Dans le même menu, allez dans APIs et services → Identifiants.
  2. Cliquez sur Créer des identifiants → Compte de service.
  3. Donnez-lui un nom explicite (ex. « datafirefly-cannibalization ») et validez. Vous pouvez ignorer les étapes optionnelles de rôles et d’accès utilisateur.

3. Générer la clé JSON

  1. Cliquez sur le compte de service créé.
  2. Onglet Clés → Ajouter une clé → Créer une clé.
  3. Sélectionnez le format JSON et validez. Le fichier se télécharge automatiquement.
Conservez ce fichier en lieu sûr : il contient la clé privée du service account. Anyone qui possède ce JSON peut lire vos données Search Console.

Autoriser le service account dans Search Console

Le service account a son propre email (visible dans le JSON sous la clé client_email, ex. datafirefly-cannibalization@projet-123.iam.gserviceaccount.com). Il faut l’autoriser en lecture sur votre propriété.

  1. Ouvrez search.google.com/search-console.
  2. Sélectionnez votre propriété (URL-prefix ou domain).
  3. Cliquez sur Paramètres → Utilisateurs et autorisations.
  4. Cliquez sur Ajouter un utilisateur.
  5. Collez l’email client_email du service account et choisissez la permission Restreint (lecture seule).
  6. Validez.

Configurer le module

Retournez dans le back-office PrestaShop, dans la configuration du module.

Service account et propriété

  • Service account JSON : ouvrez le fichier téléchargé, copiez-collez son contenu entier dans le champ.
  • URL du site (propriété GSC) : reproduisez exactement le format affiché dans Search Console.
    • Pour une propriété URL-prefix : https://www.exemple.com/ (avec le slash final).
    • Pour une propriété domain : sc-domain:exemple.com (sans protocole, avec le préfixe sc-domain:).

Seuils de détection

  • Période d’analyse : 7 à 490 jours. 90 jours est un bon compromis entre fraîcheur et volume statistique.
  • Impressions minimum : ignore les requêtes très faibles. 30 par défaut. Mettez 10 si votre boutique est récente.
  • Clics minimum : seuil de clics par requête pour être analysée. 1 par défaut. Mettez 0 pour inclure aussi les requêtes à impressions sans clic (utile pour les sites jeunes).
  • Position maximum : ignore les requêtes où la meilleure URL est au-delà de cette position. 30 par défaut.

Redirections 301 automatiques

Active l’interception via le hook dispatcher PrestaShop. Désactivez si vous préférez gérer les redirections manuellement dans Trafic et SEO → Redirections.

Cliquez sur Sauvegarder, puis sur Tester la connexion GSC. Si la connexion réussit, le module affiche un message vert.

« 403 User does not have sufficient permissions » : le service account n’a pas encore été ajouté dans Search Console, ou la propriété renseignée ne correspond pas exactement à celle affichée dans GSC. Vérifiez les deux côtés.

Lancer un scan

Cliquez sur Lancer un scan maintenant. Le module :

  1. Interroge l’API Search Console pour la période configurée (pagination jusqu’à 200 000 lignes).
  2. Groupe les lignes par requête.
  3. Filtre selon vos seuils (impressions, clics, position).
  4. Retient uniquement les requêtes ayant au moins 2 URLs distinctes.
  5. Calcule le score de gravité et la recommandation.
  6. Persiste tout en base.

Pour un site moyen (10 000 à 50 000 pages), un scan complet sur 90 jours prend entre 30 secondes et 3 minutes.

Lire le rapport

Une fois le scan terminé, ouvrez-le depuis l’onglet Historique des scans. Le rapport liste chaque requête cannibalisée, avec :

  • Le mot-clé (la requête Google).
  • Le score de gravité sous forme de pastille colorée (low / medium / high / critical).
  • Le nombre d’URLs en compétition.
  • La recommandation (REDIRECT 301, CONSOLIDATE, DIFFERENTIATE, MONITOR).
  • Le statut (en attente, examiné, résolu, ignoré).

Cliquez sur une requête pour voir le détail : la liste des URLs concurrentes avec clics, impressions, position moyenne, CTR, et type de page (produit, catégorie, CMS, blog, etc.). L’URL identifiée comme « gagnante » est surlignée en vert.

Comprendre le score de gravité

Le score est sur 100, combinant 4 facteurs pondérés :

  • Nombre de pages concurrentes (25 points max) — formule : min((n-1)/3, 1) × 25. À partir de 4 URLs concurrentes, le facteur est maximal.
  • Répartition des clics (30 points max) — basé sur un indice HHI inversé. Une cannibalisation 50/50 entre deux URLs est plus grave qu’un 95/5. Formule : ((1-HHI)/(1-1/n)) × 30.
  • Écart de position (30 points max) — pondéré par la position du meilleur résultat. Bonification × 1.0 si meilleure position ≤ 10, × 0.7 si ≤ 20, × 0.4 au-delà.
  • Volume d’impressions (15 points max) — échelle logarithmique : min(log10(impr+1)/4, 1) × 15.

Niveaux : low < 26, medium < 51, high < 76, critical ≥ 76.

Les 4 recommandations

REDIRECT 301

Le module propose cette action quand une URL capte au moins 70% des clics avec une position moyenne ≤ 15. C’est l’URL « gagnante » : Google la considère clairement comme la meilleure réponse. Les autres URLs lui sont redirigées en 301. Le contenu peut être fusionné côté éditorial avant la redirection si nécessaire.

CONSOLIDATE

Les performances sont réparties (pas de gagnante claire). Recommandation : fusionner le contenu des deux URLs sur une seule, puis rediriger l’autre en 301. Ce travail est éditorial, pas automatisable. Le module identifie le cas mais ne fait pas la fusion à votre place.

DIFFERENTIATE

Les pages sont de types différents (exemple : une fiche produit et un article de blog). La cannibalisation indique un problème de ciblage des balises title/meta plutôt qu’un vrai conflit de contenu. Recommandation : retravailler les balises pour cibler des requêtes distinctes (longue traîne sur le blog, requête principale sur le produit).

MONITOR

Le score est faible (< 26). Aucune action urgente. Le module garde la requête dans le rapport mais la classe en « à surveiller ».

Appliquer une redirection 301

Depuis le détail d’une requête recommandée REDIRECT 301 :

  1. Cliquez sur le bouton Sélectionner comme source à côté de l’URL à rediriger (celle qui n’est pas la gagnante).
  2. L’URL cible (la gagnante) est pré-remplie automatiquement.
  3. Cliquez sur Appliquer la redirection.

La règle est enregistrée et servie immédiatement depuis le hook actionDispatcherBefore. Performance : un seul SELECT par worker PHP-FPM grâce à un cache statique en mémoire.

Vérifier qu’une redirection fonctionne : ouvrez l’URL source dans un navigateur en navigation privée, ou utilisez curl -I https://votre-boutique.com/ancienne-url. Vous devez voir un HTTP/1.1 301 et un en-tête Location: vers la nouvelle URL.

Gérer les redirections actives

L’onglet Redirects 301 liste toutes les redirections en place avec leur compteur de hits. Vous pouvez :

  • Désactiver une redirection sans la supprimer (utile pour tester un retour arrière).
  • Supprimer définitivement une redirection.
  • Voir le nombre de hits depuis sa création (mesure l’efficacité).

Scans planifiés via cron

Le module expose un front controller token-protégé. L’URL est affichée dans la configuration du module sous la forme :

https://votre-boutique.com/index.php?fc=module&module=dfcannibalization&controller=cron&token=XXXX

Cron Linux standard

Sur un serveur Linux/Unix avec accès SSH, éditez votre crontab :

crontab -e

Ajoutez par exemple un scan tous les dimanches à 23h :

0 23 * * 0 curl -s "https://votre-boutique.com/index.php?fc=module&module=dfcannibalization&controller=cron&token=XXXX" > /dev/null

Tâches planifiées OVH / o2switch / Infomaniak

Tous ces hébergeurs proposent un planificateur dans leur back-office. Renseignez l’URL complète et la fréquence souhaitée. Pour la plupart des boutiques, un scan hebdomadaire suffit largement.

Régénérer le token : désinstallez puis réinstallez le module si vous pensez que votre token a fuité. Un nouveau token sera généré à l’installation.

Multi-boutique

Toutes les tables incluent une colonne id_shop. Les scans sont scopés selon la boutique active dans le sélecteur en haut du back-office. Chaque boutique a sa propre configuration (service account, URL GSC, seuils) et son propre historique de scans.

Si vous gérez plusieurs domaines depuis un même back-office, créez un service account distinct par propriété, ou autorisez le même service account sur toutes vos propriétés Search Console.

Dépannage

« OpenSSL extension required »

Demandez à votre hébergeur d’activer l’extension PHP OpenSSL. Sur 99% des hébergements modernes, elle est activée par défaut.

« Invalid service account JSON »

Le JSON collé est incomplet ou corrompu. Re-téléchargez la clé depuis Google Cloud Console et collez-la entière, sans modification.

« Site URL must match exactly the GSC property »

Vérifiez le format dans Search Console. Une propriété URL-prefix s’écrit https://www.exemple.com/ (slash final). Une propriété domain s’écrit sc-domain:exemple.com (pas de protocole, pas de slash).

« 403 User does not have sufficient permissions »

Le service account n’a pas été autorisé dans Search Console, ou il a été autorisé sur une autre propriété. Vérifiez Paramètres → Utilisateurs et autorisations.

Le scan tourne mais ne trouve aucune cannibalisation

Vos seuils sont peut-être trop élevés pour votre volume. Essayez d’abaisser les impressions minimum à 5 et les clics minimum à 0.

Une redirection 301 ne se déclenche pas

Vérifiez que (1) l’option « Redirections 301 automatiques » est bien activée dans la configuration, (2) la règle est marquée comme active dans l’onglet Redirects 301, (3) le cache PrestaShop a été vidé après activation du module.

Aller plus loin

  • Politique de revue : sur les requêtes critical, intervenez sous 7 jours. Sur les high, sous 30 jours. Sur les medium, dans le cadre d’une revue trimestrielle.
  • Stratégie 301 versus consolidation : la redirection 301 transfère le PageRank mais perd la possibilité d’avoir deux pages indexées. Privilégiez la différenciation pour des intentions de recherche différentes.
  • Cas particulier des fiches produits : si deux variantes très proches se cannibalisent, fusionnez-les en un produit avec déclinaisons plutôt qu’en deux produits séparés.
Cette page vous a-t-elle été utile ?

Toujours bloqué ? Contactez le support