整站：企业并购后两套网站内容如何选择去留
📱 Mozilla/5.0 AppleWebKit/537.36 (KHTML, like Gecko; compatible; ClaudeBot/1.0; +claudebot@anthropic.com)
🔗 /01e4347e6f5a.html
📄
整站：企业并购后两套网站内容如何选择去留
并购后两套网站的内容去留，不能按“哪套更旧”或“哪套页面更多”来定，而要先判断哪些页面承担了可迁移的用户任务。一个可执行的做法是：把两套站点里同类页面配对，逐对决定保留哪一版、合并成哪一版，或者直接下线；对无法配对的长尾页面单独评估。这样处理的结果会直接决定后续是继续补内容，还是先做重定向与内链收口。
先做页面配对，而不是先决定保哪套站
并购后内容去留最常见的误判，是把问题当成“A站留还是B站留”。实际上两套站往往各有部分页面值得保留：A站可能在某些产品词下内容更完整，B站可能在服务流程说明上更清楚。真正需要决策的单位是同类页面配对，而不是整个站点。
具体动作：从两套站各导出主要页面清单，按页面承担的任务分组，例如产品介绍、价格与方案、服务流程、常见问题、公司介绍、案例或应用场景。每组里把内容目标相近的页面配成对。配对完成后，每一对只做三种选择之一：保留A版、保留B版、合并后重写一版。无法配对的页面进入单独评估清单。
这一步的结果会影响下一步：如果大量页面能顺利配对，说明两套站内容重叠度高，工作重心应放在合并与重定向；如果配对率很低，说明两套站各自覆盖了不同任务，贸然下线会丢掉用户需求，此时应先补全覆盖，而不是急着关站。
用三个可核对的证据判断哪一版值得留
配对之后，判断保留哪一版需要证据，而不是偏好。以下三项在多数情况下可以核对：
- 内容是否完整回答该页面的任务。例如同一产品页，一版只有参数罗列，另一版还说明了适用条件、选型差异和常见误用。后者更可能被保留，但前提是这些说明确实对应该产品。
- 页面是否被其他页面正常引用。检查站内链接：如果某页是多个页面的跳转目标或说明入口，下线它需要同时处理这些链接，否则会把用户和抓取引向死路。
- 该页是否有外部链接或长期访问记录。这里要谨慎：访问量归零可能有多种解释，比如统计代码缺失、入口被移走、季节性波动，不能单独作为“可以删除”的证明。同理，抓取量下降也不等于页面没有价值。
把三个证据放在一起，通常能区分出两类页面：一类是内容弱、无内链支撑、也无外部引用，可以优先下线；另一类是内容尚可但入口混乱，应该先修内链和导航，再决定去留。
合并页面时，别把两版内容直接拼在一起
合并是并购后最常见的动作，也是最容易做坏的动作。把A版和B版段落依次堆到同一页，会造成重复表述、前后矛盾，用户读不出重点，搜索引擎也难以判断页面主题。
更稳的做法是：先确定这一对页面的唯一任务，再按任务重写结构。假设两套站各有一个“售后维修说明”页面，A版按故障类型组织，B版按产品型号组织。如果用户更常按型号查找，就以型号为主线，把A版的故障分类作为每类型号下的补充。这个例子是假设的，用于说明合并时应先定主线，而不是平均保留两边结构。
合并完成后必须做两件事：把被合并页面的旧地址指向新页面，并更新所有指向旧页面的站内链接。只做重定向、不改内链，会让用户多点一次跳转，也会让后续维护继续围绕旧地址展开。改完内链后，下一步才是检查新页面是否能独立回答该任务，而不是继续添加补充段落。
哪些页面不能照搬“保留更全的一版”
“保留内容更全的一版”在多数产品和服务页上成立，但有几类页面不能直接套用：
- 法律、隐私、条款类页面。这类页面以主体和适用法域为准，不按内容丰富度选择。并购后主体变化，应以新主体的合规文本为准，旧版本通常只能作为参考。
- 带时效承诺的页面。例如交付周期、服务范围、资质说明，旧版即使写得更详细，也可能已经不再适用。保留前要先确认现行口径。
- 公司介绍与团队页。两套站的历史叙述可能都成立，但并购后对外应只有一套主体表述，不宜两版并存。
- 纯流量型聚合页。如果某页只是罗列链接、没有独立任务，合并时优先考虑去掉，而不是保留。
这些例外说明：内容去留的判断标准不是“哪版更好”，而是“哪版仍然对应当前主体和当前用户任务”。当样本只覆盖少数页面时，结论往往看起来干净；一旦扩展到全站，例外就会集中出现在上述类别里。
把决定落成一张可执行清单
完成配对和判断后，把每个页面的处理写成明确动作，而不是“待定”。建议至少包含四列：旧地址、处理方式（保留、合并、下线）、目标地址、需要同步修改的内链位置。处理方式只允许这三种，避免出现“先放着”的中间状态。
执行顺序上，先处理有内链指向的页面，再处理孤立页面。原因是前者的改动会影响其他页面的可用性，先做可以避免重复返工。每完成一组，就检查一次：旧地址是否可达新内容、站内是否还有指向旧地址的链接、新页面是否覆盖了原来两版的任务。检查通过后再进入下一组，而不是全站改完再统一验证。
如果执行中发现某组页面反复无法决定，通常说明这一组对应的用户任务本身还没理清。此时应暂停该组，回到业务侧确认这项任务由谁承担、面向哪类用户，再回到页面层面做取舍。这个停顿不是拖延，而是避免把错误判断扩散到整站。
