在大约第 11,000 个托管商的时候，我真的开始质疑我做过的每一个决定。不是戏剧化的方式——更像是那种安静而具体的恐惧感，意识到你用一个不断增长的数据集和一个只为大约 500 条记录设计的数据模式把自己逼进了死胡同。这就是 HostList。一个网络托管商的目录。所有的，或尽可能接近所有的。
我会告诉你实际发生了什么——架构选择、数据噩梦、灵光一现的时刻，以及如果我今天重新开始的话会完全不同做法的部分。
为什么要建立网络托管目录
老实说？我烦透了。我在为一个 Seahawk 客户做研究——一个需要迁移托管商的中端 SaaS——我找不到一个既全面又实时的目录。大多数要么是假装中立的薄皮联盟页面，要么是过时的列表，里面还有 2017 年就倒闭的托管商。and current. Most were either thin affiliate pages pretending to be neutral, or outdated lists that still featured hosts that had gone under in 2017.
网络托管行业有数千个活跃提供商。不是几十个。数千个。共享主机、托管 WordPress 主机、VPS 提供商、裸金属专家、你从未听说过的地区玩家。没有人正确地绘制过它。所以我想：我来做。六周，我告诉自己。WordPress hosts, VPS providers, bare-metal specialists, regional players you've never heard of. Nobody had mapped it properly. So I thought: I'll do it. Six weeks, I told myself.
这花的时间远长于六周。
不过市场验证了这个直觉。看看利基目录在即使是适度规模下能做什么——Soak Oregon，一个简单的温泉目录，仅用 25,000 月度访客就能拉动大约每月 1,000 美元的广告收入。这不是笔误。25,000 访客。一个针对性强的目录的经济学与通用内容网站完全不同。Soak Oregon, a simple hot springs directory, pulls roughly $1,000 a month in ad revenue on just 25,000 monthly visitors. That's not a typo. 25,000 visitors. The economics of a well-targeted directory are genuinely different from a general content site.
没人谈论的数据问题
这正是大多数目录构建指南完全让你失望的地方。它们会告诉你设置分类和列表字段。好吧。它们不会告诉你的是，收集 25,000 条准确的、结构化的记录完全是另一类问题。
我的第一个方法是人工研究加上一个我在周末临时拼凑的抓取层。抓取器没问题。数据是混乱的。托管提供商不断改变他们的定价。有些有三个不同的品牌名称。有些是转销商的转销商——同样的底层基础设施穿着十五个不同的标志。单单去重就花了我三周。data was chaos. Hosting providers change their pricing constantly. Some had three different brand names. Some were resellers of resellers -- the same underlying infrastructure wearing fifteen different logos. Deduplication alone cost me three weeks.
有些我希望自己更早做出的决定：
- 每个法律实体一条规范记录，而不是每个品牌一条。有些主机商有四个品牌。它们仍然是一个主机商。, not per brand. Some hosts have four brands. They're still one host.
- 每个字段都有新鲜度日期。不只是行上的"最后更新"——每个字段。定价的过时速度比功能集快。Not just "last updated" on the row -- per field. Pricing goes stale faster than feature sets.
- 从第一天开始就有人工审查队列。自动化摄入对于初始阶段没问题。但你需要一个流程来标记看起来有问题的记录，在它们上线之前。Automated ingestion is fine for first-pass. But you need a process for flagging records that look wrong before they go live.
第三点尤其是。我早期跳过了它，结果有一堆列表的定价层完全错误，因为一个主机商重新品牌了他们的计划，爬虫在旧页面结构上匹配了。我花了很长时间才找到它。
选择合适的技术栈
我选择了 WordPress。我知道。但请听我解释。
对于这个规模的目录，你需要一个拥有成熟插件生态和你深入理解的查询层的东西。我在较小的项目上用过 Directorist，它表现很好——灵活的模式、支持 Gutenberg、合理的默认值。对于 HostList，我在上面配对了一个自定义的文章类型层，因为我需要没有现成插件预期到的字段（比如数据中心位置、对等互联安排、控制面板版本）。Directorist on smaller projects and it held up well -- flexible schema, works with Gutenberg, sensible defaults. For Hostlist specifically I paired it with a custom post type layer on top, because I needed fields that no off-the-shelf plugin anticipated (things like data-centre locations, peering arrangements, control panel versions).
真正重要的四个页面——我会说这对任何利基的目录都是真的——是：
- 首页，有清晰的目标、精选列表和一个简单易用的搜索
- 归档/浏览页面，支持快速筛选（这是你 80% 用户所在的地方）
- 单个列表页面，包含完整记录、结构化数据标记，以及认领/举报的方式
- 提交页面（即使你一开始不做用户提交，也要预留好）
我怎么强调存档页面都不过分。用户不会登陆你的首页再导航。他们从Google搜索直接落在存档页面，四秒内就决定数据看起来是否可信。先把那个页面做对。then navigate. They land on an archive page from Google and decide within four seconds whether the data looks credible. Get that page right first.
我会改变什么
自定义表。我应该早得多就把核心列表数据从文章元数据移到适当的关系表中。WordPress 文章元数据在大约 5,000 条记录时还行。过了那个数字，查询就开始吃力。大规模网络应用的性能考量是真实的——RAM、查询优化、缓存策略——这些都不是你只想启动这个东西时规划的东西。performance considerations for large-scale web applications are real -- RAM, query optimisation, caching strategy -- none of which you plan for when you're just trying to get the thing launched.
托管目录本身（真的很尴尬）
构建一个虚拟主机目录，然后不得不为它选择主机提供商，这里确实有种讽刺。我在第一年里换了三个主机。
第一个是一家托管WordPress主机，我就不点名了。它在导入过程中崩溃了——通过WP-CLI导入25,000篇文章不是他们的基础设施设计的用途。第二个是一个VPS，我自己处理一切：用Nginx作为反向代理，用Redis进行对象缓存，用ufw作为防火墙。当你知道自己在做什么时，这种自托管架构方法运作得非常出色——完全透明，没有神秘的限流，你控制缓存头。但也会出现这样的情况：周四晚上11点某些东西坏了，这完全是你的问题。That self-hosted architecture approach works brilliantly when you know what you're doing -- total visibility, no mystery throttling, you control the cache headers. But it's also 11pm on a Thursday when something breaks and it's entirely your problem.
最后我用了带 root 访问权的托管 VPS。两者兼得。我保留了前面的 Nginx，添加了一个 CDN 层来处理静态资源，从那以后一直运行得很好。
教训：无论你选择哪个主机，在你承诺之前用你的实际数据量测试它。不是样本。你的真实导入。一个轻松处理500篇博文的主机有时候在你向它扔25,000条记录进行数据库重建时会完全崩溃。test it with your actual data volume before you commit. Not a sample. Your real import. A host that handles a 500-post blog with flying colours will sometimes completely fall over when you throw 25,000 records at it during a database rebuild.
变现：我尝试过什么，什么有效果
早在 2019 年，一个客户曾对我说，"钱在列表中，不在流量中。"那时我没有完全理解。现在我理解了。
HostList 的收入来自几个地方，大致按照实际推动增长的程度排序：
- 精选/高级列表——主机商付费在相关分类页面顶部展示。这种模式有效。CPM很不错，因为购买意图很高。 -- hosts pay to appear at the top of relevant category pages. This works. The CPMs are good because the intent is high.
- 带年度续期的认证徽章——比完整的高级列表更轻量，但收益可观。 -- lighter-touch than a full premium listing, but it adds up.
- 展示广告——我后来才加入这种方式，它的表现最差。受众太小且太专业，主流广告网络无法充分重视。 -- I added this late and it's the weakest performer by quite a lot. The audience is too small and too specific for broad ad networks to value properly.
- 销售线索生成/联盟推广——我在这里很谨慎，因为我不想让HostList看起来像其他所有有偏见的对比网站。我有少量推荐安排，但都进行了披露且受限。 -- I was cautious here because I didn't want Hostlist to look like every other biased comparison site. I have a small number of referral arrangements but they're disclosed and limited.
我没有做的是一个免费增值模式，其中基础列表免费，升级付费。我想过。网络主机业的问题在于值得放在你平台上的提供商，也恰好是最不需要你的目录来获得曝光的那些。较小的主机商从被列出中受益更多，但他们的预算也最小。经济学上很尴尬。not done is a freemium model where basic listings are free and upgrades are paid. I thought about it. The problem with web hosting specifically is that the providers worth having on your platform are also the ones least likely to need your directory for exposure. The smaller hosts benefit more from being listed, but they're also the ones with the smallest budgets. The economics are awkward.
Brilliant Directories和类似平台在更多面向社区的目录上已经解决了这个问题——婚礼供应商、亲子资源——在那里成员真的想被本地人找到。网络托管就不同了。这是一个全球性的、竞争极其激烈的市场。 have this figured out for more community-oriented directories -- wedding vendors, parenting resources -- where the members genuinely want to be found by locals. Web hosting is different. It's a global, hyper-competitive market.
大型目录的 SEO：真正有帮助的部分
拥有 25,000 条条目的目录如果处理得当，就是一项 SEO 资产。如果处理不当，就是一项 SEO 负担。
真正有帮助的具体做法：
- 独特、模板化但可变的元描述——不仅仅是主机名+"网络托管评测"。我引入了实际数据点（价格级别、主要用途、成立年份）来生成真正不同的描述。 -- not just the host name + "web hosting review". I pulled in actual data points (price tier, primary use case, founding year) to generate descriptions that were genuinely different.
- 包含真实编辑内容的分类和标签页面——不仅仅是卡片网格。一篇200字的介绍文章解释"托管WordPress主机"的实际含义，写一次，应用到整个分类。谷歌想看到有人为这个页面思考过。 -- not just a grid of cards. A 200-word intro explaining what "managed WordPress hosting" actually means, written once, applied to the category. Google wants to see that someone thought about the page.
- 结构化数据（Schema.org）——每个列表都有LocalBusiness或Organization标记。我正确添加这些后，点击率明显提高了。 -- every listing has
LocalBusinessorOrganizationmarkup. Click-through rates improved noticeably after I added this properly. - 过滤组合的规范标签——这几乎要了我的命。分面搜索会生成数千个URL组合。如果你不把它们规范化回干净的存档URL，一个月内你就会因爬虫预算而破产。 -- this nearly killed me. Faceted search generates thousands of URL combinations. If you don't canonical them back to the clean archive URL, you'll be crawl-budget bankrupt within a month.
- 仅为活跃主机编制索引 -- 我对任何无法确认仍在运营的内容都设置 noindex。死链接比没有列表更糟。 -- I noindex anything I can't confirm is still operating. Dead listings are worse than no listing.
我早期犯的一个错误：我立即为所有内容建立了索引。包括几乎没有数据的存根页面。Google 爬虫抓取了它们，发现了这些瘦页面，并且在一段时间内对整个域名进行了部分折扣。教训：不要索引它，除非它值得被索引。don't index it until it's worth indexing.
我会做得不同的地方
快速总结几点：
- 先从一个更小、更专注的细分领域开始。"虚拟主机目录"太庞大了。我应该从"托管 WordPress 主机"开始 -- 也许 300-400 条记录 -- 证明这个概念，然后再扩展。
- 在前端之前先构建数据管道。我做反了。前端上线时导入流程还不稳定，所以我一直在修补线上数据。before the front end. I did it backwards. The front end was live before the import process was solid, which meant I was constantly patching live data.
- 从第一天起就对列表收费。哪怕每月1英镑。免费列表会吸引那些填写表单草率且从不回应更新请求的主机。一点小费用可以筛选出质量。
- 更早投资建立适当的贡献者系统。我收到的最好的数据更正来自发现错误的用户。前八个月我没有有结构的方式来接收这些。
说实话，构建 HostList 是我做过的最在技术上有趣的兼职项目之一 -- 同时也是最令人谦虚的。这个目录格式从外面看起来简单得不像话。
---
常见问题
开发 HostList 花了多长时间？
第一个版本 -- 粗糙，数据缺口多，但上线了 -- 花了大约三个月的晚上和周末。让它达到我真正为之骄傲的状态花了大约一年。数据质量的工作永远不会真正停止。
你为目录功能使用了哪个 WordPress 插件？
以 Directorist 为基础，然后在上面进行了大量的定制开发。对于较小的目录，我会基本上按原样使用它。但有 25,000 条条目时，你最终还是需要编写自定义查询 -- 这个插件只是给你一个起点。
网站主机目录真的能赚钱吗？
可以。我的目录能覆盖成本，还能赚点额外收入，但我不会假装它是被动收入机器。利润很大程度上取决于你能否卖出高级列表。在流量适中的情况下，仅靠展示广告是到不了的。
你怎么保持 25,000 个列表是最新的？
不完美。我采用定时爬虫检查定价页面变化、社区报告的更正队列，以及对前500个高流量主机的手动审核。长尾部分会随着时间推移而下降。我已经接受了这一点。
你会建议把建立一个大型目录作为第一个项目吗？
不。从你能在500条记录上做的东西开始。证明人们会用它，证明有变现路径。然后扩展。大型目录的技术和数据管理复杂性真的不简单，你希望在验证了想法之后再遇到那些问题，而不是之前。Then scale. The technical and data-management complexity of a large directory is genuinely non-trivial, and you want to encounter those problems after you've validated the idea, not before.
---
关于目录的事是，这是一场长期游戏。你在构建数据资产，而不是内容网站。流量增长缓慢，工作乏味无趣，头六个月你会怀疑是否有人在乎。但当数据质量好、细分市场选择恰当时，目录会产生一种难以用其他格式复制的引力。这就是我持续建立目录的原因。