快照排名：搜索需求太分散时先做聚合页还是详情页
📱 Mozilla/5.0 AppleWebKit/537.36 (KHTML, like Gecko; compatible; ClaudeBot/1.0; +claudebot@anthropic.com)
🔗 /e8912f7afe65.html
📄
快照排名：搜索需求太分散时先做聚合页还是详情页
先做聚合页还是详情页，取决于分散需求之间是否存在共同的决策任务。如果用户查的是同一件事的不同侧面，聚合页更合适；如果每个查询指向不同的具体对象、且各自有独立答案，详情页更合适。旧内容退出时也一样：先判断哪些需求还能聚在一起，再决定保留、改写还是退出。
判断标准：需求是同一任务的不同侧面，还是不同任务
把搜索需求按“用户想完成什么”归类，而不是按词面相似度归类。假设有三组查询：一组在比较不同方案，一组在查某个方案的具体参数，一组在问某个方案出问题怎么办。前两组可以放进同一聚合页，因为用户处在同一决策链上；第三组更适合独立详情页，因为它的意图是排障，和选型不是同一任务。这只是假设例子，用来演示归类方法，不代表任何真实查询数据。
可区分的证据是：如果多个查询共享同一个前置问题，聚合页能一次回答完；如果每个查询都需要不同的前置条件才能回答，强行合并会让页面变成目录，用户仍需二次点击。此时详情页更有效。
聚合页成立的前提：有共同决策任务，且能给出比较维度
聚合页不是把相关词堆在一页，而是提供一个详情页给不了的比较视角。它成立的条件通常有三条：
- 需求指向同一类对象，用户需要在其中做选择；
- 存在可横向对比的维度，例如适用条件、成本结构、维护方式；
- 每个对象都有足够内容支撑，聚合页可以摘要并链接到详情页。
满足这些条件时，先做聚合页能减少重复页面，也让搜索引擎更容易理解站点结构。聚合页应承担导航和比较职责，详情页承担具体答案。两者不是替代关系，而是分工关系。
详情页成立的前提：每个需求有独立答案和独立前置条件
当查询之间的共同点只是词面，而实际任务不同，聚合页会稀释每段内容的针对性。此时先做详情页更稳。判断方法是：把两个查询的答案互换，看是否仍然成立。如果互换后用户会觉得答非所问，说明它们需要各自的详情页。
旧内容退出场景下，这一点尤其重要。保留仍然有价值的部分，不等于保留原页面。一个旧详情页如果只覆盖了某个具体对象的过时信息，而该对象仍有搜索需求，可以改写为当前有效答案；如果该对象已无需求，但同类需求转移到了新对象上，可以把旧页面的有效段落并入新聚合页，再让旧页面退出。
一个可执行动作：先做需求归类表，再决定页面去向
具体动作是：列出仍有关注度的查询，为每个查询标注“用户要完成的任务”和“回答所需前置条件”。然后按任务合并同类项。合并后只剩一个任务、且需要比较多个对象时，先做聚合页；合并后仍有多个互不替代的任务时，先做详情页。
这个动作的结果会直接影响下一步：如果归类后发现多数查询共享同一任务，就优先建聚合页，并把详情页作为它的子页面；如果归类后发现任务彼此独立，就先补详情页，暂不建聚合页，避免聚合页变成空壳。对于旧内容，归类结果还能告诉你哪些页面值得改写、哪些可以退出。
取舍顺序：保留、改写、退出的实际判断
保留适用于页面仍有独立搜索需求、且内容仍然准确的情况。改写适用于需求还在、但答案已经变化的情况，例如旧系统或旧合作关系退出后，用户仍会查询替代方案。退出适用于需求已经消失、或需求已被其他页面完整覆盖的情况。
退出前要确认一件事：该页面是否还在承担内链或导航职责。如果只是内容过时但仍有入口价值，可以先改写为指向新聚合页或新详情页的过渡页，再决定是否退出。抓取量或请求量下降不能单独证明退出正确，它也可能来自链接减少、站点结构调整或统计口径变化，需要结合需求归类结果一起看。
把抓取、索引和排名分开看也有助于判断：页面退出后不再被抓取是预期结果，但若仍有搜索需求，就不应让用户找不到替代答案。先做聚合页还是详情页，最终取决于需求能否被归为同一任务，以及旧内容中哪些部分仍然值得保留。
