快照恢复，搜索需求太分散时先做聚合页还是详情页
📱 Mozilla/5.0 (compatible; QlyzeBot/1.0; +https://app.qlyze.io/bot)
🔗 /d3fda9f71ab2.html
📄
快照恢复，搜索需求太分散时先做聚合页还是详情页
先做聚合页还是详情页，取决于你手上的旧资料本身是否已经能回答一个完整问题。如果它只能回答问题的一个侧面，就先做详情页；如果它能覆盖同一意图下的多个侧面，就先做聚合页，把已有内容组织成一个入口。判断依据不是页面数量，而是每份资料能否独立满足一次搜索。
先看旧资料能独立回答什么
快照恢复场景下，旧内容往往来自系统迁移、合作终止或业务线收缩。你手上可能有一批说明文档、故障处理记录、接口备注或历史页面。先逐份判断：这份资料单独拿出来，能不能让一个不了解背景的人解决一个问题。能，它就有资格成为详情页；不能，它只能作为聚合页里的一个段落或一个链接。
这里要区分两个动作。聚合页是把同一类意图下的多个问题收在一页，让读者先判断自己属于哪种情况；详情页是只解决其中一个具体问题。旧资料如果已经按问题拆开，强行合并会稀释每个问题的回答深度；如果旧资料本来就是一份总览，硬拆成多页反而制造重复。
需求分散时聚合页先行的条件
当搜索需求表现为同一主题下的多个相近问法，而每个问法单独做一页都显得单薄时，聚合页更合适。判断信号是：这些问法共享同一批前置条件、同一套术语、同一类操作步骤，只是入口不同。此时聚合页可以先建立主题覆盖，再让读者从聚合页进入最接近的详情页。
假设你有一份旧系统退出说明，里面同时提到数据导出、权限回收和对外通知。这三件事单独搜索时意图不同，但都发生在同一个退出流程里。先做一个聚合页，按流程顺序列出三块内容，再分别链接到已有的详细记录。这样做的结果是：读者不会因为只找到其中一块而误以为流程不完整，你也能观察哪一块被点击得更多，再决定是否把它扩成独立详情页。
详情页先行的条件与动作
如果某个具体问题的搜索意图已经足够明确，而旧资料里恰好有一份能完整回答它的记录，就先把它整理成详情页。动作是：把这份记录里的前提条件、操作步骤、失败后的处理方式写清楚，并只针对这一个问题设置标题和段落结构。结果是这个页面可以独立承接搜索，不需要依赖聚合页来解释自己。
反过来，如果一份旧资料只能回答半个问题，比如只写了导出步骤，没写导出失败怎么办，那它还不适合作为详情页单独存在。此时更稳妥的做法是把它并入聚合页的对应段落，等补充完失败处理后再拆出来。这个顺序影响下一步：先拆详情页意味着你要为每个页面单独维护更新；先做聚合页意味着你只需要维护一个入口，但每个子问题的深度会暂时受限。
用退出决策决定先后顺序
旧内容、旧系统或旧合作关系需要退出时，保留仍然有价值的部分，这个动作本身会改变优先级。你需要先确认哪些部分仍然有人搜索、哪些部分只是内部习惯。可执行的做法是：列出手上每份资料的标题、它能回答的问题、以及这个问题是否已经有其他页面在回答。然后按以下条件分流：
- 能独立回答一个问题，且没有其他页面覆盖：先做详情页。
- 只能回答半个问题，但同一主题下有多个类似资料：先做聚合页，把它们收在一起。
- 既不能独立回答，也没有同类资料可聚合：暂时保留在旧位置，不新建页面。
这个分流的结果会直接决定你下一步是写标题和摘要，还是先写一段总览。不要因为旧资料数量多就默认先做聚合页，也不要因为某个问题搜索意图明确就跳过聚合页。判断标准始终是：读者能不能在一页之内完成一次判断或一次操作。
一个假设例子：旧接口文档怎么处理
假设你有一批旧接口文档，合作方已经停止维护，但其中三个接口的参数说明仍然被内部搜索到。这三个接口分别解决不同问题：一个用于查询状态，一个用于提交结果，一个用于取消任务。查询状态的说明完整，提交结果的说明缺少错误码，取消任务的说明只有一行。
按上面的条件，查询状态可以先做成详情页；提交结果先并入聚合页，等补上错误码再考虑拆出；取消任务暂时不单独建页，只在聚合页里保留一句说明。这样做的结果是：你不会因为三个接口来自同一份旧文档就强行做成一个聚合页，也不会因为取消任务只有一行就把它丢掉。下一步是观察查询状态详情页是否被访问，如果被访问且读者继续搜索错误处理，再决定是否把提交结果也拆出来。
快照恢复相关的旧资料处理，本质上不是恢复页面数量，而是恢复内容与搜索意图之间的对应关系。先做聚合页还是详情页，答案在你手上的资料能否独立回答一个问题。这个判断做完之后，再决定标题、结构和内链，才不会返工。
