爬虫控制：改版或迁移时应核对什么
📱 Mozilla/5.0 AppleWebKit/537.36 (KHTML, like Gecko; compatible; ClaudeBot/1.0; +claudebot@anthropic.com)
🔗 /d5fd659f153f.html
📄
爬虫控制：改版或迁移时应核对什么
改版或迁移时，爬虫控制要核对的核心是：旧URL是否还能被正常抓取、抓取规则是否随新结构同步更新、旧路径是否给出明确的去向信号。最容易被忽略的不是新页面本身，而是 robots.txt、站点地图、重定向和页面级指令在迁移过程中出现互相矛盾，导致爬虫抓不到、抓错或反复抓无效地址。
先确认哪些控制手段在迁移中会失效
爬虫控制不是单一文件，它由几个层面共同作用，迁移时每一层都可能被覆盖或遗漏：
robots.txt：控制抓取范围，但不等于索引移除。把旧目录写进 Disallow，只能阻止抓取，已经收录的页面仍可能留在结果里。- 页面级
meta robots与X-Robots-Tag：控制索引与跟踪，迁移后模板若沿用旧配置，可能把新页面一并设成noindex。 - 站点地图：列出希望被发现的新URL，但不保证收录，它只是发现渠道之一。
- 重定向：把旧URL的权重与用户导向新URL，属于迁移的核心信号。
适用前提：你已经有可访问的旧站和新站，能读取服务器上的 robots.txt，并能对具体URL发起请求查看响应。若站点还在本地未上线，先跳过线上核对，只做配置比对。
逐项核对清单与判断结果
按下面顺序执行，每步都能得到可判断的结果：
- 读取新站 robots.txt：直接请求
/robots.txt，确认没有误屏蔽整站（如Disallow: /），也没有把新资源目录、静态文件目录写进禁止段。判断结果：若关键目录被屏蔽，爬虫无法抓取，需先修正再谈其他。 - 抽查旧URL响应：取一批有代表性的旧地址，逐个请求，记录状态码。判断结果：301 表示永久迁移到新地址；302 是临时跳转，不适合长期迁移；404 表示旧地址无去向，需要补重定向或确认是否应保留。
- 检查重定向链：确认旧URL直接跳到最终新URL，而不是经过多跳。判断结果：出现 A→B→C 的多跳链，会拖慢抓取并可能丢失信号，应改为一步到位。
- 核对页面级指令：在新页面模板中查看是否存在
noindex或错误的canonical。判断结果：若新页面 canonical 仍指向旧域名，等于告诉搜索引擎“真正版本在旧站”，迁移目标落空。 - 比对站点地图：确认站点地图只列新URL，且地址可访问。判断结果：站点地图里混入大量已重定向或404的旧地址，会浪费抓取预算，应清理。
假设示例：旧站有 /old/page，新站对应 /new/page。若请求 /old/page 返回 301 且 Location 指向 /new/page，同时新页面无 noindex、canonical 指向自身，则这条迁移路径的爬虫控制是通的。反之，若旧地址返回 200 但内容是空白占位页，爬虫会认为旧页面仍有效，新页面反而难以被替换。
HTTPS 与安全信号不要混为一谈
迁移常伴随 HTTP 到 HTTPS 的切换。需要明确：HTTPS 不保证安全无漏洞，也不保证排名。它只是传输层加密。核对时把两件事分开：一是 HTTP 旧地址是否 301 到 HTTPS 新地址；二是证书是否有效、是否覆盖所有子域。证书错误会导致抓取中断，但这属于可访问性问题，不是排名手段。
不同抓取方的规则要分别核查
robots.txt 是约定，不是强制。不同搜索引擎、不同抓取目的对同一份 robots.txt 的遵守程度和处理方式可能不同，付费广告的抓取与自然搜索抓取也走不同通道。因此不要假设“写了 Disallow 就万事大吉”。可执行的核对方法是：对每个你关心的抓取方，分别查看其官方文档中对 robots.txt、站点地图、重定向的支持说明，再结合服务器日志确认实际抓取行为。日志里若出现大量对已重定向旧地址的重复请求，说明信号还没被完全接收，需要继续观察或调整。
验收信号与下一步
迁移后不要只看首页。抽查若干旧URL和新URL，确认状态码、canonical、robots 指令三者一致；查看服务器日志中抓取分布是否逐步转向新地址；确认站点地图可访问且只含有效新URL。如果发现旧URL仍返回 200 且内容重复，优先补 301；如果新页面被 noindex 挡住，先修模板再提交站点地图。
下一步：整理一份旧URL到新URL的映射表，逐条请求并记录状态码与最终地址，把不符合预期的条目按上面清单修正后重新核对。
