robots txt 改版或迁移时应核对什么 - 先查抓取边界再做替换
📱 Mozilla/5.0 AppleWebKit/537.36 (KHTML, like Gecko; compatible; ClaudeBot/1.0; +claudebot@anthropic.com)
🔗 /9c93a5fc1437.html
📄
robots txt 改版或迁移时应核对什么 - 先查抓取边界再做替换
改版或迁移时，robots.txt 最先要核对的是：它有没有在无意中挡住新页面、放行旧路径，或者把搜索引擎的抓取引向已经失效的地址。正确做法是先把旧文件完整备份，再逐行对照新站结构，确认允许与禁止规则都指向当前真实存在的路径，最后用抓取测试工具复查，而不是直接覆盖。
先观察：旧文件里有哪些规则会随迁移失效
打开旧站的 robots.txt，把它当作一份“抓取边界清单”来读。重点看三类内容：
- Disallow 路径：是否禁止了 /search、/tmp、/cart 这类功能路径，这些路径在新站是否还存在。
- Allow 例外：是否用 Allow 放行了被上层 Disallow 覆盖的目录，新站目录改名后这些例外可能失效。
- Sitemap 声明：文件末尾的 Sitemap 地址是否仍指向旧域名或旧目录。
如果旧站用 Disallow: / 在测试期屏蔽了全站，迁移上线时忘记删除，后果最严重：搜索引擎不会抓取任何页面。这类“临时屏蔽”必须在上线清单里单独列一项。
再判断：哪些规则是故意保留，哪些是历史遗留
不要默认旧规则都该照搬。逐条问两个问题：这条规则今天还保护什么？删掉它会不会暴露不该收录的页面？
常见判断依据：
- 后台、结算、用户中心等路径，通常继续禁止抓取，但要确认新路径名是否已变化。
- 旧活动页、旧分类页如果已 301 到新地址，禁止抓取旧路径意义不大，关键是让跳转可被抓取。
- 单纯为了“省抓取配额”而禁止大量正常内容页，迁移后应重新评估，因为配额问题通常不是靠 robots.txt 解决的。
需要明确一点：robots.txt 只表达抓取限制，不等于可靠的索引移除。被 Disallow 的网址仍可能因外部链接出现在搜索结果里，只是摘要信息受限。要真正移除，应配合 noindex 或移除工具，且 noindex 页面必须允许被抓取才能被读到。
处理：迁移时的最小改动顺序
时间和人手有限时，按下面顺序处理，先做影响面最大的：
- 备份旧 robots.txt，记录修改前内容。
- 确认新站根目录可正常访问
/robots.txt，返回 200 而不是 404 或 301 到无关页面。 - 删除测试期的全站屏蔽规则。
- 把 Sitemap 地址改成新域名下的真实地址；站点地图不保证收录，但地址写错会直接浪费提交机会。
- 逐条核对 Disallow 与 Allow，路径名以新站实际目录为准。
- 若新旧域名并行，确认 robots.txt 本身没有被错误地跨域引用。
假设旧站有一条 Disallow: /old-category/，新站分类改名为 /category/。若直接沿用旧文件，新分类不会被挡，但旧路径规则已无意义；若新站误把 /category/ 写进 Disallow，整批分类页将无法被抓取。这个例子说明：规则要跟着目录结构走，不能整份复制。
复查：上线后怎么验证规则真的生效
复查分两步。第一步用搜索引擎提供的抓取测试或 robots.txt 测试功能，输入几个代表性网址，看返回的是“允许”还是“被阻止”。第二步在服务器日志或抓取统计里观察这些路径是否出现真实抓取记录。
检查项清单：
- 首页、核心栏目页、新文章页：应为允许。
- 后台、结算、搜索结果页：按需禁止，且确认禁止的是当前路径。
- Sitemap 中的网址：抽样检查是否被自身规则挡住。
- HTTPS 与 HTTP、带 www 与不带 www：确认 robots.txt 在各版本下都能正确返回，避免因协议或子域不一致读到旧文件。
不同搜索引擎对 robots.txt 的解析细节和支持范围存在差异，尤其是通配符和 Allow 的处理，需要分别核查，不能只测一家就认为全部通过。另外，HTTPS 只解决传输加密，不代表站点没有漏洞，也不直接等于排名提升，别把它当作迁移后的安全或排名保证。
下一步：把上面这份核对清单落到一次实际演练中，选三到五个代表性网址跑一遍抓取测试，确认结果符合预期后，再正式替换线上 robots.txt。
