先给结论:不要试图用一份笼统的 robots.txt 或一句“主站收录、其他不收录”来解决问题。正确做法是给每个域名写一句可验证的用途声明,再让技术配置与这句话一致。例如,假设你手上有三个域名:一个品牌主站、一个面向特定地区的旧域名、一个只用于活动短期的域名。你需要逐个说明它是“对外正式入口”“地区分流”还是“临时承接”,然后决定哪些允许被抓取、哪些只做跳转、哪些必须保留独立页面。判断标准不是哪个域名更“重要”,而是用户和搜索引擎在该域名上看到的内容是否与用途声明一致。
用途声明要具体到“谁在什么条件下会看到这个域名的内容”。比如主站声明为“所有默认用户的正式入口”,地区域名声明为“仅当用户主动选择该地区时提供对应语言和价格”,活动域名声明为“活动结束后不再更新,只保留跳转”。这三句话会直接导出不同的技术处理:主站允许抓取并提交站点地图;地区域名如果内容与主站高度相似,应通过 canonical 指向主站对应页面,或只保留跳转;活动域名在结束后应返回 301 到主站相关页面,而不是长期保留相似内容。
这里有一个常见误区:把 robots.txt 的 Disallow 当成索引移除工具。它只限制抓取,不保证已有索引被删除。如果你希望某个相似域名不再出现在结果中,更可靠的动作是让页面返回 301 或 410,并确认服务器响应确实如此。做完这一步后,下一步是观察该域名下的 URL 是否仍在被抓取;如果仍被抓取,说明限制没有按预期生效,需要检查是否有其他路径或子域仍在暴露内容。
面对多个域名时,先问三个问题,答案会把你推向不同处理:
假设你有一个旧域名,上面有 200 个页面,其中 180 个与主站内容几乎相同,20 个是旧域名独有的历史资料。此时不应把整个域名全部跳转,否则会丢掉那 20 个页面的独立价值。更合理的做法是:180 个相似页逐页 301 到主站对应页,20 个独有页保留并加上指向主站相关栏目的内部链接。这个动作的结果是,搜索引擎和用户仍能通过旧域名找到独有资料,而相似内容不会形成两个入口。
个别样本成立,不代表规模化后仍然成立。你可能测试了 5 个页面,发现加 canonical 后主站版本被收录,于是决定对全部 200 个页面照做。但规模化后可能出现例外:某些页面的 canonical 指向了一个本身未被收录的 URL,或者两个域名下的页面标题和正文差异过大,导致 canonical 被忽略。此时不能因为个别样本成功就认定整个域名可以照搬同一策略。
更稳妥的做法是先按内容相似度分组,而不是按域名整体处理。相似度高的组统一加 canonical;相似度中等或存在独立价值的组保留独立页面;相似度低且无独立价值的组做 301。每组处理完后,分别检查该组内是否有页面仍被抓取、是否仍有重复标题。如果某一组出现例外,只调整该组,不推翻其他组的结论。
用途声明写完、技术配置改完后,需要确认它是否真的生效。可执行的动作包括:
curl -I 查看返回状态码,确认 301、410 或 200 与你的声明一致。这些动作的结果会直接影响下一步:如果状态码与声明不一致,先修服务器配置;如果 canonical 指向不可访问,先修目标 URL;如果站点地图包含跳转页,先清理站点地图。只有这些基础项一致后,才值得继续观察收录变化。注意,站点地图不保证收录,HTTPS 也不保证安全无漏洞或排名提升,它们只是辅助信号,不能替代用途声明本身的清晰度。
最后,把每个域名的用途、允许抓取的范围、相似内容的处理方式、停止更新后的返回状态写成一页短文档。这份文档不需要复杂,但要能让另一个人在不问你本人的情况下判断某个 URL 应该返回什么。例如:
这份文档的价值在于,当出现新的相似域名或新的页面类型时,你可以先对照用途声明判断它属于哪一类,而不是重新争论一遍。如果某个域名的实际表现与声明不符,优先修改配置或修改声明,而不是同时保留两套说法。这样,多个域名承载相似内容时,每个域名的用途就是可验证、可交接、可调整的。