密度控制，并购后两套网站内容谁留谁删怎么定
📱 Mozilla/5.0 AppleWebKit/537.36 (KHTML, like Gecko; compatible; ClaudeBot/1.0; +claudebot@anthropic.com)
🔗 /2e52aa0f9b9e.html
📄
密度控制，并购后两套网站内容谁留谁删怎么定
没有完整流量数据、也拿不到双方后台权限时，不要先决定“留哪套网站”，而是先决定“留哪一批页面”。把两套站点的URL清单合并，逐条按同一业务意图归类，重复意图只保留一个主页面，其余进入待迁移或待下线名单。这个动作不依赖后台数据，只需要站点地图、公开页面和业务方口述，就能产出一份可执行的处理方案。它不能证明保留下来的页面一定会被收录或获得排名，只能减少同一意图下多个页面互相竞争、以及用户在不同站点看到不一致信息的情况。
先合并URL清单，而不是先比较两个网站
并购后常见的误区是拿两个域名整体对比：哪个权重高、哪个设计新、哪个品牌更强势。这些判断都需要数据支撑，而现实中往往只有一方有后台，或者交接期两边都拿不到完整权限。此时可执行的最小动作是：从两套站点的公开入口出发，收集能访问到的URL，整理成一张表，字段至少包括URL、页面标题、页面主题、对应的业务意图、所属站点。数据不全没关系，能覆盖主要栏目和主要产品页即可。
这张表的作用不是评估网站优劣，而是暴露重复。两个站点在并购前各自服务过同一批业务意图，重复几乎是必然的。把重复找出来，去留问题就从“两套网站”缩小到“几十组同意图页面”，决策难度会明显下降。
按业务意图分组，一组只留一个主页面
分组标准用业务意图，不用页面形式。判断方法可以看三个信号：页面回答的是不是同一个用户问题；页面服务的是不是同一类客户或同一采购阶段；页面上的核心信息（产品规格、服务范围、资质说明）是否指向同一件事。三个信号里有两个一致，就归为同一组。
每组只设一个主页面。选择依据按可核实程度排序：
- 内容更完整、更新更近、事实更准确的一方优先；
- 品牌主体在并购后继续使用的名称、资质、联系方式所在的一方优先；
- 两个条件接近时，选结构更清晰、内链更完整、更容易继续维护的一方。
这里要说明一个容易误判的现象：某一方页面访问量归零，不能单独证明它该被删除。访问量下降还可能来自统计口径变化、跟踪代码在迁移中失效、入口链接被改、抓取与索引环节出现波动。它说明的是“需要进一步核实”，不是“处理正确”。在没有后台权限的阶段，不要用这类现象当决策依据。
用一个假设例子走完判断流程
假设A站和B站各有一个“工业阀门选型”页面，标题不同但都在讲同一类产品的选型参数。A站页面参数表更全，但联系方式是并购前的旧主体；B站页面参数较少，但主体信息与并购后一致。按上面的排序，先看内容完整度会倾向A，再看主体一致性会倾向B，条件接近时看可维护性。
如果最终选择B作为主页面，动作是：把A页面中独有的参数表补充进B，确认B的主体信息准确，然后把A页面处理为跳转到B或下线，并同步检查两站内部指向A页面的链接，改为指向B。做完这一步，下一步才是检查B是否被正常抓取和索引。顺序不能反：先合并重复意图，再观察抓取与索引，否则观察对象本身就是混乱的，结论没有意义。
没有权限时，哪些动作能做，哪些结论不能下
可执行的动作：整理URL清单、按意图分组、标注每组的主页面候选、记录需要补充的信息、列出待处理的跳转关系。这些都可以基于公开页面和业务方确认完成，产出物是一份处理方案，而不是最终执行结果。
不能下的结论：不能断定某个页面会被收录、能获得排名、能带来咨询；不能断定删除某页面后另一页面必然承接原有流量；不能因为某方站点看起来更旧就整体废弃。抓取、索引、排名是不同环节，公开页面只能支持“意图是否重复”的判断，支持不了对后续环节的预测。
当权限补齐后，再按同一张表补充实际数据，用来验证或修正之前的分组，而不是推翻重来。这样处理的顺序是：先定意图归属，再定页面去留，最后才用数据检验，而不是让缺失的数据卡住整个决策。
