hreflang里写的那些语言版本，Google只把它们当规范页的别名

摘要：把211个国际化独立站的首页拉了一遍，只有75个真写了hreflang，一共2592行标注，中位数16行，最长的一张260行。从这些表里挑出306个备用网址逐个抓：49个一请求就跳走，13个的规范网址指向别处，还有23个声明的语言跟页面实际给的对不上。而Google那边早就说过，这些备用网址并没有被真正编入索引，它们只是规范网址的别名。

这件事的起点是一条很多人问过的问题：站点做了多语言，Search Console里那些带语言前缀的网址一片“未编入索引”，可用德语搜的时候，德语版又确确实实出现在结果里了。报表说没有，眼睛说有，到底信谁。

2026年8月，Google的Gary Illyes在领英上回答了这个问题，用词很直接：hreflang的备用网址并没有在真正意义上被编入索引，它们只是被存成了规范网址的别名。这一句话，把很多人查了几年的报表状态重新解释了一遍。

你在报表里查的那个网址，系统回答的往往不是它，而是它归属的那个规范页。它自己没有一份可以单独查看的“当前状态”，因为它压根不是一条独立的记录。

这篇文章分两部分。前半段把机制讲透——别名到底是什么，它和索引条目差在哪一层。后半段是我自己动手量的一批数据：211个域名的hreflang表，306个备用网址的实际返回，以及一次让我把结论推翻重做的测量失误。

为什么Search Console说没收录，用户还是看到了那个语言版本？

先把那段回答完整地摆出来，因为它比任何转述都清楚。有人问：如果Google自己挑了某一个语言目录当规范页、其余的在Search Console里显示未编入索引，那它凭什么还能把别的语言版本给用户看。

那段回答里最关键的两层意思

他说这里面有两件事在同时起作用。第一件事叫别名：当Google把一组重复网址规范化之后，被淘汰的那些网址可能会变成所谓的别名，在用户的查询配得上其中某个别名的时候，它们会被拿出来用。

这两层意思落到报表上是什么样，8种未编入索引状态的判定路径里逐条拆过。

第二件事，hreflang的备用网址就会变成这种别名。原话是它们并没有在真正意义上被编入索引，但这个网址被映射到了那个已经被编入索引的规范页上。完整问答可以看这篇关于hreflang备用网址是别名的记录，原贴的提问和回答都在里面。

两层意思拆开看，第一层讲的是规范化的副产品，第二层讲的是hreflang恰好生产这种副产品。合起来的意思是：hreflang从来就不是一个收录机制，它是一个分发机制。

为什么site: 查询能查出一堆会跳转的网址

他举的例子特别好懂：拿一个短链域名做site: 查询，会看到一大堆其实是跳转的网址。那些网址没有被真正索引过，它们只是某个规范网址的别名。你能在结果里看到它，不等于系统给它建了一条记录。

这个命令的适用场景和常见误判，site命令怎么用单独讲过一次。

这个例子的价值在于，它把“能出现在结果里”和“被编入索引”这两件被长期混用的事，硬生生掰开了。短链域名是个极端场景，正因为极端才清楚：那个域名下几乎没有任何真实内容，却能查出成千上万条结果。

为什么偏偏拿短链举例？因为短链域名下的每一个地址天生就是别名——它存在的全部意义就是指向另一个地址。用一个纯别名的域名来解释别名，是最不容易产生歧义的选法。多语言站的情况没那么极端，但性质是一样的。

顺便说一句，这也解释了为什么site: 查询查出来的数字一直不准，不适合拿来汇报。它数的是能被匹配到的字符串，不是索引条目。这两个集合有重叠，但从来不相等，而且重叠度还随站点结构变化。

我以前带团队的时候立过一条规矩：任何一份报告里出现site: 的结果数，必须同时标注它是一个量级参考而不是收录数。一个数字只要被写进周报，三个月后就没人记得它当初是怎么来的了，只记得它是收录数。

未编入索引不等于进不了搜索结果

顺着这条线往回看，Search Console那个状态就不冤枉了。它报告的是“这个网址有没有作为一条独立记录被索引”，回答是没有。而用户搜到的，是那条规范记录带着一个合适的别名露了个面。

收录、排名、流量本来就是三件事，没流量先分清卡在哪。

两句话说的不是同一件事，所以它们可以同时为真。这跟GSC索引覆盖状态的判定逻辑是一脉相承的：状态描述的是记录，不是可见性。页面索引报告对各状态的定义里，“替代页面（有适当的规范标记）”这一条说的正是同一件事。

这件事为什么每隔一阵就要被重新问一遍

因为多语言站的运营节奏就是这样：改一版模板，跑一遍工具，看一眼报表，发现一片红，慌了，然后开始改hreflang。改完过两周，报表还是红的，于是再改一遍。

真要动手修的时候，页面不被Google收录的急救手册按症状分诊更省事。

我见过一个卖户外装备的团队，为这块红色前后折腾了四个月。第一个月怀疑是标注写错，重写了模板；第二个月怀疑是站点地图没提交，把六个语言的地图重新生成了一遍；第三个月开始怀疑服务器，换了一次CDN节点。

问题是这块红本来就不会变绿。它不是一个待修复的错误，它是一个被正确执行的机制留下的痕迹。这四个月里唯一真正该做的事，是去确认那个规范页有没有被正常收录。

这跟“重复内容”是两回事，别混着治

还有一种更贵的误判：把这片红当成重复内容问题，于是开始给语言版本加noindex，或者干脆把某几个语言目录从站点地图里撤掉。

重复内容的成因分六类，同域跨域参数变体全排查里有一张对照表。

这个动作的后果是实打实的。别名不占抓取预算，也不影响那条规范记录；但你一旦给某个语言版本加了noindex，它连当别名的资格都没了，那个市场的用户在结果里再也换不到本地版本。本来只是报表难看，现在变成真的少了一个入口。

判断很简单：如果一个语言版本的内容是真实翻译过的、面向真实市场的，那它就该留在索引流程里，哪怕报表永远显示未编入索引。要清理的是那些指向同一份内容的多余标注，不是内容本身。

先说结论，省得后面绕

整篇的判据只有一句：这个网址有没有一份属于它自己的、可以单独查询的当前值。有，它是条目；没有，它是别名。多语言站里绝大多数带语言前缀的网址，属于后者。

条目本身也分层，页面被丢进Base还是Landfill是另一个维度的问题。

后面所有的数字，都是在回答一个附带的问题：既然大部分注定是别名，那你现在这张表里，有多少行是连当别名的资格都不太够的。

别名与索引条目的差别，在于有没有一个可查的当前值

把这两个东西并排放，差别其实不抽象。

一条索引条目身上挂着什么

一条真正的索引条目，有自己的抓取时间、自己的内容快照、自己的一套信号，也有自己在报表里的一行。你去查它，系统能把这一行的内容念给你听。

抓取、索引、排名这三步的分工，搜索引擎怎么工作的讲得最基础。

更重要的是，它可以被单独优化。你改这一页的标题，改的就是这一条记录；你给这一页加内链，权重进的也是这一条记录。它是一个可以承接动作的对象。

一个别名身上挂着什么

别名身上几乎什么都没有。它是一个映射：这个字符串，指向那条记录。它不存内容，不存信号，也不存状态。你去查它，系统只能把它指向的那条记录念给你听，或者干脆告诉你这里没有记录。

Canonical URL的9大决策里，身份这件事是所有判断的起点。

所以对着别名做优化，是最典型的白干。你把某个语言版本的标题改了三遍，如果这个地址是别名，那三遍改的都是同一条记录的同一个字段，后面两遍覆盖了前面两遍。

规范化把一组网址压成一个，剩下的去了哪

Google的重复网址合并文档写得很清楚：一组被判定为重复的网址会被合并成一个规范网址，其余的成为这一组里的成员。别名就是从这个成员集合里出来的。这份关于合并重复网址的说明里把“重复网址集群”这个词用得很具体，值得对着自己的站读一遍。

Google自己怎么挑那个规范页，9大决策逻辑与排查实操列得很细。

所以hreflang并没有创造出新的索引条目，它只是往一个既有的合并关系上，补了一层“这个成员适合哪个语言地区”的说明。它是给已有的合并结果贴标签，不是阻止合并发生。

为什么很多人以为hreflang能阻止合并

因为传播里有一句被简化过头的话：hreflang可以避免多语言内容被判重复。这句话有一半是对的——它确实能避免你的德语版和英语版被当成需要择一的重复内容。

同一种英语卖到美英澳，怎么不自己跟自己打架是这个误解最常见的现场。

但它避免的是“择一”，不是“合并”。这一组网址照样是一个集群，只不过集群里的成员按语言地区各自有了用武之地。集群还是那个集群，实心节点还是那一个。

别名会在什么时候被拿出来用

用户的查询配得上它的时候。语言地区匹配是最常见的一种，站内检索式查询是另一种。除此之外它就一直躺着，不占报表，也不占抓取预算。

召回到重排的四个阶段，搜索引擎排名怎么决定里拆过。

这也解释了另一个常见困惑：为什么某些语言版本明明有排名，但在报表里查不到任何数据。因为数据记在了那条规范记录名下。

把这层关系画出来，只有一个节点是实的

一组五个语言版本的页面，在你的后台是五条内容，在你的站点地图里是五行网址，在Google那边可能只有一个实心节点加四个标签。

节点合并会影响权重怎么走，子域名还是子目录那篇算过账。

你以为在管五个页面，实际上在管一个页面和四个说明。这个落差决定了后面所有的运维策略：页面数是你的成本，节点数才是你的资产。

这个落差还会影响一件很实际的事：内链怎么给。如果一组语言版本里只有一个实心节点，那你从别处指过去的链接，无论落在哪个语言版本上，最终都汇进同一条记录。这时候纠结“该链德语版还是英语版”意义不大。

反过来，如果这几个语言版本各自内容差异很大、各自有独立的canonical、也各自被正常收录，那它们就是几条独立记录，链给谁就是给谁。同样一个动作，在两种结构下的效果完全不同，而你没法从后台看出自己处在哪一种结构里。

唯一能看出来的办法，就是去查那几个地址的canonical，以及在Search Console里看它们各自有没有独立的表现数据。有，是条目；没有，是别名。这个判据我会在后面反复用到。

我抓了75个国际站的hreflang表，第一件事该数什么？

光讲机制没意思，得看真实的表长什么样。我从公开可访问的国际化独立站、DTC品牌站和几个大型电商站里凑了211个域名，逐个抓首页，把head里的hreflang全部拆出来。

怎么抓的，先说清楚

每个域名发一次普通浏览器请求，跟随跳转，允许压缩，超时25秒，只取首页。解析的时候只认 rel=alternate 且带 hreflang 属性的link标签，其余一律不算。没有登录，没有cookie，就是一个陌生人打开首页会看到的样子。

换个角度从日志那一侧看爬虫，AI爬虫到底有没有抓你的站也是一手挖法。

样本覆盖服饰、床品、家居、户外、宠物、个护、3C配件、厨具、母婴、自行车几个品类，以欧美和北欧品牌自营站为主，另外放了几个平台型站点做对照。

选样本的时候我刻意加了一批中国出海品牌的独立站，因为这批站的多语言做法跟欧美品牌很不一样：它们通常一上来就铺十几个语言，速度快，覆盖广，但内容深度参差不齐。后面几个最典型的错配案例，确实出在这一批里。

有一点要先说明：这不是一个随机抽样，是一个便利样本。它能说明“这类站里常见什么问题”，不能推广到“全互联网有百分之多少的站有这个问题”。凡是拿便利样本算出来的比例，都只在这个样本内部成立。后面所有百分数请照这个口径读。

211个域名下来，真写了hreflang的只有75个

189个域名拿到了响应，170个的HTML能正常解析，其中 75个站的首页上有hreflang标注。剩下的近百个站，要么是单一市场单一语言，要么把多语言做成了完全独立的域名而没有互相声明。

基础写法和常见坑，多语言站的避坑清单可以先过一遍。

顺带一提，有14个站返回的是人机验证页而不是真页面，占抓取成功数的8.3%。这个数字本身不影响结论，但它提醒一件事：任何一次批量抓取，先数清楚有多少份样本是假的，再开始算比例。

那95个没写hreflang的站，在做什么

这一半样本我本来是要丢掉的，后来发现它们比写了的那一半更有代表性。翻了一遍之后，大致分成三类。

国际化最难的其实不是标注，实操对不上的5大根因说的是另一层。

第一类是真的只做一个市场，页面语言单一，连语言切换器都没有。这类站占了大头，它们不写hreflang完全正确，写了反而是负担。

第二类有意思：站上有语言切换器，切过去内容也确实变了，但head里一行hreflang都没有。也就是说多语言是做给用户的，没做给引擎。这类站的各语言版本基本靠自然抓取碰运气，能不能被正确分发全看内容本身的信号。

第三类最麻烦：每个市场一个独立域名，域名之间互不声明。从引擎的角度看，这就是几个毫无关系的站在卖同样的东西，重复内容的风险是实打实的，而且各站之间攒的信任度完全无法互相带动。

2592行标注，中位数是16行

75个站合计2592行hreflang。按站算，最少的只有1行，四分之一的站在5行以内，中位数16行，四分之三的站在39行以内。

站点地图那一侧的规模问题，2400站踩过的坑里有类似分布。

16行是个挺舒服的数字：大约对应十来个市场加一个兜底。但平均数在这里没有意义，因为分布是严重右偏的——头部那几个站，一个人顶后面二十个。所以下面我一律报中位数和分位数，平均数只在特别说明的时候才用。

右偏到什么程度？前10个站贡献的行数，超过了后65个站的总和。这意味着任何一个关于hreflang的“平均水平”说法都是可疑的，因为平均值被十来个把表铺得极大的站拉着走。

这种分布形态在SEO数据里其实很常见：页面数、外链数、关键词覆盖，画出来都是这个样子。习惯了之后有个条件反射——凡是听到“平均每个站有多少多少”，先问一句中位数是多少。两个数差得越远，那个平均数越没用。

做多语言站的时候，这个分布形态其实是个有用的参照：如果你的表长度落在5到16之间，你处在这个样本的主流区间，说明规模跟维护能力大概是匹配的。如果你只有三五个人的团队，表却铺到了60行以上，那你多半已经在维护一批自己都不知道存在的声明了。

最长的那张表有260行

排在前面的几个站，表长得有点吓人：一个瑜伽服品牌260行，一个刀具与园艺品牌236行，一个饮料品牌202行，一个美妆品牌190行。家居巨头116行，护肤品牌112行，自行车品牌110行。

声明膨胀和索引膨胀是一回事的两面，大量没用的页面拖垮流量讲的是后者。

260行是什么概念？意味着这个品牌声明自己有260个语言地区组合的入口。而它真正维护着独立内容的市场，大概率不到二十个。剩下那两百多行，是配置表里“其他地区回退到国际站”那一句话的展开式。

分档之后能看出两种完全不同的做法

站点结构本身也分两种做法，搭错了爬虫根本找不到你的产品页。

12行是一道明显的分水岭。12行以内的表，基本是人手写的，改起来有人知道在改什么；12行以上的，几乎都是模板按配置表循环出来的。而模板的问题在于，它不会因为某个市场今年关了就少输出一行。

表越长，出错的机会涨得比行数更快

因为hreflang的正确性不是逐行判定的，它是成对判定的：A声明B，B也得声明A。行数翻一倍，需要对上的关系是平方级往上走。手工维护到12行就吃力，不是巧合。

对称性怎么落地，return tags与x-default实操避坑那篇是配套的。

这也是为什么行数超过30的站，几乎必然出现某种自相矛盾——不是因为负责的人不认真，是因为这个量级已经不是人眼能盯的了。它得靠一个每周自己跑的脚本，而不是一次季度复盘。

有4个站，没在表里声明自己

hreflang有一条基本要求：这张表必须包含指向页面自身的那一行。75个站里，71个的表里出现了自己所在的域名，另外4个没有，占5.3%。

生成器给的代码粘上去往往就是单向的，这一点栽过不少人。

这4个站的表全是指向别的域名或子域的，唯独漏了自己。这种写法的后果是整组声明可能被忽略，因为引擎无法确认发起声明的这个页面属于哪一组。

换个角度想这件事就更清楚了：hreflang表本质上是在说“我们这一组有这么几个成员”。如果发起声明的人没把自己算进去，那这句话在逻辑上就是残缺的——你在描述一个你声称不属于的组。

为什么会漏？因为模板通常是这么写的：循环遍历“其他语言”的配置列表，逐行输出。而“其他”这个词天然把自己排除在外了。一个词的选择，决定了一整套标注成不成立。写这段模板的人当时觉得很自然，毕竟没人会觉得需要向自己声明自己。

x-default的覆盖率是88%

75个站里66个写了x-default，占88%。这个数字比我预期的高，说明这条已经进了大部分模板的默认输出。至于写得对不对，后面单开一节说，因为“写了”和“写对了”在这一项上差得特别远。

兜底做不好就容易改用跳转，按IP自动跳转会让半数页面进不了索引。

一张表里出现重复网址，说明了什么？

拆完2592行之后，我做的第二件事是查这张表内部有没有自相矛盾。结果比预想的多。

18个站的表里，同一个网址出现了两次以上

75个站里有 18个站，也就是接近四分之一，hreflang表里存在同一个网址被两个或更多语言代码同时指向的情况。

电商站的重复成因有八类，诊断与canonical全清单可以对着排。

这不算硬错误——一个页面确实可以同时服务于en-SG和en-MY，官方也没禁止。但它是一个信号：你声明的版本数，比你实际拥有的内容份数要多。多出来的那些，注定只能当别名。

3个站给同一个语言代码配了不同网址

反过来的情况少得多，只有3个站：同一个语言代码在表里出现两次，指向两个不同的网址。这个才是真错误，因为它让“哪个是de-DE版”这件事没有唯一答案。

同一个位置冒出两套标注，怎么把它们归一是同一类问题。

引擎遇到这种情况通常的处理是整组忽略，或者只取其一。无论哪种，你精心写的那张表在这个语言上白写了。

重复网址不是笔误，是模板生成的

18个站里，重复的模式高度一致：一个英文页面被挂在en、en-US、en-CA、en-AU、en-SG五个代码下面，或者一个国际站被挂在所有没有独立站点的地区下面。这是配置表里“回退到国际站”那一行的直接产物。

模板换一套基建就得重搭，sitemap与重定向这套得自己来。

我把其中一个站的表整理出来数了数：60行标注，去重之后只剩11个不同的网址。也就是说，平均每份内容顶着五个半的语言标签。这个比值我后面会叫它“虚实比”，它比行数本身有用得多。

站在引擎那一侧，这张表被读成什么

它读到的是：这五个标签，指向同一份内容。于是这份内容成为一条索引条目，五个标签成为它的别名。你在后台看到五个市场，它看到一份内容五个名字。

引擎读页面分几步，看懂才知道哪里丢内容。

一对多和多对一，后果完全不同

这两个标记能不能同时用，9种场景怎么判断。

虚实比这个数怎么用

拿hreflang行数除以去重后的网址数，得到的就是平均每份内容顶了几个标签。本批样本里这个数普遍在1.5到3之间，个别站超过5。

几家工具的数对不上时，三家对账方法的思路也是先统一口径。

它不是越低越好，1也不现实。但当它超过4的时候，值得停下来想想：你真的需要向搜索引擎声明这么多个市场入口吗，还是只是因为配置表里刚好列了这么多个国家。

这个数好在它不需要任何工具。把页面源码里的hreflang复制出来，粘进表格软件，一列是代码一列是地址，对地址那一列做一次去重，两个行数一除就出来了。三分钟的事。

更有意思的是把它跟另一个数放一起看：你的多语言内容团队有几个人。我见过一个团队，两个人负责本地化，站上声明了34个语言地区版本。两个人维护34份内容是不可能的，所以那34行里必然有大量是同一份内容的化名——去重之后果然只剩7个地址。

这不是说他们做错了。7份内容覆盖34个市场入口，本身是个合理的策略。问题只在于，团队内部一直以为自己在管34个版本，排期、预算、复盘全按34算，而实际的工作量和风险都落在那7份上。

这个误差会一路传导下去。做内容排期时，34这个数会让人觉得盘子很大、必须再招人；做效果复盘时，34又会让平均每个版本的产出看起来低得可怜。两头都被同一个虚数带偏，而没有人怀疑过这个数本身。

把虚实比算出来之后，那次讨论的结论从“再招两个本地化”变成了“把那7份做深，另外挑两个市场做真正的独立内容”。同样的预算，方向完全不同。一个数字算错，改变的往往不是某个动作，是整件事的方向。

声明的语言和页面实际给出的语言，能对上吗？

这是本次最花时间、也最有意思的一部分。既然hreflang是在描述“这个网址是哪个语言版本”，那就把这句描述拿去跟事实对一遍。

我做了一次三方比对

从75个站的表里，按语言均匀采样，挑出306个备用网址逐个抓取，然后比三样东西：hreflang里声明的语言、页面html标签上的lang属性、以及正文实际用的语言。

技术审计要看哪几层，从AI爬虫到accessibility的42步列过。

前两个是站长自己写的字符串，第三个是页面真正给出来的东西。三者本来应该完全一致。而只要有一处对不上，这条标注就在撒谎，区别只是谁在撒。

为什么要比三个而不是两个？因为只比声明和属性的话，两个都是人写的字符串，它们很容易一起错——同一个模板变量渲染出来的东西，错也是一起错。加上正文这个第三方，才有了一个不受模板影响的参照。

正文语言怎么判的，我在下一节会详细讲，因为这一步差点让整个结论作废。先说结果：判定分两条路，非拉丁文字按字符区间的占比直接判，拉丁文字用停用词法配合归一化和弃权线。能判就判，判不了就明说判不了，绝不硬蒙。

306个网址，288个拿到了正常页面

状态码怎么影响SEO，301、302、404和410该怎么选。

248个页面可以做三方比对，90.7% 三者一致

去掉正文语言判不出来的（小语种超出检测范围，或者页面文字太少），剩下248个可比对的页面里，225个三者一致，占90.7%；23个至少有一处对不上，占9.3%。

收录速度这类指标怎么量，3平台300站实测数据是另一组一手数字。

三类的严重程度是递增的。声明错，影响的是这一条分发规则；属性错，影响的是浏览器和辅助技术的判断；正文不对，那是内容根本没做出来，标注只是在替一个不存在的版本占位。

三类的修法也完全不同，而且成本差着量级。声明错，改一行模板变量，当天能上；属性错，改一处模板输出，也是当天的事；正文不对，那要么排一次翻译，要么把这个市场从配置里撤掉，两个都是要走排期的决定。

所以排查的时候，最好把这三类分开报给不同的人。前两类给开发，一句话就能说清；第三类给内容负责人，附上具体是哪几个市场。把三类混在一张“hreflang有23个问题”的单子里发出去，最可能的结果是这张单子在群里躺三周没人认领。

那五行是最干净的一组反例

一个无人机品牌的hreflang表里，de-LI、fr-MC、en-ID、en-LT、en-GB五个代码分别指向五个地区路径。五个网址我全抓了，五个页面返回的都是简体中文的中国大陆版首页，一个字的差别都没有。

翻译内容在AI检索里为什么吃亏，多语言AI可见性怎么做。

这不是抓取环境的问题——我从另一条完全不同的网络又抓了一次英国那个地址，拿到的还是中文版，导航是“航拍无人机”“手持摄影设备”，页脚明明白白写着中国大陆。这五行标注描述的那件事，从来没有发生过。

四个语言网址全给英文

一个手表品牌的表里，es、nl、de、fr四个代码指向四个语言路径。抓下来lang属性全是en，正文也全是英文。

翻译外包和原生再创作的差别，本地化生产线说得很直白。

有意思的是从海外网络抓那个西班牙语地址，正文确实是西班牙语的，导航写着Mujer、Hombre、Niños。也就是说内容是有的，只是lang属性一直没跟着切。这属于上表里的第二类，是三类里最轻的一种，但它会让所有依赖lang属性做判断的下游工具全部读错。

芬兰语页面是英文的

一个北欧刀具品牌声明了fi，指向fi-fi路径，抓下来lang属性是en，正文也是英文。这一类最难被发现，因为页面本身完全正常，只有一个懂芬兰语的人打开它才会觉得不对。

本地化没做透，跨文化语义与查询语言切换那一步就接不上。

这种情况通常有两个来源：一是这个市场的翻译还没做完，先用英文顶着；二是翻译做过，但某次发版之后回退了，没人发现。无论哪种，标注都在替一个不存在的芬兰语版本背书。

要发现它其实有个很省事的办法：不用懂那门语言，只要抓下来看看页面上出现频率最高的那几个词，跟你声明的语言对不对得上就行。芬兰语的页面上不该满屏都是the和and。这个检查花不了一分钟，却是本文所有排查手段里唯一能发现第三类问题的。

再说得直白些：前两类问题是标注写错了，看代码能查；第三类是内容没做出来，只能看内容。而多数团队的多语言巡检流程里，只有查代码这一环。

还有几个没那么显眼、但性质一样的

一个欧洲电商在四个国家站上都有同一个页面，声明分别是en-CH、en-DE、en-AT、en-NL，抓下来四个页面的内容完全一致，语言也一致。严格说这四行没写错，但它们描述的其实是同一份内容的四个入口。

多语言多货币叠在一起，hreflang、URL与价格Schema三层避坑。

一个北欧户外品牌声明了no-no，页面lang属性写的是nb，正文是丹麦语。这三个值两两不同，属于最少见的一类。挪威语的书面形式本来就有两套，nb和nn，写no是个偷懒但可接受的做法；正文是丹麦语就没法解释了，只能是内容回退。

还有一个韩国站，声明ko-kr，lang属性是en，正文确实是韩语。这一类的坏处在于，所有靠lang属性判断的东西——浏览器的翻译提示、屏幕阅读器的发音、部分内容管理系统的搜索索引——全都会走错路。标注写错这件事，受害者往往不在搜索引擎那一侧。

还有一行写的是一个字母

一个户外背包品牌的表里，有一行的hreflang值就是 x。不是x-default，就是一个字母x。这一行在2592行里是唯一的畸形值，但它在那儿放了很久了。

写错位置这类问题，robots.txt和meta robots别搞反也是常见现场。

我猜是某次手工编辑时把 -default 删掉了，或者模板变量取值取了半截。无论哪种，它说明了一件事：这张表没有任何人在校验，因为但凡跑一次校验，这一行是第一个会被报出来的。

这个站不是什么小作坊，是一个在欧洲户外圈子里相当有名的背包品牌，站做得很漂亮，产品页的结构化数据也写得很规矩。技术水平和维护习惯是两件事，前者决定你能做到多好，后者决定你能维持多久。

一个能自己发现自己的错误的表，长什么样

回到实操。这一节的所有问题——重复网址、缺自指、畸形代码、语言对不上——有一个共同的解法，就是让这张表在生成的时候就自带一次校验，而不是等人想起来去查。

这类断言该由谁来加，后端工程师SEO协作的7个动作点有分工建议。

做法不复杂：模板输出hreflang的那段代码，加三个断言。第一，输出完之后检查有没有一行指向当前页面自己，没有就在日志里报一条；第二，检查有没有重复的语言代码；第三，检查每个代码是否匹配语言标记的格式。

这三条断言加起来不到二十行，跑在生成阶段，几乎不耗性能。它们不能保证内容是对的，但能保证这张表在结构上不自相矛盾——而本次样本里超过一半的问题，恰恰就是结构上的自相矛盾。

为什么要放在生成阶段而不是事后扫描？因为事后扫描面对的是成千上万个页面，你得先决定扫哪些、多久扫一次、报出来给谁；而生成阶段只面对一段模板代码，错了当场就知道。越靠近问题产生的地方，修它的成本越低。

顺便说一个反直觉的经验：这三条断言最好只写日志不报错，不要直接抛异常让页面渲染失败。多语言标注出错是个内容质量问题，不是可用性问题，为它挂掉一个正在卖货的页面完全不划算。让它安静地记一笔，等有人看日志的时候自然会看到。

为什么我第一次算出来的错配率是真实值的两倍多？

这一节讲的是我自己的错误，但它比上面任何一个数字都更值得记下来。

第一版检测器说22.3% 不一致

我第一次跑三方比对，得到的结论是283个页面里63个不一致，占22.3%。这个数字当时让我挺兴奋——五分之一的多语言标注是假的，这标题都能直接写了。

数据虚高不是新鲜事，GSC展示与点击对接一年也是一次口径修正。

然后我去看具体案例，发现不对劲：一个家居巨头的丹麦语页面被判成了葡萄牙语，一个户外品牌的意大利语页面也被判成了葡萄牙语，一个服装品牌的美国站还是葡萄牙语。葡萄牙语出现的频率高得不合常理。

罪魁祸首是三个字母

我的正文语言检测器用的是停用词法：给每种语言配一组高频虚词，数哪组命中得多。葡萄牙语那一组里，我放了 com。

靠特征词判定的工具都有这个毛病，12项语言特征怎么拆。

在葡萄牙语里com是“和、带有”的意思，确实是高频虚词，放进词表没有任何问题。问题是在一份HTML里，com是每一个域名的结尾。页脚的友链、结构化数据里的地址、社交账号、CDN域名、图片源，一页下来轻松几十上百次。这一个词，把整张分数表压垮了。

更阴险的是它压得很均匀：所有站都有域名，所以所有站的葡萄牙语分数都被抬高了同一个量级。这让错误看起来不像错误，倒像一个稳定的规律。

修完之后掉到9.3%

修法有四步。第一，抓文本之前先把所有网址和域名模式清掉，用正则把 https:// 开头的串和形如 xxx.com 的串整体替换成空格。第二，从各语言词表里删掉跨语言撞车的词，com、pro、per、non这类全部拿掉。

工具自己划的及格线不算数，那个95%准确率是怎么来的。

第三，分数按词表长度归一，不让词表长的语言天然占便宜。第四，要求第一名的分数至少是第二名的1.5倍，否则判为测不出。

改完之后，不一致率从22.3% 降到9.3%，虚高了2.4倍。同时测不出的样本从4个涨到39个——这是好事，一把诚实的尺子应该在没把握的时候说没把握。

修之前和修之后，差在哪几格

报表本身也有黑洞，1000行与阈值过滤怎么补全。

最能说明问题的是最后一行。第一版里那些被判成葡萄牙语的页面，横跨丹麦语、意大利语、爱沙尼亚语、塞尔维亚语、英语，彼此毫无关系，唯一的共同点是页面上有域名。

另一个更隐蔽的坑：不支持的语言去哪了

第一版还有一个我当时没意识到的问题：我的词表只覆盖十几种语言，遇到爱沙尼亚语、塞尔维亚语、斯洛伐克语这类没配词表的，检测器不会说“我不认识”，它会挑一个分数最高的返回。

模型铺到七十多种语言那天，受益最多的不是最像英语的那几门。

于是这些页面全部被判成了某种它认识的语言，然后跟声明对不上，进了“不一致”那一栏。一个检测器不会因为遇到超纲题就交白卷，它会蒙一个答案，而蒙的答案照样进你的统计。

修正的办法就是加一道弃权线：不够自信就返回“测不出”，把这些样本从分母里拿掉，而不是让它们污染分子。这就是为什么修正后可比对样本从283掉到248——少掉的那35个，本来就不该被算进去。

为什么这个错误能撑过第一轮检查

说来惭愧，第一版跑完我是做过检查的。我看了整体分布，看了各语言的样本量，看了不一致的三类占比，都挺合理——13.4% 声明错、5.7% 属性错、3.2% 正文错，三类递减，符合直觉。

坏就坏在“符合直觉”这四个字。一个被污染的结果，只要污染是均匀的，它的形状就不会变，变的只有幅度。而我们检查数据的时候，绝大多数时候是在看形状，不是在看幅度。

形状对了，人就放松了。这也是为什么我一直建议在任何统计结论旁边留几条原始样本：形状能骗过人，具体的一行骗不过。我那十几个被判成葡萄牙语的丹麦语页面，只要看一眼域名和内容就知道离谱，但它们在汇总表里只是某个百分比里的一小部分。

还有一层：因为污染是均匀的，各语言的相对排序甚至都没变——真正是德语的页面，德语分数依然高于法语，只是都低于被虚抬的葡萄牙语。一个只看排序不看绝对值的检查，完全发现不了这个问题。

所以真正有效的那一步，是我把每一类不一致的样本按站点分组，看到某个类别里反复出现同一个语言。同一个答案在毫不相干的样本上反复出现，这是污染最可靠的指纹，比任何统计检验都直观。

这类尺子失效有个共同特征

它们几乎总是让问题看起来更严重，而不是更轻。原因也不难理解：噪声是随机撒进各个类别的，而“一致”只有一种情况，“不一致”有很多种，噪声天然往不一致那一侧倒。

收录数据到底信谁，6场景选型与三源校准也是先校尺子。

所以当一次批量测量得出的问题率明显高于常识时，先怀疑尺子，再怀疑世界。我这次要是没去翻具体案例，直接把22.3% 写出来，读到的人会拿着一个虚高一倍多的数字去做决策。

怎么给自己的检测器留一道自检

最省事的一条：把你不打算支持的类别显式排除，而不是让它们落到某个默认桶里。我那39个测不出，之前全被塞进了某个语言。

真假Googlebot怎么验，120种UA分类与验证方法是个现成例子。

第二条：给每次判定留一个置信度，低于阈值就弃权，宁可少报也别错报。第三条也是最有效的一条——手工看20个样本，比看20页统计报表管用。我这次就是靠肉眼看出葡萄牙语出现得太频繁。

还有第四条，成本最低但最容易被忽略：给你的检测器喂几个你知道答案的样本，看它答不答得对。我事后补了这一步，拿五个我确定语言的页面去跑，第一版检测器错了两个。这一步花五分钟，能省掉后面几小时的白干。

说到底，任何一次批量测量都是在用一把自制的尺子量世界。尺子准不准，世界不会告诉你，只能自己找几个已知长度的东西先量一遍。这个道理在做SEO数据分析时格外重要，因为我们量的东西大多没有权威答案，错了也不会有人报错。

同一个网址从不同国家抓，会是同一个页面吗？

这个问题是被上一节逼出来的。既然我的抓取源在国内，那些返回中文的页面，会不会只是因为对方按访问来源做了切换？

我从两条不同的网络各抓了一次

做法很简单：同一个网址，一条走国内的服务器，一条走海外的抓取通道，比对拿到的内容语言。挑的是所有声明与实际对不上的样本里最典型的几个。

海外用户打不开怎么排，从DNS、线路到CDN是同一套思路。

这一步不做的话，前面那13个“声明错了”的结论就是站不住的，因为完全可能是我这一侧的问题。

无人机那五个地址，两边都给中文

英国那个地址两边返回的都是简体中文的中国大陆版。这属于网址本身的行为，跟谁来访问无关。那五行hreflang是彻头彻尾的空头支票。

中文站为什么在又不在，Preferred Sources扩到16种语言那篇也是一次实测。

瑜伽服品牌的新西兰地址，两边给的不一样

同一个地址，从国内抓，lang属性是zh-cn；从海外抓，页面是英文的，导航是Women、Men、Accessories、Shoes。这属于服务端按访问来源换内容。

按端跳转和按地域跳转一个道理，自动跳转的SEO最佳实践。

两个例子放在一起才有意思：它们在我的第一版表格里长得一模一样，都是“声明en实际给zh”，但成因完全不同，处理方式也完全不同。前者要改的是那五行标注，后者要改的是整套地域路由策略。

一个网址的语言，未必是它自己的属性

这两个例子放在一起，结论就很清楚了：对相当一部分国际站来说，“这个网址是哪个语言版本”不是网址的属性，而是“网址加访问来源”这一对的属性。

Vary这个头就是为这种情况准备的，响应头的SEO机制讲过。

而hreflang是写在网址上的。你用一个只能描述网址的机制，去描述一件由网址和来源共同决定的事，中间那部分信息，无处安放。

Googlebot从哪抓，你控制不了

Google的抓取绝大部分来自美国，也会做地区感知抓取，但你没法指定。所以按访问来源切内容的站，等于把“Googlebot看到哪一版”交给了运气。

抓取端换一套规则会发生什么，移动优先索引与桌面掉量自救。

更麻烦的是这个运气不是一次性的：今天抓到英文版，下个月可能抓到别的。而hreflang表描述的是一个静态映射，它不可能跟着变。

怎么在自己站上验一次

不用搭什么环境。找一个你能用的境外网络出口，哪怕是手机开个国际漫游，或者让海外的同事帮忙打开一次，然后对同一个地址做三件事的比对：页面标题、货币符号、html标签上的lang属性。

CDN那一层会不会替你换内容，6层缓存与边缘路由得先搞清楚。

三样里只要有一样不同，你的站就是按访问来源在切内容。这件事一定要在做hreflang之前搞清楚，因为它决定了你整套标注是不是建立在一个成立的前提上。

更省事的一招是看响应头：如果响应里带着 Vary 且值里有跟地域相关的字段，或者有CDN加的地理标识头，基本可以确定内容是分地域的。这一步用一次请求就能完成，不需要任何工具。

这对hreflang意味着什么

意味着一个不能稳定返回同一份内容的网址，本来就没资格当独立的索引条目。它被降成别名，与其说是引擎的判决，不如说是这个网址自己的性质决定的。

在边缘改SEO的做法，边缘SEO的原理与落地形态。

反过来说，如果你希望某个语言版本真的成为一条独立记录，那它至少要做到一件事：不管谁来请求，它都返回同一份内容。这是入场券，不是加分项。

这条要求听起来简单，落地时会撞上一堆现实：价格要按当地货币显示，库存要按当地仓算，运费和税要按当地规则算，甚至某些商品在某些市场根本不能卖。这些都是合理的差异化需求。

可行的做法是把“地址决定的部分”和“来源决定的部分”分开。语言、文案、商品清单这些跟着地址走，货币显示、可售性提示这些跟着来源走，但不要让来源改变页面的语言和主体内容。前者是内容，后者是呈现，混在一起是所有地域化问题的根源。

那些一请求就跳走的备用网址还算数吗？

306次抓取里，有一个数字我一开始没打算量，后来发现它比错配率更能说明问题。

49个网址在抓取过程中发生了跳转

占全部306个的 16%。也就是说，每六条hreflang标注里，就有一条指向的地址不是最终地址。

改版之后的404和重定向链，死链检测一次揪出来。

这个数字比9.3% 的语言错配率高出不少，而且它完全不依赖任何语言检测——状态码和跳转次数是curl直接给的，没有解释空间。如果只能量一个指标，就量这个。

跳转终点往往是另一个语言版本

常见的几种：从裸域跳到带语言前缀的路径，从旧的国家路径跳到新的，从http跳到https再跳到区域站。跳完之后落在哪，取决于对方的路由规则，跟你在hreflang里写的那个地址已经没什么关系了。

双向跳转配错很容易绕圈，Apache与Nginx双向实战。

最典型的一种是把hreflang指向裸域，然后裸域按IP分流。这一条标注在不同国家的爬虫眼里，指向的是完全不同的页面。

指向重定向，等于自己动手把它降成别名

Gary举的那个短链例子里，被site: 查出来的正是一堆会跳转的网址，它们的身份就是别名。你在hreflang里填一个会跳转的地址，做的是同一件事：亲手把一个本可以成为条目的地址，写成了一个指路牌。

多域名跳主域这套配置，完整配置实战可以直接抄。

跳转的三种形态，处理方式完全不同

把这49条跳转按终点归了个类，形态只有三种，但该做的事各不一样。

五类问题网址的占比和排查顺序，Google抓取报告怎么读。

第一种是补全型：从没有斜杠的路径跳到带斜杠的，从http跳到https，从裸域跳到www。这种跳转的终点是确定的，跟访问者是谁无关。处理方式最简单，把hreflang里的地址直接改成终点就行，改完这一条就从别名候选变回了条目候选。

第二种是路由型：从旧的国家路径跳到新的结构，比如从 /uk/ 跳到 /en-gb/。这说明站点改过一次目录结构，而hreflang没跟着改。要做的不只是改这一行，是把整张表和站点地图一起过一遍，因为大概率不止这一条落下了。

第三种最麻烦，是分流型：跳到哪取决于访问者的IP或者浏览器语言。这一种改地址没用，因为终点本来就不固定。要么把这条hreflang指向一个不做分流的确定地址，要么把分流本身改成提示而不是强制跳转。

怎么区分自己遇到的是哪一种？同一个地址请求两次，一次带上英语的语言偏好头，一次带上德语的，看终点变不变。变了就是第三种，不变再看跳转链的形状：只跳一次且是协议或斜杠层面的，是第一种；跳到一个完全不同的路径结构的，是第二种。

这三种的处理成本一个比一个高：第一种改一行配置，第二种改一次全站，第三种要改产品决策。所以排查时先按类型分好，别一上来就挨个改地址——改到第三种那几条时你会发现，改了也白改。

18个网址根本没拿到正常页面

4个403、4个404、1个429、1个503、8个连接失败，合计18个，占5.9%。这里面404那4个最要命——你在告诉搜索引擎“这个语言版本在这儿”，而那儿什么都没有。

死链怎么批量查，检测、分类到提交一条龙。

403那4个也不能简单归为反爬。有两个我换了请求头重试仍然是403，说明那个路径对匿名访问就是关闭的。这样的地址写进hreflang，跟写一个404没有本质区别。

那8个连接失败的更值得说一句。它们不是超时，是域名解析不出来——也就是说，hreflang里写着一个已经不存在的域名。这种情况几乎只有一个成因：某个市场的独立域名到期没续，而所有还活着的页面上，指向它的那一行还在。

这类问题比404还麻烦一点。404至少说明域名还是你的，改回来很快；域名解析不出来，意味着这个域名可能已经被别人注册走了。等哪天有人拿它建了个站，你全站每个页面都在替一个陌生人做语言版本声明。

我知道这听起来有点耸人听闻，但过期域名被人接手做站这件事一直都有，圈子里买老域名做站甚至是一门生意。区别只在于，通常我们讨论的是你主动接手别人的域名，而这里是别人被动接手了你的，还顺带继承了你全站给出的一行推荐。

一条不能稳定返回200的标注，价值是零

不是价值低，是零。因为hreflang的作用是让引擎在合适的场景下把某个版本换上来，换上来的东西打不开，这个动作就不会发生。它甚至可能连累整组声明。

404被抓其实不全是坏事，软404修复指南说得更细。

该怎么查

把你hreflang表里的每一个地址，用一次不带任何登录状态的普通请求跑一遍，只看两件事：最终状态码是不是200，跳转次数是不是0。这两项不过，别的都不用看了。

一次查清页面被什么挡在索引外，可索引性一键体检。

这个检查一次跑完，一张60行的表大概两分钟。它能筛掉的问题，比任何一个hreflang校验工具报的都要实在，因为那些工具多数只校验语法和对称性，不去实际请求。

请求的时候有两件事必须做对，不然结论会歪。第一，不要带任何cookie和登录态，因为登录态会改变很多站的地域判断；第二，把跳转次数单独记下来而不是只看最终状态码。一个跳了三次最后返回200的地址，在状态码那一栏是完美的，在跳转次数那一栏是不合格的。

我第一版脚本就只记了最终状态码，跑完一看94.1% 正常，差点就收工了。是后来顺手加了跳转次数这一列，才发现16% 这个数。很多时候不是数据不在，是你没给它留一列。

规范网址指向别处的那13条，暴露了什么？

抓下来的287个正常页面里，我顺手把每一页的canonical也记了。

271个自指，13个指向别处，3个没写

自指率95.4%，看着挺健康。但那13个指向别处的，值得一个一个看，因为它们全都是同一类问题的不同长相。而且这13个不是零散分布的，它们集中在5个站上，也就是说这是站级别的模板问题，不是某个页面的意外。

跨页场景下的冲突诊断，canonical标签到底怎么用。

四个国家站的同一个页面

一个欧洲时装平台在瑞士、德国、奥地利、荷兰四个国家站上都有一个同名的个人中心页，四个页面的canonical全部指向各自国家站的首页。

它是提示不是命令，8种误用别再犯。

hreflang说这是四个语言版本的同一个页面，canonical说这四个页面都不是独立页面。两套信号在描述同一批地址，结论互相打架。

五个语言版本的规范网址都指向同一个后缀

一个德国户外品牌的表里，de-de、de-ch、fr-be、en-us四个地址加上裸域，canonical全部指向对应路径下的 home.html。

URL结构的细节会一路影响到这里，影响抓取与排名的9个细节。

这一组倒是自洽的，只是它把“目录首页”和home.html当成了两个地址，然后再用canonical把它们合回去。绕了一圈，回到原点，中间白白多出一层跳转和一层合并。

欧洲站和英国站都指向主站

一个3C配件品牌的en-DE和en-GB分别指向欧洲子域和英国子域，两个页面的canonical都指向主站的www。这等于明说：这两个都不是独立页面，请只记主站那一个。

跨子域看数据时，网域还是网址前缀资源会影响你看到什么。

那这两行hreflang是干什么用的呢？它们让主站那条记录多了两个别名。仅此而已。如果这就是你想要的，那没问题；如果你以为自己在经营三个市场站点，那账就算错了。

hreflang说是两页，canonical说是一页

这是最典型的信号打架。而这场架的结果没有悬念：canonical描述的是身份，hreflang描述的是关系，身份先于关系。被canonical判掉的地址，不会因为hreflang说它是德语版就重新获得独立身份。

它到底有没有生效，浏览器说它在body里那次排查很典型。

三个页面完全没写canonical

数量不多，但这种情况下引擎只能自己挑一个当规范，挑中谁全看信号强弱：内链多的、站点地图里出现的、被外链指的，更容易胜出。而这三样恰恰是你能施加影响的地方。

不同页面类型该怎么配，5类页面的差异可以当模板。

为什么这13条几乎都出现在“功能页”上

把这13个地址的路径过一遍，有个共同点：个人中心、购物车、门店查询、帮助中心、目录首页，全是功能页，几乎没有一个是商品页或者内容页。

帮助中心这类页面的索引控制，工程化怎么做。

原因不难猜。功能页在各个市场之间是完全一样的，翻译一下就能用，所以它们最容易被模板批量生成出多个地区版本；同时它们又没有独立的内容价值，所以团队里通常没人给它们单独配canonical，模板给什么就是什么。

两个批量动作叠在一起，就产生了一批既被hreflang声明成多个版本、又被canonical判成同一个页面的地址。它们不会造成排名损失，但会让你的多语言报表里凭空多出一批永远修不好的行。

先对canonical，再对hreflang

顺序不能反。canonical没理顺就去调hreflang，等于在流沙上砌墙。实操上的顺序是：先确保每个语言版本的canonical自指，再让hreflang成对声明，最后才轮到x-default和地区细分。

告警怎么分级处理，三平台分级诊断与90天闭环。

为什么这个顺序这么重要，可以用一个反例说明：有个团队花了三周把hreflang的对称性全部修好了，工具报告全绿，结果Search Console里的状态一动没动。后来才发现，那批页面的canonical全部指向英文主站——三周的活儿，改的全是一批别名之间的关系。

关系再正确，也改变不了身份。这就是为什么排查多语言问题时，我总是先要一份canonical的自指率，再看别的。这一个数不到95%，后面的活儿先别开工。

x-default那一行到底在替谁兜底？

88% 的覆盖率背后，写法的差异挺大。

它不是“英文版”的意思

最常见的误解，是把x-default当成默认英文版。它的实际含义是：当用户的语言地区跟你声明的所有组合都不匹配时，把这一个给他。它是兜底，不是主选。

全球格局摆在这儿，多平台优化实战比默认英文优先靠谱。

官方在本地化版本标注的指南里给的措辞是“当没有其他语言/地区更合适时”，这个“更合适”是相对的，不是绝对的英文优先。

语言选择页才是它的标准用法

官方文档给的典型场景，就是一个让用户自己挑国家和语言的页面。这类页面本身没有语言归属，正好承担兜底。

入口页怎么设计，10000个站的实测结论里有参照。

把x-default指向美国站，会发生什么

不会立刻出事，但你把一个没匹配上的用户，直接扔进了一个有明确地区归属的站。对巴西用户来说，他既不属于en-US，也没有pt-BR可选，落地页却是美国站的美元价格和美国仓的时效。转化数据会替你说话。

跨市场卖货还有一堆合规项，从商品条码到谷歌购物收录。

那个国家选择页刚好说明问题

本次样本里有一个欧洲美妆电商，hreflang声明en-US指向裸域，抓下来lang属性是cs，页面内容是一串国家名列表：Belgique、България、Česká republika、Danmark、Deutschland。

入口一多就容易爆炸，筛选器URL不爆炸的系统方案。

这个页面的真实身份就是国家选择页，它该挂的是x-default，不是en-US。挂错之后，美国用户会被引导到一个让他重新选国家的页面——本来一步到位的事，硬生生变成了两步，而且第二步的跳出率一向不低。

没写x-default会怎样

不匹配的用户由引擎自行判断落在哪个版本。这不是灾难，只是把选择权交了出去。12% 的站选择了这条路，多数是因为模板里没有这一项，而不是深思熟虑的决定。

抓取预算怎么分配，2026年的12项实操。

交出去之后引擎多半会给用户一个语言上最接近的版本，或者干脆给那个信号最强的版本——通常是主站。对英语站来说这个结果还行，对主站是德语或日语的品牌来说，一个巴西用户可能就直接落进了一个他一个字都看不懂的页面。

x-default写了但指向自己，算不算错

本次样本里有几个站，x-default指向的地址跟en-US那一行完全相同。这不算硬错误，引擎能读懂，但它把两件事合并成了一件：既宣称美国站是美国用户的版本，又宣称它是所有人的默认版本。

分页那一侧也有类似的自指问题，索引判断和canonical设置。

什么时候这样写是合理的？当你的主站确实是一个不带地区色彩的国际站，只是碰巧用美元和英文的时候。什么时候不合理？当那个页面上写着“美国境内免运费”“仅配送至美国”这类话的时候。那一刻它就已经是国家站了，不该再兼任默认页。

一个判断你该不该写的简单办法

问自己一句：我有没有一个页面，是专门给“我不知道你是谁”的访客看的。有，就把x-default指向它；没有，那就先做一个，或者干脆别写，别把某个国家站硬拉来顶班。

什么该做什么不该做，可交接的生产规范比拍脑袋强。

做这样一个页面其实不难，难的是说服团队它值得做。因为在数据上它几乎不产生直接转化——它的全部作用就是把人送去该去的地方，送完自己就退场了。这类页面在任何一个以转化为导向的复盘里都是垫底的。

如果非要给它找一个能上报表的指标，我建议看它的跳出率和跳转完成率：进来的人里有多少真的点了某个国家进去了。这个数低于七成，说明这个页面本身设计有问题，比如国家太多没分组、没有按访客的浏览器语言把最可能的那个排在前面。

还有个小细节容易被忽略：这个页面上每个国家的链接，最好指向对应语言版本的首页，而不是统一指向某个中转地址再分流。用户在这一步已经明确告诉你他是谁了，再让他多跳一次纯属浪费。

但它的价值不在自己身上。一个好的语言选择页，救回来的是那些原本会落错版本、看到看不懂的文字然后直接关掉的人。这部分损失不会出现在任何一份报表里，因为他们从来没有进入过漏斗。

语言代码的形态分布里，藏着一整套没人复查的默认值

2592行标注，我按形态归了个类。

另外66行x-default单独统计，不在上表内。

只写语言不写地区，什么时候更合适

当你确实只有一份该语言的内容、不区分市场的时候。写de比写de-DE更诚实，因为后者等于宣称你有德国专供的一版，而奥地利和瑞士用户会被推到别处去。

引擎对语言的理解一直在变，从关键词匹配到意图理解。

只占4.4% 说明大部分人没意识到这是个选项。模板默认输出语言加地区，于是所有人都在声明自己有国别版本，哪怕内容一模一样。

写了地区却没有对应内容，比不写更糟

这是本次数据里最普遍的浪费：把一份英文内容挂在en-US、en-GB、en-AU、en-CA、en-SG五个代码下。它不违规，但你要为此维护五倍的标注量，换来的是五个别名。

多语言跨模态那一套，MUM算法怎么影响SEO讲过。

成本还不只是标注量。每次你新开一个市场、关掉一个市场、换一个域名结构，这五行都要跟着改，而且要在所有页面上同步改对。

那什么时候这五行是真值钱的？当你打算未来给某个市场做差异化内容的时候。先把地址结构和标注铺好，等内容做出来直接填进去，比到时候再重排整套结构省事得多。这是一个合理的提前投入。

问题在于绝大多数人不是这么想的，他们只是照着平台给的市场列表全选了一遍。提前投入和顺手全选，在代码上长得一模一样，区别只在有没有人说得清为什么。能说清的，留着；说不清的，砍掉一半试试，不会有任何损失。

文字系统那一档为什么这么少

13行，全部集中在中文简繁上。这一档少，是因为大部分需要区分文字系统的市场，站长直接用地区代码糊弄过去了：用zh-CN代表简体、zh-TW代表繁体。

平台自带的实现是什么样，Magento 2的9个核心点是个参照。

能用，但遇到马来西亚、新加坡这种同语言不同书写习惯的市场就不够用了。W3C关于语言声明的问答里对这一点有很清楚的说明：文字系统子标签只在真正需要区分的时候才写，写了就要写对。

地区代码写错的几种典型

本次样本里见到的：用UK而不是GB（这个其实会被容忍）、把语言和地区顺序写反、用了已经废弃的代码、以及给一个根本没有业务的地区凭空造一行。

域名这一层的选择也有标准，TLD与老域名收购的8步决策。

标准是BCP 47，语言标记的语法定义写在RFC 5646里，语言用ISO 639，地区用ISO 3166-1的两位大写。这份文档不长，做国际站的人值得通读一次。

92.4% 都写成语言加地区，这个默认值合理吗

从数字上看，写语言加地区几乎成了行业默认。但默认不等于最优，它更多是工具链的产物：主流建站平台的多语言插件，配置项就是“语言”和“市场”两个下拉框，拼出来自然是这个形态。

变体那一侧的三层治理，Schema、canonical与URL是同一种思路。

什么时候这个默认值是对的？当同一门语言在不同市场确实有不同内容的时候——价格不同、库存不同、法律条款不同、甚至用词不同。英国人说trousers，美国人说pants，这就值得分。

什么时候它是浪费？当五个地区共用一份文案、一套价格、一个仓的时候。这时候你声明的不是五个版本，是同一个版本的五个化名。它们全部会成为别名，而你要为此维护五倍的标注。

那一行x是怎么留下来的

2592行里只有一个畸形值，比例低到可以忽略，但它值得单独说一句，因为它暴露的不是写错，是没人查。

工具本身也会坏，5步SOP与多源替代准备一手总没错。

任何一个hreflang校验工具，第一件事就是检查语言代码是否合法。x 不是合法的语言标记，也不是x-default，任何一次校验都会把它报出来。它还在那儿，只能说明这张表从生成那天起就没被校验过。

一个错误能存活多久，比这个错误本身严重多少更能说明问题。同样的道理适用于你自己的站：与其纠结某一行写得对不对，不如先确认这张表有没有一个定期跑的检查。

一份可以直接跑的自检清单

1. 每一行的地址，普通请求返回200，跳转次数为0
2. 每一行指向的页面，canonical自指
3. 每一行的语言代码符合BCP 47，地区两位大写
4. A声明B，B也声明A，包括声明自己那一行
5. 同一个语言代码在表里只出现一次
6. 整张表里至少有一行x-default，且它指向的页面没有地区归属
7. 抽查三行，人工确认页面正文语言跟声明一致
8. 行数除以去重网址数，也就是虚实比，控制在4以内

这套东西该怎么维护，才不会每半年重来一次？

讲了这么多问题，落到操作上其实只需要一样东西。

按性价比排的速赢清单，11个快速见效的动作可以并着做。

卡点是一张hreflang对账表

不是工具，是一张表。它要能回答一个问题：我声明了几个版本，我实际有几份内容，差额是多少。这个差额就是你的别名数量，也是你每次改模板要维护的额外负担。

这类定期任务用cron挂上去就行，备份、sitemap一条龙。

五列分别是什么

往上汇报的时候，6步翻译成业务语言更容易过。

第三列最容易被跳过，也最重要

因为前两列可以从页面上直接抓，第四第五列是管理信息，只有第三列既抓不到又不能省。而恰恰是这一列，把“我有60个语言版本”这句话打回原形：填完你会发现，60行标注背后可能只有11份内容。

预算会上怎么讲，用商业语言把这笔钱讲清楚。

填这一列的方法很土：把所有目标地址去重，然后人工确认哪些地址实际上指着同一份翻译。土归土，一个60行的站半小时能填完，而且填完之后一年不用重填。

有个加速的小技巧：不用逐个打开页面看，先按域名和路径前缀分组，同一组的大概率是同一份内容，抽查一个就能定性。真正需要逐个确认的，只有那些路径结构看不出规律的散户。

填完之后你会得到一个副产品，而且这个副产品往往比对账表本身更有用：一张“这几个市场共用一份内容”的清单。下次内容团队要改某个市场的文案时，这张清单能立刻告诉他这一改会影响哪几个市场——这个问题以前多半是靠某个老员工的记忆回答的。

多久跑一次

行数在12行以内的，改模板的时候顺手看一眼就够。超过30行的，建议每季度跑一次自动检查，只报三个数：跳转数、非200数、重复地址数。这三个数不变，就不用人去看。

批量监控收录可以用接口，2000条配额下的监控管线。

这张表放在哪，谁来填

放在哪不重要，重要的是它跟那份“市场配置表”是同一份，而不是两份。多数团队的问题不是没有配置表，是有两份甚至三份：运营手上一份，开发手上一份，模板里还硬编码了一份。

报表自己搭也不难，用Claude Code做GSC自定义报表。

填的人应该是那个能回答“这个市场的文案是谁在维护”的人，通常在内容或本地化那边，不在技术那边。技术能填的是前两列，第三列必须由知道内容归属的人来填。

如果这三份表能合成一份，本文里绝大多数问题会自动消失。那4个404，那3个重复语言代码，那18个站的虚高声明，追到根上都是“配置表有好几份，改了这份忘了那份”。

什么数字出现才值得叫人

非200大于0，立刻处理；跳转数比上次多，去看是不是路由改了；重复地址数变化，说明配置表里有市场被增删。其余的波动都可以忽略。

阈值设太紧会误伤，怎么不误伤GoogleBot那篇算过账。

这套阈值的设计原则是：只在有人改了东西的时候响，不在正常运行的时候响。一个一年响两三次的告警，才有人愿意看；一个每周都响的告警，三个月后就没人看了。

具体到实现，最简单的版本是一个每周跑一次的脚本：抓一次首页，把hreflang全部拆出来，逐个发请求，把三个数字追加到一个文本文件里。下次跑的时候跟上一行比，不一样就发个通知。二十来行代码的事，不需要任何平台。

关键在于比的是变化而不是绝对值。绝对值天天都有小波动——某个地区站临时维护、CDN某个节点抽风、某次抓取撞上限流。盯绝对值会被这些噪声淹没，盯变化只在真有人动了配置的时候才响。

一个30秒粗筛

打开任意一个语言版本的页面，看它的源码，做三件事：数一下hreflang有多少行；随便挑一行的地址在浏览器新标签里打开，看会不会跳；看这个页面的canonical是不是指向它自己。三样里有一样不对，这张表就该翻出来对一遍了。

要批量拿地址，6种格式解析与URL批量提取更快。

新开一个市场的时候，先做哪一步

顺序建议是这样：先把新市场的内容做出来并确认canonical自指，再把它加进站点地图，最后才动hreflang。很多团队反过来做——先在配置表里加一行，模板自动生成标注，内容还在翻译中。

反过来下架时怎么收尾，301、410与库存信号决策。

反过来做的代价是有一段时间里，你的表里有一行指向一个半成品或者一个回退页。这段时间可能是两周，也可能因为项目延期变成半年。而那半年里，引擎每次读到这张表，都会记下一个不成立的映射。

关掉一个市场的时候，最容易漏的是什么

漏的通常不是那个市场自己的页面，是其他所有市场页面上指向它的那一行。因为关站这个动作往往由运营发起，执行的是把域名或目录下线，而hreflang是写在每一个还活着的页面上的。

域名不要了也别直接扔，6信号怎么保住信任继承。

结果就是：那个市场没了，但剩下二十个市场的每一个页面上，都还留着一行指向它的声明。这一行现在指向一个404或者一个跳转。本次样本里那4个404，我怀疑有一半是这么来的。

换域名结构那次，最该提前做什么

多语言站迟早会遇到一次结构调整：从 /uk/ 换成 /en-gb/，从子域并回子目录，或者反过来。这种时候hreflang是最容易被落下的一块，因为它散落在每一个页面的头部，而不是集中在某个配置文件里。

提前该做的只有一件事：把hreflang的生成逻辑从模板里抽出来，让它读同一份市场配置。做到这一步，改结构就是改一份配置的事；做不到，就得在几十个模板文件里找那些硬编码的地址。

本次样本里第二种跳转——路由型——基本都是这一步没做到位的遗留。站点结构改完上线了，hreflang还指着旧路径，靠一层重定向硬撑着。撑得住，但每一条声明都多了一跳，而且这一跳还会在下次清理重定向规则的时候变成404。

顺带说个经验：结构调整上线之后，别只验主流程和商品页，专门挑三五个语言版本，把它们的hreflang整张表拉出来跑一次状态码。这一步花十分钟，能挡住后面半年的麻烦。

把预期调对，比修好它更省事

最后回到最开始那个问题。Search Console里那一片“未编入索引”，多数时候不需要修。你要做的是把hreflang表的行数降到跟内容份数接近，剩下的别名让它们安静地当别名。

那些数字为什么人人都读错，从配置到诊断的完整用法。

一个多语言站的健康程度，不看它声明了多少个版本，看它声明的版本数和内容份数之间的差额有多大。差额越小，你每次改动要同步的地方越少，出错的机会也越少。这个道理放在任何一套“描述关系”的标注上都成立。

写到这儿其实可以把这批数据串成一条线了。2592行标注背后，是75个站在向搜索引擎描述自己有多少个市场版本。这些描述里，16% 指向的地址会跳走，5.9% 拿不到正常页面，9.3% 说的语言跟给的语言对不上，4.6% 被自己的canonical判掉，5.3% 忘了声明自己。

这些数字彼此独立，加起来会重复计数，所以别去求和。但它们指向同一件事：这张表是被生成出来的，不是被维护出来的。生成不需要人，维护需要；生成一次就够，维护要跟着市场增删走。差别就在这儿。

所以真正的落脚点不是修某一行标注，是给这张表找一个主人。有主人的表，行数会往下走，虚实比会往1靠，那些畸形值活不过一个季度。没主人的表，会一直长，长到有一天没人敢动它，然后一个字母x在里面躺三年。

如果你现在手上正好有一个多语言站，今天能做的三件事按性价比排是这样：先花三分钟算一次虚实比，知道自己在什么位置；再花二十分钟把表里所有地址跑一遍状态码和跳转次数，把非200的挑出来；最后花半小时把内容归属那一列填了。

这三件事做完，你对自己站的多语言状况的了解，会超过绝大多数只看工具报告的人。因为工具报告回答的是“写得合不合规”，而这三件事回答的是“写的是不是真的”。后者才是所有麻烦的来源。

常见问题解答

Search Console显示未编入索引，我需要提交收录吗？

不需要。如果这个网址是某个规范页的hreflang备用地址，它本来就不会作为独立条目被索引。反复提交不会改变结论，只会消耗你的配额。要确认的是那个规范页本身有没有被正常索引。

那我的德语页面到底能不能被搜到？

能。别名会在用户查询匹配的时候被拿出来用，语言地区匹配正是最典型的匹配场景。能不能被搜到，跟有没有独立索引条目，是两件事。

换个引擎也一样，百度提交了为什么还不收录。

hreflang写在head、HTTP头还是站点地图里有区别吗？

三种位置都受支持，效果上没有优劣之分，选一种坚持用就行。区别在维护成本：站点地图适合行数多的站，因为改一个文件就够了；head里写适合行数少、模板简单的站；HTTP头主要用于PDF这类没有head的资源。混着用是最糟的选择，因为你会失去唯一的事实来源。

写进站点地图的做法，动态优先级与sitemapindex分页。

一个页面挂五个英语地区代码，会被判作弊吗？

不会。它不违规，只是浪费。真实成本是你要维护五倍的标注量，而且每次增删市场都要动这五行。如果内容确实不区分市场，写一个en更省事，也更诚实。

canonical和hreflang冲突的时候听谁的？

听canonical。它决定的是这个地址有没有独立身份，hreflang描述的是有身份的那些地址之间的关系。被canonical判给别人的地址，不会因为hreflang而重新拿回身份。所以排查顺序永远是先canonical后hreflang。

按用户IP自动切换语言，会影响hreflang吗？

会，而且影响不小。自动切换意味着同一个地址在不同来源下返回不同内容，这跟hreflang“一个地址对应一个语言版本”的前提直接矛盾。更稳的做法是给用户提示和入口，让他自己选，而不是替他跳转。

环境串了同样麻烦，8步清除与四层防御。

x-default应该指向哪个页面？

指向一个没有地区归属的页面，比如语言选择页。如果实在没有这样的页面，指向你的国际站或主站也行，但不要指向某个具体国家站——那等于告诉引擎，所有匹配不上的用户都是那个国家的人。

我的语言版本一直没被抓，是hreflang的问题吗？

大概率不是。hreflang不是抓取指令，它不会让引擎去抓一个原本不会抓的地址。一个语言版本长期没被抓，通常是因为它没有内链指过去、不在站点地图里、或者被robots规则挡住了。先查这三样，再回来看标注。

Search Console里能单独看某个语言版本的数据吗？

能看，但要理解你看到的是什么。用网页过滤按路径筛，能看到那个语言目录下的表现数据；但如果该目录下的地址多数是别名，数据会记在规范页那一侧，筛出来的数字会明显偏低。这不是报表出错，是记账口径的问题。

用工具跑出来的hreflang报告说全绿，还需要自己查吗？

需要。市面上多数校验工具查的是语法和对称性：代码合不合法、A有没有回指B。这两项确实重要，但它们都不实际请求那个地址。本次数据里16% 的跳转和5.9% 的非200，在语法层面全是合法的。

工具报告怎么读，五维度100分审计也提醒别只看总分。

子域名和子目录做多语言，哪种更不容易出这些问题？

子目录明显更省心，因为所有语言版本共享同一个域名的信任度，也共享同一套模板和同一份站点地图逻辑，出错面小。子域名和独立域名的优势在于本地化程度和运营独立性，代价就是这套标注要跨域维护，本次样本里跳转和错配集中出现的，恰恰是跨域那几个站。

服务端这一层怎么统一治理，6层综合治理实战。

hreflang里的地址必须是绝对路径吗？

必须。相对路径在这里不受支持，写了等于没写。同理，地址里的协议要跟你实际提供服务的协议一致，还在混用http和https的站要特别注意，一个协议不匹配就足以让这条声明失效。

我的站只有中英两个版本，值得折腾这一套吗？

值得，而且成本极低。两个版本只需要四行标注：中文版声明自己和英文版，英文版声明自己和中文版，再加一行x-default。全部工作量不超过半小时，之后基本不用再动。这套东西的维护成本是随版本数指数上升的，两个版本的时候几乎为零。

怎么快速判断我的多语言标注是虚的还是实的？

数两个数：hreflang行数，和你真正维护着独立文案的市场数。前者除以后者，商越接近1越健康。本次样本里这个商普遍在1.5到3之间，个别站超过5。超过4就说明你在为一堆别名付维护费。

权威参考资料