Des répertoires web qui survivent à 28 000 pages sans pénalités de contenu fin.

À peu près n'importe quelle forme d'annuaire, à partir d'une source de données structurées. Au cours des deux dernières années, les modèles que j'ai déployés se divisent en quatre grands types, et la plupart des projets clients sont une variante de l'un d'eux.

Les annuaires sectoriels listent les entreprises d'un domaine vertical, segmentés par catégorie, localisation, taille et ensemble de fonctionnalités. HostList.io est l'exemple canonical que je gère moi-même — environ vingt-huit mille entreprises d'hébergement web, découpées par type d'hébergement, région, gamme de prix et cas d'usage. Les acheteurs trouvent des fournisseurs, les fournisseurs génèrent du trafic, et l'annuaire lui-même se monétise par des placements sponsorisés, des liens d'affiliation ou des listes premium payantes selon ce qui convient au secteur.

Les annuaires locaux et géographiques constituent le deuxième modèle. Guides de restaurants, guides de pubs, annuaires de dentistes, annuaires d'entrepreneurs. Chaque fiche contient un balisage LocalBusiness avec coordonnées géographiques, horaires d'ouverture et évaluations si vous avez les droits sur les données. Des pages ville-et-catégorie programmatiques — « meilleurs restaurants italiens à Manchester » ou « pubs à Stoke Newington » — fournissent l'essentiel de la surface SEO en longue traîne sur ces sites.

Les annuaires d'outils et de logiciels listent les produits logiciels dans une catégorie. Outils CRM. Applications de gestion de projet. Plateformes no-code. Outils IA. Le moteur de trafic sur ceux-ci est constitué de pages de comparaison — Notion contre Linear contre ClickUp — et de pages de matrice de fonctionnalités, où le chercheur connaît déjà les noms et veut juste un élément décisif.

Les annuaires de personnes et de services constituent le quatrième modèle. Agences. Freelancers. Consultants. Photographes. Avocats. Le défi avec celui-ci, c'est que la plupart des annuaires de personnes meurent parce que les fiches deviennent obsolètes et personne ne les met à jour. Nous intégrons des workflows d'expiration et une édition de profil en libre-service dès le premier jour du projet plutôt que de l'ajouter rétroactivement plus tard.

HostList.io est l'annuaire que j'ai construit seul pour cataloguer l'ensemble de l'industrie de l'hébergement web. Environ vingt-huit mille pages d'entreprises d'hébergement, en ligne depuis le printemps 2024, sur la même pile Next.js plus Supabase plus Vercel que nous utilisons maintenant pour les constructions d'annuaires clients.

Ce que HostList fait, c'est cataloguer chaque entreprise d'hébergement web que nous pouvons vérifier, segmentée par type — mutualisé, VPS, WordPress géré, cloud, dédié, revente — région, gamme de prix et cas d'usage. Il y a des pages de comparaison entre des hébergeurs spécifiques, des pages de catégorie pour chaque segment, une interface de recherche et filtrage qui gère l'ensemble de données de vingt-huit mille lignes sans latence de requête, un balisage de schéma sur chaque fiche, et un sitemap en streaming parce que le nombre d'URL dépasse déjà ce qu'un seul sitemap.xml peut contenir.

Trois enseignements de son exploitation façonnent maintenant chaque construction d'annuaire client. Premièrement, la qualité des données est tout le jeu. Les pages avec trois points de données uniques au-delà du nom de l'entité survivent aux mises à jour de Google ; les pages avec seulement un nom et une description générique se font désindexer. Deuxièmement, le maillage interne compte plus que les backlinks à cette échelle. Le graphe de liens entre les fiches, les catégories et les pages de comparaison détermine quelles pages feuilles se font crawler assez souvent pour rester indexées. Troisièmement, programmatique ne signifie pas paresseux. Chaque page doit avoir une raison d'exister, et « nous avons une ligne dans la base de données » n'est pas une raison.

Nous avons gardé environ quinze pour cent de la base de données hors index parce que le seuil de données uniques n'était pas atteint sur ces lignes. Nous avons coupé les pages de catégorie qui avaient moins de cinq fiches solides parce qu'elles paraissaient minces même quand le balisage sous-jacent était correct. Nous avons ajouté des pages de comparaison entre concurrents nommés comme un type de page séparé, et ce modèle s'est avéré être l'un des trafics à la meilleure conversion sur le site. Le même playbook est maintenant standard sur chaque annuaire que nous déployons pour les clients.

Plus d'annuaires meurent qu'ils ne survivent, et les modes de défaillance sont assez prévisibles pour que je puisse généralement dire dès le premier appel vers quel mode un projet se dirige.

Le déréférencement de contenu mince est l'échec le plus courant. Un annuaire se lance avec cinq mille annonces, la moitié n'a qu'un nom et une description d'une ligne, et Google indexe les quinze cents premières pages puis s'arrête. Le site se lit comme un raclage de faible effort. Six mois plus tard, la plupart des pages indexées sont déréférencées lors d'une mise à jour principale. Le correctif doit intervenir au moment de la collecte de données — chaque ligne a besoin de trois points de données uniques avant de qualifier pour le sitemap, pas « on le remplira plus tard ».

La dérive des données obsolètes est le deuxième schéma. Un annuaire qui listait des entreprises exactes en 2023 liste des entreprises semi-défuntes en 2026 parce que personne n'a mis à jour les lignes, les informations de contact deviennent obsolètes, les sites web se resolvent vers des pages d'attente, et l'annuaire perd le signal de confiance auprès de Google et des visiteurs humains. Nous mettons en place des flux d'édition participative où l'entreprise listée peut revendiquer et modifier son profil, des vérifications automatisées de fraîcheur qui désactivent les annonces mortes, ou les deux. Sans une couche de fraîcheur, l'annuaire vieillit en dehors de la pertinence peu importe la qualité des données originales.

Pas de fossé est le troisième schéma. Trois annuaires concurrents couvrent le même secteur vertical avec des données similaires. Aucun n'a de données uniques, donc aucun n'a une raison défendable d'exister. La part de recherche se fragmente et aucun d'eux ne classe. Le correctif est la couche éditoriale — analyse originale, notation, recommandations, cadres de comparaison — que les données sous-jacentes seules ne peuvent pas fournir. HostList concurrence sur sa rubrique de notation, pas sur sa liste d'hébergeurs, parce que la liste d'hébergeurs elle-même n'est pas particulièrement défendable.

Le gonflement d'index par les filtres est le quatrième schéma. Un annuaire avec huit dimensions de filtres peut techniquement générer des millions de combinaisons d'URL. Si chaque combinaison est indexable, vous inondez Google de pages minces et diluez les fortes. Nous bloquons toujours les combinaisons de filtres minces de l'index — tout ce qui a moins de trois annonces obtient noindex, tout ce qui n'a pas d'intention de requête réelle comme les ordres de tri ou la page 2 et au-delà obtient noindex, et seules les combinaisons de filtres canoniques qui correspondent à des recherches réelles restent indexables.

Une architecture de référence pour un annuaire se livre avec cinq couches. Chaque projet flexibilise les spécificités, mais la colonne vertébrale se répète dans les versions.

La couche de données est Postgres via Supabase ou auto-hébergée, avec des index appropriés sur chaque colonne de facette. Il y a une table d'annonces dédiée par type d'entité — entreprises, produits, emplacements, personnes — et des colonnes de porte de qualité à côté du contenu (score d'unicité, pourcentage de complétude, horodatage de la dernière vérification). Une vue d'éligibilité du sitemap filtre automatiquement les lignes en dessous du seuil de qualité.

Les modèles de page se divisent en une page de détail d'annonce (données complètes, annonces associées, schéma, fil d'Ariane), une page de catégorie (liste paginée avec interface de filtrage et schéma ItemList), une page de comparaison pour comparer côte à côte des entités nommées, une page de localisation avec intégration de carte et schéma géo où la géographie importe, et des pages à propos et méthodologie qui portent le poids éditorial original que les données sous-jacentes ne peuvent pas fournir.

La recherche et le filtrage utilisent la recherche en texte intégral Postgres jusqu'à environ dix mille annonces, puis Algolia ou Meilisearch pour les plus grands annuaires avec des exigences de faible latence de requête. Les URL de filtre rendues côté serveur donnent à chaque combinaison de filtres une canonique, et noindex sur les combinaisons minces ou dupliquées empêche le gonflement d'index. La soumission et la modération obtiennent un formulaire de soumission public où le modèle est nourri par la foule, une file d'attente d'admin avec les scores de porte de qualité affichés pour l'examen du modérateur, des e-mails de rejet modélisés avec des raisons spécifiques, et un flux d'édition en libre-service pour les entités listées de revendiquer et mettre à jour leur propre profil.

L'échafaudage SEO est la couche qui décide si l'annuaire survit. Sitemap en streaming avec un motif de morceau par modèle, schema.org Organization ou Product ou Place ou Service ou LocalBusiness sur chaque annonce selon le cas, CollectionPage avec ItemList sur les pages de catégorie, BreadcrumbList partout, URL canonique émise d'une source unique de vérité (la base de données, pas le modèle), et un linter SEO en temps de construction qui fait échouer la construction sur H1 manquant, descriptions de méta surdimensionnées, ou JSON-LD invalide.

La monétisation passe par les annonces en vedette (un drapeau booléen promeut une ligne au sommet des pages de catégorie), les placements de catégorie sponsorisés (une marque possède le sommet d'une catégorie pour une période de facturation), le suivi des liens d'affiliation avec l'attribution appropriée rel="sponsored", et les niveaux premium payants pour les entités listées pour obtenir un meilleur positionnement, plus de champs de données enrichies, et l'accès aux analyses.

La variable la plus déterminante dans un projet d'annuaire est la source de données elle-même. La plupart des engagements réussissent ou échouent sur la réponse à une seule question : d'où proviendront les données le jour du lancement, et comment resteront-elles à jour après la mise en ligne ?

L'édition manuelle signifie qu'une équipe rédige chaque annonce. C'est lent, coûteux, mais défendable. Convient pour moins de mille annonces. Parmi les exemples qui fonctionnent : les guides hôteliers haut de gamme, les répertoires d'agences curés, les sites éditoriaux de niche où le fait d'être listé constitue en lui-même la valeur.

L'importation structurée signifie que vous apportez un export CSV ou base de données d'une source fiable, et nous nettoyons, dédupliquons, enrichissons et ingérons les données. Convient pour mille à cent mille annonces. Exemples : répertoires sectoriels avec données publiques, imports de registres gouvernementaux, exports de type Companies House.

Le scraping automatisé ou l'API signifie que les annonces sont peuplées à partir d'une API tierce ou d'un pipeline de scraping respectueux. Dépend légalement et éthiquement de la source. Convient pour dix mille à des millions d'annonces où les données se trouvent dans un endroit canonique connu. Exemples : répertoires d'outils pour développeurs tirés de GitHub, critiques d'hébergement scrapées à partir d'avis publics sur les sites des entreprises elles-mêmes.

Les annonces soumises par les utilisateurs signifient que les annonces proviennent des personnes listées. Peu cher à lancer, cher à modérer. Fonctionne mieux comme une couche en plus de données éditoriales de base, pas comme seule source. Le pattern hybride (seed éditorial plus importation structurée plus révision éditoriale annuelle) est ce que HostList utilise et ce que la plupart des vrais annuaires finissent par faire, qu'ils l'aient planifié ou non.

Lors du premier appel, nous vous demanderons quelle combinaison correspond à votre réalité de données. Si vous n'avez pas de réponse claire, la question des données est elle-même la première phase du travail ; le build vient après.

Des fourchettes honnêtes basées sur des engagements réels récents plutôt que sur une tarification aspirationnelle sur un pitch de vente. Un petit annuaire éditorial de moins de mille annonces coûte dix-huit à trente-cinq mille dollars US sur six à neuf semaines. Un annuaire de taille moyenne de mille à dix mille annonces avec une importation de données structurée coûte trente à soixante mille sur dix à quatorze semaines. Un grand annuaire de dix à cent mille annonces, programmé à grande échelle, coûte cinquante à quatre-vingt-dix mille sur douze à dix-huit semaines. Une forme de marketplace — biface, avec réservations ou transactions — coûte soixante à cent cinquante mille sur quatorze à vingt-deux semaines.

Toutes les fourchettes incluent l'armature SEO (schema, sitemap, linter), la couche de recherche et filtrage, et un tableau de bord admin basique. Elles n'incluent pas l'acquisition de données elle-même (édition manuelle, infrastructure de scraping, coûts d'API tiers), le travail original de marque et de design, ou l'acquisition de trafic payant. Les plans de care pour l'opération continue coûtent cinq cents à trois mille dollars US par mois après le lancement.