站长死链查询检查前需要准备哪些信息：先备好这份清单
📱 Mozilla/5.0 AppleWebKit/537.36 (KHTML, like Gecko; compatible; ClaudeBot/1.0; +claudebot@anthropic.com)
🔗 /900b99b67767.html
📄
站长死链查询检查前需要准备哪些信息：先备好这份清单
做站长死链查询之前，最该先准备的不是工具，而是三类信息：待查范围、判定依据、处理权限。范围决定你查哪些目录和参数，判定依据决定什么算死链，处理权限决定查出来之后能不能改。三者缺一个，查询结果往往只能停在表格里。
先确定查询范围：从哪几个入口开始
死链查询不是把整站无差别爬一遍就完事。时间和人手有限时，先圈定范围能省掉大量无效工作。准备以下信息：
- 站点根目录或子目录清单，例如只查
/product/和/news/。 - 是否包含参数页，例如带
?id=、?page=的地址。参数页容易产生大量重复和临时失效，是否纳入要先定。 - 是否包含已下线但仍有外链的旧栏目。这类页面往往是最该优先处理的死链来源。
- 站点当前的 URL 规范：带不带
www、用不用末尾斜杠、是否强制 HTTPS。规范不统一时，同一页面可能被当成多条记录。
如果站点有站点地图，可以直接以站点地图列出的 URL 作为初始清单。但要记住：站点地图只说明你希望被收录的地址，不代表这些地址现在都返回正常状态，也不保证搜索引擎已经收录。
准备判定依据：什么情况算死链
“打不开”和“死链”不是一回事。开始查询前，先明确判断标准，否则结果无法复现。需要准备：
- HTTP 状态码的判定口径。常见做法是把 404 和 410 视为需要处理的死链；301、302 属于跳转，是否算问题取决于跳转目标是否有效；5xx 多为服务端临时或持续故障，要和真正的“页面不存在”分开记录。
- 是否检查跳转链。一条 URL 返回 301，但跳转目标本身又是 404，这种情况只看首跳状态会漏掉。准备时说明是否跟踪多级跳转。
- 检查的超时与重试次数。网络抖动会让正常页面偶发失败。设定超时时间和重试次数，能减少误报。
- 是否核对 robots.txt。被 robots.txt 禁止抓取的地址，查询工具可能直接跳过或报错，这不等于页面失效。抓取限制和索引移除是两件事，不能互相替代。
一个可执行的判断例子（假设场景）：某条 URL 首次请求返回 503，重试两次后返回 200。按“重试后仍失败才算死链”的口径，它应被排除；若按“首次失败即记录”，它会被误判。口径不同，结果差异很大，所以判定标准要在查询前写下来。
准备处理权限与记录方式
查出死链只是第一步，能不能改决定这份清单的价值。提前确认：
- 谁有权限修改服务器配置、页面模板或内容管理系统。
- 是否有权添加 301 跳转规则，以及跳转目标由谁确定。
- 结果记录在哪里：表格字段至少包含原 URL、状态码、发现时间、处理方式、处理人、复查时间。
如果只有查看权限、没有修改权限，那么查询范围应缩小到最关键的栏目，先产出一份可交接的清单，而不是铺开全站。
按观察、判断、处理、复查推进
观察：用准备好的范围跑一次查询，导出原始结果，不做删减。 判断：按事先定好的状态码口径分类，剔除重试后恢复正常的记录，标出跳转链断裂的条目。 处理：对确认的死链，选择恢复内容、设置 301 到最相关的新页面，或保留 404/410。跳转目标要与原内容主题相关，不要全部指向首页。 复查：处理完成后间隔一段时间重新查询同一批 URL，确认状态码已改变且跳转目标可访问。
需要说明的是，HTTPS 只表示连接加密，不代表页面不会失效，也不构成安全或排名保证。死链问题要单独查、单独处理。
人手有限时的优先顺序
先处理有外部链接指向的死链，再处理站内导航和栏目页中的死链，最后处理无入口的孤立失效页。判断依据是：前者影响面更大，修复收益更集中。如果无法获取外链数据，就按栏目流量或重要性排序，从主栏目开始。
下一步建议：先写下你的查询范围和状态码判定口径，各用一句话，然后只对主栏目跑一次小范围查询，验证口径是否可行，再决定是否扩大范围。
