搜索引擎抓取日志：改版或迁移时应核对什么？
📱 Mozilla/5.0 AppleWebKit/537.36 (KHTML, like Gecko; compatible; ClaudeBot/1.0; +claudebot@anthropic.com)
🔗 /dba6371efd26.html
📄
搜索引擎抓取日志：改版或迁移时应核对什么？
改版或迁移时，搜索引擎抓取日志最该核对的是：搜索引擎是否仍在抓取旧地址、是否已发现并抓取新地址、抓取结果是否出现大量错误或异常跳转。日志本身不会告诉你排名变化的原因，但它能直接暴露迁移后抓取路径是否断裂。下面是一份可执行清单，每项都包含查什么、怎么查、结果说明什么。
先确认日志覆盖了改版前后的完整时间窗
查什么：日志是否包含改版前至少两周、改版后至少四周的记录。怎么查：按日期字段过滤，确认没有整天缺失或只保留最近几天的日志。结果说明什么：如果改版后日志量骤降甚至归零，可能是服务器配置、日志切割或CDN回源导致记录丢失，而不是搜索引擎停止抓取。缺少基线时，你无法判断抓取量变化是迁移引起还是正常波动。
核对旧URL的抓取状态码分布
查什么：旧地址返回的是301、302、404还是200。怎么查：从日志中提取状态码字段，按旧路径前缀分组统计。结果说明什么：
- 旧地址大量返回200：说明重定向未生效，搜索引擎仍能直接访问旧内容，新旧两套地址可能同时被抓取。
- 旧地址返回301且目标正确：这是迁移的正常状态，但仍需观察目标地址是否被抓取。
- 旧地址返回302：临时跳转不会传递稳定的迁移信号，应改为301。
- 旧地址返回404：若该地址原本有流量或外链，属于迁移遗漏，需要补重定向。
注意，robots.txt 的抓取限制不等于可靠的索引移除。如果你用 robots.txt 屏蔽旧目录，日志中看不到抓取，但旧页面仍可能留在索引里，必须配合重定向或移除请求处理。
检查新URL是否被实际抓取，而非只被提交
查什么：新地址在日志中是否出现，以及抓取频次是否上升。怎么查：用新路径前缀过滤日志，统计独立URL数量和请求次数。结果说明什么：提交站点地图不保证收录，也不保证抓取。如果新地址在日志中从未出现，说明搜索引擎尚未发现它们，需要检查内链、站点地图和旧地址重定向是否指向了新地址。如果新地址被抓取但频次很低，可以观察一段时间，不要仅凭一天日志下结论。
区分抓取错误是“可能原因”还是“已经定位的原因”
查什么：5xx、429、连接超时等异常状态码的比例和集中路径。怎么查：按状态码和URL分组，找出错误最集中的目录或参数。结果说明什么：
- 5xx集中出现：可能是源站压力、数据库连接或迁移后配置问题，需要结合服务器错误日志确认，不能只凭抓取日志断定。
- 429集中出现：可能是抓取频率触发了限流，需要检查是否有意设置了速率限制。
- 超时集中在特定页面：可能是该页面渲染或查询过慢，也可能是网络链路问题。
一项现象可能有多个解释，不要断言唯一原因。先定位到具体URL和时段，再结合服务端日志交叉验证。
用一次小规模验证收尾
假设你迁移了 /old-a/ 到 /new-a/。步骤是：在日志中查 /old-a/ 最近七天的状态码，确认是否为301且 Location 指向 /new-a/；再查 /new-a/ 是否被同一搜索引擎抓取过。判断结果：若旧地址301、新地址有抓取记录，说明该条迁移路径基本通畅；若旧地址301但新地址零抓取，重点检查新地址是否被内链或站点地图覆盖；若旧地址仍返回200，先修复重定向再谈其他优化。
下一步：从日志中导出改版前后各四周的抓取记录，按上述五项逐项打勾，把未通过的项目按“旧地址状态码—新地址抓取—错误集中路径”的顺序修复，再观察下一轮日志变化。
