外链发布方法：合作方更换域名时怎样核对迁移对应关系
📱 Mozilla/5.0 AppleWebKit/537.36 (KHTML, like Gecko; compatible; ClaudeBot/1.0; +claudebot@anthropic.com)
🔗 /525ed3619f33.html
📄
外链发布方法：合作方更换域名时怎样核对迁移对应关系
合作方换域名后，旧链接能否继续把权重和流量导向新站，取决于迁移对应关系是否被逐条核对过。迁移对应关系指旧站每个被引用的URL与新站目标URL的一一映射，而不是域名首页跳转。常规做法是等对方上线301，再抽查几个旧链接。若抽查后仍出现旧链接打不开、跳到首页或指向无关页面，通常不是301失效，而是对应关系本身不完整。核对的重点应放在“引用清单与映射表逐条比对”这一步，而不是继续增加抽查样本。
矛盾现象：301已上线，旧链接表现却分成两类
同一批旧链接，在对方宣布迁移完成后，可能呈现两种结果：一部分正常跳转到内容相同的新页面，另一部分跳到新域名首页，或返回404、410。这种分裂说明迁移不是整体失败，而是映射覆盖不完整。常见原因是对方只对栏目页和首页做了跳转规则，文章级URL由系统按规则匹配；当旧URL的路径结构、参数或大小写与新站规则不一致时，规则匹配失败，请求就落到首页兜底或直接报错。
还有一种可能是旧域名本身并未全部保留解析。部分子域、带www与不带www的版本、http与https版本，可能只有其中一个做了跳转。你抽查时命中的恰好是已处理的那一类，就会误以为迁移完成。
两种解释：映射缺失，还是引用清单本身过期
第一种解释是对方的映射表缺失。对方可能只迁移了站内可发现的URL，而你手上的引用清单里包含更早发布、后来被对方删除或合并的页面。这类旧URL在新站没有等价内容，对方选择不设跳转，请求便落到404或首页。
第二种解释是你的引用清单过期。合作期间对方可能改过URL结构，你记录的是更早版本；或者你记录的链接来自转载页、镜像页，并非对方当前正式页面。此时对方的新映射表是对的，问题出在你拿旧清单去比对。
两种解释的后果不同：前者需要对方补映射，后者需要你先更新清单再谈迁移。区分不清就催对方补跳转，可能把不存在的页面也要求设跳转，反而制造软404。
能区分两种解释的证据：状态码与目标页内容是否对应
把引用清单里的旧URL逐条请求一次，记录三项：最终状态码、最终落地URL、落地页标题与正文主题。然后按下面规则判断：
- 旧URL返回301或302，落地URL与旧页面主题一致，只是域名和路径变了——映射正常，无需处理。
- 旧URL返回301但落地到新域名首页或栏目页——映射缺失，属于对方需要补规则的部分。
- 旧URL返回404或410——先确认该页面在迁移前是否仍可访问；若迁移前已失效，问题在清单过期，不在迁移。
- 旧URL返回200但内容与旧页面无关——可能是新站占用了同一路径，属于路径冲突，需要对方决定保留哪一方。
假设你清单里有20条旧链接，逐条请求后发现12条正常、5条落到首页、3条404。此时不应笼统要求“把迁移做好”，而应把5条落到首页的URL单独列出，注明旧路径与新站对应内容，请对方补精确跳转；3条404则先回查迁移前存档，确认是否早已失效。这个动作的结果直接决定下一步：前者是对方的技术修复，后者是你自己更新引用记录。
核对映射时容易遗漏的一个条件：带参数与尾斜杠的变体
很多引用链接带有跟踪参数、分页参数或结尾斜杠差异。对方配置跳转规则时，往往只匹配干净路径，带参数的请求不进入规则，直接落到首页或报错。核对时要把同一路径的常见变体各请求一次，例如带?from=参数、带/结尾、大小写不同的版本。若干净路径正常而变体异常，说明问题在规则匹配范围，而不是映射表内容。
这个条件容易被忽略，因为抽查时通常直接复制浏览器地址栏的干净URL。变体异常不会影响所有引用，但会影响从旧文、邮件、社交平台历史帖子里点进来的访问，属于迁移对应关系的一部分。
核对完成后怎样把结论交给对方
把逐条核对结果整理成一张对应表，字段包括：旧URL、请求后最终状态码、最终落地URL、期望的新URL、备注。只把需要对方处理的条目发过去，并说明每条的期望结果。对方拿到具体路径后，通常能直接补规则或确认该页面已废弃。你这边则根据回复更新自己的引用清单：能修复的保留，确认废弃的从清单中移除或替换为新页面链接。这样一轮核对后，引用清单与对方新站的对应关系才是可用的，而不是停留在“已迁移”的口头确认上。
