细雨算法：搜索需求太分散时先做聚合页还是详情页
📱 Mozilla/5.0 AppleWebKit/537.36 (KHTML, like Gecko; compatible; ClaudeBot/1.0; +claudebot@anthropic.com)
🔗 /40e991a58b5d.html
📄
细雨算法：搜索需求太分散时先做聚合页还是详情页
先做聚合页还是详情页，取决于这些分散需求是否共享同一组判断标准。如果用户查的是同一件事的不同说法、不同型号或不同场景，且最终都要落到同一类比较和决策上，优先做聚合页；如果每个需求各自有独立的判断依据、独立的下一步动作，优先做详情页。判断错了，聚合页会变成大杂烩，详情页会变成一批互相竞争又都不完整的薄页。
先看需求之间是“同义变体”还是“不同决策”
把搜索需求列出来之后，不要急着按词分组，而是按用户拿到答案后要做什么分组。假设有一组需求都指向“某类工具怎么选”，用户看完之后都要进入比较、询价或试用，那么这些需求共享同一套决策路径，聚合页可以把选型标准、常见误区和对比维度放在一起，让用户一次看完。
反过来，如果一组需求里，有的用户要解决安装报错，有的用户要查价格，有的用户要找替代品，那么它们虽然都带同一个主题词，但下一步动作完全不同。这种情况下做聚合页，只会让每个部分都写不深，用户还得继续搜索。此时详情页更合适，每页只回答一个明确问题，页面上再通过内链指向相邻问题。
一个可操作的判断动作是：随机抽五个分散需求，分别写出“用户读完这一页后最可能做的下一个动作”。如果五个动作高度一致，聚合页成立；如果出现三种以上不同动作，详情页优先。
聚合页成立的条件：有共同判断框架，且能给出比较依据
聚合页不是把几个词堆在一个标题下，而是提供一个共同的判断框架。例如用户分散搜索的是不同规格、不同使用条件、不同预算档位，但他们最终都要回答“在我的条件下选哪个”。这时聚合页的价值在于把条件、代价和适用边界并列呈现，让用户自己完成匹配。
做聚合页时，至少要满足三个条件：
- 这些需求能被同一组维度解释，比如成本、维护难度、适用规模；
- 页面能给出可区分的证据，而不是每个小节都写“看情况”；
- 用户不需要跳到另一个页面才能完成比较。
实施动作上，可以先写一个比较维度表，把每个分散需求映射到维度上。如果某个需求无法映射，说明它不属于这个聚合页，应该单独做详情页。这个动作的结果会直接影响下一步：映射成功的需求进入聚合页，映射失败的需求进入详情页清单，避免为了凑页面数量而强行合并。
详情页成立的条件：每个需求有独立证据和独立下一步
当分散需求各自需要不同的证据时，详情页更稳。比如同样是“细雨算法”相关的问题，有的需求要的是概念解释，有的要的是操作步骤，有的要的是异常排查。概念解释靠定义和边界，操作步骤靠顺序和条件，异常排查靠现象和原因对照。这三类内容放在一个页面上，用户很难快速定位，搜索引擎也不容易判断页面主体。
详情页的实施动作是：先为每个需求写一句独立结论，再补一条能支撑结论的证据。如果写不出独立结论，说明这个需求还没被理解清楚，不适合单独成页。写完详情页后，再决定哪些页面可以通过内链组成一个专题，而不是反过来先建聚合页再拆内容。
例外情况是：某些需求虽然下一步动作不同，但搜索量极低且长期没有独立内容支撑。这时可以先在聚合页里用一个段落承接，等这个需求出现更多可验证的证据后，再拆成详情页。这样做的代价是聚合页会变长，所以需要把段落控制在能快速扫读的范围内。
一个假设例子：两种选择的分界点
假设你负责一个工业设备选型站点，用户搜索需求分散在“小型设备怎么选”“高湿度环境用什么”“维护成本低的型号”“替换旧型号”这几类。先别急着建四个详情页。写出每个需求的下一个动作：前三个都可能落到“选型比较”，第四个落到“替换兼容性”。
这时可以这样分：前三个需求共享选型框架，做一个聚合页，页面里按规模、环境、维护成本三个维度并列比较；第四个需求有独立的兼容性判断，单独做详情页。聚合页里指向详情页的内链只出现在“替换旧型号”相关段落，而不是全页堆链接。
这个例子里的数字和场景都是假设，用来演示判断方法，不是真实项目结果。真正要观察的是：聚合页上线后，用户是否在同一页内完成了比较；详情页上线后，用户是否继续搜索同一个问题的其他说法。如果聚合页的跳出集中在某个小节，说明那个小节可能需要独立成页；如果详情页之间互相抢同一个问题，说明它们应该合并。
决策顺序：先验证需求关系，再决定页面形态
更稳妥的顺序是：先把分散需求按“下一个动作”分组，再检查每组是否有共同判断框架。有共同框架的做聚合页，没有的做详情页。做完之后，用内链把两类页面连起来，但不要让聚合页承担详情页的深度，也不要让详情页重复聚合页的比较框架。
如果发现某个需求既没有共同框架，又暂时没有独立证据，可以先不建页面，而是在现有页面里留一个简短回答，并记录它缺少哪类证据。这个动作不会立刻带来新页面，但会影响下一轮内容规划：当证据补齐时，再决定是并入聚合页还是拆成详情页。这样处理，页面形态跟着需求关系走，而不是跟着词表走。
