构建 Hostlist 时的收获：25,000 个网络主机

大约到了第 11,000 个主机时，我真的开始质疑我做过的每一个决定。不是戏剧化的方式——更像是一种安静而具体的恐惧，意识到你用一个不断增长的数据集和一个最初只为可能 500 个条目设计的数据模式把自己逼进了死角。那就是 Hostlist。一个网络主机目录。尽可能多的所有主机。

我会告诉你实际发生了什么——架构选择、数据方面的噩梦、顿悟的时刻，以及如果我今天重新开始完全会不同做法的地方。

为什么要建立网络托管目录

说实话？我生气了。我在为 Seahawk 的一个客户进行研究——一个需要迁移主机的中端 SaaS——我找不到任何既全面又最新的目录。大多数要么是假装中立的薄薄的联盟链接页面，要么是过时的列表，仍然列出了 2017 年就已关闭的主机。andcurrent. 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 提供商、裸金属专家、你从未听说过的地区玩家。没有人正确地绘制过它。所以我想：我来做。六周，我告诉自己。

这花的时间远长于六周。

不过市场验证了这个直觉。看看利基目录在适度规模下能做什么——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 条准确的、结构化的记录完全是另一类问题。

我最初的方法是手动研究加上我周末临时拼凑的爬虫层。爬虫没问题。数据一团糟。托管供应商不断改变定价。有些有三个不同的品牌名。有些是转销商的转销商——同一基础设施穿着十五个不同的标志。仅仅去重就花了我三周。datawas 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 来说，我在其上添加了一个自定义文章类型层，因为我需要一些现成插件没有考虑到的字段（比如数据中心位置、互联互通安排、控制面板版本）。Directoriston 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).

真正重要的四个页面——我认为这对任何行业的目录网站都适用——是：

1. 首页，有清晰的目标、精选列表和一个简单易用的搜索
2. 归档/浏览页面，支持快速筛选（这是你 80% 用户所在的地方）
3. 单个列表页面，包含完整记录、结构化数据标记，以及认领/举报的方式
4. 提交页面（即使你一开始不做用户提交，也要预留好）

我怎么强调归档页面的重要性都不为过。用户不会来到你的首页然后导航。他们从谷歌着陆在归档页面上，并在四秒内判断数据看起来是否可信。先把这个页面做对。thennavigate. 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 applicationsare 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.

我没有做的是免费增值模式，即基础列表免费、升级版付费。我考虑过这样做。问题在于网络托管领域的特殊性：值得在你的平台上出现的提供商，也是最不需要你的目录来获得曝光的那些。较小的主机商从被列出中获益更多，但他们的预算也最紧张。经济学上不划算。notdone 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 genuinelywantto be found by locals. Web hosting is different. It's a global, hyper-competitive market.

大型目录的 SEO：真正有帮助的部分

拥有 25,000 条条目的目录如果处理得当，就是一项 SEO 资产。如果处理不当，就是一项 SEO 负担。

真正有帮助的具体做法：

1. 为每条列表编写独特、模板化但可变的元描述——而不仅仅是主机名 + "网络托管评测"。我纳入了实际的数据点（价格等级、主要用途、创办年份）来生成真正不同的描述。— 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.
2. 带有真实编辑内容的分类和标签页面——而不仅仅是卡片网格。一篇 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.
3. 结构化数据（Schema.org）——每个列表都有LocalBusiness或Organization标记。我正确添加后，点击率明显提高了。— every listing hasLocalBusinessorOrganizationmarkup. Click-through rates improved noticeably after I added this properly.
4. 筛选组合的规范URL——这差点让我崩溃。分面搜索会生成数千个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.
5. 仅为活跃主机建立索引——我对任何无法确认仍在运营的东西都设置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条记录——证明这个概念，然后再扩展。
• 在前端之前建立数据管道。我做反了。前端上线时导入流程还不完善，这意味着我一直在修补实时数据。beforethe 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条记录范围内完成的东西开始。证明人们会使用它，以及存在变现路径。然后再扩展。大型目录的技术和数据管理复杂性真的不容小觑，你希望在验证了想法之后才遇到这些问题，而不是之前。Thenscale. 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.

---

关于目录的事是，这是一场长期游戏。你在构建数据资产，而不是内容网站。流量增长缓慢，工作乏味无趣，头六个月你会怀疑是否有人在乎。但当数据质量好、细分市场选择恰当时，目录会产生一种难以用其他格式复制的引力。这就是我持续建立目录的原因。