SEO programmatique : le guide complet
Le SEO programmatique consiste à produire des pages à partir d'un modèle et d'une base de données, plutôt qu'une par une à la main. La technique n'a rien de nouveau — Zillow, Tripadvisor ou Indeed reposent dessus depuis quinze ans. Ce qui a changé en 2026, c'est le seuil de qualité en dessous duquel Google cesse de considérer ces pages comme légitimes.
Ce guide décrit le pipeline complet : choisir les intentions qui méritent une page, structurer le template, générer le contenu, organiser le maillage, puis faire indexer l'ensemble. Chaque étape renvoie vers un article dédié qui la détaille.
Ce qu'est — et n'est pas — le SEO programmatique
Une page programmatique est produite en croisant un modèle de page (structure fixe) avec un jeu de données (les variables). « Restaurant italien à Lyon », « Restaurant italien à Bordeaux » : même gabarit, données différentes.
Ce n'est pas la même chose que la génération de contenu par IA. L'IA est un moyen de remplir un gabarit ; le SEO programmatique est une méthode d'architecture. On peut faire du programmatique sans IA (des données propres suffisent) et de l'IA sans programmatique (un article rédigé par LLM, publié seul).
La distinction qui compte pour Google : ce n'est ni le volume ni l'outil de rédaction, mais la question de savoir si chaque page apporte une valeur que l'utilisateur ne trouve pas ailleurs.
Quand le programmatique fonctionne (et quand il échoue)
Trois conditions doivent être réunies simultanément. Si une seule manque, le projet produit des pages qui ne seront jamais indexées.
| Condition | Ce que ça veut dire | Signal d'échec |
|---|---|---|
| Demande réelle et répétée | Le motif de requête existe pour chaque variante, pas seulement pour la tête de longue traîne | 80 % des variantes à 0 recherche/mois |
| Données propriétaires ou structurées | Vous détenez une information que la page concurrente n'a pas | Le contenu est une paraphrase de Wikipédia |
| Différenciation par ligne | Deux pages du même gabarit diffèrent sur le fond, pas juste sur un nom de ville | Taux de similarité inter-pages > 90 % |
Le point le plus souvent négligé est le premier. Générer 5 000 pages sur un motif dont seules 300 variantes ont une demande réelle revient à créer 4 700 pages orphelines qui consomment du budget de crawl. Le filtrage se fait en amont : voir le filtre d'intention de recherche et la sélection des mots-clés longue traîne.
Le pipeline en six étapes
1. Cartographier le motif de requête
Un motif est une formule : [intention] + [modificateur] + [entité]. « alternative à {outil} », « {métier} salaire {ville} », « comment {tâche} avec {logiciel} ». On valide le motif sur un échantillon de 20 à 50 variantes avant d'écrire la moindre ligne de template.
2. Construire le jeu de données
Une ligne = une page. Les colonnes deviennent les variables du gabarit. Une colonne qui reste vide sur 30 % des lignes est une colonne qui produira 30 % de pages incomplètes : soit on la remplit, soit on exclut ces lignes.
3. Concevoir le gabarit
Le gabarit fixe la hiérarchie des titres, l'ordre des blocs, les données structurées. C'est là que se jouent les balises Hn, les patterns de title et de meta description et le balisage schema.org.
4. Générer
Que la génération passe par un LLM ou par de la fusion de données, la règle est la même : chaque page doit contenir au moins un bloc dont le contenu ne pourrait pas exister sur une autre page du lot. Les détails sur les limites réglementaires sont dans l'analyse de la politique scaled content abuse.
5. Relier
Une page sans lien entrant interne n'existe pas pour un crawler. Le maillage doit être défini à la conception, pas ajouté après coup : voir structurer un silo de 1 000 pages.
6. Faire indexer
Sitemaps découpés, gestion du budget de crawl, canonicals corrects. Les trois articles concernés : découpage des sitemaps, budget de crawl, canonical et duplication.
Le risque réglementaire, formulé précisément
Google définit l'abus de contenu à grande échelle comme le fait de générer de nombreuses pages « dans le but principal de manipuler le classement dans les résultats de recherche et non d'aider les utilisateurs ». La formulation est importante : le critère est l'intention principale, pas la méthode de production. Un site de 100 000 pages générées peut être conforme ; un site de 200 pages générées peut ne pas l'être.
En pratique, les trois marqueurs qui déclenchent une dévaluation sont l'absence de données propres, la répétition d'un même paragraphe sur des centaines d'URL, et l'absence totale de signaux d'engagement (aucun clic depuis la SERP sur des pages positionnées).
Ce qu'il faut mesurer
- Taux d'indexation : URL indexées / URL soumises. En dessous de 40 % sur un lot mature, le problème est le contenu, pas le crawl.
- Ratio impressions/page : détecte les pages générées qui ne récoltent rien.
- Profondeur de clic : le nombre de clics depuis la page d'accueil. Au-delà de 4, l'indexation se dégrade nettement.
- Similarité inter-pages : à surveiller comme un test de non-régression à chaque évolution du gabarit.
La mesure fine passe par l'API Search Console, dont l'exploitation est décrite dans l'article sur les Core Web Vitals des pages programmatiques pour la partie performance.
Questions fréquentes
Combien de pages faut-il pour parler de SEO programmatique ?
Il n'y a pas de seuil officiel. En pratique, on parle de programmatique dès qu'un même gabarit produit plus d'une cinquantaine de pages à partir d'une source de données. En dessous, la rédaction manuelle reste plus rentable.
Le SEO programmatique est-il pénalisé par Google ?
Non en tant que technique. Ce que Google sanctionne, c'est l'abus de contenu à grande échelle, défini comme la génération de nombreuses pages ayant pour but principal de manipuler le classement plutôt que d'aider les utilisateurs. Des pages générées à partir de données réelles et différenciées restent conformes.
Faut-il utiliser un LLM pour générer les articles ?
Ce n'est pas obligatoire. Un LLM accélère la rédaction des blocs narratifs, mais la valeur d'une page programmatique vient de ses données. Un gabarit alimenté par une base propriétaire sans IA performe mieux qu'un texte de LLM sans données.