在大约第 11,000 个主机的时候，我真的质疑过自己做过的每一个决定。不是戏剧化的方式，而是那种安静、具体的恐惧——意识到自己用一个不断增长的数据集和一个只为大约 500 条记录设计的模式把自己逼进了死胡同。那就是 HostList。一个网络主机目录。所有的，或者尽可能接近所有的。
我会告诉你实际发生了什么，架构选择、数据的噩梦、豁然开朗的时刻，以及如果我今天重新开始会完全不同做的地方。
为什么要建立网络托管目录
说实话？我被惹恼了。我在为一个 Seahawk 客户做研究，一家中等规模的 SaaS，需要迁移主机，而我找不到一个既完整又最新的目录。大多数要么是假装中立的薄弱联盟营销页面，要么是过时的列表，仍然列出了 2017 年就已经倒闭的主机商。
网络托管行业有数千个活跃提供商。不是几十个。数千个。共享主机、托管 WordPress 主机、VPS 提供商、裸金属专家、你从未听说过的地区玩家。没有人正确地绘制过它。所以我想：我来做。六周，我告诉自己。
这花的时间远长于六周。
市场验证了这个想法，不过。看看利基目录在即使适度规模上能做什么，Soak Oregon，一个简单的温泉目录，在仅 25,000 月访问量上每月产生大约 $1,000 的广告收入。这不是打字错误。25,000 访问量。一个目标明确的目录的经济学与通用内容网站真的不同。
没人谈论的数据问题
这正是大多数目录构建指南完全让你失望的地方。它们会告诉你设置分类和列表字段。好吧。它们不会告诉你的是，收集 25,000 条准确的、结构化的记录完全是另一类问题。
我的第一个方法是手动研究加上一个我在周末匆忙拼凑的爬虫层。爬虫没问题。数据是混乱的。托管提供商不断改变他们的定价。有些有三个不同的品牌名称。有些是分销商的分销商，同一个底层基础设施穿着十五个不同的标志。去重就花了我三周。
有些我希望自己更早做出的决定：
- 每个法律实体一条规范记录，而不是每个品牌一条。有些主机商有四个品牌。它们仍然是一个主机商。
- 每个字段上的新鲜度日期。不仅仅是行上的"最后更新"，是每个字段。定价变过时的速度比功能集更快。
- 从第一天开始就有人工审查队列。自动化摄入对于初始阶段没问题。但你需要一个流程来标记看起来有问题的记录，在它们上线之前。
第三点尤其是。我早期跳过了它，结果有一堆列表的定价层完全错误，因为一个主机商重新品牌了他们的计划，爬虫在旧页面结构上匹配了。我花了很长时间才找到它。
选择合适的技术栈
我选择了 WordPress。我知道。但请听我解释。
对于这种规模的目录，你需要一个成熟的插件生态和你深入理解的查询层。我在较小的项目上用过 Directorist，它表现良好，灵活的模式、与 Gutenberg 配合、明智的默认值。对于 HostList 具体来说，我在上面配了一个自定义文章类型层，因为我需要没有现成插件能预期的字段（比如数据中心位置、对等安排、控制面板版本）。
实际重要的四个页面，我会说这对任何利基的目录都成立，是：
- 首页，有清晰的目标、精选列表和一个简单易用的搜索
- 归档/浏览页面，支持快速筛选（这是你 80% 用户所在的地方）
- 单个列表页面，包含完整记录、结构化数据标记，以及认领/举报的方式
- 提交页面（即使你一开始不做用户提交，也要预留好）
我怎么强调存档页面都不过分。用户不会登陆你的首页再导航。他们从Google搜索直接落在存档页面，四秒内就决定数据看起来是否可信。先把那个页面做对。
我会改变什么
自定义表。我应该更早地将核心列表数据从文章元数据转移到适当的关系表。WordPress 文章元数据在大约 5,000 条记录以下是可以的。超过那个，查询会变得困难。大规模 web 应用的性能考虑是真实的，RAM、查询优化、缓存策略，当你只是想让这东西上线时都不会计划的东西。
托管目录本身（真的很尴尬）
构建一个虚拟主机目录，然后不得不为它选择主机提供商，这里确实有种讽刺。我在第一年里换了三个主机。
第一个是一家托管WordPress主机，我不想说出它的名字。它在导入过程中崩溃了，25,000篇文章通过WP-CLI导入不是他们的基础设施设计来处理的。第二个是一个VPS，我自己处理所有事情：Nginx作为反向代理，Redis用于对象缓存，ufw用于防火墙。当你知道自己在做什么时，这种自托管架构方法效果非常好，完全可见，没有神秘的限流，你控制缓存头。但这也意味着周四晚上11点某些东西坏了，那完全是你的问题。
最后我用了带 root 访问权的托管 VPS。两者兼得。我保留了前面的 Nginx，添加了一个 CDN 层来处理静态资源，从那以后一直运行得很好。
教训：无论你选择哪个主机，在你承诺之前用你的实际数据量测试它。不是样本。你的真实导入。一个轻松处理500篇博文的主机有时候在你向它扔25,000条记录进行数据库重建时会完全崩溃。
变现：我尝试过什么，什么有效果
早在 2019 年，一个客户曾对我说，"钱在列表中，不在流量中。"那时我没有完全理解。现在我理解了。
HostList 的收入来自几个地方，大致按照实际推动增长的程度排序：
- 精选/高级列表，主机商付费在相关分类页面的顶部显示。这行得通。CPM很好，因为意图很高。
- 带年度更新的验证徽章，比完整的高级列表更轻松，但积少成多。
- 展示广告，我后来才添加的，表现最差。受众太小，太专业，广告网络无法恰当地评估。
- 线索生成/联盟，我在这里很谨慎，因为我不想让HostList看起来像其他有偏见的对比网站。我有少量的推荐安排，但它们都有披露和限制。
我没有做的是一个免费增值模式，其中基础列表免费，升级付费。我想过。网络主机业的问题在于值得放在你平台上的提供商，也恰好是最不需要你的目录来获得曝光的那些。较小的主机商从被列出中受益更多，但他们的预算也最小。经济学上很尴尬。
Brilliant Directories和类似平台在更多面向社区的目录中已经解决了这个问题，如婚礼供应商、育儿资源，会员真的希望被当地人找到。网络托管不同。这是一个全球性的、超竞争的市场。
大型目录的 SEO：真正有帮助的部分
拥有 25,000 条条目的目录如果处理得当，就是一项 SEO 资产。如果处理不当，就是一项 SEO 负担。
真正有帮助的具体做法：
- 每个列表都有独特的、模板化但可变的元描述，而不仅仅是主机名 + "网络托管评论"。我引入了实际数据点（价格等级、主要用途、创立年份）来生成真正不同的描述。
- 带有真实编辑内容的分类和标签页面，而不仅仅是卡片网格。一段200字的介绍，解释"托管WordPress主机"实际上意味着什么，写一次，应用到分类。谷歌想看到有人思考过这个页面。
- 结构化数据（Schema.org），每个列表都有LocalBusiness或Organization标记。我正确添加后，点击率有明显提高。
- 过滤器组合的规范链接，这几乎要了我的命。分面搜索会生成数千个URL组合。如果你不把它们规范回清晰的存档URL，一个月内你的爬虫预算就会破产。
- 仅为活跃主机建立索引编目，任何我无法确认仍在运营的内容我都设置 noindex。死链接比没有编目更糟糕。
我早期犯的一个错误：我立即为所有内容建立了索引。包括几乎没有数据的存根页面。Google 爬虫抓取了它们，发现了这些瘦页面，并且在一段时间内对整个域名进行了部分折扣。教训：不要索引它，除非它值得被索引。
我会做得不同的地方
快速总结几点：
- 从一个更小、更精准的细分市场开始。"虚拟主机目录"太庞大了。我当时应该从"托管型 WordPress 主机"开始，可能 300-400 条记录，验证这个概念是否可行，然后再扩展。
- 在前端之前先构建数据管道。我做反了。前端上线时导入流程还不稳定，所以我一直在修补线上数据。
- 从第一天起就对列表收费。哪怕每月1英镑。免费列表会吸引那些填写表单草率且从不回应更新请求的主机。一点小费用可以筛选出质量。
- 更早投资建立适当的贡献者系统。我收到的最好的数据更正来自发现错误的用户。前八个月我没有有结构的方式来接收这些。
说实话，开发 HostList 是我做过最在技术上引人入胜的兼职项目之一，也是最令人谦虚的。这个目录的格式从外面看起来似乎很简单。
---
常见问题
开发 HostList 花了多长时间？
第一个版本很粗糙，数据缺口很多，但能用，花了大约三个月的晚上和周末。让它达到我真正满意的状态花了接近一年。数据质量工作永远不会真正停止。
你为目录功能使用了哪个 WordPress 插件？
以 Directorist 为基础，然后在上面进行了大量的自定义开发。对于一个较小的目录，我会基本上直接使用它，无需太多定制。在有 25,000 条记录的规模下，你最终还是需要编写自定义查询，插件只是为你提供了一个起点。
网站主机目录真的能赚钱吗？
可以。我的目录能覆盖成本，还能赚点额外收入，但我不会假装它是被动收入机器。利润很大程度上取决于你能否卖出高级列表。在流量适中的情况下，仅靠展示广告是到不了的。
你怎么保持 25,000 个列表是最新的？
不完美。我采用定时爬虫检查定价页面变化、社区报告的更正队列，以及对前500个高流量主机的手动审核。长尾部分会随着时间推移而下降。我已经接受了这一点。
你会建议把建立一个大型目录作为第一个项目吗？
不。从你能在500条记录上做的东西开始。证明人们会用它，证明有变现路径。然后扩展。大型目录的技术和数据管理复杂性真的不简单，你希望在验证了想法之后再遇到那些问题，而不是之前。
---
关于目录的事是，这是一场长期游戏。你在构建数据资产，而不是内容网站。流量增长缓慢，工作乏味无趣，头六个月你会怀疑是否有人在乎。但当数据质量好、细分市场选择恰当时，目录会产生一种难以用其他格式复制的引力。这就是我持续建立目录的原因。