baiduzhishu：搜索需求太分散时先做聚合页还是详情页
📱 Mozilla/5.0 (Macintosh; Intel Mac OS X 10_15_7) AppleWebKit/605.1.15 (KHTML, like Gecko) Version/17.4 Safari/605.1.15 (Applebot/0.1; +http://www.apple.com/go/applebot)
🔗 /dc27d01f5148.html
📄
baiduzhishu：搜索需求太分散时先做聚合页还是详情页
先做详情页，通常比先做聚合页更稳：当需求分散、你手里又没有完整的查询数据时，详情页能先承接住已经明确的那几个问题，再用它们的表现决定聚合页该聚什么。聚合页不是不能先做，但它要求你已经能说清“这些分散需求为什么属于同一件事”，否则很容易做出一个谁也不觉得该点进来的中间层。
先看一个矛盾现象：分散不等于该合并
需求分散时，直觉是“把碎片收进一个页面”，因为聚合页看起来更像入口。但实际动作常常相反：详情页先上线后，你会看到某些分散表述其实指向同一个决策，这时再聚合才有依据。反过来先做聚合页，往往是把还没验证的假设先固化成一个页面结构。
两种解释都能成立。第一种：分散只是表达差异，用户要的是同一个答案，聚合页能减少重复。第二种：分散是因为用户处在不同阶段，详情页各自解决一个具体问题，强行合并会让每类人都觉得内容不够贴。区分它们的关键不在搜索量大小，而在用户到达页面后要做的下一个动作是否相同。
缺少完整数据时，能执行的最小动作
没有查询后台权限、看不到完整词表时，仍然可以做一件事：把已知的分散需求逐条写成“用户要完成的动作”，而不是写成词。比如同样是关于某个主题，一条是“想确认是否适用”，另一条是“想知道怎么操作”，第三条是“想比较两种做法”。如果这三条的动作不同，详情页优先；如果三条最终都落到同一个判断上，聚合页才有理由。
这个动作的结果会直接影响下一步：动作相同的需求，可以进入一个聚合页的候选结构；动作不同的需求，继续各自做详情页，并在详情页里互相链接。这里不能推出的结论是：某条需求没被单独记录，就等于它不存在；也不能因为暂时没看到数据，就断定聚合页一定无效。数据缺失只说明你暂时无法用查询量排序，不说明结构判断失效。
用可区分的证据决定先后
能区分两种解释的证据，主要看三类：
- 到达后的下一步是否一致。如果用户看完内容后都要做同一个判断或同一类操作，聚合页成立；如果下一步分叉，详情页更合适。
- 已有页面是否已经在互相竞争。若几个详情页在讲同一件事、只是换说法，说明聚合有空间；若它们各自解决不同问题，合并会损失针对性。
- 聚合页能否给出详情页给不了的增量。比如统一比较、统一筛选、统一入口。如果聚合页只是把详情页标题罗列一遍，它就没有独立价值。
假设你手头只有五个已知需求，其中三个都在问“适不适合我”，另外两个在问“具体怎么做”。这组假设下，先做“适不适合我”的聚合页、把“怎么做”留作详情页，比全部合并更合理。这个例子只用于说明比较方法，不代表真实项目结果。
一个可执行的判断顺序
- 把分散需求改写成用户动作，而不是关键词列表。
- 把动作相同的需求归为一组，动作不同的单独成组。
- 对每组问一句：有没有一个页面能同时回答这一组，并且比单页回答得更好。
- 能，就先做聚合页；不能，就先做详情页，并在详情页之间建立指向关系。
- 上线后观察用户是否在详情页之间反复跳转，或用站内搜索继续找同一类答案，再决定是否补聚合页。
这个顺序的好处是，它不依赖完整查询数据也能启动，而且每一步的产出都能被下一步检验。需要说明的适用条件是：它适合需求已经能被你描述出来、但还无法用数据排序的情况；如果连用户动作都写不出来，那问题不在聚合还是详情，而在需求本身还没被理解清楚。
什么时候聚合页应该先做
如果分散需求已经明显指向同一个决策，而且现有详情页之间互相重复、用户需要在多个页面之间来回拼答案，那么聚合页可以先做。判断标准不是“词多”，而是“同一决策被拆得太碎”。此时聚合页的作用是减少拼凑成本，而不是制造一个新的中间层。
反过来，如果每个分散需求都对应不同的使用场景、不同的前提条件，先做聚合页只会让页面变得又长又泛。详情页先把各自的问题讲透，再根据它们之间实际发生的关联决定是否聚合，更符合“先改善用户获取内容、再让搜索引擎理解页面”的顺序。抓取、索引和排名是不同环节，页面结构的选择首先影响的是用户能否拿到答案，其次才是搜索引擎能否正确理解这组页面的关系。
