惊雷算法：旧页面需求分散时先做聚合页还是详情页
📱 Mozilla/5.0 AppleWebKit/537.36 (KHTML, like Gecko; compatible; ClaudeBot/1.0; +claudebot@anthropic.com)
🔗 /a0f13ec76a4a.html
📄
惊雷算法：旧页面需求分散时先做聚合页还是详情页
先给结论：如果读者手里的旧页面各自只覆盖一个很窄的问法、彼此内容重叠且都还有零散展示，优先做聚合页；如果每个页面都对应独立对象、独立决策且不能互相替代，先修详情页。判断依据不是页面数量，而是这些页面能否被同一类搜索意图收拢。
先看旧页面之间是“同题不同问法”还是“不同题”
把待处理的页面各写一句“它替谁解决什么”。若多句的主语相同、差别只在措辞，例如同一类产品的价格、参数、适用场景被拆成三页，这属于同题不同问法，聚合页成立。若主语不同，例如两种完全不同的服务对象、两套互斥的办理条件，强行合并会让读者在首屏找不到自己的分支，此时详情页更稳。
一个可操作的检验：随机抽三条旧页面的标题，遮住页面正文，只凭标题判断它们是否指向同一决策。如果判断一致，聚合页有基础；如果判断分裂，先保留详情页，只在详情页之间加互链。
聚合页成立时需要满足的三个条件
- 有一个能覆盖全部子问题的上位问法，且这个问法本身有人会搜，而不是编辑硬造的分类名。
- 各旧页面之间重复段落占比高，保留多页只会让搜索引擎在相似内容间反复选择。
- 聚合后仍能保留每个子问题的关键差异，通常用同一页内的分节、锚点或可折叠区块承载，而不是把差异删掉。
满足这三条时，实际动作是：选一个旧页面作为聚合页的落点，把其余页面的独有信息并入，其余旧地址做 301 指向聚合页。做完这一步后，下一步不是立刻删旧页面，而是观察聚合页是否开始承接原来分散的查询词，再决定是否继续合并下一组。
详情页优先的两种典型情况
第一种是每个页面各自对应一个可独立成交或独立办理的对象，读者带着明确对象名进来，聚合页会让他多一次筛选。第二种是页面之间存在互斥条件，例如不同地区的规则、不同版本的要求，合并后必须写大量“如果……则……”的分支，反而降低可读性。
这时动作相反：保留详情页，补齐每页缺失的独有信息，再在页面顶部加一条指向同组其他详情页的导航。结果是读者不必回到搜索结果重新选择，站内路径变短，后续你可以根据站内点击判断哪几个详情页其实可以进一步合并。
用一个假设例子走完判断流程
假设手上有五篇旧文，分别讲某类设备的安装条件、安装步骤、常见故障、维护周期和耗材更换。前三篇都在回答“怎么装、装完注意什么”，重叠明显；后两篇回答的是使用阶段的问题。此时合理做法是：把安装条件、步骤、故障合成一个聚合页，维护周期和耗材更换保留为详情页，并在聚合页末尾链接过去。
如果五篇里有两篇讲的是两种不同型号，且两种型号的步骤不能互换，那么这两篇必须留作详情页，不能因为标题相似就合并。假设合并后某条查询的展示位置没有立刻变化，也不能单独证明合并错误，因为抓取、索引和重新评估需要时间，也可能是该查询本身意图已经漂移。更可靠的下一步是检查聚合页是否同时覆盖了原子页面的核心词，以及旧地址是否正确跳转。
落地时的顺序与回退点
- 先给每个旧页面标注：独有信息、重复信息、目标读者。
- 按“同一决策”分组，而不是按标题相似度分组。
- 每组先做一页试验，不要一次全站合并。
- 合并后保留旧地址跳转至少一个观察周期，确认没有大量站内入口仍指向旧地址。
- 若试验组的表现不如预期，回退方式是恢复被合并页面并从聚合页撤下对应分节，而不是继续叠加新页面。
这套顺序的关键在于把“聚合还是详情”当成一次可回退的实验，而不是一次性重构。只要每个旧页面都先被判定为可替代或不可替代，后续无论是合并还是保留，都有明确依据，不会因为页面数量多就默认要合并。
