Un SEO programmatique qui résiste à la mise à jour « Helpful Content », développé par l'opérateur à l'origine de HostList.io.

J'ai lancé HostList début 2024 en tant que projet parallèle. L'idée était assez simple : répertorier tous les hébergeurs web présents sur Internet, consacrer à chacun d'entre eux une véritable page accompagnée d'un avis authentique, et permettre aux utilisateurs de comparer les hébergeurs comme ils le souhaitent réellement. Deux ans et demi plus tard, le site compte environ vingt-huit mille pages, toutes générées automatiquement à partir d'une source de données structurée, et j'ai personnellement vu le site traverser toutes les mises à jour de Google « Helpful Content » qui lui ont été imposées.

Ce que personne ne vous dit quand vous lancez un site programmatique, c’est que le travail est principalement éditorial, et non technique. La partie Next.js se met en place en quelques semaines. Le schéma Supabase, le pipeline d’ingestion, le plan du site en streaming, l’émetteur schema.org : tout cela relève de l’ingénierie. Ce qui prend le reste de l’année, c’est de déterminer lesquelles de vos vingt-huit mille lignes méritent réellement de figurer dans l’index, et ce que vous devez ajouter au modèle pour que chacune de ces lignes s’affiche comme une véritable page, plutôt que comme un simple extrait de base de données aux ambitions SEO.

J'en suis venu à considérer le SEO programmatique comme une discipline de la soustraction. La tendance naturelle est de publier toutes les lignes. La bonne approche consiste à ne publier que celles qui méritent leur place, puis à les inscrire dans un contexte éditorial suffisamment riche pour que la page ait une raison d'être au-delà du simple remplissage d'un plan du site. Si vous maîtrisez ces deux aspects, Google vous laissera tranquille lors des mises à jour majeures. Si vous en ratez ne serait-ce qu'un, vous perdrez la plupart de vos pages indexées en l'espace de deux trimestres.

Voici la procédure que j'applique quotidiennement sur HostList, et que j'utilise de la même manière pour les projets de mes clients. Il ne s'agit pas d'un argumentaire commercial, mais bien d'une véritable liste de contrôle.

La plupart des idées qui me sont présentées comme relevant de la programmatique ne devraient pas l'être. Pour faire le tri lors de l'entretien téléphonique, je me demande si l'ensemble de données est réellement intéressant et si les recherches sont véritablement dispersées sur la « longue traîne ». Ces deux conditions doivent être remplies. Si l'ensemble de données n'est qu'un appât SEO et que les recherches ne se produisent pas réellement sur la « longue traîne » que vous imaginez, la programmatique n'est pas la bonne approche et persévérer malgré tout vous coûtera vos pages indexées d'ici six mois.

Une poignée de modèles fonctionnent en 2026, et leur champ d’application est assez restreint. Les sites comparatifs fonctionnent parce que l’internaute connaît déjà les noms en jeu et cherche simplement à trancher : Notion contre Linear, Stripe contre Adyen, Cloudways contre Kinsta. Les pages de localisation fonctionnent parce que les intentions de recherche locales sont fondamentalement fragmentées et que presque personne ne les rédige manuellement à grande échelle. Les annuaires sectoriels fonctionnent lorsque la combinaison « entité × filtre » génère des requêtes avec un volume réel ; HostList est justement construit autour de ce modèle, c’est pourquoi je connais les causes d’échec pour l’avoir exploité. Les pages de glossaire fonctionnent lorsque le terme est suffisamment technique pour que les réponses existantes sur le Web soient insuffisantes. Les pages de calculateurs fonctionnent lorsque le calcul lui-même, associé à une page expliquant la méthodologie en dessous, constitue la véritable valeur ajoutée pour l’internaute.

Tout ce qu’on me propose d’autre, c’est la mauvaise version. La version « on veut un million de pages de contenu générique portant notre marque », généralement présentée comme une expérience de croissance censée multiplier par dix le trafic organique en un trimestre. Google s’est montré particulièrement intransigeant à ce sujet depuis la mise à jour « Helpful Content » fin 2022, et les vagues de désindexation n’ont fait que s’accélérer depuis. J’ai vu cinq équipes différentes tenter cette approche programmatique paresseuse au cours des deux dernières années ; toutes les cinq ont perdu la majeure partie de leurs pages indexées en l’espace de deux trimestres. Je préfère désormais refuser ce type de projet plutôt que de le livrer, ce qui est délicat lors des entretiens commerciaux, mais plus équitable pour tout le monde à long terme.

Trois filtres sont appliqués lors de la génération du plan du site, avant que la moindre page n'y figure. Il s'agit d'un processus automatisé et non d'une vérification manuelle, car avec trente mille URL, une vérification manuelle ne constitue pas réellement une vérification, et prétendre le contraire ne fait que retarder la désindexation.

Le premier critère concerne les données uniques. Prenons l’exemple d’une page sur l’hébergement WordPress géré par Cloudways sur HostList. Elle doit comporter au moins trois éléments spécifiques à Cloudways : une fourchette de prix, une liste de fonctionnalités, une région, une société mère et un cas d’utilisation. Tout ce qui ne s’applique pas également à Kinsta ou à WP Engine. Si la page ne comporte qu’un nom, un logo et une description générique, elle ne franchit pas cette étape. Elle est alors exclue du plan du site et marquée comme « noindex » dans le code source. La couche de données se complète au fur et à mesure que l’équipe enrichit la ligne, puis la page réintègre l’index. Actuellement, sur HostList, environ 15 % de la base de données reste exclue du plan du site précisément pour cette raison.

La deuxième étape, c’est la valeur ajoutée éditoriale. Le modèle doit permettre de faire ce que les données seules ne peuvent pas faire : comparaison, notation, recommandation, agrégation, avantages et inconvénients. Un modèle qui se contente d’afficher les lignes de la base de données avec une belle mise en page ne suffit pas, même si celle-ci est de bonne qualité. C’est à cette étape que les équipes échouent le plus souvent dans la pratique. Elles mettent en place un système d’ingestion ingénieux, négligent la présentation éditoriale, publient deux mille pages qui se ressemblent toutes sous le même mot-clé, puis se demandent pourquoi Google les désindexe six mois plus tard. C’est la présentation qui signale à Google que la page existe pour une raison qui va au-delà du simple remplissage d’un plan du site.

La troisième étape concerne l’intention réelle de la requête. Chaque URL doit correspondre à une requête que quelqu’un est susceptible de rechercher, avec un volume suffisant pour justifier son indexation. Les pages ciblant des requêtes générant moins de cinquante recherches mensuelles ne sont généralement pas indexées, même si elles franchissent les deux premières étapes, car elles encombrent le plan du site et diluent le budget d’exploration destiné aux pages performantes du même domaine. Ce seuil varie selon le secteur d’activité ; nous l’ajustons au cas par cas après avoir examiné les données de la Search Console relatives à des sites voisins du même secteur.

La première chose que j'ai supprimée de l'index, c'est la partie superflue. Environ 15 % de la base de données ne figure pas dans le plan du site, car le seuil de données uniques n'a pas été atteint. Une ligne ne contenant qu’un nom, un logo et une description générique d’une ligne n’est pas une page que Google devrait prendre en compte ; le coût de son exploration est supérieur à l’intérêt de son indexation. Les pages de catégories comportant moins de cinq entrées pertinentes sont également exclues, car une catégorie peu fournie est perçue comme un effort minimal, même lorsque le schéma est techniquement correct. Les combinaisons de filtres donnant moins de trois résultats se voient automatiquement attribuer l’attribut « noindex » lors d’une vérification effectuée au moment de la compilation.

Ce que j’ai conservé et développé, c’est la comparaison. Les pages de comparaison directe entre des hébergeurs spécifiques se sont avérées être le type de page générant le plus de conversions sur le site, représentant environ 30 % de l’ensemble des conversions alors qu’elles ne représentaient que moins de 5 % du nombre total d’URL. J’ai ajouté la comparaison sous forme de modèle distinct et je l’ai délibérément développée. Les pages de catégories contenant des données uniques et pertinentes ont également largement surpassé les versions génériques. Pas seulement « le meilleur hébergement WordPress », mais « le meilleur hébergement WordPress pour les boutiques WooCommerce comptant moins de dix mille produits ». Spécifique. Précis. Utile. Plus le critère de sélection était précis, meilleures étaient généralement les performances de la page, ce qui va à l’encontre de la plupart des conseils en SEO que l’on trouve en ligne.

Les pages que j’ai conservées sous forme manuscrite constituaient le centre de gravité. Environ deux cents des vingt-huit mille pages sont des articles rédactionnels entièrement rédigés à la main. La page consacrée à la méthodologie. La grille d’évaluation. Le guide « Comment choisir un hébergeur ». Une poignée de pages d'accueil de catégories très performantes. Elles ne sont pas générées automatiquement et n’ont jamais été conçues pour l’être, mais elles ont un poids disproportionné dans le graphique d’autorité thématique et chaque page de détail renvoie vers elles. Les vingt-sept mille huit cents pages générées automatiquement gravitent autour de ces deux cents. C’est cette structure qui résiste à une mise à jour du noyau.

La couche de données repose sur Postgres, soit via Supabase, soit en auto-hébergement, selon ce que l’équipe utilise déjà. Chaque colonne de facette est correctement indexée, car à grande échelle, les balayages complets de la table lors d’une requête filtrée deviennent le goulot d’étranglement avant même que la page elle-même ne soit lente. Chaque type de contenu dispose d’une table d’entités dédiée comprenant, outre le contenu proprement dit, des colonnes de contrôle qualité : score d’unicité, pourcentage d’exhaustivité et horodatage de la dernière vérification. Une vue d’éligibilité au plan du site filtre automatiquement les lignes inférieures au seuil, ce qui permet au plan du site et aux données sous-jacentes de rester synchronisés sans intervention manuelle.

Les modèles se déclinent en quatre formats. Un modèle de détail par type d’entité, comportant des champs dédiés aux données spécifiques ainsi que la mise en forme rédactionnelle. Un modèle de comparaison permettant de mettre en parallèle des entités nommées, avec le schéma « FAQPage » associé ; l’attribut « AggregateRating » ne doit jamais être utilisé, sauf si des avis provenant directement de la source existent réellement. Un modèle de catégorie et de filtre utilisant CollectionPage avec une ItemList d’entités éligibles, paginée avec une gestion canonique appropriée afin que les combinaisons de filtres ne génèrent pas d’URL en double à l’infini. Et des modèles rédactionnels utilisant le schéma Article, rédigés à la main, en plus petit nombre mais avec un poids thématique plus élevé, considérés comme la colonne vertébrale du graphe de liens plutôt que comme ses feuilles.

L’architecture SEO est l’aspect que la plupart des équipes sous-estiment à grande échelle. Le plan du site est généré par blocs, par modèle, car un seul fichier sitemap.xml est limité à cinquante mille URL et la plupart des projets programmatiques dépassent ce seuil dès la première année. Les liens internes sont générés à partir des données elles-mêmes : chaque page-feuille renvoie vers sa catégorie, son emplacement, ses concurrents désignés et des entités similaires en fonction des chevauchements de fonctionnalités. Un linter SEO intégré à la phase de compilation échantillonne un échantillon de pages à chaque déploiement et fait échouer la compilation en cas d’anomalie dans le nombre de balises H1, de méta-description hors limites, d’erreur de validité JSON-LD ou de problème d’intégrité du cluster hreflang. Après le lancement, le suivi des citations par AI Overview via Otterly ou Profound s’exécute chaque semaine afin de détecter quand un moteur de recherche génératif commence ou cesse de citer une page du domaine.

Chaque offre comprend l'infrastructure de données, les modèles, l'outil de vérification SEO et un tableau de bord d'administration de base permettant d'effectuer des modifications éditoriales. Elle n'inclut pas l'acquisition des données proprement dite. Le travail éditorial manuel, l’infrastructure de scraping, les coûts liés aux API tierces, ainsi que le travail original sur la marque et le design constituent autant de postes budgétaires distincts. L’acquisition de trafic payant n’est pas non plus incluse ; le SEO programmatique s’inscrit dans une démarche organique et nous n’intégrons pas les médias payants dans la prestation. La plupart des projets se situent sans difficulté dans la moitié inférieure de chaque fourchette ; la moitié supérieure est réservée aux projets véritablement complexes, où l’ingestion de données ou la couche éditoriale est particulièrement lourde.