权重：搜索需求太分散时先做聚合页还是详情页
📱 Mozilla/5.0 AppleWebKit/537.36 (KHTML, like Gecko; compatible; ClaudeBot/1.0; +claudebot@anthropic.com)
🔗 /58a78253c139.html
📄
权重：搜索需求太分散时先做聚合页还是详情页
先做聚合页还是详情页，不取决于哪种页面“权重更高”，而取决于需求是否已经能被一个页面完整回答。如果多个查询指向同一决策、同一批选项、同一组比较标准，聚合页先做；如果每个查询各自对应不同条件、不同步骤、不同结果，详情页先做。下面用一个假设情境把判断过程走一遍。
假设情境：一个旧站要退出三条旧产品线
假设某站有三条旧产品线准备停止维护，旧内容仍被搜索到，但页面里的型号、入口和说明已经过时。团队想保留仍然有价值的部分，又不想让旧页面继续分散搜索需求。此时会面对一个选择：把相关旧内容合并成一个聚合页，还是逐条改成新的详情页。
这个情境的关键不是“旧”，而是需求是否分散。分散意味着用户搜索的词不同，但背后要完成的事相同；也意味着不同词对应的事并不相同。判断错，后续动作会全部返工。
看需求能否被一个页面回答
把现有查询按“用户要完成什么”分组，而不是按词形分组。若一组查询都在问“有哪些替代方案”“怎么选”“差别在哪”，它们适合一个聚合页；若一组查询分别在问“某型号怎么设置”“某流程第一步做什么”“某条件不满足怎么办”，它们更适合各自的详情页。
一个可操作的动作是：先列出现有页面各自承接的查询，再在每条查询旁写一句“用户下一步要做什么”。如果多条的下一步相同，聚合页成立；如果下一步分叉，详情页成立。这个动作的结果会直接决定你接下来是合并、保留还是重写。
聚合页先行的条件与代价
聚合页先行成立的条件通常有三条：多个查询共享同一批选项；用户需要先比较再进入细节；旧详情页内容已经不足以独立成立。此时聚合页承担的是“分诊”和“比较”，把分散需求收拢到一个入口，再从入口指向仍然有效的细节。
代价也要看清：聚合页容易写成清单，缺少每个选项的适用条件。若用户点进来发现只有标题和链接，仍会退回搜索。因此聚合页至少要说清每个选项适合谁、不适合谁，以及进入下一步前需要确认什么。
详情页先行的条件与代价
详情页先行成立的条件是：每个查询对应独立决策，用户不需要先比较；旧页面仍有明确的操作步骤或条件说明；聚合在一起反而会让用户找不到自己要的那一条。此时保留详情页并逐条更新，比强行合并更稳。
代价是页面数量多、维护成本高，且容易互相竞争同一批查询。若发现多条详情页在回答同一件事，就应该回到聚合判断，而不是继续各自加内容。
旧内容退出时，先做一次可回滚的映射
无论先做哪种页面，都建议先做一次映射：旧页面保留什么、合并到哪里、哪些部分直接退出。映射不是最终改版，而是让下一步可回滚。假设某条旧详情页只保留“替代选项”这一段，其余内容退出，那么它更适合并入聚合页；假设某条旧详情页仍保留完整步骤，只是型号过时，那么它应作为详情页更新。
执行后观察两个信号：用户是否还从旧入口进入；进入后是否继续点击到下一步。若旧入口仍有进入但下一步点击很少，说明聚合页或详情页没有接住需求，需要回到分组重新判断，而不是继续加页面。
把决定写成一个可执行的顺序
- 列出旧页面和它们各自承接的查询。
- 为每条查询写一句“用户下一步要做什么”。
- 下一步相同的查询归为一组，判断能否由一个聚合页回答。
- 下一步分叉的查询保留为详情页，并明确各自适用条件。
- 先做一组映射并保留回滚路径，再决定合并或更新。
这样做的结果不是一次定稿，而是让下一步有依据：聚合页负责收拢共享决策，详情页负责承接分叉条件。若后续发现某组查询的下一步开始分叉，就把聚合页里的对应部分拆成详情页；若多条详情页的下一步重新收敛，就合并回聚合页。权重不是页面形式带来的，而是页面是否接住了需求、是否让搜索引擎和用户都更容易理解。
