Le SEO programmatique consiste à générer beaucoup de pages à partir d’un modèle et d’un jeu de données, une par ville, par couple de produits, par combinaison de paramètres. Fait avec un vrai jeu de données, c’est l’une des choses les plus efficaces de la discipline. Fait avec un dictionnaire de synonymes et un spinner, c’est exactement ce que les moteurs de recherche apprennent à détecter depuis deux décennies.

La différence ne tient pas à la technique. Les deux approches produisent des pages issues d’un modèle, à grande échelle. La différence tient à la question de savoir si chaque page contient quelque chose que cette page seule peut répondre, et c’est une question qui porte sur vos données, pas sur votre processus éditorial.

Le test qui sépare les deux : retirez le modèle et regardez ce qu’il reste sur une page. Si le reste est un fait réellement différent, un prix différent, un jeu de données différent, un calcul différent, la page a une raison d’exister. Si le reste est le même paragraphe avec un nom de ville substitué, vous avez produit une seule page mille fois, et les moteurs de recherche la traiteront comme telle.

Ce que le SEO programmatique exige vraiment

Un jeu de données qui varie de façon significative d’une page à l’autre parmi celles que vous comptez générer. C’est là toute la condition préalable, et c’est là que la plupart des projets échouent avant même d’avoir commencé.

Des exemples réels de variation suffisante : des prix qui diffèrent vraiment d’un article à l’autre, une disponibilité qui diffère d’un lieu à l’autre, des spécifications qui diffèrent d’un modèle à l’autre, des calculs dont le résultat dépend d’entrées propres à cette page. Dans chaque cas, la page détient une information que le lecteur ne peut pas obtenir du modèle seul.

Variation insuffisante, et raison pour laquelle la plupart des tentatives s’effondrent : une description de service avec un nom de ville inséré, une page de comparaison assemblée à partir de deux fiches produit sans comparaison réelle, ou une page « meilleur X pour Y » où les recommandations ne changent pas avec Y.

Si vous vous surprenez à écrire du remplissage pour atteindre un nombre de mots sur des pages générées, c’est le signal. Le remplissage existe parce que les données ne portaient pas la page, et aucune quantité de remplissage ne corrige le problème de fond.

Pourquoi la plupart de ces projets échouent après l’indexation

Les premières semaines paraissent encourageantes. Les pages sont explorées, certaines sont indexées, les impressions grimpent. Puis la courbe s’aplatit et une grande partie des pages quitte discrètement l’index.

Ce schéma est normal et il est instructif. Les moteurs de recherche indexent généreusement puis élaguent sur preuves : les pages qui n’attirent aucun engagement et qui dupliquent leurs voisines sont abandonnées. Ce qui survit, c’est le sous-ensemble où la variation était réelle, et c’est pourquoi les pages survivantes méritent plus d’attention que le total.

Le second échec est plus lent et plus dommageable. Des milliers de pages quasi identiques se concurrencent entre elles et concurrencent vos contenus existants, ce qui est le problème de cannibalisation décrit dans notre guide de l’élagage de contenu, à l’échelle industrielle. Un site peut se positionner globalement moins bien après un lancement programmatique qu’avant.

Les consignes de Google traitent les contenus produits à grande échelle principalement pour manipuler le classement comme du spam, quelle que soit la façon dont ils ont été produits. Le mécanisme n’est pas la détection de l’automatisation, c’est la détection de pages qui existent pour l’index plutôt que pour un lecteur.

Là où ça fonctionne vraiment

Un stock réel. Annonces immobilières, offres d’emploi, catalogues produits, calendriers d’événements. Chaque page décrit une chose distincte qui existe, ce qui est le cas le plus propre possible.

Un calcul réel. Des pages où la réponse est calculée à partir de données plutôt que décrite. Cette catégorie possède un avantage supplémentaire qui mérite d’être noté : un outil interactif résiste mieux aux résumés d’IA qu’un article, parce que la réponse n’existe pas tant que l’utilisateur n’a pas fourni d’entrée, si bien qu’il n’y a rien à extraire pour un résumé.

Ce n’est pas une affirmation théorique pour nous. Le groupe de requêtes le plus vu sur ce site, ce sont des gens qui cherchent des tarifs de stockage, et il n’a presque rien converti, parce que le chiffre voulu apparaissait dans le résumé au-dessus des résultats. Les quatre calculateurs de coûts de notre section outils de développement en ligne ont été construits exactement pour ce public, avec des tarifs fournisseurs vérifiés sur sources primaires et datés.

Des données réellement différentes par page. Des comparaisons où les spécifications diffèrent vraiment, une couverture où la disponibilité diffère vraiment, des statistiques où les chiffres diffèrent vraiment.

Des requêtes de longue traîne que personne n’écrit une par une. L’argument honnête en faveur de l’échelle : de vraies questions avec de vraies réponses, en quantités trop grandes pour être écrites à la main.

Le faire sans abîmer le site

Commencez petit et mesurez. Publiez 100 pages, pas 50 000. Observez ce qui est indexé, ce qui reçoit des clics et ce qui est abandonné. Cet échantillon vous dit si le jeu de données porte le format avant que vous ne vous engagiez sur l’ensemble.

Vérifiez d’abord la concurrence interne. Si vous avez déjà une page qui vise la requête que va viser une page générée, vous avez construit un concurrent plutôt qu’un ajout.

Donnez à chaque page de quoi lier et être liée. Des pages orphelines générées depuis une base de données et accessibles seulement par un sitemap ressemblent exactement à ce qu’elles sont. Un vrai maillage interne entre pages générées apparentées est à la fois utile et un signal qu’elles appartiennent au site.

Ne générez pas ce que vous ne publieriez pas seul. Si une seule de ces pages, publiée isolément, vous gênait, le problème ne s’améliore pas en volume.

Gardez les données fraîches. Des pages générées portant des prix périmés ou une disponibilité morte sont pires que des pages absentes, et la maintenance est proportionnelle au nombre. 100 000 pages, ce sont 100 000 pages à garder vraies.

Mecanik construit ces systèmes dans le cadre de nos travaux de développement web, et la première conversation porte toujours sur le jeu de données. Quand la variation n’y est pas suffisante, la recommandation honnête est de construire moins de pages et de meilleures.

Questions fréquentes

Qu’est-ce que le SEO programmatique ? Générer beaucoup de pages à partir d’un modèle et d’un jeu de données, une par ville, par couple de produits ou par combinaison de paramètres. C’est efficace quand le jeu de données varie vraiment d’une page à l’autre, et c’est traité comme du spam quand ce n’est pas le cas, parce que les pages obtenues existent pour l’index plutôt que pour un lecteur.

Quand le SEO programmatique devient-il du spam ? Quand la variation est cosmétique. Retirez le modèle d’une page et regardez ce qu’il reste : si c’est un fait, un prix, un jeu de données ou un calcul réellement différent, la page a une raison d’exister. Si c’est le même paragraphe avec un nom de ville substitué, vous avez publié une seule page de nombreuses fois.

Pourquoi les pages de SEO programmatique sont-elles désindexées ? Les moteurs de recherche indexent généreusement puis élaguent sur preuves. Les pages qui n’attirent aucun engagement et qui dupliquent leurs voisines sont abandonnées, si bien qu’une hausse initiale des impressions s’aplatit à mesure que la partie pauvre quitte l’index. Ce qui survit, c’est le sous-ensemble où les données sous-jacentes variaient réellement.

Les pages programmatiques peuvent-elles nuire au reste de mon site ? Oui. Des milliers de pages quasi identiques se concurrencent entre elles et concurrencent vos contenus existants, ce qui est de la cannibalisation de mots-clés à grande échelle. Un site peut se positionner globalement moins bien après un lancement programmatique qu’avant, et c’est pourquoi publier 100 pages puis mesurer vaut mieux que d’en publier 50 000.

Quels types de pages fonctionnent bien en programmatique ? Un stock réel comme des annonces, des offres d’emploi, des catalogues et des événements ; des pages où la réponse est calculée à partir d’entrées plutôt que décrite, ce qui leur permet aussi de résister aux résumés d’IA parce que la réponse n’existe pas tant que l’utilisateur n’a pas fourni de données ; des comparaisons où les spécifications diffèrent vraiment ; et des questions de longue traîne trop nombreuses pour être écrites à la main.