如果这些分散的搜索需求指向同一类决策,而且你能用一段稳定的比较逻辑把它们串起来,先做聚合页;如果每个需求背后是不同角色、不同使用条件、不同结果预期,先做详情页。判断依据不是词多词少,而是这些需求能不能被同一套答案承接。下面把分歧拆成可核对的项,再给一个会推翻结论的反例。
团队里有人说“应该做聚合页”,有人说“应该先做详情页”,往往不是判断力差异,而是各自在谈不同环节。有人谈的是抓取:页面能不能被稳定发现;有人谈的是索引:页面值不值得被保留;有人谈的是排名:某条查询下谁更匹配。这三件事不能互相替代,抓取正常不等于会被索引,被索引也不等于某条查询下会靠前。
把分歧转成可核对的项目,可以按下面几项记录:
记录完通常会看到:分歧集中在“要不要先合并”,而不是“要不要做”。这一步的作用是让讨论从立场变成条件。
聚合页适合承接“同一件事的不同问法”。典型条件是:用户最终要做的决定是同一个,只是入口不同;你给出的比较维度可以共用;每个子需求单独成页会重复大量前提。此时聚合页的价值在于把分散入口收拢到一处,让用户在一次浏览里完成比较,也让页面主题更集中。
假设一个场景:某类服务同时存在“怎么选”“哪类更合适”“不同做法的差别”几组问法,而它们最终都指向同一个选择。若把这几组问法拆成多个详情页,每页都要重复解释背景和判断标准,用户还得来回跳。这时先做聚合页更合理,因为一次把比较框架讲清楚,后续再针对个别条件补详情页。
动作上可以这样做:先列出这批需求共用的三到五个比较维度,写成聚合页的主干;把无法共用的部分单独标记,留作后续详情页。结果是你能看清哪些需求真的同源、哪些只是看起来像,下一步的详情页选题会更有依据,而不是凭词表堆页面。
详情页适合承接“看起来相近、实际不同”的需求。判断信号是:用户身份不同,使用条件不同,或者他们要的结果根本不是一回事。把这类需求硬塞进一个聚合页,常见后果是页面越长越像目录,每类用户都找不到自己那段,页面主题也变得模糊。
假设另一组场景:同一批问法里,一部分来自准备自己动手的人,一部分来自要委托他人的人,还有一部分只是在确认风险。这三类人要读的内容结构不同:第一类要步骤和边界,第二类要判断标准和交接事项,第三类要后果和前置条件。此时先做详情页更稳,因为每页能围绕一类人把话说完整,聚合页可以后做,用来指路。
动作上可以这样做:按“谁在读、在什么前提下读、读完要做什么”把需求分组,先给最独立、最不容易被其他页面覆盖的那一组做详情页。结果是你能验证这类需求是否真的存在稳定读者;如果验证后发现几组其实共用同一套答案,再合并成聚合页也不迟。
前面说“同源就聚合、不同源就详情”,但有一个反例会让它失效:如果这批需求目前连一个能被稳定抓取和索引的承接页都没有,那么先做哪种页面都可能只是内部自说自话。原因是抓取和索引是排名的前置环节,页面结构再合理,若长期不被发现或不被保留,讨论聚合还是详情就没有实际意义。
需要留意的是,抓取量下降或某类请求归零,并不能单独证明你做错了。它也可能是站点结构调整、内部链接变化、服务器响应波动,或者只是抓取节奏的正常起伏。把这些现象直接当成“必须改做另一种页面”的证据,容易把不同环节的问题混在一起。更稳妥的做法是先确认现有页面处于哪个环节:是没被发现,是没被保留,还是被保留了但在目标查询下不匹配。
如果核对后确认是“同一决策、共用比较维度”,先做聚合页,并在页内为个别条件留出指向详情页的位置;如果确认是“不同角色、不同条件、不同结果预期”,先做详情页,再视情况补一个指路型聚合页;如果发现现有页面连抓取和索引都不稳定,先解决承接页的可发现与可保留问题,再回到聚合与详情的取舍。
无论选哪种,都建议先写一句可被检验的假设,例如“这批需求共用同一套判断标准,因此一个聚合页能承接主要入口”。等页面上线并积累一段时间后,回看用户实际进入的查询、停留位置和后续点击,再决定是拆还是并。这样做的意义在于:把“谁说得对”换成“哪个条件成立”,让下一次讨论有可核对的起点,而不是重新争论一遍。