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

死链优化, 怎样取得可复查的状态证据

死链优化的状态证据，指的是能让你在几天或几周后重新打开、得到同一结论的记录。可复查的证据至少包含四项：请求的完整URL、请求时间、服务器返回的状态码或错误类型、以及跳转链路的每一跳。只截一张“404页面”的图不算证据，因为它无法说明这个URL此前是什么状态、是否被跳转、是否被robots.txt挡住。

先固定检查口径，再开始收集

同一批URL在不同时间、不同User-Agent、不同协议下可能得到不同结果。开始前先写死口径：用哪个域名、是否带www、是否跟随跳转、用哪个User-Agent。建议先用curl -I -L跟随跳转，再用curl -I不跟随跳转，两次结果都留存。判断规则：不跟随时看第一跳状态码，跟随时看最终落点状态码；两者不一致，说明存在跳转链，需要单独记录每一跳。

可执行清单：查什么、怎么查、结果说明什么

• 查单条URL的即时状态。用curl -I -L -A "Mozilla/5.0" https://example.com/old-page，把完整输出存成文本。结果说明：200表示可访问，301/302表示跳转，404/410表示不存在，403/401表示被拒绝，5xx表示服务端异常。5xx是临时还是持续，需要隔一段时间再查一次，不能凭一次结果下结论。
• 查跳转链长度与落点。在curl输出里数Location出现次数，或使用浏览器开发者工具的Network面板勾选Preserve log。结果说明：一跳落到200通常可接受；多跳或落到另一个404，说明跳转规则本身有问题，属于要优先修的对象。
• 查robots.txt是否挡了抓取。直接请求/robots.txt并保存内容，再对照目标路径。结果说明：被Disallow挡住的URL，抓取工具看不到真实状态，此时得到的“404”不能当作页面已死的证据。要区分“抓取受限”和“索引移除”，前者不等于后者。
• 查站点地图与实际状态是否一致。把sitemap里的URL逐条跑一遍状态检查，输出CSV：URL、状态码、跳转落点、检查时间。结果说明：sitemap里存在404，说明提交源本身要清理；sitemap里没有但站内链接指向的URL，需要从内链和日志里另找。sitemap只表示你希望被发现，不保证被收录。
• 查内链入口。用站内搜索或爬虫工具抓取全站，筛出指向目标URL的链接页。结果说明：一个404如果没有任何内链，影响面小；如果有大量内链，应优先改链接或加跳转，而不是只提交删除。
• 查历史状态。如果URL曾经是200，保留当时的响应头或日志片段作为对照。结果说明：能证明“从可用变为不可用”的时间点，比只记录当前404更有说服力。

证据怎么存，才能复查

每条记录至少包含：完整URL、检查时间（带时区）、请求方法与User-Agent、原始响应头、状态码、跳转落点。存成纯文本或CSV，不要只存截图。复查时用同一条命令重跑，对比两次输出。如果两次结果不同，先排查是不是口径变了，再判断是不是页面状态真的变了。HTTPS只能说明传输层加密，不能作为页面可用或安全的证据。

时间人手有限时的处理顺序

1. 先处理返回5xx的URL，因为它可能是服务端故障，影响面通常大于单条404。
2. 再处理有内链指向的404，改链接或做301到最相关的新页面。
3. 然后清理sitemap里已确认不存在的URL。
4. 最后处理无内链、无外链、无历史流量的孤立404，可以只记录不动作。

判断依据是影响面：被链接、被抓取、被用户访问的次数越多，越靠前。没有这些数据时，按“5xx→有内链404→sitemap不一致→孤立404”的顺序执行，属于保守但可复查的安排。

下一步

选10条已知有问题的URL，按上面的命令跑一遍，生成一份含URL、状态码、跳转落点、检查时间的CSV。拿这份表对照内链和sitemap，标出哪些必须修、哪些只需记录，再决定第一批动手的对象。