能承载28000个页面而不受薄内容惩罚的目录网站。

基本上任何目录形式，只要有结构化数据源。过去两年，我开发的模式分为四大类，大多数客户项目都是其中某一类的变体。

行业目录列出某个垂直领域内的公司，按类别、位置、规模和功能集进行分段。HostList.io是我自己运营的典范例子——约28000家网络托管公司，按托管类型、地区、价格带和使用场景切分。买家可以找到供应商，供应商获得流量，目录本身通过赞助位置、联盟链接或付费高级列表获利，具体取决于什么最适合该垂直领域。

本地和位置目录是第二种模式。餐厅指南、酒吧指南、牙医目录、承包商目录。每个列表都包含LocalBusiness schema标记、地理坐标、营业时间和评分（如果你拥有数据权限）。程序化生成的城市和类别页面——"曼彻斯特最好的意大利餐厅"或"斯托克·纽因顿的酒吧"——提供了这些网站上大部分长尾SEO流量。

工具和软件目录列出某个类别内的软件产品。CRM工具。项目管理应用。无代码平台。AI工具。这些网站的流量引擎是对比页面——Notion对比Linear对比ClickUp——和功能矩阵页面，搜索者已经知道产品名称，只是需要一个决策因素。

人员和服务目录是第四种模式。代理公司。自由职业者。顾问。摄影师。律师。这类目录的挑战在于大多数人员目录因为列表过时且没人更新而死掉。我们从项目第一天就内置过期工作流和自助式资料编辑，而不是以后再改造。

HostList.io是我独自构建的目录，用来汇总整个网络托管行业。大约二万八千个托管公司页面，自2024年春季上线以来，使用我们现在为客户目录构建所用的同一套Next.js加Supabase加Vercel技术栈。

HostList所做的是汇总我们能验证的每一家网络托管公司，按类型分段——共享、VPS、托管WordPress、云、专用、转售商——按地区、价格段和用例划分。有特定主机之间的对比页面、每个细分市场的分类页面、能处理二万八千行数据集而无查询延迟的搜索和筛选界面、每个列表上的schema标记，以及流式站点地图，因为URL数量已经超过单一sitemap.xml能容纳的范围。

运营它带来的三个教训现在影响每一个客户目录构建。首先，数据质量是全部。除了实体名称外有三个独特数据点的页面能熬过Google更新；只有名称和通用描述的页面会被取消索引。其次，内部链接在这个规模下比反向链接更重要。列表、分类和对比页面之间的链接图决定了哪些叶子页面被爬取得足够频繁以保持索引。第三，程序化并不意味着偷懒。每个页面都需要存在的理由，而"我们数据库里有一行"不是理由。

我们从索引中保留了大约15%的数据库，因为那些行不符合独特数据阈值。我们删除了拥有少于五个强列表的分类页面，因为即使底层schema正确，它们看起来也很单薄。我们添加了命名竞争对手之间的对比页面作为单独的页面类型，那个模板最后成为网站上一些转化率最高的流量。现在同一套方法是我们为客户发布的每个目录的标准。

死掉的目录比活下来的多，失败方式可预测到我通常能在第一通电话上就能判断一个项目朝哪个方向走。

薄内容取消索引是最常见的失败。一个目录上线时有五千个列表，其中一半只有名称和单行描述，Google索引了前一千五百个然后停止。网站看起来像低效的爬虫。六个月后大多数被索引的页面在核心更新中被取消索引。修复必须在数据收集时进行——每一行在符合站点地图资格前都需要三个独特的数据点，而不是"我们以后会填进去"。

过时数据漂移是第二种模式。一个2023年列表准确的目录到2026年列表了半死不活的企业，因为没人更新那些行、联系信息过期、网站解析到停泊页面，目录同时失去Google和人类访客的信任信号。我们要么内置众包编辑流，让列表中的企业可以认领和编辑他们的资料，要么内置自动新鲜度检查来禁用死链接，要么两者都有。没有新鲜度层，目录无论原始数据有多好都会过时而失去关联性。

没有护城河是第三种模式。三个相竞争的目录涵盖同一细分市场，数据相似。没有谁拥有独特数据，所以没有谁有充分的存在理由。搜索份额支离破碎，谁都排不上去。解决方案是编辑层——原创分析、评分、推荐、对比框架——这些单靠底层数据无法提供。HostList 竞争的是它的评分规则，而不是托管列表本身，因为托管列表本身不特别有防守力。

过滤器导致的索引膨胀是第四种模式。拥有八个过滤维度的目录在技术上可以生成数百万个网址组合。如果每个组合都可索引，你就会用薄页面淹没谷歌，稀释强页面。我们总是阻止薄过滤组合被索引——少于三个列表的任何东西都加 noindex，任何没有真实查询意图的东西（比如排序或第二页之后）都加 noindex，只有映射到真实搜索的规范过滤组合才保持可索引。

一个发布的目录参考架构由五层组成。每个项目在具体细节上有所不同，但脊柱在各个构建中重复。

数据层是通过 Supabase 或自托管的 Postgres，在每个分面列上有适当的索引。每个实体类型都有一个专用列表表——公司、产品、位置、人员——以及质量门列与内容并排（唯一性分数、完整性百分比、最后验证时间戳）。一个网站地图资格视图会自动过滤出质量阈值以下的行。

页面模板分为列表详情页（完整数据、相关列表、schema、面包屑）、分类页（带过滤 UI 和 ItemList schema 的分页列表）、比较页（用于命名实体间的对比）、位置页（带地图嵌入和地理 schema，用于地理很重要的情况），以及关于和方法论页面，它们承载底层数据无法提供的原创编辑价值。

搜索和过滤使用 Postgres 全文搜索（最多约一万个列表），然后对于具有低查询延迟要求的更大目录使用 Algolia 或 Meilisearch。服务器端渲染的过滤网址为每个过滤组合提供规范形式，对薄或重复的组合加 noindex 可防止索引膨胀。提交和审核有一个公开提交表单（模型众包），一个显示质量门分数的管理员队列供审核员审查，带有具体理由的模板拒绝邮件，以及一个自助编辑流程让列出的实体认领和更新自己的资料。

SEO 脚手架是决定目录是否存活的层。采用分块每模板模式的流式网站地图，在每个列表上适当使用 schema.org Organization、Product、Place、Service 或 LocalBusiness，类别页上的 CollectionPage 配合 ItemList，到处都有 BreadcrumbList，规范网址从单一真实来源（数据库，不是模板）发出，以及一个构建时 SEO linter，在缺少 H1、超大元描述或无效 JSON-LD 时让构建失败。

变现通过特色列表（一个布尔标志将行提升到分类页面顶部）、赞助分类位置（一个品牌在一个分类顶部拥有一个计费周期）、带有适当 rel="sponsored" 归属的联盟链接跟踪，以及为上市实体提供的付费高级层以获得更好的位置、更多富数据字段和分析访问权限。

目录项目中最大的变量是数据源本身。大多数项目的成败取决于一个问题的答案：第一天的数据从哪里来，发布后如何保持最新？

手动编辑意味着团队手写每个列表。速度慢、成本高，但可靠。适合不超过一千个列表的项目。我见过成功的例子：高端酒店指南、精选代理目录、小众编辑网站，其中被列出本身就是价值所在。

结构化导入意味着你从可靠的地方导入 CSV 或数据库导出，我们进行清理、去重、富化和摄入。适合一千到十万个列表的项目。例如：包含公开数据的行业目录、政府登记簿导入、Companies House 风格的导出。

自动爬虫或 API 意味着列表从第三方 API 或合理的爬虫流程填充。合法性和伦理性取决于数据源。适合数据存在于已知规范位置的一万到数百万个列表。例如：从 GitHub 提取的开发者工具目录、从公司网站公开评论爬取的主机评论。

用户提交意味着列表来自被列出的人。启动成本低，审核成本高。最好作为编辑种子数据之上的一层，而不是唯一来源。混合模式（编辑种子数据 + 结构化导入 + 年度编辑审核）是 HostList 运行的模式，也是大多数真实目录最终采用的模式，不管他们是否有计划。

在第一次通话中，我们会问哪种组合与你的数据现状相符。如果你没有明确的答案，数据问题本身就是第一阶段的工作；建设会之后进行。

基于真实近期项目的诚实范围，而不是销售报价单上的理想价格。一个不超过一千个列表的小型编辑目录需要十八到三万五千美元，耗时六到九周。一个包含一千到一万个列表、进行结构化数据导入的中型目录需要三到六万美元，耗时十到十四周。一个包含一万到十万个列表、程序化规模运作的大型目录需要五到九万美元，耗时十二到十八周。一个市场形态——双边、包含预订或交易——需要六到十五万美元，耗时十四到二十二周。

所有范围都包括 SEO 基础设施（schema、sitemap、linter）、搜索和筛选层以及基本管理后台。不包括数据获取本身（手动编辑、爬虫基础设施、第三方 API 成本）、原创品牌和设计工作或付费流量获取。发布后的持续运营护理计划每月五百到三千美元。