网页快照查看时搜索需求太分散，先做聚合页还是详情页
📱 Mozilla/5.0 AppleWebKit/537.36 (KHTML, like Gecko; compatible; ClaudeBot/1.0; +claudebot@anthropic.com)
🔗 /d36100f9df6a.html
📄
网页快照查看时搜索需求太分散，先做聚合页还是详情页
先做聚合页还是详情页，取决于分散需求之间是否存在共同决策场景。如果用户查快照是为了判断某个页面是否值得继续访问，聚合页能先承接比较动作；如果每类快照对应不同操作，详情页更合适。判断依据不是词多不多，而是这些需求能否在同一页上被同一批人连续用完。
需求分散不等于必须拆成很多详情页
网页快照查看的需求常被误判为“一个词一页”。实际搜索背后可能是三类意图：确认页面是否还能打开、判断内容是否已更新、核对搜索结果与落地页是否一致。这三类意图如果都指向同一个动作——决定是否继续点击原页面——那么它们共享同一决策链，聚合页反而更贴近使用过程。
反过来，如果一部分人要看缓存版本，一部分人要找历史版本，还有一部分人要确认站点是否更换了域名，这些动作的下一步完全不同。硬塞进一个聚合页，用户仍要二次跳转，详情页就更合理。
聚合页成立的前提：比较动作能在一页内完成
聚合页适合“先看再选”的场景。它不需要覆盖所有长尾词，而要把分散入口收拢成可比较的几组信息。判断是否成立，可以看三个条件：
- 用户目标相似：都在判断原页面是否值得访问，而不是执行不同任务。
- 判断依据可并列：快照时间、页面标题、可读状态、与当前页面的差异，能放在同一视图里。
- 后续动作一致：看完后大多选择打开原页、放弃访问或换一个来源。
满足这些条件时，聚合页的价值在于减少来回切换。它不承诺排名，也不保证收录，只是让用户更快完成一次判断。
详情页成立的前提：每类需求有独立操作链
当搜索需求虽然都带“网页快照查看”这类表述，但后续动作分化明显时，详情页更稳。例如，有人要核对某条内容是否被改动，有人要找页面历史版本，有人要确认页面是否已迁移。这三类人需要看的字段、执行的动作和离开页面的方式都不同。
此时详情页的作用不是堆更多词，而是把一类需求的操作链写完整：先看什么、怎么判断、判断后去哪里。若一个详情页只能回答“什么是快照”，却不能帮用户完成下一步，它就不该独立存在。
一个可执行的取舍动作：先做意图归并，再决定页面层级
具体做法是，把已有搜索入口按“用户看完后要做什么”分组，而不是按词面分组。假设有二十个入口，其中十五个都指向“判断原页是否值得打开”，另外五个分别指向“找历史版本”“确认是否换域名”“核对内容差异”。前十五个可以先合并为一个聚合页，后五个再按操作链拆详情页。
做完这一步后，观察聚合页上的下一步点击去向。如果大量用户仍绕回同一批详情动作，说明聚合页只完成了入口收拢，没有完成决策收拢，应把其中一类拆出去；如果用户直接在聚合页完成判断并离开，说明聚合层级成立，不必继续拆细。
保留、改写还是退出，要看前提是否变化
已有业务中，关键前提变化通常来自三处：原页面是否仍可访问、快照信息是否还能支撑判断、用户下一步是否仍指向同一动作。原页面已不可访问时，聚合页可能失去比较对象，此时应保留能解释差异的详情页，退出只重复入口的页面。原页面仍可访问、但用户开始关心内容差异时，聚合页需要改写为对比结构，而不是继续罗列入口。
如果前提没有变化，只是入口数量增加，不要急着新建页面。先检查现有聚合页能否容纳新增判断依据；不能容纳时再拆详情页。这样做的结果是，页面层级跟着用户动作走，而不是跟着词量走。
判断时别把抓取、索引和排名混在一起
网页快照查看相关页面是否被处理，涉及抓取、索引和排名三个不同环节。抓取量变化、索引状态变化或某个入口没有展现，都不能单独证明聚合页或详情页的选择正确。它们可能来自页面可访问性、内容重复、内部链接变化或搜索需求本身转移。做取舍时，先确认用户动作是否被页面承接，再去看这些环节的表现，顺序反了就容易用结果倒推结构。
