Google排名因素：搜索需求太分散时先做聚合页还是详情页
📱 Mozilla/5.0 AppleWebKit/537.36 (KHTML, like Gecko; compatible; ClaudeBot/1.0; +claudebot@anthropic.com)
🔗 /9ea9a1a424de.html
📄
Google排名因素：搜索需求太分散时先做聚合页还是详情页
先做哪个，取决于这些分散需求是否共享同一决策任务。如果用户搜的是一组近义、同场景的问法，并且最终都在比较同一件事，先做聚合页；如果每个问法对应不同的使用条件、规格或人群，先做详情页，再用聚合页做导航。判断依据不是词多词少，而是页面能否同时满足这些问法背后的任务。
先判断：分散的是说法，还是任务
把待处理的需求列出来，逐条写一句“用户拿到答案后要做什么”。如果多数条目写出来是同一动作，例如都在判断某类方案是否适合自己、都在比较两种做法的取舍，那么它们是同一任务的多种说法，适合聚合。若写出来分别是“查某个规格能否兼容”“确认某种材料是否耐高温”“了解某类人群能否使用”，这些是不同任务，硬塞进一页会让每个部分都浅。
还有一个可观察的信号：搜索结果里排在前面的页面类型是否一致。如果同一批问法返回的多是同一类页面，说明搜索引擎对这批需求的理解接近，聚合页更容易覆盖；如果不同问法返回的页面类型明显不同，说明需求已经分叉，详情页更稳妥。这里要注意，抓取、索引和排名是不同环节，页面能被抓取不代表会被索引，被索引也不代表能排到前面，所以这个观察只用于判断需求结构，不能当作结果承诺。
条件一：任务一致时，聚合页优先
当需求共享同一任务，聚合页的价值在于把分散说法收拢到一个可维护的答案上。实施动作是：先确定一个主问题作为页面主线，再把各问法写成小节，每节给出可执行的判断依据，而不是只换措辞重复同一句话。
假设有一组问法都在问“某类设备在什么情况下值得买”。聚合页可以按使用场景分节：空间受限时看什么、需要连续运行时看什么、预算有限时先放弃什么。每节都指向同一个购买决策，读者读完能作判断。这样做的结果是，后续新增近义问法时只需补充一节，不必新建页面，站内重复内容的风险也更容易控制。
聚合页成立的前提是：这些问法确实能被同一批读者在同一决策阶段使用。如果其中混入了售后、安装、兼容性等不同阶段的问题，应把它们拆出去，否则页面会同时服务多类意图，反而让每类读者都找不到重点。
条件二：任务分叉时，详情页优先
当每个问法对应不同条件，详情页更合适。实施动作是：先为需求最明确、差异最大的那一组建详情页，每页只回答一个任务，并在页面上给出返回聚合页的路径。等详情页稳定后，再用聚合页汇总入口和选择标准。
假设有一组问法分别涉及两种规格、三种使用环境和两类人群。若强行合成一页，读者需要在一页里反复跳读才能确认自己那一类；拆成详情页后，每页的判断依据更集中，读者能直接得到结论。这样做的结果是，内部链接结构更清晰，聚合页承担导航和比较，详情页承担具体条件，后续修改某一条件时也不会牵动整页。
拆分的例外是：如果某个问法的搜索量极小、且与已有详情页高度重叠，单独建页只会制造薄内容。此时应把它并入最接近的详情页，作为该页的一个小节，而不是为了覆盖说法而建页。
旧内容退出时，用同一标准决定保留哪部分
旧内容、旧系统或旧合作关系需要退出时，先按上面的标准分类，而不是整批删除或整批保留。动作是：逐页标注它回答的是哪个任务、是否与现有聚合页或详情页重复、是否还有独立判断价值。
- 任务一致且已被聚合页覆盖的旧页，保留其中仍成立的判断依据，合并进聚合页后退出。
- 任务分叉且仍有独立条件的旧页，保留为详情页，更新过时条件，补上返回聚合页的链接。
- 既无独立任务、又无有效判断依据的旧页，退出，并检查站内是否还有指向它的链接需要处理。
这里要避免一个误判：某个旧页的抓取量或请求量下降，不能单独证明它该退出，也可能是入口减少、链接调整或统计口径变化。反过来，某个页面仍有访问量，也不能证明它值得保留，可能只是旧链接还在导流。判断仍要回到“它是否还在回答一个独立任务”。
先做哪个：一个可执行的排序
如果只能先做一个，按这个顺序：先确认需求是否共享同一决策任务；共享则先做聚合页，不共享则先做差异最大的详情页。做完第一版后，观察读者是否还需要在页面之间来回跳才能完成判断。若需要，说明聚合页的小节划分或详情页的入口设计有问题，下一步应调整结构，而不是继续加页。
这个排序的意义在于，它把“先做哪个”从感觉变成可验证的动作：先做一个，再看它是否减少了读者的判断成本。若减少，继续沿同一结构扩展；若没有减少，回到任务分类重新拆分或合并。这样处理，Google排名因素中的内容与需求匹配问题，才会落到具体页面结构上，而不是停留在词表层面。
