历史页面存档：多个业务争夺同一搜索需求时如何划界
📱 Mozilla/5.0 AppleWebKit/537.36 (KHTML, like Gecko; compatible; ClaudeBot/1.0; +claudebot@anthropic.com)
🔗 /7e2aabf7cc2f.html
📄
历史页面存档：多个业务争夺同一搜索需求时如何划界
划界的关键不是谁“更有资格”保留页面，而是先判断这些页面是否在满足同一种搜索意图。如果多个业务的历史页面都在回答同一个问题，应保留一个主入口，其余页面转为补充、重定向或下线；如果它们分别覆盖不同阶段或不同约束，则可以并存，但必须让每个页面有独立的任务和可验证的差异。
先判断是同一需求还是相邻需求
把几个业务的历史页面放在一起，逐页看它回答的问题、面向的使用阶段和下一步动作。若用户搜同一个词时，几个页面给出的答案几乎可以互相替换，这就是同一需求；若一个页面解决“是什么”，另一个解决“在特定限制下怎么选”，则属于相邻需求，可以保留。
判断时不要只看标题和关键词，要看正文中实际提供的选择依据。两个页面都只讲概念、都没有帮助读者做决定，即使措辞不同，也应视为同一需求。反过来，一个页面讲通用方法，另一个页面讲某类旧系统退出时的处理顺序，后者的差异是真实的，可以独立存在。
两种条件下的不同选择
条件一：页面满足同一种意图，且没有独立证据
这种情况下保留一个主页面，把其他页面视为历史页面存档。主页面承接该需求，其他页面根据价值决定处理方式：仍有外部链接或少量访问的，可以保留并明确指向主页面；没有独立价值的，做重定向或返回合适状态码。实际动作是先选主页面，再逐条检查其他页面的入站链接和访问来源，把仍有效的链接和流量导向主页面，然后观察这些页面是否还持续产生独立访问。
这个动作的结果会直接影响下一步：如果重定向后主页面开始承接原本分散的访问，说明合并成立；如果某些旧页面仍有稳定访问且访问者行为与主页面不同，就需要重新检查它们是否其实覆盖了另一种意图。
条件二：页面覆盖不同阶段或不同约束
这种情况下不要强行合并。给每个页面明确边界：一个负责通用解释，一个负责特定条件下的操作，页面上互相链接，但各自回答的问题不重叠。实际动作是修改每个页面的标题、开头段落和内部链接，让读者一眼看出当前页面解决的是哪一步，以及下一步该去哪个页面。结果是搜索意图被分流，用户不会在几个相似页面之间反复跳转。
用可区分的原因证据来支持决定
不要凭“哪个业务更重要”来划界。可以收集的证据包括：页面各自承接的查询词是否高度重合；访问者进入页面后是否继续访问同一业务的其他页面；页面是否被其他页面或外部来源当作独立参考引用。若查询词高度重合且访问路径互相替代，支持合并；若查询词分属不同阶段且访问路径互补，支持并存。
这里要区分相关与因果。某个旧页面访问量下降，可能是因为它被合并，也可能是因为季节、外部链接变化或搜索需求本身转移。不能只凭访问量归零就断定处理正确。
一个假设的短例子
假设两个业务都留有“旧系统数据导出”的历史页面：A 页面讲导出前的准备，B 页面讲导出失败后的排查。两者都包含“导出”一词，但用户所处阶段不同。若强行只留一个页面，准备阶段的读者会看到排查内容，排查阶段的读者会看到准备清单，两边都得不到直接答案。此时应保留两个页面，并在 A 页面末尾链接到 B，在 B 页面开头说明前提。若两个页面都只讲“导出是什么”，则保留一个，另一个转为存档或重定向。
实施时的顺序与例外
- 列出所有相关历史页面，记录每个页面回答的问题和下一步动作。
- 按意图重合度分组，每组先选出主页面。
- 对非主页面做链接和访问来源检查，再决定保留、重定向或下线。
- 修改保留页面的开头和内部链接，让边界可见。
- 处理完成后观察一段时间，重点看原本分散的访问是否集中到主页面，以及是否出现新的未覆盖意图。
例外情况是：如果旧页面涉及合规、合同或对外承诺，不能仅因搜索需求重合就删除或重定向，应先确认保留义务，再选择不参与搜索的存档方式。划界的最终目的不是减少页面数量，而是让每个仍然存在的页面都有明确的服务对象和下一步动作。
