Feed优化：搜索需求太分散时先做聚合页还是详情页
📱 CCBot/2.0 (https://commoncrawl.org/faq/)
🔗 /d2c198a184be.html
📄
Feed优化：搜索需求太分散时先做聚合页还是详情页
先做聚合页还是详情页，取决于分散需求之间是否存在可共享的同一决策意图。如果多个查询都指向同一类选择、同一组比较维度，只是措辞不同，聚合页优先；如果每个查询各自对应不同型号、不同故障、不同使用条件，答案无法互相替代，详情页优先。Feed优化在这里的作用是让抓取和索引更早发现这两种结构各自的入口，而不是替你做选择。
判断依据：需求分散但意图同源，还是需求分散且答案互斥
把已有查询按“用户下一步会做什么”分组，而不是按词面相似度分组。假设有一组查询分别问某类设备在低温环境、潮湿环境、长时间运行下的表现，如果这三种情况最终都指向同一条选型建议，那它们就是同源需求，适合一个聚合页。反过来，如果低温对应一种型号，潮湿对应另一种型号，长时间运行又对应第三种，每个答案不能互换，那就是互斥需求，硬做聚合页只会让页面同时讲三件事，每件都讲不透。
可区分的证据有三类。第一，看搜索结果页是否混入大量不同形态的内容：同源需求往往出现教程、对比、问答混杂；互斥需求往往清一色是具体型号或具体场景页面。第二，看现有页面能否用一段话同时回答两个查询而不产生矛盾；能，则同源。第三，看用户从查询到转化之间是否需要二次选择；需要二次选择，说明查询本身还没收敛，聚合页更适合承接。
先做聚合页的条件与动作
当分散查询共享同一决策意图，且你已有至少三到五个可验证的细分答案时，先做聚合页。聚合页不是把关键词堆在一段文字里，而是提供一个可比较的结构：每个细分需求一个小节，小节内给出该条件下的结论和依据，再在页面上方给出总判断。
实际动作可以这样安排：先建立一个聚合页，把已确认的同源查询各写成一个独立小节，每节末尾链接到更细的说明页；然后在Feed中优先提交这个聚合页的地址，观察它是否被索引、是否开始为多个查询获得展现。如果索引后展现集中在其中一两个小节对应的查询上，说明另外几个查询的意图并没有真正同源，下一步应把未被覆盖的部分拆成详情页，而不是继续往聚合页里加内容。这个动作的结果直接决定你是继续扩聚合页，还是转向详情页。
先做详情页的条件与动作
当每个查询的答案互斥，或者你目前只有一两个细分需求有把握写清楚时，先做详情页。详情页的目标是让一个查询对应一个明确答案，页面标题、首段和结论都只服务这一种条件。Feed优化此时的任务是保证每个详情页都有独立可抓取的地址，并在站内用清晰的路径把它们和上级分类连起来，避免它们成为孤页。
动作上，先选两到三个你最有把握、且已有真实业务支撑的细分需求，各做一个详情页，互相之间只在确实相关时链接。提交后观察抓取和索引情况：如果这些页面被正常索引，但彼此之间没有形成任何共同入口，下一步再补一个聚合页作为导航层；如果连索引都不稳定，先检查页面是否内容过薄或路径过深，而不是急着做聚合。
一个注明假设的短例子
假设你经营一类工业耗材，查询分散在“耐高温”“耐腐蚀”“食品接触”三个方向。若你的产品线里同一款材料同时满足这三种条件，且选型逻辑一致，那就先做聚合页，用三个小节说明同一款材料在三种条件下的表现，Feed优先提交聚合页。若这三种条件分别对应三款不同材料，选型逻辑互不兼容，那就先做三个详情页，各自回答一种条件，等三页都稳定后再考虑是否需要一个对比聚合页。这个例子中的数字只是说明比较方法，不代表任何实际业务结果。
例外与回退条件
有两种情况需要回退。第一，聚合页做完后长期只为一个查询获得展现，说明同源判断错误，应拆成详情页。第二，详情页做完后发现多个页面的查询开始互相渗透、用户在不同页面间来回跳转，说明需求其实同源，应合并为聚合页并保留原详情页作为小节锚点。判断回退的依据是索引后的展现分布和站内跳转行为，而不是提交当天的抓取量；抓取量归零或激增都可能由抓取预算、站点改版或外部链接变化引起，不能单独证明结构选择正确。
Feed优化在这个决策里始终是配套动作：它决定搜索引擎多快发现你新建的聚合页或详情页，但不决定哪种结构更适合当前需求分布。先判断意图同源还是互斥，再决定先做哪一种，最后才用Feed把入口送出去。
