你的收录该指向 /product 还是 product.domain.com

每一份你提交的 directory 收录都会问一个你大概率凭直觉回答的问题：URL 填什么？你三十秒给出的答案会复利好几年——因为收录是黏的，架构一变，你不会回头去改四十个目录档案。所以先给结论：对大多数产品，提交子目录——domain.com/product。 子域名是你需要理由才配得上的选择，不是你可以漂进去的默认值。

这不是一场关于「子域名 vs 子目录」的宗教战争。这是一个更窄的问题：当三十个第三方页面指向你的产品时，你希望这些指向落在哪里？

你真正在选的是什么

一条收录就是一个 citation。它对两类受众说同一句话：「这个产品住在这个 URL。」一类是爬虫——搜索引擎的和助手的——它们顺着 URL 走，并把信号关联到它们找到的东西上。另一类是人，点一次，要么落点不错，要么直接走。

架构选择本质上是信号怎么分配。所有收录指向一个 URL，信号就集中；所有收录分散在两个 URL，信号就分裂。分裂谈不上灾难，但近乎不可逆：过时的收录出了名地难更新，所以你选什么，大量第三方页面就会长期替你这么说。

注意这个决策位于很多问题的上游。如果你日后更换目标，旧收录会一直指向已经死掉的地址——就是本系列之前讨论过的那类 URL 变更事故。改动既有 citation 的去向是一个清理工程，不是设置里的一个开关。

站在子目录这边的理由

一个实体，一个地址。 住在 domain.com/product 的产品，和域名下的其他东西共享权重、品牌搜索、抓取节奏和实体。当助手解析你的公司时，所有东西指向同一个地方。游戏全部内容就在这里。

品牌搜索落在一个点上。 导航类意图是零点击伤不到你的地方——打你名字的人要的就是你的站。如果产品住在子域名上，意图会被劈开：一半链接和提及指向营销站，一半指向产品，每一半都是一个更弱版本的你。

一致性的成本更低。 描述、规范 URL、结构化事实，只有一份东西时更容易保持连贯。交叉印证只在独立页面互相印证时起作用；你自己先把家拆成两半，等于给它们两个版本去取平均。

Citation 会累加。 当十个目录和三个集成页都指向 domain.com/product，那个 URL 就在积累引用——正是这种积累，让一个页面成为 AI 答案的候选来源。分裂在子域名和子目录之间，你会得到两个平庸的候选，而不是一个强的。

对大多数 SaaS、大多数博客、大多数小电商，这就是答案，你可以到此为止。剩下的篇幅讲什么时候不是。

子域名什么时候配得上

子域名不是错的。当产品确实是独立实体时，它是对的：

产品有自己的名字和自己的搜索需求。 如果人们把「ProductX」当作一个区别于你公司的东西来搜，ProductX 有自己的定位、自己的定价、自己的竞争集合，那它配得上自己的地址。市场在告诉你它是独立实体，架构应该同意。

平台面或开发者面。 docs.、api.、app.、status.——这些是功能性子域名，把面向开发者的收录指向它们是正确的。你不会想要一个 API 工具目录指向你的营销 homepage。

被收购但保留品牌的产品。 它的 citation、品牌搜索、既有收录都指向旧家。第一天就把一切强并到你的域名上，会砸掉本来在工作的东西；迁移是之后另一个刻意的项目。

受众确实不同。 如果企业买家和消费用户落在合并后会互相伤害转化的页面上，分开首先是商业决策，其次才是 SEO 决策。

代价在两种情况下都真实存在：权重分裂、品牌搜索分裂，所有一致性问题翻倍。这是独立的价钱。只有独立是真的时候才付它。

比争论本身更值钱的三条操作规则

不管你选哪边，决定这个选择是否回本的是这三个习惯：

1. 一个规范目标，到处统一。 决定「我们的产品」唯一的 URL，在每份收录、每页 partner page、每份简介、每一篇你能控制的媒体提及里都用它。目标混杂是 citation 资产漏掉的方式。

2. 把目标 URL 写进你的提交清单。 留记录：平台、提交的 URL、日期、状态。当一条收录过时、一个平台死掉时，你需要准确知道它指向什么才能做判断。跳过这一步的团队，未来要花一周凭记忆和搜索结果把记录重建出来。

3. 更改一个在用的目标之前，先给清理工作定价。 换目标意味着：把你能编辑的每条收录找出来改，接受改不了的那部分损失，然后把重定向立稳。做决定前先读本系列之前讲过的 URL 变更问题；外面一半的迁移之痛，来自先搬家、后盘点的团队。

诚实条款

架构是二阶效应。 子域名上一个出色的产品页，每次都赢子目录上一个单薄的页面。这个决策优化的是你已经赢得的注意力怎么分配；它不创造注意力。

不要只为收录而重做架构。 如果你的站在子域名上而且运转良好，合并的价值通常小于迁移的成本。先修好你提交内容的一致性——那是免费的。

这里没有几周内见效的东西。 Citation 随收录被抓取、被印证而积累。今天就切换，预期它在月的尺度上才有意义。

子域名或子目录救不了歧义。 如果十个目录用十种方式描述你的产品，任何 URL 结构都救不了你。描述的活儿排在前面。

如果拖慢你的是机械层——提交、追踪、记住什么指向哪里——那部分正是 BackLink 从你盘子里拿走的东西：向一份人工筛选的平台清单做人工提交，自动去重让你不会重复提交同一份档案，加上每条收录的实时状态。你把目标 URL 一次性定对。我们负责让它一致地落地。

常见问题

子目录真的比子域名传更多权重吗？

现代搜索引擎对子域名的处理已经比过去更像独立站，差距在缩小——但合并仍然在实际层面胜出：一个品牌搜索落点、一堆集中的 citation、一套要保持一致的描述。优势不是传说中的 PageRank 算术，而是连贯性。

我已经把一切都提交到 product.domain.com 了，要重做吗？

通常不用。在同一批平台上用不同 URL 重新提交，只会制造重复和混乱。改掉你能编辑的收录，让所有*新*提交指向你的规范目标；只有当产品真的并入主站时，才考虑把子域名重定向到子目录。

目录该链到我的 homepage 还是产品页？

能回答读者下一个问题的那一页。对于描述你产品的收录，那就是产品页。Homepage 属于公司/简介字段，属于「关于公司」的平台，不属于每一条产品收录。

应用商店和市场类平台——算法上算得不一样吗？

它们算作生态 citation：用结构化事实描述你产品的第三方页面。同样把它们指向产品的规范 URL。一致性在那里同样重要——助手解析你的实体时会读这些页面。

怎么追踪每条收录指向哪个 URL？

一张简单的表：平台、提交的 URL、日期、状态、备注。它很无聊，但一年后你会庆幸有它。带状态追踪的自动提交服务（包括 BackLink）会替你记这些；如果你纯手工做，一个共享文档就够用。