死链修复工具：怎样区分访问抓取与索引结果
📱 Mozilla/5.0 AppleWebKit/537.36 (KHTML, like Gecko; compatible; ClaudeBot/1.0; +claudebot@anthropic.com)
🔗 /f8fa5c60af8e.html
📄
死链修复工具：怎样区分访问抓取与索引结果
用死链修复工具处理一批失效链接后，真正要判断的是两件事：搜索引擎有没有尝试访问这些链接（抓取），以及这些链接有没有从索引里消失（索引）。抓取记录只能说明爬虫来过，索引状态才决定用户还能不能从搜索结果点进死链。两者不一致是常态，需要分别查、分别处理。
一个假设例子：抓取成功不等于索引已移除
假设某站点改版后留下 200 条旧产品页，全部返回 404。用死链修复工具扫描后，你把它们统一改成 301 跳转到新分类页，并在服务器日志里看到爬虫当天访问了其中 150 条。此时容易犯的错误是：看到日志有记录就认为问题已解决。实际上日志只证明“抓取”发生了，索引里那 200 条旧 URL 可能仍然存在，用户搜索旧标题时照样能点到跳转页甚至 404。
正确做法是分两步核对：先确认抓取层面的响应状态，再确认索引层面的 URL 是否还在。抓取是过程，索引是结果，工具报出的“已处理”通常只覆盖前者。
抓取层面的检查项
抓取指爬虫请求 URL 并拿到响应。判断抓取是否正常，看的是服务器返回的状态码和响应内容，而不是搜索结果里有没有这条链接。
- 用
curl -I或浏览器开发者工具查看目标 URL 返回的状态码，确认是 301、302、404 还是 410。 - 检查
robots.txt是否屏蔽了该路径。注意：robots.txt 的抓取限制不等于可靠的索引移除，被屏蔽的 URL 仍可能留在索引中。 - 查看服务器访问日志中的爬虫 UA 与请求时间，确认它确实请求过，而不是只出现在站点地图里。
- 提交站点地图只能提示发现入口，站点地图不保证收录，也不代表抓取已经完成。
如果目标是让旧 URL 彻底退出，永久失效的页面更适合返回 410 或保留 404，而不是 301 到无关页面。301 会把权重和用户导向新地址，但旧 URL 的索引替换需要时间，且不保证一定替换。
索引层面的检查项
索引指 URL 被搜索引擎收录、可被搜索展现。判断索引状态要用站点维度的查询方式，而不是单看某次抓取日志。
- 在对应搜索引擎的站点管理后台查看“已编入索引”的 URL 数量与具体列表。
- 用
site:查询做粗筛，但它只是估算，不能作为精确的收录依据。 - 对重点 URL 使用“网址检查”类功能，查看该 URL 当前的索引状态与上次抓取时间。
- 核对 canonical 标签指向，避免旧 URL 被新页面声明为规范版本而继续保留。
不同搜索引擎的索引更新节奏和支持的移除方式不同，需要分别核查，不能用一个平台的结果推断另一个平台。
两种处理方案的适用条件
面对死链，常见选择是“修复并跳转”与“直接移除索引”，判断依据是页面是否还有等价内容。
- 301 跳转：适用于旧页面有明确的新对应页面，且内容主题一致。判断结果是用户和爬虫都被导向有效内容，旧 URL 逐步被替换。
- 410 或保留 404：适用于内容已永久删除且无替代。判断结果是抓取层面明确告知失效，索引移除比 301 更直接，但仍需等待搜索引擎处理。
错误组合是：页面已无内容却 301 到首页，这会被视为软 404，既不利于索引清理，也浪费抓取配额。另一个错误是只改 robots.txt 就认为索引已移除，实际抓取被挡、索引仍在。
下一步怎么执行
先导出死链修复工具给出的失效 URL 清单，逐条标注“有替代内容”或“无替代内容”，再按上面的条件分别设置 301 或 410/404。设置完成后，隔一段时间分别复查服务器日志的抓取状态和站点管理后台的索引列表，确认抓取与索引两个层面都已按预期变化，而不是只看其中一项就结束。
