先做聚合页还是详情页,取决于这些分散需求之间是否存在可被同一批用户接受的共同任务。如果多个查询指向同一件事的不同说法,聚合页更容易让百度理解页面主题;如果每个查询对应不同决策阶段、不同使用场景,详情页更合适。判断依据不是词多词少,而是用户点进来后是否愿意留在同一个页面上完成同一件事。
做百度推荐优化时,常见做法是先挑一个搜索需求做详情页,发现它能带来点击和停留,于是把同类词逐个复制成独立详情页。小范围看没问题,规模一放大,问题就出现了:一部分页面长期没有稳定展现,另一部分页面之间互相抢同一批需求。
这个现象容易被误读成“百度不收录新页面”或“聚合页一定比详情页好”。但更合理的解释通常有两个:一是这些需求本来就不该拆开,用户搜不同说法时想解决的是同一件事;二是这些需求虽然表面相似,但用户所处的决策阶段不同,硬合并会让页面同时讲几件事,反而谁都讲不透。
当多个查询描述的是同一个任务,只是措辞、口语化程度或地域叫法不同,它们对百度来说更像同一主题的不同入口。此时如果每个说法都做一个薄详情页,每个页面能承载的独有信息很少,百度难以判断哪一个页面最该被推荐,用户也会在不同页面之间反复跳转。
判断是否同源,可以看一个动作:把几个候选查询分别交给不熟悉业务的人,请他们用一句话说出“搜这个词的人想完成什么”。如果多数人给出的任务描述高度接近,聚合页更合适。聚合页的价值在于把同一任务下的分支、条件、常见变体集中在一处,让页面有足够内容支撑一个明确主题。做完这一步后,下一步应观察这些分支是否真的被用户逐条消费;如果聚合页里大部分分支无人点击,说明合并过度,需要回退到详情页。
另一种情况是,查询词看起来属于同一大类,但用户要解决的问题并不一样。例如有人想了解概念,有人想比较方案,有人已经准备执行某个具体操作。把这些内容塞进一个聚合页,页面会变得很长,用户需要不断滚动才能找到自己那一段,百度也难以判断页面到底在回答哪个问题。
这时详情页更合适,因为每个页面可以围绕一个明确任务展开,标题、首段和正文结构都能直接对应查询意图。但详情页也不是越多越好。一个可执行的判断是:先为差异最大的两三个需求各做一个详情页,观察它们是否都能获得独立展现和点击。如果只有其中一个有效,其余长期没有反应,说明这些需求可能并不独立,应该考虑合并,而不是继续加页。
不要只看某个页面有没有排名。更有区分力的证据包括:同一批查询下,用户进入页面后的行为是否集中;页面之间是否频繁出现互相替代的展现;以及新增页面后,原有页面的展现是否被明显分走。
需要说明的是,抓取量、索引量或某个查询的展现量下降,不能单独证明聚合或拆分做错了。服务器波动、页面改版、竞争内容变化、百度对同类页面的重新判断,都可能造成类似现象。要把这些指标和用户行为、页面之间的替代关系放在一起看。
假设某类服务有十个相近查询,其中六个是同一件事的不同说法,四个分别对应“是什么”“多少钱”“怎么选”“怎么做”。在样本阶段,单独做“怎么做”的详情页可能表现不错,因为任务明确。但把其余九个也各做一个详情页,规模化后很可能出现部分页面长期没有独立展现。
更稳妥的动作是:先把六个同源说法合并成一个聚合页,把“是什么”和“怎么选”作为聚合页内的分支;再为“多少钱”和“怎么做”各保留一个详情页,因为它们对应不同的用户任务和不同的下一步。执行后,如果聚合页能稳定承接那六个说法,而两个详情页各自有独立展现,说明这个划分成立;如果“怎么选”在聚合页内被大量点击,说明它可能也值得独立成页,下一步再拆。
这套判断适用于已有一定内容基础、能观察到用户行为和页面替代关系的站点。如果站点刚起步,样本量很小,任何关于“聚合还是详情”的结论都只是假设,需要先小范围验证。如果业务本身要求每个需求都必须有独立落地页,例如涉及不同资质、不同服务承诺或不同地区政策,那么即使需求同源,也不能简单合并,因为页面承载的不只是搜索意图,还有合规和转化要求。
百度推荐优化的核心不是把页面做成一个固定模板,而是让用户获取内容的过程更顺,让搜索引擎更容易理解页面在回答什么。先判断需求是否同源,再决定聚合还是详情,做完后根据用户是否在同一页面完成同一任务来调整下一步,而不是一次性铺开所有页面。