先做聚合页还是详情页,取决于分散需求之间是否存在共同的决策前提。如果这些词指向同一类服务、同一批客户、同一套选择标准,聚合页能更快建立主题相关性;如果每个词背后对应不同的预算、资质、交付方式或使用场景,强行合并只会让页面失焦,此时应优先做详情页。判断依据不是词多词少,而是用户点进来后想解决的问题是否一致。
聚合页成立的前提,是多个搜索词可以共用一段解释、一组对比和同一个转化动作。例如围绕开户的咨询里,有人搜流程,有人搜所需材料,有人搜多久能开始投放,这些需求虽然表述不同,但都指向“准备开户并尽快投放”这一条决策链。把它们放在一个聚合页里,用分节回答,用户不必在多个页面之间跳转,页面也更容易被理解为覆盖同一主题。
反过来,如果搜索词分别对应不同行业、不同投放预算、不同资质条件,甚至有人只是查政策、有人已经准备签约,那么它们不共享同一决策前提。此时聚合页会写成大杂烩,用户找不到与自己匹配的段落,跳出率上升,后续再补详情页也要重新分配内链和入口。更稳妥的做法是先做详情页,把差异讲透,再决定是否需要一个总览页。
聚合页的优势是启动快。你可以在一个页面里覆盖多个相关问法,减少初期页面数量,也方便把内部链接集中指向一个地址。但它有明确代价:当子话题之间的差异足够大时,每个部分都只能写浅,用户看完仍无法判断自己该选哪种方案。
一个可操作的判断方法是做一次假设分组。假设你手上有二十个分散问法,先按“用户下一步动作”分成三组:只想了解、正在比较、准备提交资料。如果超过七成的词落在同一组,聚合页通常成立;如果三组分布接近,说明需求并没有真正聚合,先做详情页更合适。这个例子只是说明分组方法,不是固定阈值,实际分组要按你的业务逐条核对。
动作上,可以先建一个聚合页草稿,把每个子话题写成两到三句摘要,并标注它需要多长的解释才能让用户做决定。如果多数子话题都需要独立展开,就说明聚合页承担不了,应拆成详情页;如果多数只需两三句就能说清,聚合页可以保留并继续补充。
详情页适合需求之间差异明显的情况。每个页面只回答一个问题,用户意图更集中,后续做内链和更新也更清楚。代价是页面数量增加,初期需要更多入口和链接关系,否则容易出现有的页面长期没有抓取、没有展现。这里要区分抓取、索引和排名:页面没被收录,可能是入口太少,也可能是内容重复或质量不足,不能只凭一个现象就断定是聚合没做。
如果选择详情页路线,至少要给每个页面一个明确的来源:从聚合页分节链接过去,从相关详情页互相引用,或从已有流量页面补充入口。缺少入口的详情页,即使内容准确,也可能长期停留在未被充分理解的状态。反过来,如果详情页已经能稳定承接某类问法,就不必再为它强行做一个聚合页,避免两个页面互相竞争同一批需求。
面对已经存在的页面,不要只凭感觉决定去留。可以按下面这组证据逐项核对:
这里要注意,某个页面请求量下降或抓取频次变化,不能单独证明它该退出。服务器波动、入口调整、季节变化、竞争对手改版,都可能造成类似现象。判断退出前,至少确认它是否还有来自其他页面的内链、是否仍能回答一个独立问题、是否与现有页面高度重复。三项都指向重复且无入口,才考虑合并。
如果需求确实分散,建议按以下顺序推进:先列出所有分散问法,按用户下一步动作分组;再挑出共享前提最多的一组,做一个聚合页草稿;草稿完成后,逐节检查哪些部分需要独立展开。需要独立展开的,拆成详情页并从聚合页链接过去;不需要独立展开的,留在聚合页里继续完善。
这个顺序的结果会直接影响下一步:如果聚合页草稿里超过一半的分节都需要独立展开,说明你面对的是多个不同决策,应转向详情页优先;如果多数分节都能在聚合页内说清,就继续补充聚合页,并把详情页作为后续扩展,而不是一开始就铺开大量页面。无论选哪条路,都要保证每个页面有明确入口、有独立回答的问题,并且不与已有页面重复。这样做的目的不是追求页面数量,而是让用户和搜索引擎都能判断每个地址该在什么时候出现。