什么是友情链接：合作方更换域名时怎样核对迁移对应关系
📱 Mozilla/5.0 AppleWebKit/537.36 (KHTML, like Gecko; compatible; ClaudeBot/1.0; +claudebot@anthropic.com)
🔗 /aa616eebe8d3.html
📄
什么是友情链接：合作方更换域名时怎样核对迁移对应关系
友情链接是两个站点之间互相放置的可见链接，通常用于互相导流和增加外部引用。当合作方更换域名时，核对迁移对应关系的核心动作是：拿到对方新旧域名的完整对照清单，逐条验证旧链接是否真的指向新域名下的对应页面，而不是只确认新首页能打开。如果只核对首页，个别样本会成立，但规模化后大量旧链接会指向新站首页或失效路径，形成例外。
矛盾现象：首页通了，旧链接却大面积对不上
假设一个场景：合作方从旧域名迁移到新域名，对方通知你“已经全部迁移”。你抽查首页，新域名正常返回，旧域名也做了跳转，看起来没问题。但当你有几十条友情链接分布在文章内页、栏目页和友情链接专区时，情况会分化：部分旧链接跳转到新域名对应内容，部分跳到新站首页，部分直接 404，还有部分仍停留在旧域名不跳转。
这种分化说明迁移不是单一动作，而是“域名层跳转”和“页面层映射”两件事。域名层通了，不代表页面层映射完整。个别样本成立，往往是因为你抽到的恰好是被重点处理过的页面。
两种解释：全局跳转规则与逐页映射清单
第一种解释是对方配置了全局跳转规则，把旧域名的所有请求统一指向新域名首页。这种做法实现成本低，能避免旧域名完全失效，但代价是内页权重和用户路径被压缩到首页，旧内页链接不再对应原内容。
第二种解释是对方做了逐页映射，为每个旧路径指定了新路径。这种做法的对应关系更完整，但依赖一份准确的对照清单，且容易在动态参数、大小写、末尾斜杠、中文路径编码等细节上出现漏配。
两种解释可能同时存在于同一个迁移项目中：核心页面逐页映射，长尾页面走全局规则。所以你不能用“大部分能打开”推断“全部对应正确”。
能区分两种解释的证据
要区分是全局跳转还是逐页映射，可以看三类证据：
- 跳转目标是否随旧路径变化。如果不同旧内页都跳到同一个新首页，说明是全局规则；如果不同旧内页分别跳到不同的新内页，说明存在逐页映射。
- 旧路径与新路径的对应是否可解释。逐页映射通常能给出“旧栏目 A → 新栏目 A”的规则；全局跳转则给不出这种规则。
- 失败样本的分布。逐页映射的失败往往集中在少数特殊路径；全局跳转的“失败”表现为大量内页无法到达原内容，但首页始终可用。
实际动作建议：从友情链接清单中按类型分层抽样，内页链接、栏目链接、首页链接各取若干，记录旧地址、期望的新地址、实际返回状态和最终落点。如果抽样结果显示落点与期望地址不一致的比例超过你能接受的范围，下一步就不是继续抽查，而是要求对方提供完整的路径对照表，再按表复核。
核对迁移对应关系的操作顺序
第一步，确认合作方迁移的范围。是只换主域名，还是同时调整了目录结构、URL 命名规则和内容归档方式。范围不同，核对重点不同。
第二步，索要新旧路径对照清单。清单至少包含旧地址、新地址、页面类型和迁移方式。没有清单时，只能按抽样结果反推，无法规模化核对。
第三步，按友情链接的实际位置逐条测试。测试时记录最终返回状态和最终落点，不要只看是否发生跳转。跳转后落到无关页面，对友情链接来说同样属于对应关系断裂。
第四步，对无法对应的链接做取舍。可以更新为新地址、暂时保留并观察、或从友情链接区域移除。取舍依据是这条链接是否仍能带来相关访问，以及对方是否愿意继续维护对应关系。
第五步，把核对结果反馈给对方，并约定后续新增或调整链接时的通知方式。迁移是一次性事件，但链接维护是持续动作，没有通知机制，下一次改版还会重复同样的问题。
不能直接照搬的边界
上述方法适用于你能拿到路径清单、且对方愿意配合核对的合作场景。如果对方只提供新域名首页，不提供任何路径信息，你无法完成逐条对应，只能按实际落点决定保留或移除。如果友情链接数量很少，逐条人工核对成本可控；数量很大时，需要先按页面类型分层，否则容易在长尾链接上耗尽精力。
另外，旧链接跳转到新域名对应页面，不等于该页面仍然适合作为友情链接目标。页面内容可能已经改版、合并或不再更新。对应关系核对解决的是“链接是否指向预期位置”，不解决“这个位置是否还值得链接”。这两件事需要分开判断。
把迁移核对做成一次性的清单核对，并留下可复用的对照记录，比在每次改版后重新猜测对应关系更省成本。核对完成后，下一步应更新你自己的友情链接页面，并确认对方新页面上的链接是否也同步指向了你的当前地址。
