细雨算法应对：搜索需求太分散时先做聚合页还是详情页
📱 Mozilla/5.0 AppleWebKit/537.36 (KHTML, like Gecko; compatible; ClaudeBot/1.0; +claudebot@anthropic.com)
🔗 /80e71aaf86c8.html
📄
细雨算法应对：搜索需求太分散时先做聚合页还是详情页
先看这些分散需求是否共享同一个可核对的购买或使用场景。若共享，优先做聚合页承载比较与筛选；若各自对应不同决策条件、不同交付方式，先补详情页。判断依据不是词多词少，而是用户下一步要做的动作是否相同。
把分歧转成一张可核对的需求表
团队里有人说该做聚合页，有人说该补详情页，往往是因为各自盯着不同的搜索词。把手上已有的资料，比如客服记录、站内搜索词、页面标题草稿，逐条拆成四列：用户说的需求、他可能处在哪个阶段、他下一步要做什么、现有页面能否直接回答。填完后，把“下一步动作”相同的行归到一组。
如果三行都指向“先比较再选”，它们适合进入同一个聚合页；如果一行要查规格、一行要问安装条件、一行要确认售后，它们更可能各自需要详情页。这个动作的结果会直接影响下一步：归组完成后，你才知道该新建一个列表页，还是给某个详情页补一段说明。
聚合页成立的条件：需求共享同一决策入口
聚合页的价值在于把分散入口收拢到一个可比较、可筛选的页面。它成立的前提是这些需求背后的人在做同一类判断。例如，假设有三组搜索词分别指向不同规格的同一类产品，用户都需要先看参数对比，那么一个带筛选条件的聚合页比三个孤立详情页更容易让人继续往下走。
- 需求之间可以放在同一张对照表里比较；
- 用户进入后仍需要再选一次，而不是直接下单或直接照做；
- 现有详情页各自只覆盖一个点，缺少横向关系。
满足这些条件时，先做聚合页。做完后观察站内搜索和客服提问是否开始集中到少数几个筛选维度，再决定是否拆出新的详情页。
详情页优先的条件：每个需求对应不同事实
如果分散需求各自要求不同的事实确认，聚合页会变成一张什么都想说、什么都说不清的清单。比如一组词问的是交付周期，另一组问的是兼容条件，第三组问的是退换规则，这三类信息放在同一页会互相干扰。此时更稳的动作是先补详情页，把每个事实写完整，再在详情页之间加一条指向聚合页的路径。
判断方法很直接：把每个需求写成一句用户会核对的话。如果这些话无法用同一组字段回答，就不该硬塞进一个聚合页。完成详情页后，下一步是看这些页面之间是否出现共同的上层选择需求；若出现，再补聚合页。
一个假设例子：先聚合还是先详情
假设你手上有一份客服记录，里面出现“怎么选”“哪个适合小空间”“安装要什么条件”“坏了怎么换”四类问题。前两类可以放进一个聚合页，用场景和尺寸做筛选；后两类各自对应安装条件与售后规则，应放进详情页或帮助页。若强行把四类都塞进聚合页，用户会在同一页里找不到自己要看的那一段；若只做详情页，前两类用户又缺少比较入口。
可执行顺序是：先按“下一步动作”分组，再决定页面类型。分组结果决定先建哪个页面，而不是先争论聚合页和详情页哪个更好。
做完之后看什么，避免把现象当结论
页面上线后，抓取量、索引量或某个词的请求量变化，都不能单独证明聚合页或详情页做对了。请求量下降也可能是季节、展示位置变化或统计口径调整。更可靠的下一步是回到需求表：原来分散的问题是否开始集中到少数几个页面，用户是否还需要反复搜索同一件事。
如果聚合页带来了新的筛选需求，就补筛选字段；如果详情页仍被反复问到同一个事实，就把该事实提到更靠前的位置。把每次调整都写回那张需求表，团队对“先做哪个”的分歧才会变成可以核对的记录。
