先做聚合页还是详情页,取决于分散需求之间是否存在可共享的决策信息。如果多个搜索词指向同一类选择、同一批对比对象或同一套前置条件,聚合页能更快承接流量并减少重复页面;如果每个词背后对应不同规格、不同使用场景或不同办理条件,详情页更合适,聚合页反而会让读者找不到答案。
把搜索词列出来后,不要按字面归类,而是问三个问题:读者是否在做同一类决定,是否需要用同一组信息比较,是否会在同一页里继续追问。如果三个问题都接近,聚合页成立;如果答案分叉,详情页更稳。
这个判断动作的结果会直接影响下一步:共享决策成立时,先搭聚合页的框架;不成立时,先写最靠近实际选择的那一个详情页,再决定是否补聚合入口。
当多个角色对同一事实有不同理解时,分歧往往不在“要不要做页面”,而在“先做哪一类页面”。如果大家能核对同一份搜索词清单,并确认这些词都指向同一类选择,聚合页就是更优先的动作。
假设有一组搜索词分别围绕“怎么选”“哪种合适”“有什么区别”展开,且读者最终都要看同一张对比维度表。此时聚合页可以先把对比维度写清楚,再为每个细分方向留出内链位置。实施动作是:先写聚合页的核心判断标准,再把无法在聚合页内讲透的部分标记为待拆详情页。结果是,团队能先用一个页面验证需求是否集中,后续详情页也有明确的承接对象。
适用条件:分散需求之间确实存在共享的判断标准,且聚合页不会因为覆盖太宽而失去重点。例外是,如果某个词已经表现出明确的独立意图,比如指定规格、指定材料或指定办理情形,就不应为了聚合而把它硬塞进同一页。
另一种常见情况是,搜索词看起来相近,但每个词背后的条件不同。此时先做聚合页,容易出现“每个点都提了一句,但每个点都没答完”的结果。更稳妥的动作是选一个条件最明确、最容易被核对的需求,先写详情页。
假设多个角色对“用户到底要什么”争执不下,有人主张做总览,有人主张做细分。可以把争议转成可核对的项目:列出每个搜索词对应的前置条件、需要引用的材料、读者下一步会做什么。如果这些项目无法合并,就先做详情页。实施动作是:完成一个详情页后,观察读者是否继续搜索相邻词;如果继续搜索,再决定是补第二个详情页,还是做一个聚合入口把已有详情页串起来。结果是,页面建设顺序由可核对的条件决定,而不是由角色立场决定。
适用条件:每个需求都有独立条件,且聚合页无法在不牺牲信息完整度的前提下回答清楚。例外是,如果多个详情页已经存在,只是缺少一个总览入口,那么补聚合页是整理动作,不是替代详情页。
团队内部对“先做哪个”有分歧时,不要继续争论页面类型,而是把分歧拆成可以核对的条目。下面这组项目可以直接用于会议记录或任务拆分:
核对后通常会出现两种结果:共享信息多、独立信息少,先做聚合页;独立信息多、共享信息少,先做详情页。这个动作的结果不是一次定论,而是决定第一轮先写什么、第二轮再补什么。
实际执行中,聚合页和详情页常常需要配合,但先后顺序仍然重要。聚合页负责把分散需求收拢到同一判断框架里,详情页负责把独立条件讲透。如果先做聚合页,后续要用详情页承接细分需求;如果先做详情页,后续要用聚合页或内链把相关页面串起来。
需要调整的信号包括:聚合页出现大量跳出后继续搜索的行为,说明读者没有找到对应条件;详情页之间互相抢同一批搜索词,说明缺少总览入口。遇到这些信号时,不要只凭单一现象下结论,因为跳出、继续搜索或抓取变化还可能有其他解释,比如页面加载、标题与内容不匹配、内部链接不足。更可靠的做法是把页面类型、搜索词条件和读者下一步动作放在同一张核对表里,再决定是补聚合页、补详情页,还是先修改现有页面的承接关系。
如果只能选一个起点,就选那个能让读者完成下一步动作的页面:共享决策明显时先做聚合页,独立条件明显时先做详情页。