Hreflang 指南：语法、常见错误与最佳实践

Hreflang（rel=alternate hreflang）是一个 HTML link 属性，告诉搜索引擎把页面的哪个语言和地区版本展示给哪些搜索者。它解决多语言站点的重复内容问题：同一内容的英文页和西语页可能被判为重复而只收录一个；hreflang 告诉 Google"这些是面向不同受众的有意备选——都收录，并把搜索者路由到正确版本"。

没有 hreflang，美国用户搜"附近的管道工"可能看到你的西语页面然后立刻跳出。配置正确时，英文页展示给美国用户、西语页展示给墨西哥用户：互动更好、转化更高，locale 之间不再互相蚕食。多语言服务企业、跨境电商以及任何多语言发布同一内容的站点都依赖它。

hreflang 最重要的场景：多语言服务企业（移民社区、跨境专业人士）、国际电商，以及任何以多语言发布同一内容的站点。如果你的站点只有一个 locale，hreflang 并非必需——Google 没有它也能正确处理。

hreflang 由语言代码和可选的地区代码组成，例如 en、en-US、zh-CN、zh-TW、es-MX。Google 对 hreflang 值不区分大小写；地区码大写只是符合 ISO 惯例的推荐写法，真正需要避免的是无效或不支持的代码。

Google 的 hreflang 值不区分大小写：zh-CN、zh-cn 和 zh-cN 都可识别。为统一格式，建议按 ISO 惯例使用大写地区子标签，但不应把大小写当作收录错误。

每个语言版本应声明自身 URL，并与可用的其他语言版本双向关联。x-default 是可选的：当需要为未匹配语言提供合适的默认页或语言选择页时可以添加；缺少 x-default 不会使其他有效 hreflang 失效。

语言版本之间需要双向对应：A 声明 B，B 也应声明 A。缺少回链可能导致这对注释被忽略，但不会自动让所有其他有效的语言配对失效。x-default 并非实现的必选条件。

错误一：使用无效或不受支持的语言/地区代码，例如只写地区码。Google 不区分 hreflang 代码大小写；地区子标签大写只是 ISO 风格。应修复无效代码，而不是误判 zh-cn 的大小写。

错误二：缺少回链。页面 A 声明页面 B 为备用，但页面 B 没有回声明 A。修复：每条备用必须双向；新增 locale 时，更新所有既有页面回声明它。

错误三：选错 x-default 的默认落点。x-default 是可选项；如果设置，应指向能帮助未匹配语言访客的默认页或语言选择页。单纯缺少 x-default 不属于 hreflang 配置错误。

错误四：hreflang URL 与 canonical URL 不一致。/pricing 的 canonical 是 /pricing，但 hreflang 指向 /pricing?utm_source=internal——Google 会忽略该备用。修复：hreflang URL 必须与 canonical URL 逐字符一致。

错误五：在 noindex 或已被 canonical 的页面上放 hreflang。禁止索引的页面不应声明 hreflang。修复：noindex 路由、重定向路由和被 canonical 到其他 URL 的页面省略 hreflang。

错误六：备用指向软 404 或"该语言不可用"页面。不要声明一个返回"抱歉，此页面没有您的语言版本"的 URL——那是软 404，两个方向都会被惩罚。修复：只声明有真实内容的备用；某 locale 没有该页面就不要声明。

错误七：各页面 locale 变种不一致。页面 A 声明 en、zh-CN、es，页面 B 只声明 en、zh-CN。不一致会让 Google 困惑。修复：存在于多个 locale 的页面声明全部所在 locale——不存在的不要声明。

第一步：检查页面渲染后的 HTML 或站点地图标注，核对合法语言代码、自指与双向备用 URL，以及目标页面能否抓取。仅在选择使用可选的 x-default 时核查其落点；地区码大小写不是 Google 的识别限制。

第二步：Google Search Console。旧版国际定位报告已于 2022 年弃用。使用网址检查确认具体页面的收录与 canonical 状态，并通过爬虫或站点审计检查 hreflang 的回链、语言代码和备用 URL。Google 仍支持 hreflang，但该报告已不可用。

第三步：Ahrefs 或 Sitebulb 爬取。这类工具能规模化检测 hreflang 问题——数千页面间的双向不一致、失效备用、错误语言代码。每季度全站爬取一次。

第四步：手动 SERP 测试。用不同地区的设备（VPN 或 google.com.hk 这类地区域名）搜索品牌名，确认正确的语言版本出现。如果看到 locale 互相蚕食，hreflang 很可能是原因。

五步验证：查看渲染后的 HTML head 中的 link rel=alternate 标签（自指 + 备用 + x-default）；用网址检查确认具体 URL 的收录与 canonical 状态；通过站点爬取检测 hreflang 双向不一致；检查不同语言的搜索结果；再确认各语言 URL 的收录情况。旧版国际定位报告已于 2022 年弃用。错误语言版本出现时，还应检查 canonical、可抓取性、内容和其他信号，不能只归因于 hreflang。

最佳实践一：内容没有地区差异时只用语言代码（en、zh、es）；内容确有地区差异（货币、法律引用、词汇）时才用地区码（en-US、en-GB、zh-CN、zh-TW）。内容相同时过度指定地区码会制造不必要的备用关系。

最佳实践二：可以为未匹配的语言设置可选的 x-default，尤其适用于语言选择页。请根据访客体验选择目标，不必机械指向公司所在国或主语言。缺少 x-default 不会让有效的备用注释失效。

最佳实践三：hreflang 从单一事实源（CMS 或建站工具）生成。手工维护上千页面的 hreflang 注定漂移。WordPress + WPML、Shopify 的多语言功能都会自动生成——选一个会自动生成的。

最佳实践四：hreflang URL 保持干净稳定。不要在 hreflang URL 里放查询参数、会话 ID 或追踪参数。备用 URL 一经发布，未经重定向不要更改——Google 的 hreflang 缓存重建需要数周。

最佳实践五：每次新增 locale、下线 locale 或大迁移之后都重新审计 hreflang。漂移总会发生；hreflang 是多语言站点健康的金丝雀。

目前 Cogo Site 提供多语言内容编辑、由你审核的 AI 翻译初稿，以及面向访客的语言切换器。

Cogo Site 目前还不会为你发布的站点生成 hreflang 标签或站点地图 alternate，切换语言也不会改变页面 URL。

如果你的 SEO 方案依赖带 hreflang 的独立语言 URL，Cogo Site 目前还不合适。