检查失效链接：搜索需求太分散时先做聚合页还是详情页
📱 Mozilla/5.0 AppleWebKit/537.36 (KHTML, like Gecko; compatible; ClaudeBot/1.0; +claudebot@anthropic.com)
🔗 /0cdb75719950.html
📄
检查失效链接：搜索需求太分散时先做聚合页还是详情页
先做聚合页还是详情页，取决于这些分散需求背后是否共享同一批失效链接和同一类查询意图。若多个查询都指向已下线但主题相近的旧页面，聚合页通常更合适；若每个查询各自对应独立、仍有存续价值的内容，详情页更合适。先检查失效链接的分布，再决定页面层级。
一个常见矛盾：需求分散，但旧链接指向同一处
清理旧内容时，常出现一种情况：搜索需求看起来分散在十几个词上，但检查失效链接后发现，这些词对应的旧地址大多跳向同一个已删除栏目或同一份旧文档。此时如果按词逐个建详情页，会得到一批内容相近、彼此竞争的页面；如果先做聚合页，则可能用一个入口承接这些分散需求。
反过来也成立：需求分散，且每个需求对应的旧链接各自独立、内容主题差异明显，那么强行聚合只会让用户找不到重点。判断的关键不是需求数量，而是失效链接是否共享同一去向，以及这些需求是否共享同一决策场景。
两种解释：聚合页成立的条件与详情页成立的条件
聚合页更合适的条件
- 多个失效链接指向同一旧栏目、同一旧系统入口或同一类已下线服务。
- 分散查询之间共享同一前提，例如都在问“旧版本还能不能用”“退出后还剩什么”。
- 保留价值的部分可以在一页内讲清，不需要为每个查询单独展开。
详情页更合适的条件
- 每个查询对应独立的旧页面，失效原因各不相同，有的只是改址，有的确实退出。
- 各查询的意图分属不同阶段，例如一部分在找替代方案，一部分在确认旧内容是否仍可访问。
- 其中仍有价值的部分需要独立说明，合并后反而增加理解成本。
这里的分界不是“聚合一定比详情好”，而是失效链接的归集程度和意图重合度。归集程度高、意图重合度高，聚合页优先；归集程度低、意图各自独立，详情页优先。
能区分两种解释的证据
可以按下面顺序收集证据，而不是凭感觉选页面类型。
- 失效链接去向分布：把待处理的失效链接按目标地址归类。若多数指向同一处，聚合页有依据；若指向多处且互不相关，详情页更稳。
- 查询意图重合度：抽取代表性查询，看它们要解决的是同一个问题还是不同问题。同一问题适合聚合，不同问题适合分开。
- 保留价值的粒度：仍然有价值的部分是一段通用说明，还是每个查询各有一段专属信息。前者聚合，后者详情。
- 后续维护成本：聚合页更新一次即可覆盖多个入口；详情页需要逐页维护。若旧系统仍在变动，聚合页的维护压力通常更低。
这些证据里，失效链接去向分布最先能区分两种解释。因为它直接反映旧结构是否曾经把分散需求收拢到同一处。
一个假设例子：先聚合再决定是否拆分
假设某旧站退出了一项预约功能，留下若干失效链接，分别来自旧帮助页、旧活动页和旧入口页。搜索需求分散在“旧预约是否还能用”“退出后资料怎么办”“替代方式是什么”等方向。检查后发现，这些失效链接大多跳向同一个已删除的预约栏目。
此时先做一个聚合页，统一说明退出范围、仍可访问的部分和后续动作。上线后观察用户是否在同一页内继续寻找更细的信息。如果出现明显分化，再把其中独立部分拆成详情页；如果没有分化，聚合页就足够。这个动作的结果会直接影响下一步：聚合页承接得住，就不必为每个查询单独建页；承接不住，再按真实分化点拆分。
假设中的数字只用于比较方法，例如“多数失效链接指向同一处”比“少数指向同一处”更能支持聚合页，而不是用来预测流量或排名。
操作顺序与判断点
先检查失效链接，再决定页面类型，顺序不能反。具体动作是：导出待处理失效链接，按目标地址分组；对每组标注查询意图和保留价值；然后选择聚合或详情。若一组内多数链接指向同一处且意图重合，先建聚合页；若各组之间差异明显，直接建详情页或保留原详情结构。
需要说明的是，抓取、索引和排名是不同环节。失效链接处理得当，只说明旧入口的指向更清楚，并不单独保证后续表现。请求量或抓取量归零也不能单独证明处理正确，它还可能来自旧入口本身不再被访问、链接已从导航中移除，或站点整体结构调整。判断时应结合失效链接去向、意图重合度和保留价值粒度，而不是只看某一个现象。
如果旧内容、旧系统或旧合作关系需要退出，先保留仍然有价值的部分，再让失效链接指向最合适的承接页。聚合页和详情页不是二选一，而是先聚合验证需求是否真的分散，再按验证结果决定是否拆分。
