百度业务，搜索需求太分散时先做聚合页还是详情页
📱 Mozilla/5.0 AppleWebKit/537.36 (KHTML, like Gecko; compatible; ClaudeBot/1.0; +claudebot@anthropic.com)
🔗 /25d6b9f42a0b.html
📄
百度业务，搜索需求太分散时先做聚合页还是详情页
先做聚合页还是详情页，取决于你手上这批需求能否被一个共同任务串起来。如果多个查询指向同一件事，只是问法不同，聚合页优先；如果每个查询背后是不同场景、不同决策条件，详情页优先。判断依据不是词多词少，而是用户点进来之后要完成的任务是否一致。
先拿一个页面做判断，不从全站铺开
从你现有的旧内容里挑一个页面，最好是有一定访问、但主题边界模糊的那一页。把它最近承接的搜索词列出来，逐条问：用户搜这个词，是想看同一类信息，还是想解决不同阶段的问题。
如果十条词里有七条都在问“某类服务包含什么、怎么选、多少钱”，它们可以共享一个页面框架，这时聚合页成立。如果其中三条问流程、三条问材料、四条问售后，彼此答案无法互相替代，硬合在一页只会让每段都写不深，应该拆成详情页。
这个动作的结果会直接决定下一步：聚合页成立，就进入结构设计；详情页成立，就进入选题拆分和优先级排序。
聚合页成立的条件：共同任务、可比较、能收口
聚合页不是把相关词堆在一页，而是给用户一个统一入口，让他快速判断“这里有没有我要的”。它适合以下情况：
- 多个查询共享同一个决策目标，例如选型、对比、办理条件。
- 各分支之间有可比性，用户需要放在一起看才能做决定。
- 你能给出统一结论或筛选逻辑，而不是只罗列。
假设你手上有旧内容分别讲三种相近方案，访问都不高。如果它们的目标都是“帮用户选一种”，可以合并为一页，顶部给判断路径，下面分块讲差异。这样做的结果是减少重复页面，也让用户不必来回跳转。但要注意，合并后如果每个分支只剩两三句话，说明深度不够，应该退回详情页分别写。
详情页成立的条件：场景不同、答案不可互换
当每个查询背后是不同使用场景时，详情页更合适。判断方法是：把两个查询的答案对调，看是否仍然成立。
假设一个查询问“初次办理要准备什么”，另一个问“已有记录如何变更”。把变更流程写进初次办理页，用户会困惑；把初次材料写进变更页，也不解决问题。这说明两个需求不能被同一页有效承接，应各自成页。
详情页优先的顺序，可以按三个维度排：是否已有旧页可改、是否有明确转化动作、是否与其他页重复。先改旧页，再补空白，最后处理重复。这个动作的结果是避免一边堆新页、一边留着旧页互相竞争。
旧内容退出时，先决定保留哪一部分
你手上的旧页面可能既包含聚合信息，又包含详情段落。处理时不要整页删除或整页保留，而是先标记：哪些段落回答共同任务，哪些段落只服务单一场景。
- 把共同任务段落抽出，作为聚合页的骨架。
- 把单一场景段落拆出，判断是否值得独立成详情页。
- 对既不服务共同任务、也没有独立搜索需求的段落，直接舍弃。
- 旧页面若仍有访问，设置指向新页面的站内链接，再决定是否保留或退出。
执行后观察一段时间：如果聚合页承接了原本分散的查询，说明合并方向成立；如果某些查询仍然没有合适落地页，说明详情页拆分还不够。抓取和索引变化只是参考，不能单独证明处理正确，还要看用户是否在页面上完成预期动作。
一个可执行的判断顺序
面对一批分散需求，按下面顺序处理，比先争论页面类型更有效：
- 先写出一句话：这些需求共同要解决的任务是什么。写不出来，就做详情页。
- 再看现有页面能否改造成这个任务的入口。能改，就优先改旧页。
- 改造后若单个场景仍讲不透，再为它建详情页，并从聚合页链接过去。
- 最后检查是否有旧页与新页主题重叠，重叠部分只保留一个主页面。
这个顺序的核心是：聚合页负责收口，详情页负责讲透。先判断需求能否收口，再决定是否拆分，能避免把分散需求硬塞进一页，也能避免为每个问法都建一个单薄页面。对旧内容、旧系统或旧合作关系下的页面，先保留仍然有价值的部分，再让其余部分有序退出，通常比一次性重做更可控。
