SEO programmatique dans une boutique en ligne : des landing pages en série sans contenu de remplissage

Votre catégorie « robes » est en concurrence avec des centaines de boutiques sur une recherche générique. Mais beaucoup de gens ne cherchent pas « robes » : ils cherchent « robes d'invitée pour mariage à Madrid », « robes en lin pour l'été » ou « robes de soirée grandes tailles ». Chacune de ces recherches a moins de volume, mais elles sont nombreuses, et avec une intention d'achat bien plus nette.

Rédiger à la main une page pour chaque combinaison est impossible. Le SEO programmatique résout ce problème : une liste de combinaisons, un modèle bien pensé et des données réelles de votre catalogue. Le risque est évident : si les pages sont toutes identiques à un mot près, Google les traite pour ce qu'elles sont.

Ce qu'est (et ce que n'est pas) le SEO programmatique

C'est générer des pages à grande échelle à partir d'un schéma : produit + ville, produit + usage, produit A contre produit B. Chaque page répond à une recherche précise avec un contenu qui change vraiment selon la combinaison.

Ce n'est pas copier une page cent fois en changeant le nom de la ville. Google pénalise depuis des années les doorway pages (pages satellites) : des pages créées uniquement pour se positionner sur des variantes d'une recherche et qui mènent toutes au même endroit sans rien apporter.

Les trois schémas qui fonctionnent dans une boutique

Catégorie + lieu

C'est pertinent si le lieu change quelque chose de réel : délais de livraison, retrait en magasin, installation, réglementation locale ou catalogue différent. Si vous livrez de la même façon dans toute l'Espagne et que rien ne change, une page par ville apporte peu.

Catégorie + usage

« Sacs à dos pour ordinateur portable 17 pouces », « peinture extérieure pour zones côtières », « chaussures de course sur bitume ». C'est le schéma le plus utile dans une boutique, car la page peut filtrer les produits qui correspondent vraiment à cet usage.

Comparatifs

« Modèle A ou modèle B », « lin ou coton pour l'été ». Ils répondent à ceux qui sont déjà en train de décider. Ils exigent des données réelles sur chaque produit ; un comparatif inventé se remarque.

Comment éviter le contenu de remplissage

1. Des produits réels sur chaque page. Une landing page de boutique sans produits, ou avec des produits qui ne correspondent pas, ne répond pas à la recherche. Prix et stock réels, pas du texte isolé.
2. Des variables qui changent le contenu, pas seulement le titre. Si la seule différence entre deux pages est un mot dans le H1, c'est la même page.
3. Des questions fréquentes spécifiques. Bien choisies, elles apportent un contenu différent par combinaison et répondent à de vraies questions.
4. Moins de pages, mais meilleures. Deux cents bonnes pages valent mieux que deux mille médiocres. Commencez par les combinaisons qui ont des recherches réelles dans vos outils de mots-clés.
5. Relisez avant de publier. Lisez un échantillon de pages générées comme si vous étiez le client. Si elles ne vous servent pas, elles ne serviront pas à Google non plus.

Cannibalisation : le problème que personne ne regarde

La cannibalisation se produit quand deux pages de votre site se disputent la même recherche. Google ne sait pas laquelle afficher, alterne entre elles et aucune ne se positionne bien. Dans le SEO programmatique, elle est presque inévitable si on ne la contrôle pas :

• Une landing page « chaussures running » face à votre catégorie « Chaussures de running ».
• Deux landing pages qui ne diffèrent que par un pluriel ou une faute de la liste d'origine.
• Une landing page face à une page CMS ou un article de blog qui traite déjà le sujet.

La règle est simple : avant de créer une page, vérifier qu'il n'en existe pas déjà une autre sur votre site qui répond à la même chose. Et ne pas confondre cela avec deux combinaisons légitimes : « robes à Madrid » et « robes à Séville » ne se marchent pas dessus.

La partie technique qui ne doit pas échouer

• Des URL propres et stables, qui ne changent pas si vous régénérez.
• Un meta title et une meta description propres par page et par langue.
• Une balise canonical pointant vers la page elle-même, sauf si vous décidez délibérément le contraire.
• Un sitemap incluant les landing pages, pour que Google les découvre.
• Des liens internes vers elles depuis les catégories ou les pages liées ; une page que personne ne lie est presque invisible.
• Des données structurées cohérentes avec le contenu réel (questions fréquentes uniquement si elles sont visibles sur la page).
• Une génération par lots : créer des centaines de pages d'un coup sur un hébergement mutualisé finit en délai d'attente dépassé.

Check-list avant le lancement

1. Liste de combinaisons propre : sans doublons, sans lignes vides, avec le bon encodage.
2. Vérification des conflits avec les catégories, les pages CMS, les produits et les landing pages existantes.
3. Modèle avec au moins trois blocs qui changent selon la combinaison.
4. Des produits réels sur chaque page.
5. Lancement par étapes : un premier lot, mesurer dans Search Console pendant quelques semaines et élargir si cela fonctionne.

Comment le résoudre dans PrestaShop

RKR Programatic SEO génère des landing pages à partir d'un CSV avec trois types de pages — catégorie et ville, usage et comparatif —, chacun avec des modèles par langue pour le H1, le meta title, la meta description, l'URL, le contenu et les questions fréquentes, et avec vos produits et prix réels intégrés à votre thème. Avant de créer quoi que ce soit, il analyse le CSV : il détecte le séparateur et l'encodage (y compris les fichiers enregistrés depuis Excel en Windows-1252), comprend les en-têtes de Semrush et d'Ahrefs et signale les lignes en double. Son moteur anti-cannibalisation compare chaque nouvelle page avec vos catégories, pages CMS, produits et landing pages existants, avec trois politiques (bloquer, avertir en laissant la page en brouillon ou désactiver) et un seuil de similarité configurable entre 50 et 100 %. La génération se fait par lots de 1 à 200 pages avec barre de progression, pour ne pas dépasser le temps d'exécution sur des hébergements modestes. Il fonctionne de PrestaShop 1.7.8 à 9.2.