先做聚合页还是详情页,取决于你能否为同一批分散需求找到稳定的共同上位主题。如果这些需求共享同一决策阶段、同一对象类别,并且你手头已有足够可区分的素材,就应优先做聚合页,用它承接分散流量再向详情页分流;如果各需求之间缺少共同上位主题,或每个需求都需要独立证据、独立操作步骤才能回答,就应优先做详情页,避免聚合页变成关键词堆砌。
聚合页成立的前提,是搜索需求虽然表达分散,但背后指向同一个决策对象或同一类任务。例如用户分别搜索“某类工具怎么选”“某类工具对比”“某类工具适合谁”,这些需求可以被一个“选择指南”聚合页承接,再通过内链把用户送到具体对象的详情页。
如果需求只是词面相近,实际对象不同,聚合页就会失焦。判断方法很简单:把待处理的需求逐条写下来,在旁边标注“用户此刻要做的决定”。若超过一半的需求指向同一个决定,聚合页成立;若每条需求对应不同决定,详情页更合适。
这里有一个容易被忽略的条件:聚合页需要你有能力写出高于详情页的归纳内容。如果只是把详情页摘要拼在一起,用户没有理由停留在聚合页,搜索引擎也难以判断它比详情页更有价值。
当分散需求集中在同一决策阶段,聚合页是更经济的起点。它可以用一个页面覆盖多个长尾表达,减少重复建设,同时把内部链接集中到一个可维护的入口。
实施动作可以按以下顺序进行:
这个动作的结果会直接影响下一步:如果聚合页能自然形成三到五个比较维度,说明共同上位主题成立,可以继续扩充详情页;如果写了两段就无话可说,说明需求之间缺少真正的共同点,应退回详情页路线。
假设一个例子:某类设备有“家用怎么选”“小户型怎么选”“预算有限怎么选”三种搜索表达。若这三种表达最终都指向“在面积和预算约束下选型号”,聚合页可以成立;若“家用”指向安装条件,“小户型”指向尺寸,“预算有限”指向二手渠道,三者决定不同,聚合页只能做成导航,价值有限。
当每条需求都需要独立的数据、步骤或适用条件才能回答时,详情页是更稳妥的起点。聚合页无法替代详情页承担证据密度,强行合并会让每个问题都答不完整。
判断信号包括:需求涉及不同对象的具体参数;需求对应不同操作流程;需求面向不同使用场景且结论互相冲突。出现这些信号时,先做详情页,再观察是否出现新的共同上位主题。
实施动作:先选一个需求最具体、你最有把握写清楚的条目做详情页,页面内只回答该需求,不急于覆盖其他表达。发布后观察该页面是否开始获得与相邻需求相关的展示。如果出现,说明这些需求可能共享上位主题,此时再建聚合页,用聚合页链接已存在的详情页。
这个顺序的好处是:详情页先验证单个需求是否真实存在,聚合页后建时已经有可链接的目标,不会出现聚合页指向空页面的情况。代价是前期页面数量多、维护成本高,适合需求差异大、证据要求高的主题。
有些分散需求既不适合聚合,也不适合逐条建详情页。典型情况是需求本身不稳定,表达随季节或热点变化,且没有稳定的上位主题。此时更合理的动作是先在一个宽泛页面上用段落回答,不单独建页,也不做聚合。
另一个例外是站点已有详情页但内容薄弱。这时优先补强详情页,而不是新建聚合页。聚合页链接到薄弱详情页,只会把用户送到低质量页面,内链的引导作用会被削弱。
还需要说明:抓取量、索引量或某个词的展示量下降,不能单独证明聚合或详情页的选择正确。排名波动可能来自竞争页面变化、搜索意图漂移或页面自身内容更新,需要结合页面级别的展示与点击变化一起看,而不是只看总量。
把待处理需求写成清单后,按以下顺序判断:
执行后用一个动作检验:在聚合页或详情页发布两周后,查看页面是否获得了与目标需求语义接近的查询展示。若聚合页只获得自身标题词的展示,没有带动相邻需求,说明聚合的上位主题不成立,应改为详情页分别承接。若详情页开始获得相邻需求的展示,说明聚合条件正在形成,可以准备聚合页。这个检验只用于判断下一步方向,不构成对收录或排名的保证。