360与百度，搜索需求太分散时先做聚合页还是详情页
📱 Mozilla/5.0 AppleWebKit/537.36 (KHTML, like Gecko; compatible; ClaudeBot/1.0; +claudebot@anthropic.com)
🔗 /c762cc74c37a.html
📄
360与百度，搜索需求太分散时先做聚合页还是详情页
先做聚合页，前提是这些分散需求共享同一个选择意图，只是表达方式不同；如果每个需求对应不同阶段、不同交付物或不同决策人，就先做详情页。判断依据不是词多不多，而是用户点进来后想完成的是同一件事还是不同的事。
矛盾现象：词很分散，但落地页表现不像同一类需求
在百度或360搜索里，一个旧栏目常出现这种局面：后台能看到几十个入口词，彼此措辞差异明显，可真正带来有效咨询或停留的，往往集中在少数几个词上。于是团队容易得出相反结论。一派认为需求太散，必须用聚合页把流量收拢；另一派认为散就是散，只有详情页才能逐条承接。
这两种判断都可能成立，因为“分散”描述的是入口，不是任务。入口词分散，但任务相同，聚合页有效；入口词分散，任务也分散，聚合页只会让每类用户都找不到答案。把入口数量当成需求种类，是这类决策最常见的误判。
两个解释：同任务多说法，还是多任务被混在一个栏目
解释一：同任务多说法。用户在用不同词描述同一个选择，比如比较对象、规格、适用条件、替代方案。此时聚合页能提供一张对照视图，让用户在同一页完成筛选。聚合页的价值是“帮你选”，不是“帮你查”。
解释二：多任务被混在一个栏目。有的用户在做前期了解，有的在核对参数，有的在找售后或替换件。这些任务需要的证据不同：前者要范围和取舍，后者要具体条件和操作步骤。把它们塞进一个聚合页，只会让页面变成目录，谁也读不完。
还有一种中间情况：同一任务，但决策阶段跨度大。此时更稳妥的做法不是二选一，而是先做聚合页承担筛选，再把每个分支的详情页作为下一步。聚合页负责分流，详情页负责收口。
能区分两种解释的证据，不在词表里，在退出行为上
要区分“同任务多说法”和“多任务混杂”，可以看三类证据，且都不需要编造平台数据。
- 退出位置。如果用户集中在聚合页的对照区之后继续点击，说明他们在做筛选；如果大量退出发生在页面中段，且退出词分属不同任务，聚合页就不适合作为第一落点。
- 回搜行为。用户从聚合页返回搜索结果后，换的是同义表达，还是换成了另一个任务词？前者支持聚合，后者支持详情。
- 转化动作的形态。如果有效动作是“提交比较需求”“索取对照清单”，聚合页能承接；如果是“确认某条件是否适用”“按步骤处理”，详情页更合适。
这里要提醒一点：某个入口词的请求量下降、抓取量变化或排名波动，都不能单独证明该做聚合还是详情。它可能来自内容更新、链接变化、展示方式调整，也可能只是需求季节性移动。把单一指标归零当作决策依据，容易把页面结构问题误判成需求消失。
一个假设例子：旧内容退出时，先保留哪一部分
假设一个旧系统栏目准备下线，里面既有总览页，也有若干条件说明页。团队不确定该保留总览还是保留条件页。可以按下面的动作走：
- 把现有入口词按“用户要完成的事”分组，而不是按措辞分组。
- 若多数词指向同一件事，先保留并改造总览页为聚合页，在页内给出分支入口。
- 若词分别指向不同阶段或不同交付物，先保留条件说明页，并把总览页降为导航。
- 改造后观察退出位置和回搜词是否从“同义替换”转为“任务切换”。若仍大量切换任务，说明聚合页承担了过多任务，下一步应拆出详情页；若切换减少、分支点击增加，说明聚合页方向成立，下一步再补各分支详情。
这个动作的关键不是一次定稿，而是用退出行为决定下一步是继续聚合还是拆详情。聚合页和详情页不是互斥的最终答案，而是先后顺序问题。
适用条件与取舍
先做聚合页的适用条件是：需求共享同一选择意图，用户需要对照而非逐条操作，且旧内容中已有可复用的对照信息。先做详情页的适用条件是：每个需求对应独立条件、独立步骤或独立责任方，聚合只会稀释答案。
在百度与360搜索语境下，还要考虑旧系统退出时的可维护性。聚合页通常维护成本低，但容易变成空目录；详情页承接更准，但数量一多就需要持续更新。若旧合作关系或旧系统即将退出，优先保留仍能独立回答一类任务的页面，把无法独立回答的入口并入聚合页，而不是让两者互相复制。
最终判断可以落成一句话：需求分散不是做聚合页的理由，任务同源才是；任务不同源时，先做详情页，再用聚合页做导航。
