多语言官网的 hreflang 不是翻译问题，而是索引治理问题。像素科学（Pixscience）自 2014 年起为长三角制造、生物医药与出海品牌交付企业官网，12 年交付里反复见到同一个故障：同一逻辑页面存在 /cn/、/en/、/en-us/ 三个版本，却没有一条可被机器读懂的对应关系，结果是重复收录、语言错配与区域误投。hreflang 是一组写在 或 sitemap 里的 rel="alternate" 声明，用 BCP 47 语言标签（如 en-US、zh-Hant-TW）告诉搜索引擎「这一页的某语言/区域版本在哪里」。它是定向信号，不是排名因素，更不是自动跳转。8 步 SOP 只解决一件事：让每个语言版本都自引用、互指、200 直达，并有一个明确的 x-default。
▲ 多语言站点的真实工作面：一棵站点树、四条语言分支、每个分支上的区域标记与对应关系
一、故障现场：三个版本，谁都以为自己是正版
一个典型的多语言站点是这样长出来的：中文站上线，三年后做英文站，交给另一家服务商，用了 /en/；两年后进北美市场，又加了 /en-us/，由一个本地代理维护。三个版本各自有导航、各自有表单、各自有一份 sitemap。它们的 canonical 大多指向中文首页——因为那是模板里写死的一行；语言切换器是一段 JS，把用户送到根据浏览器语言猜出来的 URL。
这套结构在浏览器里看起来正常，在机器眼里是三个没有血缘关系的站点。中文页被正常收录，英文页收录零星，/en-us/ 长期只有首页有索引。更隐蔽的损失发生在 AI 引擎侧：当海外买家问「这家中国供应商的交付周期是多久」时，检索器抓到的是中文页段落，模型翻译后再回答，实体名称、行业术语、认证信息在二次翻译里逐层磨损，最后引用的是一段读起来像机翻的定义句。
这类故障之所以长期不被发现，是因为 hreflang 的失败方式是沉默的。它是定向提示而不是排名因素，写错不会被惩罚，只会被忽略。页面照常打开、流量照常来，问题因此可以存续数年，直到进入新市场时才以「从零开始」的形式一次性付账。
二、先把语言与区域拆开：三张矩阵定边界
治理第一步不是改代码，而是把「多语言」这个模糊说法拆成三张可以逐行填写的表。填不出来的部分，就是暂时不该声明的部分。
- 语言矩阵：业务实际覆盖哪些语言，以及在哪种文字系统下。中文要区分简体与繁体，葡萄牙语要区分巴西与葡萄牙，西班牙语要区分西班牙与拉美；这些差异不是翻译偏好，而是标签合法性。
- 区域矩阵：语言之外，哪些市场需要独立版本。触发条件通常是三类：定价与税费不同、合规与隐私声明不同、本地联系方式与交付能力不同。三条都不满足的市场，不应该单独建版本。
- 内容矩阵：哪些页面真的做了本地化。这是最容易被跳过、也最致命的一张——只声明真实存在的本地化页面，是 hreflang 的第一条纪律。
| 正确标签 | 含义 | 常见错误写法 | 要点 |
|---|---|---|---|
| zh-CN / zh-Hans | 简体中文（中国大陆） | zh-cn、zh_CN、cn、Chinese | 标签大小写不敏感，但区域必须用 ISO 3166-1 二字母码，不能用国家英文名 |
| zh-Hant-TW | 繁体中文（台湾地区） | tw、zh-TW-Hant、zh-TW | 文字系统（Hans/Hant）写在区域之前，区域不是语言 |
| en | 英语（不限定区域） | en-ALL、en-WORLD、en-INTL | 只声明语言时不要补一个假区域，全站英文站用 en 即可 |
| en-US / en-GB | 英语（美国 / 英国） | en-USA、en-UK | UK 不是 ISO 3166-1 代码，英国是 GB；USA 同理应为 US |
| es-419 | 拉丁美洲西班牙语 | es-LA、es-419-MX | 419 是 UN M.49 区域码，用于「拉美整体」这类跨多国的区域定向 |
| pt-BR / pt-PT | 葡萄牙语（巴西 / 葡萄牙） | pt-Brazil、pt-PT-BR | 同一语言跨区域经营必须分标签，否则两国用户看到同一版本 |
判断一个标签是否该存在，只问一句：这一页是否真的为这类用户写过？如果答案是把中文页机翻过去再换一个 URL，那它不是一个新的语言版本，而是一份重复内容。正确做法是先把它排除在声明之外，等人工本地化完成后再纳入集群。
三、8 步治理 SOP：从盘点走到可验收
下面八步按依赖顺序排列，前三步不碰线上代码，只在表格里完成；后五步才进入模板与服务器。顺序不能颠倒——先有页面级对应表，再注入声明，否则改动会变成在整个模板里循环输出一堆与页面无关的语言标签。
- 盘点现有语言与区域入口全量导出站点 URL，标出目录结构、语言切换器实现方式、现有 hreflang 与 sitemap 提交情况。产出是一张原始清单：哪些语言、哪些区域、由谁维护、哪些页面有独立版本。
- 确定 URL 承载结构在子目录、子域名、独立域名之间做一次明确选择并写进交付文档。多数企业站应选子目录：权重集中、证书与部署只有一套；只有区域法律主体不同、需要本地团队独立运营时才拆分。
- 建立页面级对应表用一张三列 CSV 落盘：逻辑页 ID、语言/区域标签、实际 URL。这是整个治理的唯一事实来源，后面所有声明、sitemap 与验收都从它生成，绝不能靠模板循环猜。
- 生成并注入 hreflang 集群每页输出「自引用 + 全部互指 + x-default」，条数在 2~8 条之间是正常量级；超过就说明声明粒度过粗。注入位置统一在
，由对应表驱动，而不是手写进每个模板。 - 在 sitemap 或 head 二选一，并保持单一来源两种声明方式都有效，但同一站点同时维护两份且内容不一致时，机器只能取其一。选 head 就只在 head 输出；要用 sitemap 的
xhtml:link，就确保它与 head 完全同构。 - 把 canonical 与 hreflang 对齐canonical 指向本语言版本的自身 URL，绝不跨语言指向中文页；hreflang 目标必须是 200 且可索引的最终地址，不能是 301 链、参数页或带 noindex 的占位页。
- 改造语言切换器换成真实
，指向对应 URL，保留「当前语言」状态；移除 IP 与浏览器语言自动跳转，或降级为一次性提示条。爬虫与用户走同一条路径，是这套结构能被读懂的前提。 - 上线后 30 天按表验收72 小时内完成技术项（集群完整率、自引用率、目标 200 率），30 天内看收录结构、语言定向命中与 AI 引用语言。验收表在开工前就写死，避免复盘变成对曲线的各自解读。
八步里最容易跳过的是第三步。它没有代码产出，看起来像文档工作，但它决定了后面五步是「按对应表生成」还是「在模板里循环输出」。前者一次做对、长期可维护；后者每加一个市场就要重新排查一遍，且错误以页面为单位散落，无法审计。
四、子目录、子域名、独立域：结构选择的工程账
结构选择没有绝对正确答案，但有明确的失败模式。子目录最常见的失败是命名混乱——/en/、/english/、/en-us/ 三种写法并存，同一语言出现两个入口；子域名与独立域最常见的失败是没有互指，被搜索引擎当成完全无关的站点，各自的权重从零开始。
推荐：单域 + 语言目录 + 页面级声明
一套部署、一套证书、一套 CDN，权重集中在主域；目录名只用语言标签，区域版本用子目录或查询无关的固定路径表达。
对应表驱动 hreflang，新增市场只是往表里加行，模板不再改动。
高风险：按 IP / 浏览器语言自动跳转
抓取器从固定出口进入，被统一送到同一语言版本，另一版本不再被发现；用户切回原语言会被再次弹回，形成循环。
页面源码里没有任何对应关系，机器只能看到一个语言，多语言投入全部沉没。
| 维度 | 子目录（推荐默认） | 子域名 / 独立域（按需） |
|---|---|---|
| 权重继承 | 同域同证书，整站权重集中，新语言版本继承主域信任 | 子域被视为独立站点，需从零积累；独立域等同新站 |
| 运维成本 | 一套部署、一套 CDN、一套证书 | 每增加一个语言即多一套解析、证书与发布流程 |
| 区域隔离 | 靠目录与 hreflang 表达区域，隔离度中等 | 子域/独立域隔离度更高，适合合规或本地支付差异大的市场 |
| 适用场景 | 2~5 个语言版本、同一品牌同一业务线 | 区域法律主体不同、需本地化运营团队独立负责 |
| 失败模式 | 目录命名随意（/en/、/english/、/en-us/ 混用），对应表缺失 | 子域未做 hreflang 互指，被当成完全无关的站点 |
多语言不是把中文页翻译三遍，而是把同一份事实用三种语言各写一遍，并且让机器知道——它们是同一件事的三个版本。
五、标注矩阵与 x-default 的真实写法
一个英文页要声明的不是「我是英文」，而是「这一组页面里，英文版本是我」。因此每条声明都是双向的，且必须包含自己。下面是一个三语言集群的最小完整写法，逻辑页为「企业官网建设服务」：
三个要点。第一，en 与 en-US 同时存在是合法的：前者是「不限定区域的英语」，后者是北美专用版本，两者内容若完全相同，就应该只保留一个，否则同一语言出现两个入口。第二，x-default 指向语言选择页或默认语言版本，不能指向 404、不能指向靠 JS 跳转的中转页，它是无匹配语言时的兜底，不是「最重要的版本」。第三，canonical 与 hreflang 必须指向同一个自身 URL——canonical 跨语言，等于告诉机器这些页面是重复内容，集群随即失效。
| 错误写法 | 具体表现 | 后果 |
|---|---|---|
| 只写语言不写区域 | 覆盖英美加澳 | 区域差异被抹平，英美用户命中同一版本，价格与合规文案无法分流 |
| 缺少自引用 | A 页只指向 B 页，B 页只指向 A 页 | 集群不闭合，搜索引擎可能忽略整组声明 |
| 指向 301/302 的 URL | hreflang 目标写成 http 或非 www 版本 | 定向信号落在跳转链上，等于把声明交给了重定向 |
| 指向 noindex 或 robots 屏蔽页 | 语言版本未完成先上线，页面带 noindex | 被屏蔽页不能作为目标，整条对应关系失效 |
| 全站写同一组 hreflang | 模板循环里输出全部语言，与页面内容无关 | 页面级对应表被抹成站点级声明，语言错配照旧 |
| 缺 x-default | 未声明默认版本，或指向 404 | 无匹配语言时无兜底，用户与爬虫落到随机版本 |
还有一条常被国产建站服务商忽略的边界：百度没有与 hreflang 对应的机制。面向国内的多语言站点，靠的是独立语言目录、站内互链、分语言 sitemap 与页面级 TDK，而不是往 head 里加一段 Google 语义的声明。把 hreflang 当成「全引擎通用」的方案，是国内出海站点最常见的认知错位。
六、30 天验收：六项可测量指标
治理动作如果没有验收表，最后一定会退化成「代码加了、应该好了」。下表六项全部可以在不依赖第三方工具的前提下采集，前四项在 72 小时内就能出结论。
| 指标 | 口径 | 采集位置 | 合格线 |
|---|---|---|---|
| hreflang 集群完整率 | 每页声明的语言数 ÷ 该逻辑页面实际存在的语言版本数 | 页面源码 / sitemap | = 100%，缺一即视为未完成 |
| 自引用率 | 包含自身语言标签的页面数 ÷ 已声明页面数 | 源码正则抽样 | = 100% |
| 目标 URL 可达率 | hreflang 目标返回 200 的比例 | curl 批量探测 | = 100%，不允许 301/404/noindex |
| 逻辑页重复收录 | 同一逻辑页在同一语言下被收录的 URL 数 | 站长平台收录报告 | 同一语言 ≤ 1 条 |
| 语言定向命中 | 按语言+区域检索时，落地页语言是否匹配 | 目标市场本地网络 + 无痕窗口 | 抽查 20 条查询，错配 0 条 |
| AI 引用语言正确率 | 英文提问得到的回答是否引用英文页 | 固定 10 条英文问题，逐条记录引用来源 | ≥ 8 条引用英文版本 |
最后一项值得单独说明。AI 引擎的引用语言，本质上是「它认为哪一版是这一实体的权威表述」。让十位英文提问者得到十段中文机翻回答，说明英文版本在检索层几乎不存在；这时继续优化英文页面的视觉与文案没有意义，问题在索引结构。像素科学在交付里把这项与收录结构放在同一张表上，是因为它比排名更早、更直接地反映多语言投入是否真的被机器看见。
七、常见问题
- 只有中英两个语言版本，还需要 hreflang 吗？
- 需要，而且这是最容易做对的一组。两个版本时，每页各写两条 alternate（自引用 + 对方），中文页与英文页互相声明，再给一个 x-default 指向默认语言版本，就完成了。工作量是模板级的一次性改动，收益是搜索引擎不会把中英文页当成两个无关站点，也不会在两个版本之间随机选一个作为代表页。若暂时不做，代价不是立刻可见的，而是英文页长期只能靠自己积累信号。
- 用 IP 或浏览器语言自动跳转，体验不是更好吗？
- 对真人可能是，对搜索引擎和 AI 抓取器是灾难。Googlebot 与多数 AI 检索器从少数固定出口抓取，IP 判断会把它们统一送到同一个语言版本，另一语言版本从此不再被发现；用户若想切回原语言，还会被再次弹回，形成循环。可接受的做法是：默认输出一个语言版本，页面顶部常驻语言切换器，切换用真实链接指向对应 URL，把选择权交给用户，把对应关系交给 hreflang。
- 机器翻译的页面能不能单独作为一种语言版本上线？
- 技术上可以，策略上要分清两类页面。产品参数、公司介绍这类结构化事实，机器翻译加人工校对是合理成本；品牌主张、案例叙事、合规声明这类需要语感与法律审慎的内容，机器翻译上线只会拉低整站质量分，并让 AI 引擎抽取出语义走样的定义句。判断标准很直接：这一页是否承载你希望被引用的核心事实。如果是，就必须人工重写而不是翻译。
- 子域名、子目录、独立域名到底怎么选？
- 先看组织而不是技术。同一主体、同一业务线、两到五个语言版本，子目录是最省成本且权重最集中的方案；区域法律主体不同、需要本地团队独立运营与独立合规，才值得拆子域名或独立域名。无论选哪种，页面级对应表与 hreflang 互指都必须做，否则结构选得再对也只是三个互不相认的站点。
- hreflang 写错会被惩罚吗？
- 不会。官方口径是定向信号而非排名因素，写错的结果是被忽略，而不是降权。也正因为不惩罚，错误会长期沉默地存在：页面照常收录、流量照常来，只是每进入一个新市场都要从零建立认知，且同一逻辑页面在多个 URL 上互相分流。这就是为什么治理动作必须落到可测量的验收表上，而不是靠「加了一段代码」结案。
- 多久能判断 hreflang 生效？怎么判断？
- 上线后先做 72 小时的技术验收（集群完整、自引用、目标 200），再看 30 天内的收录结构变化：同一逻辑页在同一语言下是否只剩一个被收录 URL、按语言与区域检索是否落到正确版本。真正的业务信号更慢，通常要跟着一个完整的区域投放周期走。判断依据要提前写死，否则每次复盘都会变成对曲线的各自解读。
