回到2021年，一个中等规模的电商客户在他们的德国商店上线八个月后联系了Seahawk。整整八个月。他们的英国网站排名很好。德国版本？在Google.de上几乎无人问津。我们在二十分钟内审计后发现了问题：他们的开发者实现的hreflang标签指向了迁移后不再存在的URL。Google一整年都在读取相互矛盾的信号。他们来自德国的有机流量只有应有水平的4%左右。
这种安静的灾难正是国际SEO充满的东西。它不会嘈杂地爆炸。它只是缓缓流血。
所以让我告诉你我在40多个国家构建和修复国际网站时学到的东西，包括真正有效的方法、文档没有告诉你的内容，以及我经常看到的具体错误。
---
三种域名结构（以及何时使用各种结构）
这是第一个决定，也是最永久的一个。做错了要花你几个月，有时甚至几年的时间。
你的选择有国家代码顶级域名（ccTLD，如 .de、.fr、.com.au）、子域名（de.example.com）或子目录（example.com/de/）。就这些。没有什么神秘的第四种选择。
ccTLD
ccTLD 给你最强的地理信号。Google 知道 example.de 是针对德国的。不需要任何配置。但你也在每个新的 ccTLD 上从零开始建立域名权威。如果你同时在五个国家推出，你就在建立五个独立的权威档案。这需要大量的链接建设预算和时间。
我建议在业务真正在每个国家以独立的本地实体运营、品牌有预算长期投资每个域名、以及本地信任信号很重要的情况下使用 ccTLD（金融服务、医疗保健、与政府相关的工作）。否则，你正在攀登一场你本不需要参加的上坡战。
子目录
坦白说，对于我合作的大多数客户来说，example.com/de/ 是正确的答案。你保持所有域名权威的集中。你在根域名上多年建立的信号会流向子目录。Google 明确表示子目录对国际目标定位效果很好。
权衡是你需要做更多工作来建立地理相关性。这就是 hreflang 和 GSC 地理定位的用武之地。
子域名
子域名没问题，但我发现它们在实践中很麻烦。从爬虫的角度来看，它们的表现更像独立的站点。我见过一个客户有八个语言子域名和一个处理效率不高的机器人，导致爬虫预算受到影响。除非有特定的技术或 CMS 原因使用它们，否则我会劝人们避免使用。
hreflang：每个人都会搞错的部分
hreflang：每个人都会搞错的部分
我要说的话听起来很戏剧化，但完全准确：hreflang 是技术性 SEO 中最容易出错的东西之一。规范本身足够清晰，但实现方式大约有十五种方法会出问题。
自指标签不是可选的
每个页面都需要一个指向自己的 hreflang 标签。这让我合作的大约 40% 的首次实现此功能的开发人员感到困惑。你不能只列出替代语言版本。当前页面必须引用自己。
`` <link rel="alternate" hreflang="en-GB" href="https://example.com/en-gb/product/" /> <link rel="alternate" hreflang="de" href="https://example.com/de/product/" /> <link rel="alternate" hreflang="fr" href="https://example.com/fr/product/" /> ``
第一行的 en-GB 标签？该页面正在引用自己。遗漏它，Google 可能无法正确处理该集群。
双向或出局
每个 hreflang 关系都必须是互惠的。如果你的英文页面指向德文页面，德文页面必须指向英文页面。Google 将未配对的标签视为错误，基本上忽略它们。
我见过开发人员只在"主"语言上实现 hreflang，然后想知道为什么排名没有提高。完整的关系图必须在每个节点上声明。
语言代码与地区代码
hreflang="de" 表示德语，任何地区。hreflang="de-DE" 表示在德国使用的德语。hreflang="de-AT" 表示在奥地利使用的德语。如果你向德国和奥地利提供相同的德语内容，你可能会使用 de 作为通用标签。但如果你有真正本地化的变体，要明确指定。
这会给人们造成问题的地方：使用 en 但实际上想表示 en-GB，然后疑惑为什么美国网站获得了英国流量。这两个标签不是一样的。
x-default 标签
添加 hreflang="x-default" 指向你的备用 URL（通常是英文主页或语言选择器页面）。这告诉 Google 当没有其他 hreflang 变体与用户的语言/地区匹配时要提供什么。很多网站忽视这一点。这不是灾难性的，但确实是个漏洞。
---
我在真实项目中看到的常见错误
让我快速过一遍我最常遇到的那些。直截了当。
- Hreflang 标签指向重定向。你的 hreflang URL 必须是规范的最终目标 URL。如果
example.com/de/重定向到example.com/de/home/，你的 hreflang 标签应该指向后者。 - 尾部斜杠不一致。
example.com/de/和example.com/de在技术上是不同的 URL。选择其中一个并在每个 hreflang 标签和规范标签中保持一致。 - 在XML网站地图中实现hreflang，而不是在HTML head标签中。两种交付方法都有效，但在整个网站中不一致地混合使用会造成混淆。选择一种方法，然后在各个地方统一使用。
- 未在GSC中设置地理定位。对于子目录或子域结构，你需要在Google Search Console中设置地理定位。进入GSC并在"国际定位"报告中选择目标国家只需要五分钟，但令人惊讶的是很多团队完全跳过了这一步。
- 仅翻译正文内容，而不翻译元数据。你的
<title>、meta描述，甚至URL slug都应该本地化。仅翻译内容而保留英文元数据是一种混乱的做法，会让用户和搜索引擎都感到困惑。 - 没有本地化链接建设。这不是技术错误，但它对国际排名的杀伤力同样有效。域名权重不会自动对德国受众产生意义。你需要来自德语、与德国相关的网站的链接。
---
规范标签与hreflang标签的冲突
这是一个连经验丰富的开发者都容易犯的错误。规范标签和hreflang标签必须保持一致。如果页面A有一个hreflang标签指向页面B作为德文版本，但页面B的规范标签指回页面A，你就创建了一个循环。Google会看到规范标签并假设B不是真实版本，这会使hreflang信号基本上失效。
Seahawk在2022年有一个SaaS客户遇到了完全相同的问题。他们的CMS自动生成的规范标签全部指向英文根目录。每个本地化页面。全部规范标签指向英文。hreflang在技术上有效，但规范标签是在告诉Google忽略除英文版本之外的所有内容。三个月的努力白费了。
规则是：每个本地化页面应该有一个自引用的规范标签指向自身URL，而不是指向主语言版本。
---
Google 实际上是如何处理这个的（以及它不会告诉你的事）
Google 不保证会遵循你的 hreflang 标签。我想直言不讳地说这一点。这只是一个提示，而不是指令。Google 在自己的文档中明确表示过这一点。实际上这意味着，如果你的内容没有真正本地化（只是英文加上 /de/ 前缀和机器翻译的正文），Google 可能仍然会提供"错误的"版本，因为它自己的语言检测与你的标签不一致。
好的 hreflang 实现会放大好的本地化效果。它不是替代品。
另一件事：hreflang 不会影响主搜索索引中的排名。它决定了哪个 URL 在哪个国家向哪个用户显示。你的德语页面仍然需要自己凭实力为德语查询排名。hreflang 只是确保当你已经获得排名时，正确的页面出现在正确的受众面前。
如果你手动构建这些标签，使用 Aleyda Solis 的 hreflang 标签生成器。这是我首先向初级人员推荐的工具。实现后，通过 Merkle 的 hreflang 测试工具运行你的实现，在 Google 发现错误之前捕获它们。
---
跨市场内容策略（大多数文章跳过的部分）
技术设置获得了所有关注。但我见过具有完美 hreflang、正确规范标签和配置良好的 GSC 属性的网站，在国际上仍然表现不佳。为什么？因为他们拿了英文博客内容，逐字翻译，然后称之为本地化。
德国受众的搜索方式不同于英国受众。英国的"Running shoes"可能是德国的"Laufschuhe"，没错，但查询背后的意图、表现良好的格式、人们想要阅读的具体内容，这些都是不同的。你需要用目标语言进行关键词研究，由实际使用该语言的人进行，而不是在英文研究之上叠加翻译层。
一些实际上能改变国际内容效果的事情：
- 使用 VPN 或 Google 的国家特定搜索网址在浏览器中研究本地 SERP
- 检查目标国家的竞争对手内容，而不是你的英国或美国竞争对手
- 调整示例、定价和文化参考。充满美元符号的文章在德国不会产生共鸣。
- 在内容推送前或同时建立本地反向链接，而不是六个月之后
---
何时使用 CDN 或托管位置
服务器位置对国际 SEO 是否重要？比起过去已经没那么重要了。有了 Cloudflare 这样的 CDN 在你网站前面，服务器的物理位置几乎不重要。Cloudflare 的边缘节点会从地理位置最接近用户的地方提供内容。
仍然重要的是：目标地区的页面速度。通过 PageSpeed Insights 运行你的网站，特别是检查目标市场移动用户的核心网页指标。我见过针对英国优化的网站，在国内速度很快，但在澳大利亚加载需要 6 秒，因为他们的图片 CDN 在那里没有边缘节点。这会独立影响排名。
---
常见问题
hreflang 是否直接影响 Google 排名？
不影响。hreflang 告诉 Google 向哪个用户群体展示哪个版本的页面，但不会提升排名。排名本身由常规因素决定：相关性、权威性、页面信号。可以把 hreflang 看作路由，而不是排名。
我可以在 WordPress 多站点上使用 hreflang 吗？
可以，而且如果设置得当，这实际上是最清晰的方案之一。WPML 或 Polylang 等插件会自动生成 hreflang，但我总是会检查它们的输出，因为自动生成的标签有时会出现上面提到的自引用或双向性问题。不要假设插件完全做对了。要检查。
我如何检查 hreflang 是否有效？
在 Google Search Console 的"国际定位"报告中拉取你的页面，查看是否有错误。另外用网址检查工具获取单个页面，看 Google 实际索引了哪些标签。还要在完整爬取期间使用 Screaming Frog 的 hreflang 选项卡。这样可以全面了解情况：缺少的互相引用对、断掉的网址、语言代码错误。
我是否需要为每个国家或语言单独创建网站地图？
严格来说不是必需的，但这样更清晰。如果你使用子目录，单独为每种语言创建一个 XML 网站地图并在 GSC 中单独提交，会让爬取管理更容易，尤其是网站增长的时候。单个网站地图也可以用，只要每个 hreflang 网址都包含在内就行。
hreflang 最常见的单一错误是什么？
缺少自引用标签。每次都是。我在过去四年审计了大约 200 个国际网站，这是我最频繁发现的错误，通常是因为开发者看了某个没有提到这一点的简化教程。第二常见的是在 HTML 页面上实现了 hreflang，但在 URL 迁移后忘记更新 XML 网站地图版本（或反过来）。
国际 SEO 确实是那些能把枯燥的技术细节做对的网站实现全球增长,而不是多年原地踏步的领域之一。这些概念并不神秘。只是执行需要比大多数人预期的更高精度。先把域名结构做对。然后仔细构建 hreflang 并进行验证。然后才做真正的本地化工作。按这个顺序。
国际 SEO 确实是那些能把枯燥的技术细节做对的网站实现全球增长,而不是多年原地踏步的领域之一。这些概念并不神秘。只是执行需要比大多数人预期的更高精度。先把域名结构做对。然后仔细构建 hreflang 并进行验证。然后才做真正的本地化工作。按这个顺序。
我开头提到的那个德国客户?我们修复了 hreflang,清理了规范标签,从当地行业网站获得了适当的德语链接。四个月内,他们获得的流量达到了英国网站的 60%。对于一个他们之前在市场上完全看不见的地区来说,这还不错。