检查失效链接，页面主题过宽时依据什么拆成独立任务
📱 Mozilla/5.0 AppleWebKit/537.36 (KHTML, like Gecko; compatible; ClaudeBot/1.0; +claudebot@anthropic.com)
🔗 /939b28d16184.html
📄
检查失效链接，页面主题过宽时依据什么拆成独立任务
判断标准不是“链接多不多”，而是每个失效链接背后的页面意图是否唯一。当同一批失效链接指向的页面主题混杂了多个不相关的搜索需求时，拆成独立任务才有意义；如果它们共享同一意图，保留在一个页面并集中修复更省成本。常规做法通常是逐条替换链接，但当页面本身主题过宽时，继续逐条修只会把问题拖长，因为失效链接只是症状，页面意图不纯才是根因。
先判断失效链接指向的是同一意图还是多个意图
把待处理的失效链接按“用户点进来想解决什么”分组，而不是按链接出现的位置分组。可用的区分证据有三类：
- 锚文本是否指向同一类需求，例如都指向“下载入口”或都指向“政策原文”；
- 链接所在段落的上下文是否在回答同一个问题；
- 替换后的目标页如果只能满足其中一部分需求，说明意图已经分裂。
假设一个页面同时挂着指向旧版申请表、旧版填写说明和旧版提交入口的失效链接。这三者表面都是“旧版文件”，但用户意图分别是获取表格、理解填写规则、完成提交。此时把它们塞回同一个页面，只会让新链接再次互相稀释。分组后如果发现只有一类意图有持续需求，其余两类已无实际价值，就不必为它们分别建任务。
保留：意图一致且替换目标可共用时
保留的前提是替换后的目标页能同时承接这批链接，且不会让页面主题继续膨胀。动作上，先选定一个权威目标页，再统一替换所有指向同一意图的失效链接。这样做的结果是页面主题收窄，后续新增链接也有明确归属，不必每修一条就重新判断一次。若替换目标本身已经覆盖多个意图，保留就会把问题推迟到下一次检查，这时应转向拆分。
改写：意图分裂但仍有搜索需求时
改写适用于失效链接背后的需求仍然存在，只是当前页面无法同时承载。此时把页面拆成独立任务，每个任务对应一个明确意图，并各自指定替换目标。判断依据是：拆分后每个新页面都能独立回答一个完整问题，而不是把原页面切碎。动作是先写出每个任务的意图句，再检查是否存在重叠；重叠部分应归入其中一个任务，避免两个页面争同一批链接。改写完成后，原页面的失效链接总量会下降，下一步只需按任务逐项验证替换是否到位。
退出：需求已消失或无法验证目标时
退出的条件是链接指向的内容已无持续需求，或找不到可验证的替换目标。此时正确动作是移除链接并保留必要的说明文字，而不是强行指向一个近似页面。移除后应记录该意图已退出，避免下一轮检查时重复判断。需要说明的是，链接返回状态码变化或抓取量归零，并不能单独证明退出正确，它们也可能来自服务器临时故障、页面迁移或抓取预算调整，必须结合意图判断一起看。
一个可执行的拆分顺序
- 导出失效链接清单，逐条标注锚文本和所在段落意图。
- 按意图合并同类项，得到若干意图组。
- 对每组判断保留、改写或退出，并写明依据。
- 只对“改写”组建立独立任务，指定目标页和验证方式。
- 处理完成后复查原页面，确认没有遗留指向已退出意图的链接。
这套顺序的关键在于先分组再动手，而不是边修边判断。分组结果会直接决定后续是集中替换还是拆成多个任务，也会影响你下一次检查时从哪一层开始。若分组后仍无法确定某个意图是否独立，可先保留观察一轮，用实际点击和替换后的目标页表现来验证，而不是一次性全部拆开。
