Quelque part autour du numéro d'hébergeur 11 000, j'ai sérieusement remis en question chaque décision que j'avais jamais prise. Pas de manière dramatique, plutôt cette crainte tranquille et précise de réaliser qu'on s'est enfermé dans un coin avec un dataset qui continue de croître et un schéma conçu pour peut-être 500 entrées. C'était HostList. Un annuaire d'hébergeurs web. Tous, ou presque autant que je pouvais en trouver.
Je vais vous raconter ce qui s'est réellement passé, les choix architecturaux, les cauchemars de données, les moments où ça s'est déclenché, et les parties que je ferais complètement différemment si je commençais aujourd'hui.
Pourquoi un annuaire d'hébergement web
Honnêtement ? Je me suis énervé. Je faisais de la recherche pour un client Seahawk Media, une SaaS de taille intermédiaire qui avait besoin de migrer d'hébergeur, et je ne trouvais pas un seul annuaire qui soit à la fois complet et à jour. La plupart étaient soit des pages d'affiliation minces se prétendant neutres, soit des listes obsolètes qui présentaient encore des hébergeurs qui avaient fermé en 2017.
L'industrie de l'hébergement web compte des milliers de fournisseurs actifs. Pas des dizaines. Des milliers. Hébergement mutualisé, hébergement WordPress géré, fournisseurs VPS, spécialistes de bare-metal, acteurs régionaux dont vous n'avez jamais entendu parler. Personne ne l'avait correctement cartographié. Alors j'ai pensé : je vais le faire. Six semaines, me suis-je dit.
Cela a pris considérablement plus de six semaines.
Le marché a validé l'intuition, cependant. Regardez ce que les annuaires de niche peuvent faire même à petite échelle, Soak Oregon, un simple annuaire de sources chaudes, génère à peu près 1 000 dollars par mois en revenus publicitaires sur seulement 25 000 visiteurs mensuels. Ce n'est pas une faute de frappe. 25 000 visiteurs. L'économie d'un annuaire bien ciblé est vraiment différente de celle d'un site de contenu généraliste.
Le problème des données dont personne ne parle
C'est là que la plupart des guides de création d'annuaires vous laissent complètement tomber. Ils vous diront de configurer des catégories et des champs de listing. D'accord. Ce qu'ils ne vous diront pas, c'est que rassembler 25 000 enregistrements précis et structurés est un problème d'une classe entièrement différente.
Ma première approche était la recherche manuelle plus une couche de scraping que j'ai bricolée en un week-end. Le scraper allait bien. Les données étaient le chaos. Les prestataires d'hébergement changent leurs tarifs constamment. Certains avaient trois noms de marque différents. Certains étaient des revendeurs de revendeurs, la même infrastructure sous-jacente portant quinze logos différents. La déduplikation seule m'a coûté trois semaines.
Quelques choses que j'aurais aimé décider plus tôt :
- Un enregistrement canonique par entité juridique, pas par marque. Certains hébergeurs ont quatre marques. Ce sont toujours un seul hébergeur.
- Dating de fraîcheur sur chaque champ. Pas juste « dernière mise à jour » sur la ligne, par champ. Les tarifs deviennent obsolètes plus vite que les ensembles de fonctionnalités.
- Une file d'attente d'examen humain dès le départ. L'ingestion automatisée convient pour une première passe. Mais il vous faut un processus pour signaler les enregistrements qui semblent incorrects avant qu'ils ne soient publiés.
Le troisième point surtout. J'ai sauté dessus au début et j'ai fini avec un tas de listings qui avaient des niveaux de tarification complètement erronés parce qu'un hébergeur avait réorganisé ses plans et le scraper avait fait correspondre l'ancienne structure de page. Cela m'a pris une éternité à trouver.
Choisir la bonne pile technologique
J'ai opté pour WordPress. Je sais. Mais écoutez-moi.
Pour un annuaire à cette échelle, vous voulez quelque chose avec un écosystème de plugins mature et une couche de requête que vous comprenez en profondeur. J'avais utilisé Directorist sur des projets plus petits et ça a bien tenu, schéma flexible, fonctionne avec Gutenberg, paramètres sensés. Pour HostList spécifiquement, je l'ai associé à une couche de type de publication personnalisée par-dessus, parce que j'avais besoin de champs qu'aucun plugin prêt à l'emploi n'anticipait (des choses comme les emplacements des centres de données, les arrangements de peering, les versions de panneau de contrôle).
Les quatre pages qui comptent vraiment, et je dirais que c'est vrai pour tout annuaire quel que soit le créneau, sont :
- Accueil avec un objectif clair, des annonces en vedette, et une recherche très simple
- Page d'archive/navigation avec filtrage rapide (c'est là que vivent 80 % de vos utilisateurs)
- Annonce unique avec l'enregistrement complet, le balisage de données structurées, et un moyen de réclamer/signaler
- Page de soumission (même si vous ne faites pas de soumissions d'utilisateurs initialement, construisez-la prête)
Je ne peux pas assez insister sur l'importance de la page archive. Les utilisateurs ne viennent pas à votre page d'accueil puis naviguent. Ils arrivent sur une page archive depuis Google et décident en quatre secondes si les données semblent crédibles. Réglez d'abord cette page correctement.
Ce que je changerais dans la pile technologique
Tables personnalisées. J'aurais dû sortir les données de listing principal de post meta et les mettre dans de véritables tables relationnelles beaucoup plus tôt. WordPress post meta convient jusqu'à peut-être 5 000 enregistrements. Au-delà, les requêtes deviennent pénibles. Les considérations de performance pour les applications web à grande échelle sont réelles, RAM, optimisation des requêtes, stratégie de cache, rien dont vous ne planifiez quand vous essayez juste de lancer la chose.
Héberger le répertoire lui-même (véritablement maladroit)
Il y a une ironie particulière à construire un répertoire d'hébergement web et à devoir ensuite choisir un hôte pour celui-ci. J'ai changé trois hôtes au cours de la première année.
Le premier était un hébergeur WordPress géré que je ne nommerai pas. Il a plié sous le processus d'import, 25 000 posts entrant via WP-CLI n'était pas quelque chose pour lequel leur infrastructure était conçue. Le second était un VPS où j'ai tout géré moi-même : Nginx en tant que reverse proxy, Redis pour la mise en cache d'objets, ufw pour le pare-feu. Cette approche d'architecture auto-hébergée fonctionne brillamment quand tu sais ce que tu fais, visibilité totale, pas de limitation mystérieuse, tu contrôles les en-têtes de cache. Mais c'est aussi 23h le jeudi quand quelque chose se casse et c'est entièrement ton problème.
J'ai opté pour un VPS géré avec accès root. Le meilleur des deux. J'ai gardé Nginx devant, ajouté une couche CDN pour les actifs statiques, et cela a tenu depuis.
La leçon : quel que soit l'hébergeur que vous choisissez, testez-le avec votre volume de données réel avant de vous engager. Pas un échantillon. Votre vrai import. Un hébergeur qui gère un blog de 500 posts sans souci va parfois s'effondrer complètement quand vous lui jetez 25 000 enregistrements dessus pendant une reconstruction de base de données.
Monétisation : Ce que j'ai essayé, Ce qui a fonctionné
En 2019, un client m'a une fois dit, « l'argent est dans la liste, pas le trafic. » Je ne l'ai pas complètement compris à l'époque. Je comprends maintenant.
Le revenu d'Hostlist provient de plusieurs endroits, en ordre approximatif de ce qui a vraiment fait bouger les choses :
- Annonces en vedette/premium, les hébergeurs paient pour apparaître en haut des pages de catégories pertinentes. Ça marche. Les CPM sont bons parce que l'intention est élevée.
- Badges vérifiés avec renouvellement annuel, approche moins invasive qu'une annonce premium complète, mais ça s'accumule.
- Publicité display, j'ai ajouté cela tardivement et c'est le plus faible performer de beaucoup. L'audience est trop petite et trop spécifique pour que les réseaux publicitaires larges la valorisent correctement.
- Lead gen / affiliate, j'ai été prudent ici parce que je ne voulais pas que HostList ressemble à tous les autres sites de comparaison biaisés. J'ai un petit nombre d'arrangements de parrainage mais ils sont divulgués et limités.
Ce que je n'ai pas fait, c'est un modèle freemium où les annonces de base sont gratuites et les mises à niveau payantes. J'y ai pensé. Le problème avec l'hébergement web spécifiquement, c'est que les fournisseurs qui valent la peine d'être sur votre plateforme sont aussi ceux qui ont le moins besoin de votre annuaire pour la visibilité. Les petits hébergeurs en tirent plus profit en étant listés, mais ce sont aussi ceux avec les plus petits budgets. L'économie est maladroite.
Brilliant Directories et des plateformes similaires ont compris cela pour les annuaires plus orientés communauté, prestataires de mariage, ressources parentales, où les membres veulent vraiment être trouvés par les locaux. L'hébergement web est différent. C'est un marché global et hyper-compétitif.
SEO pour un Grand Annuaire : Les Points Qui Ont Vraiment Aidé
Un annuaire avec 25 000 entrées est un atout SEO si vous le gérez correctement. C'est un handicap SEO si vous ne le faites pas.
Les choses spécifiques qui ont aidé :
- Descriptions meta uniques, basées sur des modèles mais variables par annonce, pas juste le nom de l'hôte + « examen d'hébergement web ». J'ai intégré des points de données réels (gamme de prix, cas d'usage principal, année de fondation) pour générer des descriptions qui étaient vraiment différentes.
- Pages de catégories et d'étiquettes avec du contenu éditorial réel, pas juste une grille de cartes. Une intro de 200 mots expliquant ce que « l'hébergement WordPress géré » signifie réellement, rédigée une fois, appliquée à la catégorie. Google veut voir que quelqu'un a réfléchi à la page.
- Données structurées (Schema.org), chaque annonce a un balisage LocalBusiness ou Organization. Les taux de clics se sont améliorés sensiblement après que j'ai ajouté cela correctement.
- Canoniques sur les combinaisons de filtres, cela m'a presque tué. La recherche à facettes génère des milliers de combinaisons d'URL. Si tu ne les canonises pas vers l'URL d'archive propre, tu seras en faillite de budget de crawl en un mois.
- Les annonces indexées uniquement pour les hébergeurs actifs, je mets en noindex tout ce que je ne peux pas confirmer comme encore opérationnel. Les annonces mortes sont pires que l'absence d'annonces.
L'erreur que j'ai commise au début : j'ai indexé tout immédiatement. Y compris des ébauches avec presque aucune donnée. Google les a explorées, trouvé des pages minces, et a partiellement dévalué tout le domaine pendant un temps. Leçon : ne l'indexe pas tant que ça ne vaut pas la peine de l'indexer.
Ce que je ferais différemment
Quelques choses, rapidement :
- Commencer par une niche plus petite et plus resserrée d'abord. « Répertoire d'hébergement web » c'est énorme. J'aurais dû lancer avec « hébergeurs WordPress gérés », peut-être 300-400 entrées, prouver le concept, puis élargir.
- Construisez le pipeline de données avant le front end. Je l'ai fait à l'envers. Le front end était en ligne avant que le processus d'import soit solide, ce qui a signifié que je patchais constamment les données en direct.
- Facturez les annonces dès le premier jour. Même 1 £/mois. Les annonces gratuites attirent les hôtes qui remplissent mal le formulaire et ne répondent jamais aux demandes de mise à jour. Un petit paiement filtre pour la qualité.
- Investissez dans un système de contributeurs approprié plus tôt. Certaines des meilleures corrections de données que j'ai reçues provenaient d'utilisateurs qui ont repéré des erreurs. Je n'avais aucun moyen structuré d'accepter celles-ci pendant les huit premiers mois.
Honnêtement, construire HostList a été l'un des projets secondaires les plus intéressants techniquement sur lequel j'ai travaillé, et l'un des plus humiliants. Le format répertoire semble désarmamment simple vu de l'extérieur.
---
FAQ
Combien de temps a-t-il fallu pour construire Hostlist ?
La première version, brute, pleine de lacunes dans les données, mais en ligne, a pris environ trois mois de soirées et de fins de semaine. Pour la mettre dans un état dont j'étais vraiment fier, il a fallu closer à un an. Le travail de qualité des données ne s'arrête jamais vraiment.
Quel plugin WordPress avez-vous utilisé pour la fonctionnalité de répertoire ?
Directorist comme base, puis un développement personnalisé substantiel par-dessus. Pour un plus petit répertoire, je l'utiliserais plus ou moins tel quel. Avec 25 000 entrées, vous devrez éventuellement écrire des requêtes personnalisées de toute façon, le plugin vous donne juste un point de départ.
Un répertoire d'hébergement Web est-il vraiment rentable ?
Ça peut l'être. Le mien couvre ses coûts et gagne au-delà, mais je ne prétendrai pas que c'est une machine de revenu passif. Les marges dépendent fortement de votre capacité à vendre des annonces premium. Les annonces d'affichage seules ne vous y mèneront pas à des niveaux de trafic modérés.
Comment gardez-vous 25 000 annonces à jour ?
Imparfaitement. J'ai une combinaison de scrapers planifiés qui vérifient les changements de pages de tarification, une file d'attente de corrections signalées par la communauté, et un cycle d'examen manuel pour les 500 premiers hébergeurs par trafic. La longue traîne se dégrade au fil du temps. J'ai accepté cela.
Recommanderiez-vous de créer un grand annuaire comme premier projet ?
Non. Commencez par quelque chose que vous pouvez faire en 500 enregistrements. Prouvez que les gens l'utilisent et qu'il y a un chemin vers la monétisation. Puis montez en échelle. La complexité technique et de gestion des données d'un grand annuaire est véritablement non-triviale, et vous voulez rencontrer ces problèmes après avoir validé l'idée, pas avant.
---
La chose avec les annuaires, c'est que c'est un jeu de longue haleine. Vous construisez un actif de données, pas un site de contenu. Le trafic augmente lentement, le travail est sans glamour, et pendant les six premiers mois vous vous demandez si quelqu'un s'en soucie. Mais quand les données sont bonnes et la niche est juste, les annuaires développent une sorte de traction gravitationnelle qui est difficile à reproduire avec n'importe quel autre format. C'est pourquoi je continue à les construire.
