失效链接排查_内容与技术如何协作
📱 Mozilla/5.0 AppleWebKit/537.36 (KHTML, like Gecko; compatible; ClaudeBot/1.0; +claudebot@anthropic.com)
🔗 /639a5ab75b99.html
📄
失效链接排查_内容与技术如何协作
内容与技术协作排查失效链接，核心是建立一份“单一可信来源”的链接清单：由内容侧确认每个链接应该指向什么，由技术侧确认它现在返回什么状态，双方用同一份清单核对差异，而不是各自维护一份表格。适用前提是站点有一定规模、链接由多人修改、且出现过改了内容却忘了改链接或删了页面却留下死链的情况。如果只有一个人维护且页面很少，直接手动检查即可，不必上这套流程。
先约定谁负责什么
协作失败通常不是工具问题，而是职责边界模糊。建议按下表先分好工，再开始排查。
- 内容侧负责“意图”：这个链接原本指向哪篇内容、这个页面是否应该继续存在、失效后应该跳到哪个替代页面。
- 技术侧负责“事实”：链接实际返回的状态码、是否经过跳转、跳转链有多长、目标页面是否可被抓取。
- 共同负责“决策”：是修复链接、换成新地址、还是删除该链接并补一段说明文字。
判断结果的方式很简单：任何一条失效链接，如果内容侧说不出它“应该指向哪里”，这条就不该由技术侧擅自决定跳转目标。反过来，如果技术侧拿不出实际状态码，内容侧也不该凭印象判断链接是否正常。
用一份清单串起两边的工作
具体做法可以按下面的步骤执行，规模不大时用表格软件即可，不必一开始就引入复杂系统。
- 技术侧先跑一遍站内链接和出站链接，导出“链接地址、所在页面、返回状态码”三列。状态码为 404、410 以及连续多次 5xx 的，先标记出来。
- 内容侧在同一份清单上补两列：“期望目标”和“处理意见”。期望目标写具体页面，处理意见写修复、替换或删除。
- 双方对不一致的行逐条确认。例如技术侧报 404，内容侧认为该页面还在，那就要查是不是路径写错或大小写不一致。
- 技术侧执行修改，内容侧复核修改后的页面读起来是否通顺，链接文字与目标内容是否匹配。
- 修改完成后重新跑一遍，确认原失效地址不再返回错误状态。
这里要区分“可能原因”和“已经定位的原因”。某条链接返回 404，可能是页面被删除、可能是路径拼写错误、也可能是大小写或结尾斜杠不一致，在没逐条核对前不要断言是其中某一个。只有查过服务器记录或实际请求结果，才能写成已定位的原因。
技术侧要给出的可核对信号
内容侧看不懂日志，所以技术侧要把结果翻译成能核对的信号，而不是丢一堆原始数据。
- 状态码：200 表示正常，301 或 302 表示跳转，404 表示未找到，410 表示已删除，5xx 表示服务器端问题。
- 跳转链：一个链接如果经过多次跳转才到目标，用户和抓取都会变慢，应尽量改成直接指向最终地址。
- 目标可达性：跳转后的目标页面本身是否正常，避免“修好的链接指向另一个坏页面”。
- 范围说明：本次检查覆盖了哪些页面、哪些没覆盖，避免内容侧误以为全站都已排查。
如果要在页面里说明链接结构，技术侧可以用文字描述，例如把跳转关系写成 <a> 标签的指向变化，但不要把它当成真实可点击的代码直接贴进正文。
验收信号与返工预防
做完一轮后，用下面几条判断是否真的交付清楚：
- 清单上每一行都有明确结论，没有“待定”长期挂着。
- 内容侧能指着任意一条说清它为什么这样处理。
- 重新检查时，原先标记的错误状态不再出现。
- 新增或删除页面时，有约定的人负责同步更新相关链接。
返工最常见的原因是两边各改各的：内容侧换了页面地址却没通知技术侧，技术侧批量改了跳转却没让内容侧确认。把“谁在什么情况下必须通知对方”写进流程，比事后反复排查更省事。
下一步建议先选一个栏目做小范围试点：技术侧导出该栏目的链接状态，内容侧补上期望目标，走完一轮完整流程。跑通之后再决定是否扩大到全站，以及是否需要把清单换成更自动化的方式。
