站长死链查询检查前需要准备哪些信息:先备好这份清单

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

站长死链查询检查前需要准备哪些信息:先备好这份清单

做站长死链查询之前,最该先准备的不是工具,而是三类信息:待查范围、判定依据、处理权限。范围决定你查哪些目录和参数,判定依据决定什么算死链,处理权限决定查出来之后能不能改。三者缺一个,查询结果往往只能停在表格里。

先确定查询范围:从哪几个入口开始

死链查询不是把整站无差别爬一遍就完事。时间和人手有限时,先圈定范围能省掉大量无效工作。准备以下信息:

如果站点有站点地图,可以直接以站点地图列出的 URL 作为初始清单。但要记住:站点地图只说明你希望被收录的地址,不代表这些地址现在都返回正常状态,也不保证搜索引擎已经收录。

准备判定依据:什么情况算死链

“打不开”和“死链”不是一回事。开始查询前,先明确判断标准,否则结果无法复现。需要准备:

  1. HTTP 状态码的判定口径。常见做法是把 404 和 410 视为需要处理的死链;301、302 属于跳转,是否算问题取决于跳转目标是否有效;5xx 多为服务端临时或持续故障,要和真正的“页面不存在”分开记录。
  2. 是否检查跳转链。一条 URL 返回 301,但跳转目标本身又是 404,这种情况只看首跳状态会漏掉。准备时说明是否跟踪多级跳转。
  3. 检查的超时与重试次数。网络抖动会让正常页面偶发失败。设定超时时间和重试次数,能减少误报。
  4. 是否核对 robots.txt。被 robots.txt 禁止抓取的地址,查询工具可能直接跳过或报错,这不等于页面失效。抓取限制和索引移除是两件事,不能互相替代。

一个可执行的判断例子(假设场景):某条 URL 首次请求返回 503,重试两次后返回 200。按“重试后仍失败才算死链”的口径,它应被排除;若按“首次失败即记录”,它会被误判。口径不同,结果差异很大,所以判定标准要在查询前写下来。

准备处理权限与记录方式

查出死链只是第一步,能不能改决定这份清单的价值。提前确认:

如果只有查看权限、没有修改权限,那么查询范围应缩小到最关键的栏目,先产出一份可交接的清单,而不是铺开全站。

按观察、判断、处理、复查推进

观察:用准备好的范围跑一次查询,导出原始结果,不做删减。 判断:按事先定好的状态码口径分类,剔除重试后恢复正常的记录,标出跳转链断裂的条目。 处理:对确认的死链,选择恢复内容、设置 301 到最相关的新页面,或保留 404/410。跳转目标要与原内容主题相关,不要全部指向首页。 复查:处理完成后间隔一段时间重新查询同一批 URL,确认状态码已改变且跳转目标可访问。

需要说明的是,HTTPS 只表示连接加密,不代表页面不会失效,也不构成安全或排名保证。死链问题要单独查、单独处理。

人手有限时的优先顺序

先处理有外部链接指向的死链,再处理站内导航和栏目页中的死链,最后处理无入口的孤立失效页。判断依据是:前者影响面更大,修复收益更集中。如果无法获取外链数据,就按栏目流量或重要性排序,从主栏目开始。

下一步建议:先写下你的查询范围和状态码判定口径,各用一句话,然后只对主栏目跑一次小范围查询,验证口径是否可行,再决定是否扩大范围。

图1 图2

nginx