先做聚合页还是详情页,取决于分散需求之间是否存在稳定的共同意图。如果这些词指向同一类决策、同一批比较对象,聚合页能更快形成主题入口;如果每个词背后是不同使用条件、不同人群或不同答案,详情页更稳,强行合并只会让页面谁也不满足。判断依据不是词多词少,而是用户看完一页后能否完成同一件事。
搜索需求分散通常有两种来源。一种是表达差异:同一件事被写成不同说法,用户目标其实一致。另一种是目标差异:词面接近,但有人想了解原理,有人想直接选型,有人想解决故障。前者适合聚合,后者适合拆分。
可以做一个假设例子。假设有十个查询分别围绕“价格构成”“报价差异”“预算怎么定”“费用为什么不同”。它们都指向预算判断,共同意图明显,可以先用一个聚合页承接,把不同问法作为小节展开。若其中混入“合同怎么签”“发票怎么开”,这些属于交易流程,和预算判断不是同一任务,应另做详情页。
实际操作时,把候选查询逐条写成“用户想完成什么”,而不是只记录词。若超过七成查询能归入同一任务,聚合页成立;若归入三个以上任务,优先做详情页,再考虑用聚合页做导航。
聚合页成立需要三个条件:需求共享同一决策场景;各分支内容量不足以独立成页;站内已有或即将有详情页可以承接细分问题。满足时,聚合页能减少重复页面,让搜索引擎更容易理解站点在某一主题上的覆盖范围,也方便用户先建立整体认知。
代价是内容容易变浅。若把十个不同条件的问题压进一页,每个都只写两句,用户仍要跳转,页面也缺少独特价值。更常见的风险是聚合页与详情页互相竞争,内部链接没有主次。此时应明确:聚合页负责主题概览和分流,详情页负责具体条件、步骤和证据。聚合页上的每个小节只给结论和判断标准,把操作细节链接到详情页。
可执行动作:先发布聚合页,同时为其中最独立的两三个分支建立详情页,并在聚合页对应小节放置内链。两周后观察哪些小节被点击进入详情页,哪些小节停留明显偏短。点击少不等于需求不存在,也可能是入口位置或摘要不匹配;应结合站内搜索词和用户留言再判断,而不是仅凭一次数据就删改。
当每个查询对应不同条件、不同角色或不同结果时,详情页更合适。例如同一类服务,个人用户关心流程,团队用户关心权限和协作,采购关心比价和交付。三种人需要的证据不同,合并后只能写通用介绍,反而降低可信度。
详情页的代价是维护成本高、页面之间容易重复。若十个页面只换了标题和少量词,搜索引擎和用户都会把它们视为近似内容。要避免这一点,每页必须回答一个独立问题,并给出该问题特有的判断依据,例如适用条件、不适用情形、需要准备的资料、常见失败原因。页面之间用聚合页或相关链接连接,而不是互相复制段落。
另一个代价是起步阶段入口分散。此时不必急着为每个词建页,可以先选搜索意图最明确、最可能带来后续动作的两三个问题做详情页,其余需求先记录在内容计划中。等详情页能稳定回答具体问题后,再回头做聚合页,结构会更清楚。
面对一批分散需求,可以按以下顺序处理:
这个顺序的关键是先判断现有页面能否承接,而不是先决定新建聚合页还是详情页。很多分散需求并不需要新页面,只需要把已有页面的适用范围写清楚。
把候选查询按“任务、角色、条件”三列归类。若同一任务、同一角色、条件差异只是表述不同,做聚合页;若任务相同但角色或条件会导致不同答案,做详情页,并用聚合页做入口。若任务都不同,不要做聚合页,分别评估是否值得建页。
发布后验证时,区分抓取、索引和排名三个环节。页面未被抓取,可能是入口不足或站点结构问题;已抓取未索引,可能是内容质量或重复问题;已索引但排名不理想,才需要回到意图匹配和内容深度。把其中任一现象直接当成“聚合页无效”或“详情页无效”,都会导致错误决策。
最后给一个简短的执行例子:假设你有一组关于“费用”的分散查询。先建一个费用判断聚合页,写清影响费用的变量、常见报价差异和预算区间逻辑;再把“不同规模团队的费用差异”和“费用包含哪些项目”拆成两个详情页。聚合页负责让用户判断自己属于哪种情况,详情页负责给出该情况下的具体依据。这样既保留主题覆盖,也避免把所有答案压在一页里。