百度惊雷算法：搜索需求太分散时先做聚合页还是详情页
📱 Mozilla/5.0 AppleWebKit/537.36 (KHTML, like Gecko; compatible; ClaudeBot/1.0; +claudebot@anthropic.com)
🔗 /347e471886f8.html
📄
百度惊雷算法：搜索需求太分散时先做聚合页还是详情页
先给有条件的结论：当同一意图下存在多个近义问法、而每个词单独做详情页都撑不起足够内容时，优先做聚合页；当某个问法已有明确、独立、可验证的答案，且用户看完即走、不需要横向比较时，优先做详情页。百度惊雷算法针对的是点入后体验与预期不符的问题，所以这个选择本质上不是页面形态之争，而是“用户在这类需求下想要的是聚合后的对照，还是单一结论”。判断错方向，聚合页会变成关键词堆砌，详情页会变成薄页。
判断依据：看需求是“比较型”还是“结论型”
把待处理的需求按问法拆开，逐条标注它更接近哪一种：
- 比较型信号：同一批词里反复出现“哪个好”“区别”“和……一样吗”“怎么选”，用户需要同时看到多个对象或多种情况，任何单一详情页都只能回答一部分。
- 结论型信号：问法收敛到一个动作或一个事实，例如“某功能怎么开”“某条件是否满足”，答案唯一，用户拿到就走。
比较型需求先做聚合页，把可对照的维度列成结构清晰的段落或列表，让用户在一个页面上完成筛选；结论型需求先做详情页，把唯一答案写透，避免为了凑长度塞入无关的近义问法。这里的关键动作是：先列出至少十个真实问法并归类，如果超过一半落在比较型，聚合页优先；否则详情页优先。这一步的结果会直接决定后面内链是“聚合页指向详情页”还是“详情页之间横向互链”。
反例：什么情况下这个结论会失效
如果比较型需求虽然分散，但每个对象自身都有独立的品牌词、独立的操作步骤或独立的价格结构，那么强行合并成一个聚合页会稀释每个对象的完整信息，用户仍要跳出去找。此时更合理的做法是先做对象详情页，再用一个轻量的聚合页做导航，而不是让聚合页承担全部解释。反过来，如果结论型需求背后其实牵涉多个前置条件（不同身份、不同地区、不同设备），单页详情页无法覆盖，也应先做聚合页按条件分流。判断标准是：合并后是否会让某一类用户找不到自己那一段。会，就先分开；不会，就先合并。
一个注明假设的短例子
假设某类查询可以归成“A 和 B 的区别”“A 适合谁”“B 适合谁”“A 换成 B 要注意什么”四组。若直接为每组做一个详情页，四页内容会大量重叠；若做一个聚合页，用一个小节讲区别、一个小节讲适用人群、一个小节讲切换注意事项，用户在一次访问内就能完成判断。此时聚合页更符合意图。但如果“A 换成 B”涉及具体操作步骤且步骤较长，就应把它拆成独立详情页，聚合页只保留摘要和入口。注意这只是用于说明比较方法的假设，不是真实项目数据。
落地动作与下一步
选定形态后，做一次可验证的检查：把聚合页或详情页的标题、首段、小节标题单独摘出来，遮住正文，看它们是否仍能让目标用户判断“这页是不是我要的”。如果摘出来之后无法判断，说明结构没有对上意图，先改结构再谈其他。完成这一步再决定内链方向：聚合页负责把分散问法收拢并指向详情页，详情页负责把单一结论写实并回指聚合页。抓取和索引只是后续环节，页面意图是否对齐才是这一步真正要解决的问题。
