robots.txt编写：多个域名承载相似内容时怎样说明各自用途
📱 Mozilla/5.0 AppleWebKit/537.36 (KHTML, like Gecko; compatible; ClaudeBot/1.0; +claudebot@anthropic.com)
🔗 /cb25b4b865ac.html
📄
robots.txt编写：多个域名承载相似内容时怎样说明各自用途
结论先说：当多个域名承载相似内容时，robots.txt 只能表达“哪些抓取代理可以访问哪些路径”，它无法说明域名用途，也无法完成跨域去重。真正决定各域名命运的，是你先确定每个域名是主站、备用站、区域站还是纯引流站，再用 robots.txt、canonical 与跳转配合。前提是这些域名都归你控制；若其中某个域名由合作方或第三方运营，本文结论不成立。
先判断每个域名是“可索引资产”还是“过渡入口”
相似内容分布在多个域名时，最常见的错误是给所有域名写同一份 robots.txt，然后期待搜索引擎自己挑一个。搜索引擎没有义务替你判断哪个域名代表业务主体。你需要先给每个域名分配一个明确角色，再让 robots.txt 与该角色一致。
- 主域名：承载最终内容，允许抓取，canonical 指向自身。
- 备用或旧域名：只做 301 跳转，robots.txt 不应阻止抓取，否则跳转信号难以被完整发现。
- 区域或语言域名：若内容确实本地化，允许抓取并各自 canonical；若只是同一内容的镜像，应并入主域名。
- 纯投放落地域名：若不希望进入自然搜索，用 robots.txt 限制抓取只是第一步，仍需处理已收录 URL。
这里有一个容易被忽略的取舍：对备用域名写 Disallow: / 看似干净，但它会阻止抓取代理读取该域名上的跳转指令。若你的目标是合并权重，通常应允许抓取并返回 301，而不是用 robots.txt 封死。只有当你确定该域名不需要传递任何信号、且已用其他方式处理已收录页面时，全面禁止抓取才成立。
robots.txt 能说明用途吗？不能，只能说明抓取边界
robots.txt 的语法里没有“用途声明”字段。你无法在文件里写“此域名是备用站”。它只能通过 User-agent、Allow、Disallow、Sitemap 等指令，间接表达你希望抓取代理如何对待不同路径。因此，“说明各自用途”这件事必须由人来做决策，由 robots.txt 来执行其中与抓取有关的部分。
假设你有三个域名：example.com 为主站，example.net 为旧域名，example.org 为活动落地页。一个可执行的分配方式是：主站允许全站抓取并在 robots.txt 中声明站点地图；旧域名允许抓取、全站 301 到主站对应路径；活动域名若只用于广告投放且不打算参与自然搜索，可限制抓取，但必须接受“已收录页面不会因为 Disallow 而立刻消失”这一事实。
这个例子的关键不是照搬，而是让你看到：robots.txt 的动作发生在抓取阶段，而域名用途的合并发生在索引与排序阶段。两者不是同一个层面。
什么情况下这套做法会失效
反例很明确：如果多个域名中的某一个并不受你控制，或者内容相似但业务主体不同，那么用 robots.txt 统一处理就是错的。例如区域经销商各自运营独立域名，内容模板相似但价格、库存、联系方式不同。此时把这些域名当作镜像去限制抓取，会误伤各区域站点的自然流量。
另一种失效情形是：你希望某个域名彻底从索引中移除，却只写了 Disallow: /。抓取限制不等于索引移除。已收录 URL 可能仍会出现在结果中，只是摘要信息可能陈旧。要移除索引，通常需要让页面返回 404 或 410，或使用 noindex，并确保抓取代理能够读到该指令。若 robots.txt 阻止了抓取，noindex 也可能无法被看到，这是常见的自相矛盾配置。
还有一个判断依据：如果多个域名的相似内容各自有独立外链和用户直接访问，那么“合并为一个主域名”未必是最优解。此时更合理的做法是保留各域名，分别写清 canonical，并让 robots.txt 保持允许抓取。是否合并，取决于你是否愿意放弃这些域名的独立信号。
下一步动作：先做域名角色表，再改 robots.txt
不要先打开 robots.txt 编辑器。先列一张表，每个域名一行，写清四列：当前是否有自然流量、是否有独立外链、业务上是否必须保留、目标角色。填完之后，只有“目标角色”这一列会决定 robots.txt 的写法。
- 目标角色为主站：允许抓取，canonical 自指，提交站点地图。
- 目标角色为备用站：允许抓取，配置全站 301，不写 Disallow。
- 目标角色为不参与自然搜索的落地页：可限制抓取，但同步检查已收录 URL，必要时用 404 或 noindex 处理。
- 目标角色为独立区域站：允许抓取，各自 canonical，不与其他域名互指。
改完之后，用一个具体动作验证：对每个域名分别请求 /robots.txt，确认返回 200 且内容与角色表一致；再抽查一个代表性 URL，确认它的跳转、canonical 和 meta robots 没有和 robots.txt 互相矛盾。如果发现某个域名允许抓取但 canonical 指向另一个域名，而另一个域名又禁止抓取，这就是需要优先修复的冲突。修复后重新检查该 URL 的抓取与索引状态，再决定是否调整角色表。整个判断的落脚点始终是：先明确域名用途，再让 robots.txt 只承担它真正能承担的那部分工作。
