SEO Programmatique : Générer des Pages à Grande Échelle

Écrire un article de blog par mot-clé, ça ne scale pas. Si vous avez une base de données avec 50, 200 ou 2000 entités (villes, métiers, produits, intégrations…), vous avez potentiellement 2000 pages à forte intention de recherche qui dorment dans votre schéma SQL. Le programmatic SEO consiste à générer ces pages automatiquement, à partir d’un template et de données structurées, plutôt que de les rédiger une par une. Bien fait, ça peut multiplier votre trafic organique par 10. Mal fait, c’est un aller simple pour une pénalité Google liée au contenu dupliqué. Cet article détaille comment le faire proprement, avec un exemple réel : la génération de pages métiers sur Oneki, un SaaS de création de sites vitrines pour indépendants, TPE, PME et associations que j’ai construit en Nuxt 4 et Supabase.

Qu’est-ce que le programmatic SEO ?

Le programmatic SEO (ou “pSEO”) désigne la génération automatisée de pages web optimisées pour le référencement, à partir d’une source de données structurée et d’un template réutilisable. Au lieu d’écrire manuellement une page “Meilleur CRM pour startups” et une autre “Meilleur CRM pour agences immobilières”, vous construisez un seul template capable de produire les deux à partir d’une table use_cases en base.

Le principe repose sur une observation simple : beaucoup de recherches Google suivent un pattern répétable.

“Site web pour [métier]”
“CRM pour [secteur]”
“convertisseur [format A] vers [format B]”
“prix [service] à [ville]”

Ces requêtes sont individuellement peu volumineuses, mais leur somme représente un volume de longue traîne considérable, avec une intention de recherche très précise, donc un taux de conversion souvent meilleur qu’un mot-clé générique.

Des acteurs comme Zapier (pages “Connect [outil] to [outil]”) ou AirBnb (pages “location maison à [commune]”) ont construit une part significative de leur trafic organique sur ce principe. La logique est la même à petite échelle : dès que vous avez une entité répétable dans votre modèle de données, vous avez un candidat pSEO.

Ce qui différencie le pSEO d’un simple CMS headless, c’est l’intention : chaque page générée cible un mot-clé ou une variation de recherche précise, identifiée en amont via une étude de mots-clés, et non produite au fil de l’eau.

Les prérequis techniques

Avant de brancher un template sur une table SQL, trois conditions doivent être réunies. Les ignorer, c’est se garantir un contenu dupliqué massif et une désindexation à moyen terme.

1. Des données structurées et exhaustives

Chaque entité (ligne en base) doit porter suffisamment d’attributs pour alimenter un contenu réellement différent d’une page à l’autre : description, caractéristiques, statistiques, avis, exemples, FAQ spécifique. Une table avec juste un nom et un slug ne suffit pas à produire une page qui vaut la peine d’être indexée.

2. Un template réutilisable, mais paramétré en profondeur

Le template ne doit pas se contenter d’interpoler {{nom}} dans un texte fixe. Chaque bloc doit pouvoir varier selon les données : conditions d’affichage, contenu généré dynamiquement à partir d’attributs métier, sections optionnelles selon la disponibilité des données.

3. Une garantie d’unicité de contenu par page

C’est le point le plus sensible. Avec N pages issues du même template, le risque de contenu quasi-identique (thin content ou duplicate content) augmente avec N.

Il faut budgétiser, dès la conception du template, un pourcentage minimal de contenu unique par page : un texte d’intro qui varie réellement selon les attributs de l’entité (pas juste son nom injecté dans une phrase fixe), et des blocs qui s’affichent ou disparaissent selon la richesse des données disponibles.

Cas pratique : Oneki et les pages par métier

Sur Oneki, l’outil que j’ai développé pour permettre aux indépendants, TPE, PME et associations d’obtenir leur site vitrine, j’avais un problème classique : impossible d’écrire manuellement une landing page pour chaque métier. Artisans du BTP (plombier, électricien, menuisier, carreleur…), professionnels de santé et du bien-être (naturopathe, ostéopathe, sophrologue…), métiers du droit et du conseil (avocat, notaire, expert-comptable…), commerces de proximité (coiffeur, réparateur vélo…) ou associations (club sportif, association culturelle…) : chacun a ses propres attentes, son propre vocabulaire et ses propres requêtes Google.

C’est exactement le genre de cas où le programmatic SEO a du sens : une entité répétable (job), une intention de recherche claire (“site web pour [métier]”), et un volume de longue traîne qui justifie l’automatisation plutôt que la rédaction unitaire.

La table `jobs` comme source de vérité

Tout part d’une table Supabase jobs, avec pour chaque métier un slug, un name et un sector, une accroche (catchphrase), une description et un pitch commercial (pitch), ainsi que du contenu contextuel dédié au SEO local et à la tarification (local_search_context, pricing_context, why_website_intro).

Un champ naf (jsonb) relie le métier à son code NAF officiel, utilisé pour interroger l’API INSEE et afficher le nombre réel de professionnels du secteur en France. Un booléen is_active permet de désactiver un métier sans le supprimer : seuls les métiers actifs sont pris en compte au build et dans le sitemap.

Ce socle est enrichi par des tables liées :

services et service_items listent les prestations types du métier
job_faqs fournit des questions/réponses spécifiques à chaque métier
jobs_pain_points associe les problématiques clients typiques (douleur/bénéfice), piochées dans une table pain_points commune à tous les métiers
jobs_certifications relie les certifications professionnelles pertinentes, elles aussi puisées dans une table certifications partagée.

Cette table jobs (et son réseau de tables associées) est la seule source de vérité : aucune page n’est écrite à la main, tout est dérivé de ces lignes au moment du build.

Le rendu en SSG au build

La route dynamique /creation-site-internet/[job] consomme cette table au moment du build pour produire une page statique par métier, plutôt qu’un rendu à la demande.

C’est ce mécanisme qui produit par exemple création de site internet pour menuisier : même template, même structure de composants, mais un contenu — hero, texte de contexte local, statistique INSEE, grille de services, points de blocage, certifications, FAQ — entièrement dérivé des données de cette ligne en base.

Le template lui-même contient des sections conditionnelles, gouvernées directement par la présence ou l’absence de données liées au métier. Le bloc “Vous êtes [métier] sans site internet ?”, qui liste les points de blocage du quotidien (jobs_pain_points), ne s’affiche que si au moins une ligne existe pour ce métier. Il en va de même pour le bloc “Certifications et labels” (jobs_certifications) et pour la FAQ, qui combine deux questions génériques toujours présentes avec les questions spécifiques stockées dans job_faqs — sans quoi le composant ne s’affiche pas du tout, plutôt que de montrer une section vide qui sentirait le contenu creux.

C’est visible en comparant les pages site internet pour plombier et site internet pour électricien : les deux métiers partagent des points de blocage communs (besoin urgent, méfiance des clients, appels inutiles à filtrer), mais leurs certifications divergent nettement. Le plombier met en avant des labels liés aux énergies renouvelables (QualiPAC, QualiSol, Chauffage+, Ventilation+), tandis que l’électricien affiche des certifications propres à son corps de métier comme Qualifelec, QualiPV ou IRVE.

L’écart est encore plus marqué d’un secteur à l’autre : une page site internet pour naturopathe ou site internet pour avocat n’a ni les mêmes prestations, ni les mêmes problématiques clients qu’une page artisan — et c’est précisément la base de données qui porte cette différence, pas le template.

Deux pages au contenu différent, générées depuis les mêmes composants, mais avec des données de compétences et de certifications distinctes en base.

Le maillage interne entre pages générées

Un piège classique du pSEO est de générer des pages orphelines, mal reliées entre elles. Sur Oneki, chaque page métier expose un bloc “Métiers proches de [métier]” qui pointe vers une poignée de métiers voisins, plutôt qu’une simple liste alphabétique : l’idée est de faire remonter en priorité les métiers sémantiquement liés (par exemple relier “plombier” à “chauffagiste” ou “thermicien”, “naturopathe” à “réflexologue”) pour créer un maillage cohérent, et pas seulement une liste de liens. Le fil d’Ariane (Accueil › Création de site internet › Artisans du BTP › Plombier) complète ce maillage en remontant vers la page du secteur.

Le sitemap dynamique

Dernier maillon : un sitemap généré automatiquement à partir des métiers actifs de la table jobs, régénéré à chaque build. Chaque métier ajouté en base (avec is_active = true) apparaît automatiquement dans le sitemap, sans intervention manuelle — c’est ce qui garantit que Google découvre les nouvelles pages générées sans attendre un déploiement dédié au SEO.

L’importance de la page d’archive

Un piège fréquent en programmatic SEO est de générer des dizaines de pages enfants sans jamais les relier depuis une page d’archive — un hub qui liste et catégorise l’ensemble des pages générées, plutôt que de laisser le sitemap XML seul faire le travail de découverte.

Sur Oneki, ce rôle est tenu par deux niveaux d’archive :

/creation-site-internet, la page hub qui présente l’offre de site internet et regroupe les métiers par secteur (artisans du BTP, santé & bien-être, droit & conseil, associations, commerces de proximité), chaque carte secteur mettant en avant quelques métiers et un lien “Plus de métiers” ;
les pages secteur, comme /creation-site-internet/btp, qui listent l’ensemble des métiers actifs du secteur issus de la table jobs, chacun pointant vers sa page /creation-site-internet/[slug] dédiée.

C’est cette hiérarchie hub → secteur → métier qui fait le lien entre l’offre générale et les centaines de déclinaisons par métier.

C’est un rôle que le sitemap seul ne peut pas jouer :

une page d’archive transmet du PageRank interne à chaque page enfant, du fait d’être elle-même liée depuis la navigation principale et les pages à forte autorité (accueil, pages services) — le sitemap, lui, n’est qu’un fichier lu par les robots, sans poids de lien ;
elle donne à Google un point d’entrée unique et catégorisé, ce qui aide au maillage sémantique bien mieux qu’une liste plate ;
elle réduit la profondeur de clic : sans elle, une page métier ne serait reliée qu’aux autres pages métiers, diluant l’autorité en boucle fermée plutôt que de la faire descendre depuis les pages à fort trafic du site ;
elle constitue elle-même une page indexable à forte valeur (“site internet pour artisans du bâtiment”, “site internet pour association”…), qui capte des requêtes plus larges que les pages individuelles.

Sur un site pSEO, une page d’archive n’est donc jamais une simple commodité de navigation : c’est l’infrastructure qui fait que le “jus SEO” des pages à fort trafic irrigue réellement les centaines de pages générées, au lieu de les laisser dépendre uniquement d’un sitemap et de liens croisés entre elles.

Pièges à éviter

Le contenu dupliqué (thin content)

C’est le risque numéro un. Si vos pages ne diffèrent que par un nom propre injecté dans un texte fixe, Google les traitera comme quasi-identiques et n’en indexera qu’une poignée, voire aucune. La règle empirique : si vous supprimez le nom de l’entité, un lecteur humain doit encore pouvoir deviner de quelle page il s’agit rien qu’au contenu.

Les pages fines sans valeur ajoutée

Une page qui se limite à un titre H1 et deux phrases génériques n’a aucune raison de se classer, même avec un excellent maillage. Chaque page pSEO doit répondre concrètement à l’intention de recherche : données chiffrées, exemples concrets, FAQ ciblée.

Si une entité de votre base n’a pas assez de matière pour justifier une page à part entière, il vaut souvent mieux la regrouper avec d’autres plutôt que de publier une coquille vide.

La cannibalisation SEO

Générer des pages trop proches sémantiquement (ex : “plombier” et “plombier chauffagiste” avec un contenu quasi identique) crée une concurrence interne : Google hésite entre les deux et peut pénaliser les deux au lieu d’en classer une.

Avant de générer massivement, il faut valider en amont, via un outil de recherche de mots-clés, que chaque entité correspond bien à une intention de recherche distincte, et fusionner les entités trop proches en une seule page.

L’absence de page d’archive

Comme détaillé plus haut, générer des pages enfants sans hub qui les regroupe et les relie depuis les pages à forte autorité du site limite mécaniquement leur potentiel d’indexation et de classement, même si le contenu de chaque page est par ailleurs irréprochable.

C’est un piège facile à éviter dès la conception : prévoyez la page d’archive en même temps que le template de page enfant, pas après coup.

Conclusion

Le programmatic SEO n’est pas une astuce de croissance rapide, c’est une discipline d’ingénierie de contenu : données structurées en amont, template capable de produire une vraie variation de contenu, et une infrastructure (SSG, sitemap dynamique, maillage interne, page d’archive) qui suit le rythme de la base plutôt que l’inverse.

Bien exécuté, il transforme une table SQL en un actif SEO qui continue de croître à mesure que les données s’enrichissent. Si vous voulez creuser la partie base de données derrière ce genre d’architecture, la formation Modélisation de bases de données relationnelles et la formation Supabase couvrent les fondations nécessaires pour construire ce type de source de données proprement.

FAQ

Le programmatic SEO est-il pénalisé par Google ?

Non, à condition que chaque page apporte une valeur réelle et un contenu différencié. Google pénalise le thin content et le duplicate content, pas la génération automatisée en tant que telle. De nombreux sites à fort trafic (Zapier, Canva, TripAdvisor) reposent massivement sur du pSEO bien exécuté.

Combien de pages minimum pour que le programmatic SEO soit rentable ?

Il n’y a pas de seuil strict, mais en dessous d’une trentaine d’entités, la rédaction manuelle reste souvent plus simple à maîtriser. Le pSEO devient pertinent dès que le volume d’entités (villes, métiers, produits) rend la rédaction unitaire impossible à tenir dans le temps.

Faut-il du SSG ou du SSR pour du programmatic SEO ?

Le SSG (Static Site Generation) est généralement préférable pour du pSEO : pages servies instantanément, coût serveur maîtrisé même sur des milliers de pages, et un contenu qui ne dépend pas de la disponibilité d’une API au moment du crawl. Le SSR reste pertinent si les données changent très fréquemment.

Une page d’archive est-elle vraiment nécessaire si j’ai un sitemap ?

Oui : le sitemap aide au crawl, mais ne transmet pas d’autorité de lien et n’est pas visible par les utilisateurs. Une page d’archive HTML, liée depuis la navigation, fait circuler le PageRank interne vers les pages enfants et leur donne un point d’entrée organisé — un rôle que le sitemap ne remplit pas.