采集规则编写，企业并购后两套网站内容如何选择去留
📱 Mozilla/5.0 AppleWebKit/537.36 (KHTML, like Gecko; compatible; ClaudeBot/1.0; +claudebot@anthropic.com)
🔗 /ec2275139b98.html
📄
采集规则编写，企业并购后两套网站内容如何选择去留
并购后两套网站的内容去留，不能按“哪套设计新”或“哪套域名权重高”来定，而应先判断两套内容是否在回答同一批用户问题。如果高度重叠，保留一套并做301与内容合并；如果分别覆盖不同产品线或地区，就保留两套但明确主从关系和内链路径。采集规则编写在这里的作用，是把两套站点的标题、正文、栏目、URL和更新时间整理成可比对的结构化清单，让去留判断有依据，而不是凭感觉删站。
矛盾现象：合并后收录没掉，咨询却变少
常见情况是，并购后把A站内容整站复制到B站，搜索引擎仍能抓到两套页面，但用户从搜索结果进入后找不到原来熟悉的产品说明，于是跳出。这个现象有两种解释：一是两套内容重复，搜索引擎在结果中做了替换；二是两套内容虽然相似，但面向的采购阶段不同，合并后丢掉了其中一段决策信息。
区分这两种解释，可以看搜索结果落地页与用户搜索词是否匹配。如果搜索词指向旧站型号，落地页却跳到新站品牌首页，说明是内容覆盖错位；如果搜索词相同、落地页在两套域名间交替出现，说明是重复内容竞争。前者应补回被删的产品说明，后者才适合合并。
判断去留的第一组依据：内容是否回答同一批问题
把两套站点中排名靠前或带来咨询的页面按主题分组，逐组比较：标题是否指向同一产品、正文是否给出相同参数、页面是否面向同一地区或同一采购阶段。如果一组页面满足其中两项以上相同，就属于重叠内容，适合保留信息更完整的一套，把另一套的独有段落并入后设置301。如果一组页面分别覆盖不同型号、不同语言或不同售后区域，就不应合并，而应保留两套并在导航中互相指向。
这里有一个实际动作：先用采集规则编写把两套站点的页面标题、H1、正文首段和URL整理成对照表，再按主题分组。做完这一步，下一步才是决定哪些URL做301、哪些保留。没有这张对照表就删站，往往会把仍能回答用户问题的页面一起删掉。
判断去留的第二组依据：URL与内链是否还能承接旧流量
旧站URL如果已有外部链接和稳定访问，直接删除会让这些入口失效。此时有两种成立条件不同的做法：
- 保留旧URL并更新内容：适合旧站页面仍在产生咨询、外部链接较多、且新站没有同等主题页面的情况。代价是要同时维护两套模板和导航。
- 301到新站对应页面：适合新旧页面主题一致、新站页面信息更完整、且能保证跳转后用户仍能找到原产品说明的情况。代价是旧站独有内容若未迁移，会随跳转一起消失。
两种做法都成立的前提是：跳转目标页必须与旧页回答同一问题。如果旧页讲的是安装尺寸，新页只讲品牌介绍，301之后用户仍会离开，这时应先在目标页补回安装尺寸，再考虑跳转。
一个假设例子：两种去留方案的比较方法
假设A站有200个产品页，B站有180个产品页，其中120个标题和参数高度相似，60个分别覆盖不同型号。此时可以这样处理：把120个相似页中信息更全的一套保留，另一套的独有段落并入后做301；60个不同型号页保留两套，并在各自导航中增加指向对方型号的链接。这个例子只说明比较方法，不表示任何真实站点的处理结果。
执行后要观察的是：旧URL的访问是否落到相关内容、用户是否继续点击站内下一步、以及新站对应页面是否获得原本属于旧页的入口。如果跳转后访问量归零，不能单独证明合并正确，也可能是跳转目标不匹配、导航缺失或用户需求已经转移。需要结合搜索词和落地页内容再判断。
采集规则编写在去留决策中的边界
采集规则编写负责把两套站点的内容结构提取出来，方便比对和迁移，但它不负责判断哪套内容更值得保留。判断依据仍要回到用户问题、页面完整度和旧URL的承接能力。对于涉及具体品牌、机构或联系方式的页面，迁移前应核对信息是否仍然有效，避免把过期内容带入新站。
最终选择去留时，先确认两套内容是否在回答同一批问题，再确认旧URL是否还有承接价值，最后才决定保留、合并还是跳转。这个顺序能让下一步的301和内容迁移有明确目标，而不是在删除之后才发现丢失了仍被需要的页面。
