📍 WDQWDWQD987AAAAA:216.73.216.165
📱 Mozilla/5.0 AppleWebKit/537.36 (KHTML, like Gecko; compatible; ClaudeBot/1.0; +claudebot@anthropic.com)
🔗 /3dd3dabd8ee4.html
📄

死链查询怎样区分访问抓取与索引结果：先看日志与状态码

死链查询时，访问抓取和索引结果是两件事：抓取只说明搜索引擎的爬虫来请求过这个 URL，索引则说明该 URL 被选入并可出现在搜索结果中。判断顺序应该是先看服务器日志确认有没有真实请求，再用状态码和页面内容确认返回是否正常，最后才判断它是否仍在索引里。时间和人手有限时，优先处理“有抓取、返回异常、且仍有索引入口”的死链，而不是所有 404。

先分清三个可观察信号

把死链查询拆成三层，判断会清晰很多：

• 访问抓取：服务器访问日志或 CDN 日志里出现爬虫 UA 对某个 URL 的请求记录。它只证明“来过”，不证明“收录”。
• 抓取结果：这次请求返回的状态码，如 200、301、404、410、5xx。它决定爬虫这次拿到了什么。
• 索引结果：该 URL 是否能通过站内搜索指令或搜索表现被观察到。抓取成功不等于被索引，返回 404 也不等于立刻从索引消失。

适用前提是你能拿到至少一份服务器日志或 CDN 日志。如果完全没有日志，只能依赖搜索端的索引观察，那就无法严格区分“抓取过”和“被索引”，结论要相应保守。

用日志区分抓取，用状态码区分结果

具体做法可以按下面几步执行：

1. 从日志中筛出目标 URL，记录请求时间、UA、状态码和响应大小。若同一 URL 多次出现不同状态码，按时间排序看变化。
2. 对每个 URL 用 curl -I 或等效方式复测当前返回，确认现在返回的是 200、301 还是 404/410。注意复测结果只代表你请求的这一刻，不等于爬虫当时看到的结果。
3. 把 URL 分成四类：有抓取且返回 200；有抓取且返回 3xx；有抓取且返回 4xx/5xx；无抓取记录。
4. 再对每一类做索引观察，判断它是否仍可能出现在搜索结果中。

判断结果时注意：返回 404 或 410 表示资源不存在，是死链的典型信号；返回 301 表示已永久跳转，应检查跳转目标是否有效；返回 5xx 说明服务器或应用出错，这属于需要优先修复的故障，而不是普通死链。日志里没有某 URL，只能说明在你查看的时间范围内没有抓到，不能断言搜索引擎从未抓取过。

索引结果要单独观察，不能从抓取推断

索引结果需要独立检查。常用方式是站内搜索指令，例如在搜索框输入 site:example.com/具体路径，看该 URL 是否作为独立结果出现。也可以观察该 URL 在搜索表现报告或流量数据中是否还有点击与展示。

需要留意的边界：站内搜索指令的结果是观察窗口，不是权威的索引数据库，不同搜索引擎的支持和呈现可能不同，必须分别核查。robots.txt 的抓取限制不等于可靠的索引移除：它可能阻止抓取，但已索引的 URL 仍可能因外部链接等原因出现在结果中。站点地图不保证收录，提交了不代表会被抓取或被索引。HTTPS 也不保证页面安全无漏洞或排名更好，它只解决传输加密问题。

时间有限时按这个顺序处理

在资源有限的情况下，建议按影响面排序，而不是按死链数量排序：

• 第一优先：有抓取记录、返回 5xx、且仍有索引或内链指向的 URL。这是服务故障，既影响用户也影响抓取。
• 第二优先：返回 404/410、但仍有站内链接或外部链接指向的 URL。要么恢复内容，要么做 301 指向最相关的新页面。
• 第三优先：返回 404 且无任何入口的孤立 URL，可以只做记录，不必立即处理。
• 最后处理：无抓取记录、无索引、无入口的 URL，通常不影响当前工作。

验收信号可以这样设定：目标 URL 复测返回预期状态码；站内链接不再指向已失效地址；对确认要移除的 URL，观察其索引状态是否随时间变化。不要期待固定见效时间，索引更新取决于搜索引擎自身的调度。

下一步

先导出最近一段时间的服务器或 CDN 日志，按状态码和 URL 分组，标出“有抓取且返回 4xx/5xx”的条目，再对这批 URL 逐一做索引观察。这样得到的就是一份按优先级排序的死链处理清单，而不是一堆无法判断轻重缓急的地址。