先做聚合页还是详情页,取决于这些分散需求是否共享同一个购买意图,以及现有页面里有没有一个已经能承接搜索流量的“母页”。如果需求只是问法不同、指向同一类产品,优先把聚合页做成可筛选、可比较的入口;如果需求各自对应不同规格、不同用途、不同决策链条,先补详情页更稳。下面用一个假设情境把判断过程走一遍。
假设某工业配件站准备下线旧系统,旧站上有一批早年发布的页面:有的写“耐高温密封圈”,有的写“食品级密封圈”,有的写“耐油密封圈”,还有几篇是某次展会留下的产品介绍。它们各自有一点搜索流量,但内容薄、参数旧、互相不链接。新站上线时,团队只剩一个月的编辑资源,于是出现一个取舍:先做“密封圈”聚合页,还是先重写其中流量最大的详情页。
这里的关键不是页面数量,而是这些需求是否属于同一决策。耐高温、食品级、耐油,表面上是三种搜索词,实际可能是同一批采购者在不同工况下的选型条件。若它们最终都落到同一类产品、同一套询价流程,聚合页就能把分散需求收拢;若每种条件对应不同材料、不同认证、不同安装方式,详情页才是承接点。
把旧页面按“用户想完成什么”重新分组,而不是按关键词字面分组。可以逐个问三个问题:
如果三个问题都指向“同一类”,聚合页成立。它可以把耐高温、食品级、耐油作为筛选维度,让用户在一个页面内完成比较,也帮助搜索引擎理解这些分散页面共同指向一个主题。如果答案分裂,说明需求并不共享意图,硬做聚合页只会得到一张大而空的列表。
聚合页不是凭空新建的目录页。它需要一个已经能承接搜索流量、且有实质内容的详情页作为支撑。判断方法是检查那个流量最大的详情页:
如果答案偏向肯定,实际动作是:先保留并更新这个详情页,把它作为母页,再从它延伸出聚合页,用筛选和对比把零散需求接回来。这个动作的结果是,聚合页有内容可引用,详情页也不会因为改版而失去原有承接能力。下一步才是决定哪些旧页面重定向到聚合页、哪些重定向到详情页。
如果那个详情页本身内容陈旧、参数缺失,先做聚合页等于把分散需求集中到一个更薄的页面上,风险更大。此时应先补详情页,再考虑聚合。
假设旧站有两个页面:A 页讲“耐高温密封圈”,B 页讲“食品级密封圈”。如果两种密封圈使用同一材料体系、同一认证范围,只是工况描述不同,那么把它们合并到一个聚合页,用筛选区分工况,通常比维护两个薄详情页更省资源。用户进入后仍能完成比较,搜索引擎也更容易判断这个聚合页的主题边界。
反过来,如果耐高温对应一种材料,食品级对应另一种必须单独认证的材料,且安装尺寸、询价单字段都不同,那么把它们塞进同一聚合页会让用户无法判断该选哪个。此时先做两个详情页,各自写清材料、认证、适用工况,再在详情页之间做交叉链接。聚合页可以后置,等详情页稳定后再作为总入口。
这个例子中的数字只用于说明比较方法:不是看哪个词流量大,而是看两种需求能否共用同一套页面结构。
旧内容、旧系统或旧合作关系退出时,保留仍然有价值的部分,意味着不是简单删页,而是重新分配承接关系。可以按以下顺序处理:
这个顺序的结果是,分散需求被收拢到有明确分工的页面上,旧内容的退出不会直接切断承接路径。下一步可以观察哪些聚合页筛选条件被频繁使用,再决定是否把某个筛选条件升级为独立详情页。
先做聚合页的条件是:多个搜索需求共享同一购买意图,现有详情页能提供实质内容支撑,且用户需要在一个页面内完成比较。先做详情页的条件是:每种需求对应不同材料、认证、规格或决策链条,聚合页无法用统一结构承接。两种做法并不互斥,但在资源有限时,顺序会影响后续动作。
如果先做聚合页,下一步应检查它是否把用户顺利送进详情页;如果先做详情页,下一步应检查这些详情页之间是否需要一个新的聚合入口来收拢分散需求。抓取、索引和排名是不同环节,页面被收录不代表它已经能承接搜索需求,因此判断应回到用户意图和页面分工,而不是只看旧页面是否还有进入。