手动外链建设：合作方更换域名时怎样核对迁移对应关系
📱 Mozilla/5.0 AppleWebKit/537.36 (KHTML, like Gecko; compatible; ClaudeBot/1.0; +claudebot@anthropic.com)
🔗 /93479498ad65.html
📄
手动外链建设：合作方更换域名时怎样核对迁移对应关系
先给结论：对方换域名后，不要从新站首页开始逐页找旧链接，而要先拿到一份“旧URL→新URL”的对应表，再按旧URL逐条验证。因为迁移后出现排名或抓取波动，最常见的原因不是链接被删，而是对应关系没有完整传递。下面用一个假设情境串起核对流程。
假设情境：旧域名整体换成新域名，旧链接全部跳首页
假设你曾与某合作方互换内容页链接，对方把整站从旧域名迁到新域名。你打开旧页面地址，发现它跳到新域名首页，而不是原来那篇文章。直觉上你会认为“链接还在，只是换了地址”；但更可能的解释是：对方只做了全站兜底跳转，没有逐条映射。此时你手上的旧链接虽然能打开，传递的却是首页地址，与原来约定的内容页不对应。
这个现象的反常之处在于：用工具检查旧链接，返回状态可能是跳转而非失效，看起来“没丢”；但从对应关系看，它已经偏离了合作时的目标页面。因此不能只看“链接是否可访问”，要核对“旧URL最终落在哪个新URL”。
第一步：先确认迁移范围，再决定核对粒度
向合作方要三样信息：迁移是否覆盖全站、是否保留旧域名、是否提供对应表。如果只是个别栏目换域名，核对粒度可以按栏目；如果是整站换域名，必须按旧URL逐条核对。缺少对应表时，不要凭新站导航猜，因为栏目改版后路径往往不再一一对应。
一个实际动作是：把合作时记录过的旧URL整理成清单，逐条访问并记录最终落地地址。结果分三类——落到同一内容的新地址、落到栏目页或首页、返回失效。第一类可以进入下一步验证；第二类和第三类都需要先向对方索取映射说明，而不是直接补新链接。
第二步：用三类证据区分“已迁移”和“只跳首页”
只凭一次访问容易误判，建议同时看三类可核对证据：
- 最终地址：旧URL跳转后，地址栏和页面标题是否指向同一主题，而不是首页或无关栏目。
- 页面自指：新页面上的规范地址是否为新域名下的该页地址；如果仍写旧域名，说明迁移未完成。
- 站内入口：从新站导航或站内搜索能否找到该内容；找不到时，跳转可能只是临时兜底。
这三类证据指向不同解释：最终地址正确但规范地址仍是旧域名，属于技术收尾未完成；最终地址是首页且站内也找不到，属于内容未迁移或已合并。两种情况的处理动作不同，前者等对方修正，后者需要重新协商对应页面。
第三步：按对应关系更新链接，而不是按新域名重发
确认新URL后，更新你这边指向对方的链接。这里有一个取舍：如果旧URL仍能稳定跳转到正确新页，可以暂时保留旧地址，减少改动；如果旧域名即将停用或跳转不稳定，应改为新URL。判断依据是对方是否承诺保留旧域名跳转，以及你能否持续验证跳转目标。
更新后要做的验证不是“链接能打开”就结束，而是再次确认：新链接指向的页面主题、页面上的规范地址、以及你页面上的锚文本是否仍与内容相关。若锚文本还描述旧主题，而新页面已合并到别的栏目，就需要同步调整文字，否则对应关系只是地址对了，语义仍错位。
第四步：把核对结果写回合作记录，决定下一步
把每条旧URL、最终新URL、验证日期和异常类型记在同一份表里。若多数旧链接只跳首页，说明对方迁移映射不完整，下一步应要求其提供逐条对应表，而不是自己逐页猜；若只有少数失效，可以就这几条单独确认是否保留、合并或删除。这个动作直接影响后续判断：映射完整时，你只需更新地址；映射缺失时，继续补链接可能把首页地址重复指向多个位置，反而让对应关系更乱。
假设你核对十条旧链接，其中六条落到正确新页、三条落到首页、一条失效。合理的下一步不是把十条全部改指新首页，而是先处理三条和一条的映射，再统一更新六条。这样做的结果是，你手上的链接清单与对方新站结构保持一致，后续复查时也能快速区分是对方再次改版，还是你这边记录过期。
最后提醒一点：迁移后的抓取或点击波动不能单独证明对应关系已经处理好，也可能来自对方站点结构调整、页面合并或你自身页面改版。把对应表、最终地址和页面自指三项证据放在一起看，才能判断该继续等待、要求修正，还是重新协商链接位置。
