hreflang互指对不上，多半是另一边先改的

摘要：从73个多语言站的首页抓出2529条语言版本声明，再顺着这些声明实抓258个目标页，逐个检查对面有没有把你列回来。240个能打开的目标页里，211个两侧集群完全一致，站级口径下14个站（19.2%）至少有一个成员对不上。更值得看的是另外两个数：同一个地址在两侧被标成不同语言代码的比例高达19.8%，绝大多数集中在谁该当默认版本这一件事上；18条打不开的目标里换个浏览器身份重抓，7条立刻变成正常。文中给出跨域集群的规模、跳转造成的错位与按责任方划分的修复顺序。

八月十九日有一组数据在圈子里传得挺快：某个大型论坛站在某AI搜索里的引用份额，从3.83%掉到0.52%，跌了86.4%。有人把原因归到八月八日那次检索方式变更上，但仔细对一下时间线这个解释并不成立——变更发生在八日，份额是十四日之后才塌下去的。

这件事里最让人不舒服的不是掉了多少，而是掉的原因在别人家里，而对方没有义务告诉你。你能做的只有事后拿数据反推，还未必推得对。

网站上有一类声明天生就是这个处境：它的正确性不取决于你自己写得对不对，取决于另一个页面怎么写。那个页面可能归另一个国家的团队，可能归一家代理商，甚至可能压根不是你公司的资产。

语言版本声明就是最典型的一个。保哥把这批多语言站的首页拉下来，顺着它们声明的每一条链路往对面走，看看对面认不认这门亲戚。

你写的那一半对了，另一半算数吗？

先把规矩说清楚。这套声明的核心要求不是你指对了人，而是同一组语言版本里的每一个页面，都必须列出完全相同的一整套地址，并且要把自己也列进去。

真正难的其实不在这套标签，实操里对不上的五大根因往上追了一层。

落地时最容易栽的几处，回指对称与默认版本的实操避坑说得比较具体。

这套机制的全貌先过一遍，多语言站的国际化SEO避坑清单把该有的都列了。

它是少数几个必须双向成立的声明

网页上大多数声明是单向的：你写规范网址，你写索引指令，你写修改时间，写完就生效，跟别的页面没关系。

被指的那些地址在索引里是什么身份，搜索引擎只把它们当规范页的别名这一点常被误解。

生成器给的代码往往只做了一半，粘上去就是一份单向标注是常见的坑。

语言版本声明不一样。你在中文页上写英文版在那儿，英文页上必须也写中文版在这儿。少了任何一边，搜索引擎都不会把这两个页面认成一组——它没法确认这门亲戚是不是你单方面攀的。

这个设计有它的道理：如果单向就算数，任何人都可以在自己站上声明你是他的某语言版本，然后蹭走一部分流量。双向要求把这条路堵死了，代价是维护成本翻倍。

翻倍还只是最好的情况

实际成本远不止翻倍。一个站有12个语言版本，那就是12个页面每个都要列出完整的12条。新加一门语言，要改的不是1个页面，是13个。

一个模板生成十份内容有它的代价，字符层看不出重复、信息层十份一模一样是它的另一面。

语言一多就得上产线，从翻译外包到原生再创作的工程体系给了完整分层。

如果这12个版本跑在同一套模板上，改起来还算容易；如果它们分属不同的市场团队、不同的建站系统、甚至不同的域名，这件事就变成了一次跨组织协作。

算一笔账：一个成员掉队，损失面有多大

把这件事量化一下会更有体感。假设一个站有8个语言版本，每个版本有5000个页面，也就是4万个页面组成8000组关系。

出问题时先分清卡在哪一层，收录、排名、流量是三件事能省掉一半无用功。

声明的数量和真实页面的数量常常对不上，236条地区声明背后只有6个真页面是同一批站上的实测。

现在其中一个语言版本的模板漏了自指。后果不是那5000个页面出问题，而是全部8000组关系里，每一组都少了一个成员——剩下7个版本之间的关系仍然成立，但它们跟那一个版本之间的定向全部作废。

换个更糟的情形：漏的不是自指，而是那个版本的模板压根没输出这套声明。这时候它自己的5000个页面完全脱离集群，其他7个版本指着它的那8000条声明也全部变成单向，等于白写。

这就是为什么这件事值得单独查一遍：一个模板文件里的一行，能一次性废掉整个站的语言定向。而它出错时页面照常打开，任何常规监控都不会响。

这次怎么查的

做法分三步。第一步，从73个站的首页里把所有语言版本声明抽出来，一共2529条。第二步，每个站挑4条目标地址，实际抓一遍，一共258个页面。第三步，解析目标页自己的声明，跟源页那一套做集合比对。

抓下来的东西可能被截断，抓取体积上限怎么实测是先要排除的干扰项。

判断跨不跨域要先把根域名提出来，把一堆地址批量提成去重根域名是这一步的做法。

批量取地址有现成办法，六种格式的解析与地址批量提取可以省掉自己写解析器。

比对的判据严格按规范来：两侧列出的地址集合应该完全相同，且各自都包含自己。差一条就算对不上。

这次没算进去的几件事

三类情况被排除在外。

写进清单文件那种表达方式有人做过，用脚本从爬虫结果自动生成是可行的一条路。

逐条查一百天不如按模板抽样半天，按页面模板抽样的审计做法更适合大站。

一是只在首页上做的抽查。一个站的语言关系是逐页成立的，首页对得上不代表商品页也对得上；反过来也一样。所以文中的站级出错率是下限，真实情况只会更高。

二是写在清单文件里的那种表达方式。规范允许把同样的关系写进站点地图，这次只解析了页面上的写法。有些站两种都用，也有些站只用后一种——后者在本文的口径里会被记成没写，这一点要打个折扣看。

三是响应头里的写法。它同样合法，但实际使用极少，这批样本里一条都没遇到。

73个站的集群到底有多大、跨得有多远？

先看静态的那一面，也就是这些站自己写了些什么。

权重怎么在这些结构之间传，子域名还是子目录的六维实战有对照数据。

域名结构是这件事的地基，国别域、子目录还是子域名怎么选决定了后面所有的维护成本。

规模：中位数15条，最大259条

73个站一共写了2529条声明，每站中位数15条，最大的一个站写了259条。写得多的几个站分别是259、236、202、190、116、112、110条。

语言一多，维护面就会以另一种形式暴露，208个版本里曾经翻满的四成已掉队是同一种衰减。

大型电商系统上这件事更复杂，分层导航与语言标签的九个核心点是平台侧的做法。

同一种语言卖到多个国家最容易撑大集群，同语言多地区站怎么不自己跟自己打架单独拆过。

259条意味着什么？意味着这个站有两百多个语言地区组合，而每一个组合对应的页面上，都得原样再写一遍这259条。整个集群的维护面是259乘259。

默认版本：87.7%的站声明了

这套声明里有一个特殊值，用来指定当用户的语言不在你的列表里时该去哪儿。73个站里64个写了它，占87.7%。

兜底页的选择也会影响AI检索，翻译内容为什么在AI检索里吃亏值得一并考虑。

兜底没做好，流量会被别的东西接走，自动翻译结果正在抢走你的国际流量是其中一种。

兜底这件事很多站是靠自动跳转做的，按地址自动跳转让半数页面进不了索引是那条路的代价。

这个覆盖率算高的。但后面会看到，恰恰是这个特殊值成了两侧最容易吵架的地方。

条数最少的那批站，未必是做得差

73个站的中位数是15条，但分布很偏：有一批站只写了两三条。

每加一门语言都要重做一轮词，跨文化语义与本地化变体的完整流程是那笔成本的大头。

加不加一个市场要先算清楚，七步决策与十二周落地把该考虑的都摆出来了。

看下去会发现这批站多数是双语站——英语加一门本地语言，或者英语加中文。它们的集群小，维护面自然也小，出错的机会跟着变少。

这一点值得给正在扩语言的团队提个醒：每加一门语言，维护面不是线性增长而是平方增长。三门语言是9条关系，十门语言就是100条。决定加不加一个市场时，这笔维护成本很少被算进去，而它是要一直付的。

跨域：277条指向别人的域名

2529条里有277条指向的不是本站的域名，占11.0%，涉及21个站，一共124个不同的外部主机。

国别域名不好拿的时候只能凑合，带连字符的域名到底伤不伤SEO那篇给了官方口径。

多个域名要不要合并是个老问题，域名整合的决策框架与跳转实操有取舍分析。

形态分几种。最常见的是国别域名矩阵：主站在通用域上，各个市场用各自国家的域名，比如同一个鞋类品牌指向新西兰、澳大利亚、英国、韩国、科威特五个国别域。

其次是中国单独一套：有的品牌把中国站放在另一个域名下，从主站指过去。样本里有几个都是这个形态。

最有意思的一条跨到了别的公司

那个鞋类品牌的日语版本，指向的域名既不是它的主域，也不是它的国别域，而是一家日本本地公司的域名——那是它在日本市场的经营方。

把口头约定写成文字永远划算，达标定义、违约责任与四类经典纠纷可以拿来改。

跟外部方合作的边界要提前谈清楚，从选人、谈合作到衡量效果的完整框架是另一个场景的同一道理。

这一条把本文的主题摊得非常清楚：这个页面上的声明能不能长期成立，取决于另一家公司的网站怎么改。他们换个建站系统、调一次地址结构、或者干脆终止合作，你这边不会收到任何通知。

顺手说一句：跨域这件事本身没错

容易把跨域读成不规范，其实规范里明确允许。真实世界的多语言站有大量正当理由要用不同域名——商标在某些国家归别人所有，某些市场必须用本地域名才有信任度，某些国家的支付通道只认本地主体。

中国站那一套基建跟海外不是一回事，备案、速度与合规怎么权衡是绕不开的功课。

进入一个市场要办的手续不止建站，商品条码怎么申请、跟收录有什么关系是很实在的一环。

真正决定难度的不是域名，是那一头归谁管。同一个团队维护五个国别域，改起来跟改一个站没区别；不同公司各管一头，哪怕只有两个域也很难同步。看域名判断风险会看错，要看的是组织边界。

语言代码本身写错的不多

顺手也查了代码写法。明显不合规的只有七条：把国家码当语言码用的两条，把语言写成不存在的两字母的一条，还有几条把语言和地区写反或者重复。

地区变体这件事在有些语言里格外要紧，西班牙语的地区差别到了AI问答只剩一个词是个好例子。

机器判断一个页面是什么语言并不总是对，字最少的那几类页面最容易被认成别的语言是一次实测。

中文的繁简本身就是一层，台湾香港用语本地化与那个会转错的词说的是同一类细节。

这里要坦白一个自己的口径问题：第一版校验把中文的繁简写法判成了不合规，因为我的规则只认两位国家码，没考虑到语言标签规范里语言与地区之间还能插一层文字子标签。这类误报的成因是校验规则比规范本身更窄，属于写检查脚本时最常见的一种错。修正之后，真正的代码错误就剩那七条。

抓到的240个目标页里，有多少真的把你列了进去？

这是本文的核心实验。258个目标地址实抓下来，240个正常打开，逐个解析它们自己的声明再跟源头比对。

抓下来的东西有没有内容也得确认，132个独立站首页有28个是空壳量的是同一种落差。

抓到的页面跟用户看到的可能不是同一个，爬虫和用户看到的页面不一样怎么揪出来是先要排除的干扰。

两侧完全一致的有87.9%，对不上的12.1%

240个目标页里，6个页面一条语言版本声明都没有，占2.5%。剩下234个有声明的，211个（90.2%）的集合与源页完全相同。以240为分母算，完全一致的是87.9%。

判断两个东西是不是一回事有通用做法，87个站的清单先替你答了一半是同一种取数思路。

用别人的工具前先校准口径，六步校准法能挡掉大部分噪声。

做比对最怕基线没定好，补上对照组之后差异从七成掉到两个点就是一次返工。

集合重合度的分布是这样的：

重合度中位数是100%，四分之一分位也是100%。最低的一个只有1.2%——那意味着两侧几乎在说两件不相干的事。

自指：95.0%的目标页把自己列了进去

规范要求每个成员都要包含自己。240个目标页里228个做到了，占95.0%。剩下12个漏了自己，涉及少数几个站。

声明写在哪儿也会决定它算不算数，工具说在头部、浏览器说在正文该信哪一边是另一种边界问题。

声明与实际判定不一致是常态，规范网址选择的九条决策逻辑解释了它凭什么不听你的。

自指这件事在另一套声明里同样关键，规范网址的九大决策与完整设置可以对照着理解。

漏掉自指的后果比想象中大：搜索引擎会认为这个页面不属于任何一组，于是它跟其他语言版本之间的关系全部作废，哪怕别人都指着它。

站级看，五分之一的站有问题

把页面级结果收到站级：73个站里14个至少有一个成员对不上，占19.2%。

资深团队反而更容易栽在结构性问题上，被忽略的那几类技术SEO失灵原因说的就是这种局面。

整站体检该查什么有现成框架，从抓取、内容到AI可见度的完整诊断清单可以照着排。

这个口径比页面级更有意义。原因是一组语言版本是共同体，只要其中一个页面掉队，那一整组的关系在搜索引擎那边就不完整。页面级的87.9%听着还行，翻译成站级就是每五个做多语言的站里有一个，某些页面上的语言关系根本没生效。

出问题的站各有各的形态

多语言站的问题往往不止标签这一层，省下的那道审校最后拿收录和排名分期还是另一笔账。

多语言加多货币是双重复杂度，语言标签、地址与价格标记的三层避坑得一起考虑。

小语种站的落地步骤单独说过，从插件选型到内容本地化的四步适合先搭骨架。

最整齐的一个例子是某家居品牌：抓到的4个目标页全部一条声明都没有。这不是漏写，更像是那几个国家的站点由完全独立的系统在跑，压根不知道主站在指着它们。

那6个没有任何声明的页面，值得单独想一想

集群对不上还算有救——两边都参与了这套机制，只是内容有出入。目标页一条声明都没有是另一种情况：对面根本没上这条船。

同一份资料翻十遍是另一种做一半，十种语言里十份口径一致的资料其实是同一篇值得警惕。

换系统时这类配置最容易整块丢掉，清单、重定向与规范网址集体失分是常见的第一课。

各市场站用不同系统是常态，跨四种建站系统共有的12项隐性失分可以逐条对照。

这6个页面里4个来自同一个家居零售巨头，剩下两个分别来自一个服装品牌和一个小站。前者的形态最值得注意：主站的清单里认认真真列了几十个国家，而被列进去的那几个国家站，页面上干干净净什么都没有。

合理的推测是这些市场站建站更早、或者由本地团队独立采购的系统，从来没有接入过总部这套国际化配置。主站那边加清单时只需要在自己的模板里填地址，不需要对面配合，所以这件事可以做完一半就上线。

这也解释了为什么这类问题能长期存在：做一半也能上线，而上线之后没有任何东西会告诉你另一半没做。

非200的那18条，有几条是真的坏了？

258个目标里有18条没能正常打开。这个数字不能直接当失败率用，必须先做一步。

状态码要会读才不会误判，几个常用状态码各自该在什么场合用有一张速查表。

要弄清对面怎么看你再谈待遇，120种爬虫标识的分类与真假验证是一份可以照做的清单。

为什么要换个身份再抓一遍

跨站抓取有一条铁规矩：一次失败可能说的是这个地址坏了，也可能说的是这台机器不受欢迎。这两件事的处置方式完全不同，混在一起报会得出错误的结论。

拦与不拦要分层做，三层选型框架比只改一个文件靠得住。

模拟不同身份去测站有现成办法，用生成的标识去试探自己的站能复现大部分差别待遇。

拦截往往发生在你看不见的那一层，防火墙到底拦不拦得住那些程序答案没那么简单。

所以那18条全部换成普通浏览器身份重抓了一次。

7条立刻变成正常

结果是18条里7条换个身份就打开了，占38.9%。其中某个家电品牌的3个欧洲语言页面，某个户外品牌的4个欧洲页面，全部属于这一类。

爬虫拿到的可能压根不是页面，人机验证屏被当成正文索引是最难查的一种。

限速和拦截规则最容易误伤，怎么拦住不该来的又不误伤该来的有具体配置。

写了放行也未必等于对方进得来，说允许、仍有十个站把对方挡在门外是另一层错位。

还有1条反过来，原本返回拒绝的换了身份变成完全连不上——这类抖动在跨境链路上很常见。

不做这一步，这份报告里的失败率会写成7.0%；做完之后是4.3%。虚高了六成。

剩下那11条是真问题，而且形态很说明问题

剩下的11条里，最值得说的是三条来自同一个珠宝品牌：它的欧洲站把保加利亚、爱沙尼亚、拉脱维亚三个市场的英语版本，指向了自己的中国站域名。而那个中国站上，这三个地区页面全部返回未找到。

早该下线的东西留在线上不止这一种，测试站被索引后的八步清除与四层防御是最典型的一例。

同一批站上量过另一件事，提交层、交付层与索引层三处说法对不上的比例是19.2%。

指向已经不存在的东西不止这一处，死链批量检测、分类到提交的一条龙能顺手一起做。

这一条几乎是本文主题的标本：声明写在欧洲团队的模板里，被指的页面归中国团队管，而中国团队做地区页面调整时，不会有任何机制去通知欧洲团队。

另外两条来自一个服装品牌：它声明了香港和俄罗斯两个版本，前者返回未找到，后者返回服务不可用。俄罗斯那条尤其典型——那是一个几年前就退出的市场，页面早就不提供服务了，而首页上的声明还在。

还有三条来自一个美妆零售站，它的罗马尼亚、法国、芬兰版本对两种身份都返回拒绝，看起来是地区级的访问限制。这类严格说不算坏，只是从我这个位置进不去。

地区限制这一类要单独想清楚

访问限制看起来是最无害的一类：真实用户在当地能打开，只是我这台在境内的机器进不去。但它有一层容易被忽略的影响。

当地用户的实际体验要单独测，海外客户打开你的站到底有多卡有实测数据。

谁真的来过只能看日志，每5次抓取就有1次来源不对是同一批数据挖出来的。

海外用户打不开有很多层原因，从解析、线路到分发网络的网络层排障可以照着往下走。

搜索引擎的抓取程序也不是从各国均匀发起请求的，它的出口位置相对集中。如果一个页面对大部分位置都不接待，那么它被抓到、被理解、被纳入语言关系的机会就会下降。

所以这一类的处置不是修声明，而是回去问一句：这个访问限制策略是有意为之，还是防护规则误伤？这两种情况的答案完全不同，而多数团队从没被问过这个问题。

把这11条按责任方分个类

跨团队的事要有账本，13类信号、5档工具栈与22周落地是一套变更日志的做法。

一堆问题先修哪个得有依据，五百个站实测排出来的技术SEO优先级可以当排期底稿。

同一个地址在两边被标成不同的语言，占多少？

集合比对只回答了地址对不对得上，还有一个更细的问题：同一个地址在两侧被贴的标签是不是同一个。

语言这层标注对机器理解的影响一直在变，模型铺到七十多种语言之后受益最多的是谁有反直觉的结论。

同一件事在不同语言里说法不一致很常见，问十种语言给出十个结论、其中一类改了就是改错值得先分类。

8894次比对里，1758次标法不同

做法是把两侧共同拥有的每一个地址挑出来，看它在源页和目标页上各被标成了什么。一共比了8894次，其中1758次标法不同，占19.8%。

本地化对不齐的地方不止语言，把跨境多市场价格排得像本地店是另一处细节。

口径要有单一来源才不会各说各话，五大指标的单一事实来源怎么建是配套的治理办法。

两组数放一起比之前要先对口径，一条五年趋势线上有三处口径变更是最典型的一例。

这个比例远高于集合对不上的比例。也就是说，两侧列的地址往往是同一套，但对每个地址是什么语言的理解并不一致。

绝大多数争的是同一件事：谁该当默认版本

把这1758次按标法组合排个序，头部几组是这样的：

双语市场的兜底更难定，两种语言都看得懂的用户与一套地址的矛盾是个具体案例。

两门相近语言要不要合成一套也是同类决策，印尼语和马来语能不能合并至今没有定论。

前五组全部围绕同一个地址：那个既是英语版又被当成默认落点的页面。源页说它是默认版本，目标页说它是某个具体的英语；或者反过来。

为什么这一处最容易吵

因为默认版本这个值在语义上是特殊的：它不描述这个页面是什么语言，它描述的是当没有更好的匹配时该去哪儿。这是一个关于整组的决策，不是关于单个页面的属性。

要让口径落地得进需求文档，产品经理配合SEO的七个动作点给了具体嵌入方式。

同一件事两个角色理解不同是常态，三类分工与团队配比是同一个协作问题。

一个页面可以既是美式英语版，又同时是整组的默认落点，规范也允许同一个地址被写两条声明来同时表达这两件事。问题在于，很多站只写了其中一条，而写哪一条取决于当初是谁在改这个模板。

英文站的人觉得它就是英语版；负责国际化的人觉得它是兜底页。两边都不算错，凑到一起就对不上。

另一组更像是整体平移出了错

还有一组很整齐的：某个站的波兰英语版，在目标页上分别被标成了比利时英语、希腊英语、法国英语、立陶宛英语、葡萄牙英语，各4次。这些地区码本身全部合法，都能在官方的语言子标签登记表里查到，所以任何语法检查都不会报错。

正文和结构化数据的语言口径要反着写，正文越本地化越好、标记里却要写回国际格式是容易搞混的一处。

批量本地化最容易整片出错，五个翻译陷阱与人审六步给了拦截的位置。

这个形态不像人手写错，更像模板在渲染时把地区变量取错了——每个国家的页面都把这条声明贴上了自己所在国家的地区码。一处模板逻辑的偏差，会在整组里复制出几十条错误声明。

标法不一致到底要不要紧

要紧程度介于中间。搜索引擎在处理这类冲突时通常会取更保守的解释，也就是把有分歧的那条声明忽略掉，其余的照常生效。所以后果不是整组失效，而是有分歧的那个语言版本失去了定向。

到了AI检索这层，语言标注挡不住的东西更多，为什么它挡不住跨市场的知识污染往前看了一步。

声明改了多久生效是另一个常见问题，六大场景下的生效时间实测给了参照。

但默认版本那一处是例外。如果整组都说不清谁是兜底，那么当用户的语言不在列表里时，搜索引擎只能自己挑一个——而它挑的往往不是你想要的那个市场。

怎么把默认版本这件事一次定死

内部先回答三个问题，答完就不会再吵。

要让上面拍板得先翻译成业务语言，六步把报告翻译成业务语言是推动决策的办法。

平台侧的语言覆盖也在变，某项功能扩到16种语言、中文站为什么在又不在是相邻的一件事。

第一，如果一个用户的语言和地区都不在你的清单里，你希望他看到哪个页面？多数品牌的答案是英语总站，少数会选主力市场的站。

第二，那个页面本身是不是也代表一个具体的语言地区？如果是，就要写两条声明——一条说它是某语言版本，一条说它是整组的兜底。这两条并不冲突，规范允许。

第三，这个决定怎么传达给所有市场团队？口头说没用，最好是写进那份共用的模板变量或者配置文件里，让各站取同一个值。

第三问答不上来，前两问答得再清楚也会在半年内重新走样。

声明的地址和最终落地的地址是同一个吗？

还有一层错位不在声明里，在链路上。你写的地址能打开，但打开之后已经不是它了。

同一个页面能有十几种写法，11种写法都返回200而查重复时一条都不报是这一节的前提。

240个正常打开的目标里，32个跳到了别处

把最终落地地址跟声明地址逐条比，32条不一样，占13.3%，涉及12个站。多数站是4条全中——说明这是站点级的跳转规则，不是个别页面的问题。

多域名跳转的配置本身也容易写乱，主域归一的完整配置可以照着核对。

跳转规则的代价常常看不见，每八次抓取就有一次撞在跳转上是同一类隐形损耗。

为什么跳转在这件事上格外要命

假设你在中文页上声明德语版在某个地址，而那个地址会把访客跳到另一个地址。那么搜索引擎抓到的是跳转后的页面，而跳转后的页面上列的是它自己那一套地址——里面很可能没有你声明的那个原地址。

靠脚本判断再跳转同样有坑，设备判断与跳转的现代写法里有该避开的几种。

跳转链一长就会丢东西，两种服务器上的双向跳转实战里有该避开的写法。

结果就是：你指的那个门牌号有人住，但住的人说自己不认识你。这一类错位在集合比对里会表现成两侧对不上，但根因不在任何一侧的声明，在中间那道跳转。

常见的三种跳转成因

第一种是地区探测跳转：站点按访客的网络位置自动分流。这类跳转对搜索引擎特别不友好，因为抓取程序的位置通常在少数几个地方，它永远只能看到其中一个版本。

跳转规则本身怎么配也有讲究，几种服务器上的现代写法可以照着抄。

标签类地址的改造是个典型场景，地址优化与跳转实战是个小而完整的例子。

地址结构改版是跳转的主要来源，扁平还是层级、改版怎么做有实操路径。

第二种是地址结构改版遗留：语言目录从一种写法换成另一种，老地址做了跳转，而声明里还写着老地址。

第三种是尾斜杠、大小写、参数这类归一化跳转。这类无害，但会让机械比对报出一堆假问题——所以做比对时必须先做地址归一化，否则你会看到一份全是噪声的报告。

本文的处理办法

这次比对前先做了归一化：统一去掉协议、统一去掉开头的通用子域、去掉尾斜杠、去掉锚点和查询参数、统一转小写。做完这一步之后剩下的32条，是真的跳到了不同路径上。

层级深浅到底影响什么，六招优化实战说得比较具体。

地址形态的行业惯例值得知道，一万个站的实测结论能帮你判断自己是不是异类。

跨域那277条，另一头到底在谁手里？

跨域是本文主题最直白的形态：声明的另一头写着别人的域名。这一节把这277条拆开看。

第三方那边自己变了你也不会知道，两天半里四分之一的站悄悄换了东西是一次实测。

站外那些提到你的地方同样要盯，品牌被提及没给链接怎么追回是另一种向外的动作。

21个站，124个外部主机

写了跨域声明的站有21个，占73个站的28.8%。它们一共指向124个不同的外部主机。

大规模站群一旦出问题就是整片，590万页面被清零的复盘值得当反面教材看。

多个站绑在一套基建上是常见做法，把多个独立目录绑到不同域名的三种方案是技术侧的实现。

国别域名的取舍从起名那一步就开始了，命名策略与顶级域避坑可以先看。

规模最大的几个：某家居零售巨头指向六个以上国别域，某北欧礼品连锁指向阿联酋、印尼、韩国、科威特、土耳其五个市场的独立域，某鞋类品牌指向六个国别域外加一个代理商域。

按另一头归谁管，可以分成三档

推不动往往不是技术问题，重写汇报方式的八个步骤比反复解释有效。

跨团队推事情有具体抓手，后端工程师配合SEO的七个动作点是从22周账本里总结的。

样本里三档都有。前面提到的那个日语版指向本地经营方的例子属于第三档，而那三条指向中国站却打不开的属于第二档。

124个外部主机里，顶级域的分布很说明问题

把这124个主机按顶级域归类，能看出这些站的国际化策略。

一张区域预算表底下往往是三套语言，三个市场没有一处能共用是拆开算的结论。

选市场别只看人口，先看有没有人拿这门语言写价格和退货政策是更实在的判据。

数量最多的是国家顶级域，覆盖从北欧到东南亚到中东的几十个市场。第二类是在通用域上开的地区子域，比如某电商平台给德语区、法语区各开一个。第三类最少，也最有意思：跟主站毫无字面关系的独立品牌域，也就是代理商或者合资方那种。

这个分布对应着三种截然不同的维护难度，而它们在页面源码上长得一模一样——都是一行声明，看不出背后隔着几个组织。

所以做审计时最好先做一件事：把所有跨域目标按注册主体归个类，标上归谁管。这份归类表做一次能用很久，也是后面所有沟通的底稿。

一个负结果：跨域不等于跨平台

本来预期跨域声明的另一头会跑在完全不同的技术栈上，那样问题会更严重。实际测下来不是这样。

响应会不会因人而异也能量，说会变的3个站、真会变的17个站是同一种对照。

平台指纹就藏在响应头里，索引指令、缓存与协商字段各管什么有一份完整机制图。

技术栈选型决定了很多默认行为，托管、自建还是纯代码怎么选把各自的代价摊开了。

把39个能拿到响应头的跨域目标跟源站首页做平台指纹对照，39个全部与源站相同，一个例外都没有。

这说明多数国别域只是同一套系统的不同门牌，技术上是通的。所以真正的障碍不是技术，是组织——同一套系统，两个团队，各自有各自的发布节奏。

集群大小不对称的三个例子

还有一类信号能直接看出两侧脱节：两边列的条数根本不一样。

相邻市场看着能合并，实际未必，两门语言的距离比想象中远有语言学层面的依据。

语言数量的账不能按国家算，十一门语言分摊在九套书写系统上是另一种不对称。

某鞋类品牌源页列了86条，目标页只列71条，少了15条；某平台源页66条、目标页71条，反而多了5条；最悬殊的一个是源页列了35条，目标页只列3条。

差5条可能是时间差——一边刚加了新市场，另一边还没同步。差32条就不是时间差了，那是两边压根用的不是同一套清单。

把这套关系挪到清单文件里，是不是更省事

规范提供了第二种表达方式：把语言版本关系写进站点地图，每个地址下面挂上它的所有兄弟版本，跟写在页面上的效果等价。清单文件本身的结构与扩展方式决定了这种写法必须由程序生成，手写基本不现实。

不装插件也能把这份清单做扎实，动态优先级、图片节点与分页缓存的写法是一份完整实现。

清单文件里另一个字段也做过实测，41万条地址的修改时间到底记的是哪一刻结论不太乐观。

清单文件本身的写法讲究不少，2400个站踩出来的坑基本都在那份清单里。

这个方案在大集群上有明显优势。站点地图由程序生成，每次导出都会重新算一遍，天然带一个触发点；而模板里那几行是静态的，除非有人主动去改，否则永远不变。前面几节量出来的那些问题，本质上都来自后者的这个特性。

它的代价有三条。一是可读性差，出问题时不能靠打开页面源码看一眼就定位；二是排查工具支持不如页面写法普遍；三是它只解决你自己那一半的维护问题，对面不列你，写在哪儿都不成立。

务实的组合是：自己这边用清单文件生成，同时保留页面上的写法做冗余，两边由同一个数据源产出。这样既有触发点，又不损失可排查性。

为什么这套声明比别的声明更容易坏？

把前面几节的数字放到一起，能看出一条共同的线索。这一节把它说清楚。

不是哪天突然坏的，它从第二周就开始走形而没人发现说的是同一种慢性失效。

这类欠账攒起来相当可观，技术债怎么排查和分批偿还给了可执行的顺序。

它的正确性不由你单独决定

规范网址、索引指令、修改时间、资源提示，这些声明有一个共同点：写在你的页面上，由你的系统生成，正确与否你自己说了算。它们会失效，但失效的原因通常在你这边。

有些结论换个环境就不成立，四层架构分歧导致建议跨平台失灵是同一类陷阱。

写下去却没有接收方的声明不止一种，有多少条规则压根没人在读比想象中高得多。

同一批站上量过另一类没人维护的声明，首页预连接指着的域名有8个已经不解析了是另一头的故事。

语言版本声明是另一类。你把自己那一半写得完美无缺，只要对面那个页面没把你列回来，这一组关系就不成立。你能控制的是必要条件，充分条件在别人手里。

更新这件事没有触发点

再看它什么时候该改。新增一个市场、下线一个市场、某个国家站换地址结构、某个页面被合并——这四件事发生时，整组所有页面的声明都应该跟着改。

没有触发点的字段最后都会走样，真更新与假刷新的副作用实测是相邻的一次验证。

没人碰的东西会慢慢失效，内容衰退的识别与分级更新是另一个场景的同一道理。

把检查接进流水线才不会反复，自动化为什么不能放在最后一段做讲的正是这件事。

问题是这四件事都不发生在维护声明的那个人手里。新增市场是业务决策，下线市场是财务决策，换地址结构是那个国家团队的技术决策。没有任何一件会自动变成一张改声明的工单。

那三条指向中国站却打不开的声明，就是这样来的：中国团队调整了地区页面，这个动作在他们那边是完全正常的一次改版，没有任何理由去通知欧洲团队。

坏了之后没有任何报错

第三个条件是失效完全静默。页面照常打开，用户照常购物，后台不会亮红灯。唯一的表现是搜索引擎在某个市场把错的那个语言版本排了上去，而这件事很难被归因到具体某一条声明。

静默失效最难发现，引用归零而监控没报警是同一类事故。

想批量核对状态有配额限制，2000条配额下的监控管线怎么搭是一套现成方案。

后台告警要分级处理才有用，分级诊断与90天监控闭环能把噪声压下去。

三个条件凑齐——正确性依赖外部、更新没有触发点、失效没有报错——这套声明的长期状态几乎注定是慢慢烂掉。样本里19.2%的站级出错率，还是在只抽查首页的情况下量出来的。

跟另外两类失效的区别

前两类的解法都是往自己的流程里加东西。第三类不行——你没法在别人的发布流程里加检查点，只能在自己这边加一道定期核对。

还有一个常被忽略的相互作用

这套声明跟规范网址那一套是有交互的，而且交互的方式经常出人意料。

规范网址自相冲突是常见故障，八种跨页场景与冲突诊断可以按图索骥。

两个声明同时出现该怎么判，九种场景下这两者能不能一起用有逐个场景的答案。

规则是这样：如果一个页面的规范网址指向别的地址，那么它的语言版本声明会被连带处理到那个地址上。所以当某个语言版本的规范网址被误设成英语版时，等于告诉搜索引擎这两个页面是同一个东西——语言关系当场作废。

这类错在做多语言站的时候相当常见，成因通常是模板里的规范网址取了一个全局变量，而那个变量在所有语言版本上都指向主站。判断办法很简单：打开任意一个非英语版本，看它的规范网址是不是指向自己。不指向自己，后面所有的语言版本工作都白做。

出问题的时候，怎么判断该找谁？

发现对不上之后，第一件事不是改，是分清这是谁的活。改错方向会白花很多力气。

内容侧的协作有对应的动作点，从选题到内容审计的七个动作是配套的一份。

跨职能这件事本身就是一项能力，八个信号与22周的协作实战是从招人那头讲起的。

四个问题，顺序不能乱

第一问：我这边列的那一套，自己站内的所有页面是不是一致的？先把自己那一半查干净，不然后面全是噪声。

两个来源给的数不一样时，六种场景下该信谁与三源校准给了判据。

后台那份报告要会读，五类问题地址的占比与排查顺序能帮你分清是谁的问题。

桌面爬虫能把前两问一次跑完，全站审计的十二类问题排查清单是配套的检查表。

第二问：对面那个地址能不能打开？打不开就先解决存活问题，比对集合没有意义。注意要换两种身份各试一次。

第三问：对面打开之后有没有跳转？有跳转就先看跳转的终点，不要拿声明地址去比。

第四问：终点页面上有没有列回来？没有列回来，才是真正要去找对面团队的那种问题。

三种典型局面与对应的动作

同样的问题在不同规模的站上优先级不同，三类站点的高投入产出比修复顺序可以直接套。

删还是改需要一套判据，留、改、并、删、转的决策系统比拍脑袋靠谱。

找对面团队的时候，带上这三样

跨团队推这类事最容易卡在对方不理解影响。经验是别讲原理，直接给三样东西：出问题的具体地址清单、他们那边应该加的那几行代码原文、以及这件事对他们自己市场的影响。

跨部门协作的账本长什么样，七个动作与复盘机制可以照着搭。

要别人配合先让他看到收益，用商业语言把这笔钱讲清楚是同一种沟通思路。

最后一样最关键。这套声明的收益是双向的——对面不列你，他们那个市场的页面同样拿不到你这边的定向。把这句话说清楚，比讲十遍规范有用。

一份可以直接抄的沟通结构

写给对面团队的那封邮件，四段就够。

写给外部的邮件有固定套路，目标页筛选与外联打法里的模板可以借。

给对方可直接执行的东西最有效，设计师配合SEO的七个动作点也是这个路数。

第一段说现象：我们站上有N个页面声明贵站的某某地址是它的某语言版本，实测那些页面上没有指回来的声明。附一份不超过十行的地址对照表。

第二段说影响：这会导致我们两边的页面在搜索里互相抢同一批用户，你们那个市场拿到的可能是我们的英文页。

第三段说动作：需要在你们的页面头部加这几行，代码原文附上，位置在哪里也写清楚。

第四段说验证：改完之后告诉我们，我们这边抓一次确认。

关键是第三段要给到可以直接粘贴的东西。对面团队多半不熟悉这套机制，让他们自己去查规范，这件事就会一直排在待办的最后一行。

推不动的时候怎么办

如果对面短期内改不了，务实的做法是先把自己这边的那一条删掉。

团队能力决定了能推动什么，四画像三阶段的路线图可以拿来对照现状。

推不动时先做自己能做的，实体权威的四阶段协作框架给了分阶段的路径。

理由是单向声明不生效，留着不但没用，还会在你自己的审计报告里持续报错，消耗每次核对的注意力。等对面能配合了再一起加回来。

需要说清楚的是，删掉不等于放弃那个市场——它只是不再声称这两个页面是一组。那个页面照常被收录、照常排名，只是少了一层定向。

自己站上怎么查，查完按什么顺序修？

这一节给可执行的顺序。整套流程不需要付费工具。

整页抓下来做多维打分是另一种做法，五维度百分制审计怎么用可以顺手一起跑。

不花钱也能把基础检查做全，预算为零时真正好用的那批工具列过一份清单。

五步核对

第一步，从自己站上抽一批代表页面——首页、一个分类页、一个商品页、一个帮助中心页各一个，把它们的声明抽出来。

抽样口径直接决定结论真假，抽样口径怎么定是同一类方法论问题。

批量打开一堆地址人工核对也是一条路，它只开标签页、不替你判断页面死活要知道它的边界。

单条地址的验证有现成工具，用接口测试工具看清状态码与响应头也够用了。

第二步，检查自指。每个页面的清单里必须有它自己。这一步最快，也最容易一次抓到问题。

第三步，检查站内一致性。同一组的几个页面列的应该是同一套，条数先对一下，条数不等就直接是问题。

第四步，实抓所有目标地址。记状态码，记最终落地地址，非正常的换个身份再抓一次。

第五步，解析目标页的声明，跟源页做集合比对，同时比每个地址的标法。

修的优先级

改完之后要能看出效果，从指标体系到异常诊断的完整做法可以拿来搭框架。

变体和语言版本是同一类多身份问题，标记、规范网址与地址的三层治理是相邻的一套。

这几类问题最后都会落到重复上，八类成因地图与诊断清单可以对照排查。

这个顺序的逻辑是先做完全在自己手里的，再做需要别人配合的。前三项通常能解决掉大半问题，而且当天就能上线。

有一点要提醒：别把第五项当成拖延前四项的理由。实践中很常见的一种状况是，团队盯着推不动的那一项反复开会，而自己模板里那个缺自指的问题挂了大半年没人改。前者是别人的进度，后者是自己的进度，混在一张表里汇报，最后两边都停在原地。

把两类分开排期、分开汇报，是这件事能推下去的关键。自己那部分改完就能拿到确定的收益，别人那部分再慢慢磨。

把核对做成例行的三个触发点

定期巡检对这件事效果一般，因为问题不是匀速产生的，它集中在几个特定时刻。更有效的是把核对挂在这三个触发点上：

做这行容易被这类琐事耗空，一套个人审计五步法顺手也留给自己用。

例行核对可以交给定时任务，把巡检挂上定时配置起来不算麻烦。

迁移这类大动作最容易丢配置，数据库替换与域名切换的执行流程里有该核对的清单。

第一，新增或下线一个市场时。这是最大的一次变更，必须全组同步。

第二，任何一个国家站做地址结构调整时。这一条需要提前跟各市场团队约定：改地址前先通知。

第三，每次做站点迁移或换建站系统时。这类动作最容易把整块声明弄丢。

还有一个偷懒但有效的办法

如果集群规模大到手工维护不动，可以把这套声明从页面上挪到清单文件里——规范允许在站点地图里表达同样的关系，而站点地图是程序生成的，天然带一个每次导出都重算的触发点。

导出这类动作都能自动化，备份、导出、缓存与证书一条龙有现成脚本可抄。

生成器说格式正确并不代表内容对，它说校验通过时其实只查了三件事值得看一眼。

它的代价是可读性变差、排查更麻烦，而且不解决对面不配合的问题。但它至少把你自己那一半从手工维护变成了自动生成，这已经能砍掉相当一部分错误。

把核对写成一段脚本，逻辑就这几步

不想每次手工做的话，这段逻辑不难写，核心不到五十行。

哪些能交给机器有一条边界，能交给工具的和不能交给工具的划得比较清楚。

把它串成工作流也不难，怎么搭一条SEO自动化工作流有完整实测。

这类小脚本自己写最快，用对话式编程做小工具的八步避坑讲的就是这种自养工具。

输入是一批本站地址。第一步抓每个页面，解析出它的声明清单，同时记下它的规范网址。第二步检查规范网址是不是指向自己，不是就直接标红，后面都不用查了。第三步检查清单里有没有自己。第四步把清单里所有目标地址去重，做归一化，然后逐个抓，记状态码和最终落地地址。第五步解析每个目标页的清单，跟源页做集合比对，同时比每个共有地址的标法。

三个容易写错的地方要提一句。一是归一化必须做，否则尾斜杠和大小写会制造大量假问题。二是非正常状态必须换身份重抓一次，否则失败率会虚高。三是要按最终落地地址去比，不是按声明地址，跳转会让后者失去意义。

输出建议分成两张表：自己能修的和要找别人的。这两张表的处置节奏完全不同，混在一起会让前一张也拖着。

还有一件小事值得提前想：这段脚本抓的是别人的站，频率要收着点。每个域之间留一两秒间隔，别开太高的并发。跨域目标里有相当一批带着地区级的防护策略，一次密集请求就可能把自己的出口地址拉进黑名单，之后你连正常核对都做不了。

另外，脚本跑出来的结果要留一份带时间戳的存档。这类问题往往要来回几轮才能推动，半年后再看时，能拿出当初那份记录说清楚哪些是新出的、哪些是一直没改的，比重新解释一遍有说服力得多。

常见问题解答

只有我这边写了，对方没写，能生效吗？

不能。规范明确要求这套声明必须双向成立，且每个成员都要包含自己。搜索引擎的处理方式是把单向的那条忽略掉——它没法确认这门关系是不是你单方面声称的。实测240个目标页里，有12个漏了自指，还有6个一条声明都没有，这两类都会导致整组关系不成立，哪怕别的成员都写对了。

怎么快速判断我的站有没有这个问题？

最快的一步是查自指：打开任意一个语言版本的页面，看它的清单里有没有它自己。没有就是硬伤，而且这一条改自己的模板就能修。接下来抽三到四个目标地址实抓，看能不能打开、有没有跳转、打开之后列不列你。整套下来半小时以内，实测里19.2%的站会在这一步就暴露问题。

目标地址打不开，一定是对方的问题吗？

不一定。实测18条打不开的目标里，7条换成普通浏览器身份重抓就正常了，占38.9%。原因通常是对方的防护策略不接待自动化请求，或者做了地区级访问限制。所以看到失败先换个身份再试一次，不然失败率会被虚报——本文这批数据不做这一步会写成7.0%，做完是4.3%。

同一个地址被两边标成不同语言，要紧吗？

分情况。如果是普通的语言地区标法不同，搜索引擎通常会忽略有分歧的那一条，其余照常生效，影响有限。如果分歧出在谁是默认版本上就比较麻烦——整组说不清兜底页是哪个，搜索引擎只能自己挑。实测8894次比对里1758次标法不同，占19.8%，而头部几组全部围绕默认版本这一件事。

声明的地址会跳转，需要改吗？

需要。搜索引擎抓到的是跳转终点，而终点页面上列的是它自己那一套，很可能不包含你写的那个原地址，于是两侧对不上。实测240个能打开的目标里32个跳到了别处，占13.3%，而且多数站是抽到的几条全中，说明是站点级规则。改法很简单：把声明直接写成跳转终点的地址。

跨域声明是不是应该避免？

不用避免，规范本来就允许。实测21个站写了跨域声明，一共277条。真正的风险不在跨域本身，在于另一头归谁管——同一个团队的不同国别域基本没问题，跨部门和跨公司的才难维护。一个可以参考的负结果是：39个能对照的跨域目标，平台指纹全部与源站相同，说明技术上是通的，障碍主要在组织上。

集群太大维护不动，有什么办法？

可以把这套关系从页面挪到站点地图里表达，规范允许两种写法。好处是站点地图由程序生成，每次导出都会重算，天然带一个更新触发点，不像模板里那几行会一直不动。代价是可读性和排查便利性都变差，而且不解决对面不配合的问题。适合语言版本超过十几个、又确实维护不动的站。

对面团队推不动怎么办？

短期内推不动的话，先把自己这边指向对方的那一条删掉。单向声明本来就不生效，留着只会让每次核对都报同样的错，白白消耗注意力。等对方能配合了再一起加回来。要注意删掉不等于放弃那个市场，那个页面照常被收录和排名，只是少了一层语言定向。沟通时带上具体地址清单、对方要加的代码原文、以及这件事对他们自己市场的收益，比讲规范有效得多。

权威参考资料