促使人们关注这个话题的症状几乎总是相同的：公司有日文板块，也已被索引，但在日本搜索的用户却总是落到英文页面上。有时，对于日文查询，英文页面的排名甚至还高于日文页面。

hreflang 通常是原因之一。它并不总是全部原因——一个没人搜索的日文页面，无论怎么标注都不会有排名——但它是能够明确修好的那一部分，在下其他结论之前，值得先把它修好。

hreflang 实际起什么作用

hreflang 并不会让页面获得排名。它告诉 Google：若干个 URL 是同一内容的不同语言或地区版本。这样，当其中某个版本有资格出现在搜索结果中时，Google 就可以替换成与用户语言和所在地相匹配的版本。

由这一定义可以推出两个结论，而大多数 hreflang 错误都源于忽视了其中之一。

第一，它是一种替换机制，而不是排名提升机制。如果日文页面本身没有可见度，英文页面也没有，那么即使 hreflang 配置正确，也不会带来任何变化。

第二，它作用于 URL 集群，而不是整个网站。每个页面都有自己的集群。/services/technical-seo/ 和 /ja/services/technical-seo/ 构成一个集群；两个语言版本的首页构成另一个集群。在全站每个页面上重复同一段指向各语言首页的标注，是”配置了 hreflang 却毫无收益”最常见的情形之一。

ja 还是 ja-JP？

语言子标签是 ja，不是 jp。jp 是国家代码——出现在 .co.jp 和 ja-JP 中的就是它——单独使用时并不是有效的语言值。hreflang="jp" 是无效的，会被直接忽略。这是我们在日文板块中最常见到的 hreflang 错误，而且由于无效标注不会报错，它可能在那里静静存在好几年。

在 ja 和 ja-JP 之间，坦白说，对大多数网站而言 ja 才是正确选择。

  • ja 表示”此页面面向日语使用者”，无论身处世界何地。
  • ja-JP 表示”此页面面向在日本的日语使用者”，会将身在其他地区浏览的日语使用者排除在外。

只有当您确实拥有多个按国家区分的日文版本时，才需要使用地区子标签——比如一个包含日本定价的 ja-JP 页面，和一个面向新加坡法人的 ja-SG 页面。如果您只有一个日文页面，ja 就能覆盖所有应该看到它的人，包括在海外旅行或居住的日语使用者。无故缩小到 ja-JP，只会白白丢掉一部分受众。

如果确实使用地区子标签，它必须是 ISO 3166-1 alpha-2 国家代码，惯用写法是 ja-JP（该值不区分大小写，但保持一致会让审计更容易）。

双向互指：几乎所有问题都出在这里

集群中的每个 URL 都必须列出该集群中的全部 URL，包括它自己。如果页面 A 声明页面 B 是其日文版本，而页面 B 没有反向声明页面 A，Google 可能会完全忽略该标注。

自我引用确实是必需的，也确实经常缺失。日文页面必须包含一行指向自身的 hreflang="ja"，而不能只有指向英文版的那一行。

对于一个有英文原版和日文版的网站，两个页面上出现的是完全相同的代码块：

<link rel="alternate" hreflang="en" href="https://example.com/services/pricing/" />
<link rel="alternate" hreflang="ja" href="https://example.com/ja/services/pricing/" />
<link rel="alternate" hreflang="x-default" href="https://example.com/services/pricing/" />

确保双向互指最可靠的方法，是不再手工维护。从单一可信来源生成集群——例如一个记录每个页面存在哪些语言版本的页面注册表——这样集群中的每个页面必然输出相同的列表。手工维护的 hreflang，在第一次有人新增页面时就会开始失效。

x-default

x-default 用于标记在没有其他版本与用户匹配时应展示的页面。它是可选的，而且经常被误解。

把它指向对”找不到更合适版本的用户”而言最合理的兜底页面。通常是全球英文版，如果您有真正的语言选择页，也可以指向该页面。不要把 x-default 指向日文页面——否则它会被展示给您并不打算面向的用户。

x-default 同样需要遵守双向互指：同一条标注应出现在集群中的每个页面上，包括它所指向的那个页面。

还有一个值得了解的细节：只有当存在多个版本可供选择时，x-default 才有意义。对于只有单一语言版本的页面，整段标注都是多余的。

放在哪里

有三种实现方式，对 Google 而言同样有效：

  • <head> 中的 <link> 元素——最简单，也是大多数网站的默认首选。它们必须位于原始 HTML 的 <head> 中，而不是通过 JavaScript 注入到 <body> 里。
  • HTTP Link 标头——对于 PDF 等非 HTML 文件，这是唯一的选择。
  • XML 站点地图标注——对于大型网站，这往往是最易维护的方案，因为整个集群映射集中在一个自动生成的文件里，而不是分散在成千上万个模板中。

只选一种。两种方式同时存在且相互矛盾，比单独使用任何一种都糟糕——而当插件和手写模板同时生效时，这种情况出人意料地常见。

canonical 与 hreflang 必须一致

很多原本正确的配置就是在这里出了问题。

每个语言版本都必须是自引用 canonical。日文页面的 canonical 指向它自己。如果日文页面带有指向英文 URL 的 <link rel="canonical">——这种情况比您想象的更常见，通常是早年担心重复内容时留下的遗留设置——那就等于告诉 Google 日文页面根本不应被索引，而指向它的 hreflang 标注也就失去了意义。

由同一原则推出的相关规则：

  • hreflang 必须指向规范且可索引的 URL——不能是重定向，不能是带参数的变体，也不能是 noindex 页面。
  • 使用包含协议的绝对 URL。hreflang 不支持相对 URL。
  • 严格匹配末尾斜杠、www 和 https 的使用约定。https://example.com/ja/pricing 和 https://example.com/ja/pricing/ 是两个不同的 URL，即使浏览器最终打开的是同一个页面，这种不一致也会破坏双向互指。

子目录、子域名还是 .co.jp

hreflang 在这三种结构下的工作方式完全相同。example.com/ja/、ja.example.com 和 example.co.jp 都可以互相标注为替代版本，Google 也能很好地处理跨域名的 hreflang 集群。

因此，URL 结构的决策并不是 hreflang 的决策——它关乎权重、运营和信誉，我们在想在日本获得排名，必须使用 .co.jp 域名吗？一文中单独做了分析。与 hreflang 相关的只有一点：跨域名集群更难保持双向互指，因为两边通常由不同团队、按不同发布周期维护。这是运营风险，而非排名风险，但它确实存在。

最先值得排查的常见错误

大致按我们发现它们的频率排序：

  1. 使用了 hreflang="jp" 而不是 hreflang="ja"。
  2. 一侧或两侧缺少自我引用标注。
  3. 集群不对称——通常是因为日文板块建得较晚，由另一个团队基于另一套模板搭建。
  4. 全站统一的标注把每个页面都指向两个首页。
  5. hreflang 的目标 URL 发生重定向、返回 404，或带有 noindex。
  6. 日文页面的 canonical 指向英文页面。
  7. 标注中的协议、www 或末尾斜杠与实际 URL 不一致。
  8. 标注由客户端 JavaScript 注入。
  9. 基于 IP 的自动重定向把 Googlebot——它主要从美国 IP 地址抓取——完全挡在日文页面之外。

最后一项值得特别强调，因为它会让其他一切努力都白费。如果来自日本 IP 的访客被强制重定向到 /ja/，而其他所有人都被强制重定向离开那里，那么您的标注描述的就是一个 Google 无法抓取的网站。可以用一个可关闭的横幅来建议用户切换语言，但不要强制跳转。

如何验证

Google 已经下线了 Search Console 中专门的”国际定位”报告，因此不再有官方的 hreflang 验证工具可以依赖。验证现在是您自己的工作，好在并不困难：

  • 抓取两个语言板块，使用能够提取 hreflang 的爬虫工具，在整个页面集合范围内检查双向互指，而不是只抽查一个页面。双向互指错误往往是系统性的：一个页面有问题，很可能几百个页面都有。
  • 确认每个目标 URL 都返回 200、是自引用 canonical，并且可被索引。
  • 检查原始 HTML，而不是浏览器开发者工具中渲染后的 DOM——两者可能不同。
  • 使用网址检查工具检查一个有代表性的日文页面，确认 Google 识别到的是您预期的 canonical。
  • 在 Search Console 效果报告中按日本筛选，查看日文查询的展示次数究竟落在哪个 URL 上。如果修复几周后仍然是英文 URL，那么要么标注没有被采纳，要么日文页面对于该查询来说还不是一个可信的结果。

最后这个区分值得牢记。hreflang 决定展示您的哪个页面，却不决定其中任何一个是否值得被展示。如果日文页面只是英文页面的直译，围绕英文搜索需求构建，那么正确的标注只会把一个没人在找的页面推到前台——这正是为什么网站翻译不等于日本SEO一文详细阐述的观点。

先修好技术层，因为它的问题有明确答案，修好之后也不会反复。然后再去攻克更难的那一半。

如果您希望有人认真检查一遍配置，这属于我们面向日本市场的国际SEO和技术SEO服务的工作范围——把 URL 发给我们，我们会告诉您发现了什么。