检查失效链接，外包前应整理哪些需求
📱 Mozilla/5.0 AppleWebKit/537.36 (KHTML, like Gecko; compatible; ClaudeBot/1.0; +claudebot@anthropic.com)
🔗 /5c337425689b.html
📄
检查失效链接，外包前应整理哪些需求
把“检查失效链接”外包出去之前，需求文档要能让对方在不追问的情况下判断三件事：查哪些页面、判定什么算失效、交付什么结果。最低限度应写清扫描范围、链接类型、失效判定规则、输出格式、复查方式和验收标准。否则多人协作时最容易出现的情况是：对方交来一份链接清单，你却发现漏了站内链接、把跳转当成失效、或者没有记录原始位置，最后只能返工。
先观察：把现状和范围写成可核对的清单
需求整理的第一步不是写工具要求，而是描述现状。可以从以下检查项入手，每一项都写成可验证的句子，而不是“全站检查一下”这类模糊表述。
- 扫描范围：列出具体目录、栏目或页面集合，例如“产品文档下全部页面”“博客文章及其分页”。如果站点有多个子域，要分别列出，不要用“整站”一笔带过。
- 链接类型：区分站内链接、出站链接、图片与脚本等资源引用、下载文件链接、导航与页脚中的重复链接。不同来源的失效处理方式不同，混在一起会让交付物难以使用。
- 页面来源：说明是抓取线上页面，还是直接分析源代码或站点地图。多人协作时，这一条决定了对方能否复现你的页面集合。
- 排除项：明确哪些不算，例如测试环境地址、登录后才可见的页面、第三方统计脚本、邮件中的链接。
范围写完后，让另一位同事只读这份清单，看能否说出“要查多少页面、哪些不查”。如果对方需要猜，说明需求还不够具体。
判断：定义什么算失效，什么不算
“失效链接”在实际检查中并不是一个单一状态。外包前必须把判定规则写死，否则双方对同一份结果的理解会不一致。
- 明确失效：请求返回表示资源不存在的状态码，例如常见的 404、410。这类可以直接列入待处理清单。
- 需要确认：返回 403、401 或超时。它们可能是权限设置、临时网络问题或服务器限制，不能直接当成死链，应单独标注并说明复测方法。
- 跳转链接：301、302 等重定向不等于失效。要说明是否把跳转计入报告、是否追踪最终落点、多级跳转是否算问题。如果站点正在做地址迁移，跳转往往是预期行为。
- 软失效：页面返回正常状态码，但内容已变成“页面不存在”提示或空白模板。这类只能靠页面内容判断，需求里要写清是否检查、由谁抽查。
- 锚点与文件：指向页面内锚点的链接，锚点不存在时页面本身仍可打开；指向 PDF、压缩包的链接，失效表现也可能是下载报错。是否纳入范围要提前说明。
判定规则越具体，外包方越容易给出稳定结果。可以要求对方在报告中保留原始状态码、最终跳转地址和请求时间，便于你复核。
处理：约定交付格式和字段
一份能直接用于修复的链接报告，至少应包含以下字段。可以要求表格或结构化文件，字段名提前定好。
- 问题链接的完整地址。
- 发现该链接的页面地址，也就是链接所在位置，方便定位修改点。
- 链接类型，例如正文、导航、图片、文件。
- 观察到的状态或现象，例如状态码、跳转链、超时。
- 初步判断，例如确认失效、需人工确认、跳转待定。
- 建议处理方向，例如替换目标、删除链接、更新文件地址。建议不等于最终决定，要写明由谁确认。
如果同一目标地址在多个页面重复出现，要说明是逐条列出还是合并统计。合并时仍需保留出现位置，否则修复时还要重新查找。
复查：写清验收方式和责任边界
外包交付不是终点。需求里要写明复查步骤，避免“报告交了但问题没解决”。
- 抽样复核：从报告中抽取若干条，按原始页面地址实际访问，确认现象与报告一致。
- 修复后复测：由谁在修改完成后重新检查同一批链接，复测范围是全部还是抽样，结果如何记录。
- 责任边界：外包方负责发现和记录，还是也负责修改页面。若负责修改，要说明可改哪些文件、是否需要提交记录、由谁审核上线。
- 变更说明：如果检查期间站点内容发生调整，报告以哪个时间点的页面为准。
多人协作时，建议指定一个需求负责人统一解释规则，避免不同同事分别向外包方补充要求，造成口径冲突。
可直接套用的需求骨架
把上述内容压成一页，可以按这个顺序写：检查目标一句话；扫描范围和排除项；链接类型清单；失效与跳转的判定规则；交付字段和格式；复查与验收方式；双方责任和沟通人。写完后再做一次自检：随便挑一个页面，能否根据这份需求判断它是否在范围内、其中一条链接该不该报、报出来长什么样。如果三问都能答上，就可以进入外包询价和比价环节；如果答不上，先补齐对应条目再发出。
