蓝天算法，搜索需求太分散时先做聚合页还是详情页
📱 Mozilla/5.0 AppleWebKit/537.36 (KHTML, like Gecko; compatible; ClaudeBot/1.0; +claudebot@anthropic.com)
🔗 /ea97a47ddb2b.html
📄
蓝天算法，搜索需求太分散时先做聚合页还是详情页
先做聚合页还是详情页，取决于这些分散需求是否共享同一套判断标准。如果用户搜不同词，最后都要比较同一组选项、走同一条决策路径，聚合页优先；如果每个词背后是独立的操作步骤、参数或适用条件，详情页优先。蓝天算法针对的是内容质量与需求匹配，判断顺序不能只看词的数量。
先看一个反直觉现象：详情页越多，搜索入口反而越碎
假设一个站点围绕同一主题写了二十篇详情页，每篇只覆盖一个长尾词。直觉上，页面越多，能接住的搜索需求越多。实际可能出现相反结果：这些页面互相争夺同一批词，内部链接没有形成主次，用户从任何一个入口进来都看不到完整选项，跳出后回到搜索结果。
这个现象不等于“详情页没用”，也不等于“聚合页一定更好”。它只说明一件事：分散需求没有被组织成可比较的结构。要区分原因，需要看用户在这些词之间是否来回切换。
两种解释：需求本身分散，还是页面没有承接路径
第一种解释是需求确实分散。每个搜索词对应不同场景，用户不需要横向比较，只需要一个明确答案。例如同一类操作在不同设备、不同前提下的步骤不同，用户搜到对应详情页就能解决问题。
第二种解释是需求并不分散，只是缺少承接路径。用户先用宽泛词了解全貌，再用具体词确认细节。如果只有详情页，宽泛词没有合适落点；如果只有聚合页，具体词又得不到足够深的答案。两种页面承担的任务不同，不能互相替代。
能区分这两种解释的证据不在搜索量大小，而在用户行为路径：
- 站内搜索词、跳出后的二次搜索词是否频繁在宽泛词与具体词之间往返；
- 同一批用户是否在多个详情页之间来回点击，却始终没有完成比较；
- 聚合页加入后，详情页的入口点击是否变得更集中，而不是被稀释。
如果往返明显，优先补聚合页；如果用户进入某一篇后直接完成动作，优先补详情页。请求量或抓取量下降不能单独证明选错了页面类型，也可能是抓取预算、站点结构或索引状态变化造成的，需要与用户路径证据一起看。
聚合页成立的条件：共享判断标准，且需要横向比较
聚合页适合这样的需求：多个搜索词指向同一类选择，用户需要先看全貌，再决定进入哪个细节。它成立的三个条件：
- 这些词共享同一套评价维度，例如适用条件、成本区间、操作难度；
- 用户需要在多个选项之间比较，而不是只找一个答案；
- 站内已有足够数量的详情页可以作为聚合页的支撑，而不是空壳目录。
动作上，可以先建一个聚合页，把已有详情页按用户决策顺序排列，并在每个条目下写清适用条件。结果会直接影响下一步：如果聚合页带来了更集中的站内点击，说明需求确实需要横向比较，可以继续补充比较维度；如果聚合页只获得曝光却很少被点击进入详情，说明用户要的是直接答案，应回到详情页补足内容，而不是继续扩张聚合页。
详情页成立的条件：独立操作、独立前提、独立结论
详情页适合另一类分散需求：每个词背后是一个独立问题，答案不能靠比较得出。判断依据是，把两个词的内容合并后，是否会出现前提冲突、步骤互相干扰，或者读者必须跳过一半无关内容才能找到自己要的部分。
如果会，就保留独立详情页，并在页面顶部说明适用前提。动作上，先选一个最具代表性的词写成完整详情页，观察它是否被用户当作终点页使用。如果用户读完即离开，且没有继续搜索同类词，说明该需求独立成立；如果用户读完后仍返回搜索更宽泛的词，说明还缺一个聚合入口。
这里要避免一个常见误判：把“页面数量多”当成“覆盖充分”。抓取、索引和排名是不同环节，页面被收录不等于被用户选中，被选中也不等于完成了需求。详情页的价值在于把一个问题讲透，而不是把同一个问题拆成多个近似页面。
一个可执行的判断顺序
假设一个站点有三十个相关搜索词，其中二十个词的用户会互相跳转比较，十个词的用户只看一个答案。此时不必二选一，而是分两步：
- 先为那二十个词建一个聚合页，明确比较维度，并把十个独立详情页作为其中的特例链接出去；
- 再检查十个独立词是否已有对应详情页，缺哪个补哪个，不为了凑数量把可合并的内容拆开。
这个顺序的前提是：聚合页必须有真实可比较的内容，不能只是链接列表；详情页必须有独立结论，不能只是聚合页的复制段落。执行后看两个信号：聚合页是否让详情页入口更集中，详情页是否让用户不再返回搜索同类宽泛词。两个信号指向不同结论，再决定继续加聚合层还是加详情层。蓝天算法约束的是内容是否真正匹配需求，页面类型只是实现匹配的手段。
