hreflang生成器给的sitemap代码，粘上去就是一份单向标注

摘要：这款生成器出的两份代码，质量差得有点远。HTML那一份是对的，标签集完整、带自引用、x-default也在，复制到每个语言版本的头部就能用。Sitemap那一份不能直接用——我们团队用四个语言版本实测，它只吐出一个 url块，loc固定是x-default那条地址，另外三个语言页在这份代码里完全没有归属。而谷歌的要求是为每个网址各建一个url元素、每个元素里列出包括自己在内的全部版本。更微妙的是，工具自己的提示语明明写着“标签必须双向引用才生效”，它却生成了一份单向的。另外自动生成网址时www会被静默剥掉，批量导入猜语言码会把 /my/ 认成马来语。

hreflang是国际化SEO里最容易被做成“看起来做了”的一件事。标签写了，代码也上线了，搜索控制台里却常年一片红，或者干脆什么反馈都没有——因为它的失效方式极其安静，不报错、不警告，就是不生效。

它安静的原因在于规则本身：这套标注不是单方面声明，而是一组页面之间的相互确认。一旦某一环没对上，整组标注会被当作无效丢掉。而工具通常只帮你生成其中一环。

这篇要做的事，是把这款生成器给你的东西拆开看：哪一份可以直接用，哪一份必须自己加工，以及加工的时候要补上什么。

这个生成器到底替你做了什么？

它做的是一件很朴素的事：把你填的语言、地区、网址整理成一张表，然后按两种模板拼成代码。整个过程在你自己的浏览器里完成，不经过服务器。

界面上有两种工作方式。自动模式下你只填一个基础网址，选好网址结构，工具会按规则给每个语言版本推算出对应的地址。手动模式下每条地址你自己填，工具只负责拼标签。

输出可以选HTML、Sitemap或者两者都要。这两种形态对应hreflang的两种落地方式：写在页面头部，或者写进XML网站地图。两种方式官方都认，选一种做到底就行，同时做两份反而增加维护成本，还容易两边打架。

需要说清楚的是它的能力边界：它只管把代码拼出来，不验证你填的地址是否存在、是否互相指向、是否和页面上的canonical标签一致。这三件事恰恰是hreflang失效的三大原因。

这种分工其实很常见——生成器管拼装，验证是另一码事。麻烦在于hreflang这件事上，拼装的部分本身就不难，难的全在验证那一侧。所以用它的时候心里要有个预期：它替你省的是敲键盘的力气，不是动脑子的力气。

另外还有一层：它一次只处理一组页面。所谓一组，指的是同一个内容的各个语言版本，比如首页的四国语言版是一组，某个产品页的四国语言版是另一组。工具不知道你站上有多少组，也不会帮你跨组检查一致性。页面一多，这个“一次一组”的节奏就是主要的成本来源。

三种网址结构该怎么选？

自动模式提供子域名、子目录和组合三种结构，选哪种不只是形式问题，它影响后续的运维成本。

谷歌的多地区站点文档给出的判断依据很实在：国家顶级域名给出的地域信号最强，但成本高、只能对准一个国家；通用域名下的子目录维护最省心；子域名配置灵活，缺点是用户不一定一眼看出这是给哪个地区的。

官方还明确不推荐一种做法：用网址参数区分地区，比如在地址后面挂个地区代码。这种结构没法按网址做切分，搜索引擎和分析工具都难处理。工具没提供这个选项，算是替你挡掉了一个坑。

对绝大多数刚开始做多语言的站，子目录是稳妥的默认选择。等某个市场真的做到需要独立团队、独立服务器的规模，再考虑拆出去。

为什么它生成的sitemap代码是单向的？

这是全文最关键的一节，也是这款工具最需要提防的地方。

我们做了一次干净的验证：填入四个语言版本——英语美国、中文中国、德语德国、日语日本，其中英语版设为默认，然后分别取HTML和Sitemap两份输出。

HTML那份没问题，五行标签，四个语言版本各一行，外加一行x-default，指向默认版。

Sitemap那份是这样的：

<url>
  <loc>https://example.com/</loc>
  <xhtml:link rel="alternate" hreflang="en-US" href="https://example.com/" />
  <xhtml:link rel="alternate" hreflang="zh-CN" href="https://example.com/zh/" />
  <xhtml:link rel="alternate" hreflang="de-DE" href="https://example.com/de/" />
  <xhtml:link rel="alternate" hreflang="ja-JP" href="https://example.com/ja/" />
  <xhtml:link rel="alternate" hreflang="x-default" href="https://example.com/" />
</url>

数一下：四个语言版本，输出里只有一个 url 块。这个块的 loc 是 https://example.com/，也就是默认版那条地址。

这意味着这份代码只声明了一件事：英语版有这四个语言的替代版本。至于中文版、德语版、日语版有没有替代版本，这份代码只字未提。

谷歌的本地化版本文档对sitemap写法的要求写得非常具体：为每个网址创建一个单独的 url 元素，并且每个 url 元素都必须有子元素列出每一个替代版本，包括它自己。按这个要求，四个语言版本应该产出四个 url 块，每个块里各有五行标注。

差距是四倍。

单向标注上线之后会发生什么？

不会报错，这正是它麻烦的地方。

hreflang的生效机制是相互确认。谷歌的原话是：如果两个页面没有互相指向，这些标签会被忽略。你在英语版上声明“德语版在这里”，谷歌会去德语版看一眼，确认德语版有没有反过来说“英语版在那里”。确认不上，这条关系就不算数。

把上面那份单向代码贴进sitemap，结果是：谷歌读到英语版指向另外三个版本的声明，然后去另外三个版本找回指，一个都找不到——因为这份sitemap里根本没有它们的 url 块。于是四条关系全部作废。

整套标注等于没做，但你的文件里确实躺着五行 xhtml:link，控制台里也不会跳出红色警告告诉你“这些标注是单向的”。这就是那种典型的“看起来做了”的状态，能瞒过内部检查，瞒不过搜索引擎。

最讽刺的是，工具自己是知道规则的。生成结果下方那行提示语原文写着：标签必须双向引用才生效。它把正确的规则告诉了你，然后给了你一份不符合这条规则的代码。

那么这份sitemap代码该怎么用？

它不是废的，把它当模板就行。正确的用法是拿它当一个块的样板，自己复制成N份。

具体做法是：把生成的那个 url 块复制四份，然后逐份修改 loc，让它们分别指向四个语言版本的地址。中间那五行 xhtml:link 完全不用动——每个块里的替代版本清单本来就应该一模一样，包含全部版本和x-default。

改完之后的结构大致是这样：

<url>
  <loc>https://example.com/</loc>
  ...五行标注...
</url>
<url>
  <loc>https://example.com/zh/</loc>
  ...同样的五行标注...
</url>

四个语言版本就是四个块，每个块里那五行标注一字不改地重复。这一点常让人觉得别扭——五行标注抄四遍，看着冗余得很。但这正是规范要求的：每个页面都要独立、完整地声明自己所在的这一组。

顺带说个对照：同一个站上那款做XML网站地图的工具，在这件事上反而做对了。它的多语言模式会给每条地址各建一个 url 块，结构完全符合规范。同一件事两款工具一对一错，具体差别我们在Sitemap生成器那篇实测里也提到了。语言版本多的时候，用那款拼骨架可能更省事。

直接粘进sitemap.xml为什么会报解析错误？

因为工具给的是个片段，不是完整文件，缺了两样东西。

第一样是外壳。sitemap文件必须有一个 urlset 根元素把所有 url 块包起来，还得有XML声明行。工具输出的是从 <url> 开始的裸片段。

第二样更容易被忽略：命名空间声明。那些标签前面的 xhtml: 前缀不是随便写的，它必须在根元素上声明来源。声明缺失时，XML解析器遇到一个没定义过的前缀会直接报错——不是警告，是整个文件解析失败。

完整的头应该长这样：

<?xml version="1.0" encoding="UTF-8"?>
<urlset xmlns="http://www.sitemaps.org/schemas/sitemap/0.9"
        xmlns:xhtml="http://www.w3.org/1999/xhtml">

粘进已有文件的话，检查一下那个文件的 urlset 上有没有 xmlns:xhtml 这一句。绝大多数插件生成的sitemap是没有的，因为它们本来就不打算放hreflang。少了这句，你辛苦拼的四个块会让整份文件报废，连原来能正常工作的部分一起废掉。

这也是我们更推荐用HTML方式落地的原因之一：改页面头部只影响单个页面，改sitemap一旦出错是整份文件级别的事故。

HTML那一份为什么反而可以直接用？

说完毛病，得公道地讲讲它做对的地方。HTML输出这一份质量是合格的。

它输出的标签集包含三个要件：每个语言版本各一行、其中包含指向自己的那一行、外加一行x-default。这三样齐了，就是一份完整的标注。

自引用那一行特别容易被手写的人漏掉。很多人觉得“这是我自己，还用得着标”——用得着。官方文档明确要求每个语言版本必须列出自己以及所有其他版本。少了自引用，这一组的对称性就破了。工具默认就带着它，省了一个常见错误。

x-default的处理也对。它是额外的一行，指向你设为默认的那个版本，而不是替换掉那个版本原本的标注。所以默认版会出现两次——一次以自己的语言代码出现，一次以x-default出现。这不是重复，是正确写法。

用法很直接：把这一整段复制到每一个语言版本页面的头部区域，一字不改。四个语言版本，四个页面，贴同样的内容。这样每个页面都完整声明了自己所属的组，双向确认自然成立。

自动生成的网址里，www去哪儿了？

这是个藏得比较深的行为，我们实测才发现。

在自动模式下填入基础网址 https://www.example.com/shop/，选子目录结构，工具给德语版生成的地址是 https://example.com/de/shop/。www 不见了。子域名结构下同样如此，www 会被剥掉之后再拼上语言前缀。

从代码逻辑上看这是有意为之——处理子域名结构时必须先把已有的前缀去掉，否则会拼出 de.www.example.com 这种畸形地址。问题在于它对子目录结构也一视同仁地剥了，而子目录结构根本不需要动主机名。

后果取决于你的站怎么配置。如果 example.com 会301跳到 www.example.com，那么这批hreflang全都指向了跳转地址。搜索引擎沿着标注走过去，得到的是一次重定向，而不是目标页面本身。

这类标注即便不算完全失效，也是在给自己制造不必要的信号损耗——你告诉搜索引擎“德语版在这儿”，它到了那儿却被告知“不对，在隔壁”。做多语言的站在这一步翻车，往往几个月后才从数据里看出端倪。

解决办法很简单：自动生成之后，逐条核对地址栏里的主机名对不对。工具生成的地址是可以直接编辑的，改完再点生成。或者干脆用手动模式，自己把每条地址填准，稳当。

批量导入猜出来的语言代码可信吗？

不太可信，得逐条看过。

批量导入功能会从你粘进来的网址里猜语言。它的判断依据是路径里的两字母目录段——看到 /de/ 就认成德语，看到 /ja/ 就认成日语。规则简单，多数时候管用，但两字母目录并不都是语言代码。

我们拿五条地址试了一遍，结果如下：

后四条全是误判。my、no、it 恰好都是合法的语言代码，也恰好都是英文里的常用词，这种巧合在真实站点的路径里并不罕见。而最后一条说明它只认第一个匹配到的两字母段，多层结构会取错。

批量导入的价值在于省去逐条粘贴地址的力气，这部分它做得不错。猜出来的语言代码就当个初始值，导入之后挨个下拉框核对一遍，几十条也就一两分钟的事。把这一步省掉，你可能会给账户页打上马来语的标签，然后困惑为什么马来西亚的流量一直不对劲。

语言代码和地区代码怎么填才规范？

这一处工具帮你规避了大部分风险，因为它用的是下拉选择，不让你自由输入。

hreflang的取值要求遵循BCP 47语言标签规范。这套规范由RFC 5646定义，语言子标签来自ISO 639-1的两字母代码，地区子标签来自ISO 3166-1的两字母国家代码，中间用连字符连接。

工具生成的代码形如 en-US、zh-CN，语言小写、地区大写。这个大小写用法符合RFC 5646的书写惯例——规范里说明两字母的地区子标签按惯例全大写。严格来说搜索引擎对大小写不敏感，但按惯例写更利于人读，也更不容易在跨系统传递时出岔子。

有两个容易搞错的点值得单独说：

• 第二段是地区不是语言。en-GB 的意思是“给英国用户看的英语版”，不是“英式英语”。它约束的是受众所在地，不是语言变体。
• 只有语言没有地区是合法的。de 表示“给所有德语使用者”，覆盖德国、奥地利、瑞士。除非你真的为不同国家准备了不同内容（比如价格和配送政策不同），否则只写语言更省事，也更不容易做错。

反过来，只写地区不写语言是不合法的。没有 -US 这种写法，语言子标签是必需的。工具的下拉设计不让你这么填，这一点上它是安全的。

x-default到底该指向哪个页面？

工具让你在语言列表里点一个地球图标指定默认版，这个选择决定了x-default那一行指向哪儿。很多人随手点了英语版就过去了，其实这里值得想两秒。

x-default的语义是：当用户的语言和地区都不匹配你列出的任何一个版本时，把他带到这里。它是个兜底出口，不是“主版本”的意思。

按这个语义，合适的候选有两类。一类是语言选择页——用户落地后自己挑，适合语言版本多、受众地域分散的站。另一类是覆盖面最广的那个语言版本，通常是英语版，适合大部分站点，因为英语是最可能被看懂的兜底选项。

不合适的选择也很明确：别指向一个小语种版本。如果你的x-default指向德语版，那么一个用泰语的用户搜到你的站，落地看到的是一页德语。这不是兜底，这是把人劝退。

还有个常见疑问：x-default是必须的吗？严格说不是强制项，标注组里没有它也能工作。但加上它成本极低，收益是把“其他所有人”这部分流量的落地行为掌握在自己手里，而不是交给搜索引擎猜。工具默认就带着这一行，不用特意去掉。

同一种语言卖到好几个国家该怎么标？

这是跨境电商最常撞上的场景：英语站要同时面向美国、英国、澳大利亚，三个市场的价格、货币、配送政策都不一样，但正文内容高度重合。

这种时候语言代码就得带上地区了，写成 en-US、en-GB、en-AU。工具的地区下拉框正是为这个场景准备的，选了地区之后生成的代码会自动变成带连字符的形式。

但要提醒一句：hreflang解决的是“给谁看”的问题，解决不了“内容太像”的问题。三个站点的商品描述如果一字不差，搜索引擎照样可能认为这是重复内容而只选一个收录。hreflang的作用是在它决定收录之后，把对的版本送到对的用户面前，而不是保证三个版本都被收录。

所以这类站的功课得做在内容上：价格和货币要真实体现地区差异，配送时效和退换政策要写各自的实际情况，尺码表要按当地标准。有了这些实质差异，三个版本才站得住。这个话题的细节，同一种英语卖到美英澳那篇拆得比较透。

另外别忘了给这一组加一个只写语言的兜底项。除了三个带地区的版本，再标一个 en，指向你最主要的那个英语站。这样爱尔兰、新加坡这些没单独做站的英语市场也有个明确归属，不至于被随机分配。

页面头部、网站地图、HTTP头，三种方式怎么选？

hreflang官方认可三种落地位置，工具只覆盖了前两种，第三种得自己配。

选择的关键不在于哪个更好，而在于只选一种。三种方式官方都认，但同时用两种就得同时维护两份，一旦有一处漏改，两份就会打架，而搜索引擎面对矛盾信号时通常谁都不信。

页面少于几百个、模板改得动，就用页面头部，最直观也最好排查——右键查看源代码就能验证。页面成千上万、或者模板归别的团队管，就用网站地图，一个文件管全站。

第三种方式很少用到，但有个场景绕不开：多语言的PDF手册。这类文件没有HTML头部可写，只能在服务器上给它们配响应头。做产品文档站的可能会碰上，配置方法在.htaccess重定向生成器那篇提到的服务器配置思路里有相通之处，都是在服务器层面而不是页面层面动手。

多语言站还有哪些配套动作容易被漏？

标注做对只是及格线，下面这几件事没做好，多语言站照样跑不起来。

语言切换器要用真链接。页面上那个切换语言的下拉框，如果是靠脚本跳转的，爬虫走不过去。它应该是实实在在的 a 标签，能被点击也能被抓取。这一条经常被前端做成纯脚本交互，然后整站的语言版本互相之间一条链接都没有。

别按IP强制跳转。检测到用户来自德国就自动跳德语版，听着贴心，实际上爬虫大多从美国的地址访问，一跳就把它们全导到英语版去了，其他语言版本永远抓不到。正确做法是提示而不是强制——弹个横幅问“要不要切换到德语版”，把选择权留给用户。

翻译要真翻译。机器翻译直接上线、或者只翻了界面文案而正文还是英文，这类页面在搜索引擎眼里价值很低。语言版本的价值来自内容本身对当地用户有用，不是来自多了一个语言标签。

每个版本都要有自己的内链网络。德语版的文章之间要互相链接，而不是全都链回英语版。一个只有入口没有内部链接的语言版本，爬虫进去转一圈就出来了。

做多语言标注最常见的五个错误长什么样？

把前面散落的问题集中成一张表，上线前对着过一遍。

这五条里，前两条本质上是同一件事的两种表现——都是对称性没做到。它们加起来大概占了hreflang失效原因的一多半，而工具生成的那份单向sitemap代码，正好会把你直接送进第一条。

第三条最隐蔽，因为标注本身写得完全正确，问题出在地址多了个或少了个 www、多了个或少了个末尾斜杠。这类差异肉眼扫过去根本看不出来，得真去访问一遍才知道。

hreflang和canonical打架了听谁的？

这是多语言站最容易自伤的一处，工具完全管不到，但不讲清楚前面做的都可能白费。

最常见的错误做法是：把所有语言版本的canonical都指向英语主版本。想法是“避免重复内容”，实际效果是亲手废掉整套hreflang。

因为这两个标签说的是相反的话。canonical指向别处，意思是“我不是正主，请收录那个页面”；hreflang说的是“我们是一组平等的语言版本，请按用户的语言各收各的”。两个信号撞在一起，搜索引擎按canonical来——于是所有语言版本都被合并到英语版，其余语种在搜索结果里彻底消失。

谷歌关于网址规范化的文档给出的做法很明确：使用hreflang时，要为每个页面指定同语言的规范网址。也就是说德语页的canonical应该指向德语页自己，而不是英语页。

同一份文档里还有一条提醒：别用不同的方式给同一个页面指定不同的规范网址，比如网站地图里说是这个、页面上的canonical标签说是那个。信号打架的时候，搜索引擎只能自己猜，而它猜的结果通常不是你想要的。

值得一提的是，文档里还说到谷歌在做规范化判断时，会偏好那些属于hreflang集群的网址。把这一组做对做完整，本身就是一个正向信号。关于这套标注在落地时的对称性细节，hreflang标签怎么落地那篇讲得更细，做之前值得过一遍。

几个语言版本才值得动手做标注？

这个问题值得在动手之前想清楚，因为hreflang是有维护成本的，而且成本随版本数增长得不慢。

只有两个语言版本时，收益最直接，工作量也最小——两个页面各贴一份三行的标签集，做完基本不用再管。这个投入产出比很好，值得做。

到四五个版本，事情开始变得需要纪律。每新增一个语言，所有已有版本的标签集都要跟着加一行。四个版本时是四个页面各改一次，五个版本时是五个页面各改一次。漏改任何一个，那一组的对称性就破了，而破了不会有任何提示。

再往上，手工维护基本就不现实了。十个语言版本意味着每个页面头部有十一行标注，全站几千个页面，任何一次结构调整都可能引发大面积失效。这个规模必须交给程序——要么用建站系统的多语言插件自动输出，要么写脚本从数据库生成网站地图。

那这类手工生成器的位置在哪儿？主要在两处：做样板——先手工拼一组标准的出来，确认结构对了，再让开发照着这个格式做自动化；做排查——线上某一组标注不对劲，用工具重新拼一份正确的，和线上那份逐字比对，差异一眼可见。

还有一种情况适合手工：语言版本不多，但页面结构特殊，比如只有几个落地页需要做多语言，主站其他部分不涉及。这种局部需求上插件反而是杀鸡用牛刀，手工贴几段最干脆。

标注上线之后怎么确认它真的生效了？

生成代码只是第一步。hreflang的验证有点特殊，因为它是组关系，得成组地看。

第一步，抓源码对称性。把每个语言版本的页面源码拉下来，看头部的标签集是不是完全一致。四个页面应该有一模一样的五行标注。任何一个页面少一行或者地址写错一个字符，这一组就破了。

第二步，跟着标注跳一遍。把标注里的每个地址挨个打开，确认返回的是200而不是跳转，落地的也确实是那个语言的内容。这一步能抓出前面讲的www被剥掉的问题。

第三步，查canonical。每个语言版本的canonical应该指向自己。这一条最容易被CMS的默认配置搞砸，尤其是用插件做多语言的站。

第四步，看控制台反馈。搜索控制台里有专门的国际定位报告，会列出检测到的hreflang错误，最常见的两类就是“没有返回标记”和“未知的语言代码”。这两条正好对应本文讲的两个坑。

另外提醒一句关于时间的预期：hreflang生效不是立等可取的事。搜索引擎得把这一组页面全都重新抓一遍，才能确认对称关系成立，页面多、抓取频率低的站等上几周很正常。所以上线后头两周没看到变化，先别急着改代码，那样只会让你分不清是哪一版在起作用。

页面数量多的时候，前两步靠人眼不现实，用爬虫工具跑一遍更实际。关键是别只验一个页面就宣布完工——单个页面的标注看着再完美，只要对面没回指，它就是不生效的。

常见问题解答

工具生成的sitemap代码可以直接粘进网站地图吗？

不可以，得先加工。它只输出一个url块，loc固定是默认版那条地址，四个语言版本共用这一个块。而谷歌要求为每个网址各建一个url元素、每个元素列出包括自己在内的全部版本。正确用法是把这个块复制成N份，逐份改loc指向各语言版本，中间那几行标注一字不动。另外它给的是裸片段，缺urlset外壳和xmlns:xhtml命名空间声明，直接粘会让整份文件解析失败。

单向的hreflang标注上线会报错吗？

不会报错，这正是它麻烦的地方。hreflang靠相互确认生效，谷歌明确说过两个页面如果没有互相指向，标签会被忽略。单向标注的结果是整组关系全部作废，但文件里确实躺着那几行标签，控制台也不会主动告诉你它们是单向的。这属于典型的看起来做了，能瞒过内部检查，瞒不过搜索引擎。

HTML那一份输出可以直接用吗？

可以，这份是合格的。它包含三个要件：每个语言版本各一行、指向自己的自引用那一行、以及一行x-default。用法是把整段复制到每一个语言版本页面的头部，一字不改，四个页面贴同样的内容。默认版会出现两次，一次以自己的语言代码、一次以x-default，这不是重复而是正确写法。

为什么自动生成的网址里www不见了？

工具在推算多语言网址时会先把主机名里的www剥掉。这个处理对子域名结构是必要的，否则会拼出畸形地址，但它对子目录结构也一视同仁地剥了。如果你的站会从不带www的地址301跳到带www的，那这批标注全都指向了跳转地址，搜索引擎沿着标注走过去只会得到一次重定向。生成之后逐条核对主机名，或者直接用手动模式填准。

批量导入自动识别的语言代码准吗？

只能当初始值，必须逐条核对。它的规则是从路径里找两字母目录段，看到de认德语。问题是两字母目录未必是语言，实测 /my/account/ 被认成马来语、/no/results/ 被认成挪威语、/it/support/ 被认成意大利语，而多层结构如 /en/de/ 只取第一段。导入之后挨个下拉框看一遍，几十条也就一两分钟。

可以只写语言不写地区吗？

可以，而且多数情况下更推荐。只写语言表示面向所有使用该语言的用户，比如德语版覆盖德国、奥地利、瑞士。只有当你真的为不同国家准备了不同内容，比如价格和配送政策不一样，才需要细分到地区。反过来只写地区不写语言是不合法的，语言子标签是必需的，工具的下拉设计不让你这么填。

所有语言版本的canonical都指向英文主版本行不行？

绝对不行，这会亲手废掉整套hreflang。canonical指向别处等于声明自己不是正主，hreflang说的是这些版本平等各收各的，两个信号相反时搜索引擎按canonical走，结果是其余语种在搜索结果里彻底消失。谷歌的规范化文档要求使用hreflang时为每个页面指定同语言的规范网址，德语页的canonical就该指向德语页自己。

权威参考资料

• 谷歌本地化版本标注指南——“为每个网址创建一个单独的url元素”以及每个元素必须列出包含自身在内的全部替代版本，这两句是判断本文那份单向代码不合规的直接依据。
• 谷歌多地区与多语言站点管理——国家顶级域名、子域名、子目录三种结构的取舍分析，以及明确不推荐用网址参数做地域定位的表述。
• 谷歌网址规范化文档——“使用hreflang时为每个页面指定同语言的规范网址”的原文出处，也说明了谷歌在规范化判断中偏好属于hreflang集群的网址。
• RFC 5646语言标签规范——BCP 47的主体文件，规定语言子标签取自ISO 639-1、地区子标签取自ISO 3166-1，以及两字母地区子标签按惯例大写的书写约定。
• MDN link元素文档——hreflang属性的取值必须是有效的BCP 47语言标签，以及该属性仅在href存在时才有意义的说明。
• Sitemaps XML协议——urlset根元素与XML命名空间声明的结构要求，解释了为何缺少xmlns:xhtml声明会导致整份文件解析失败。