一位客户在2021年找到我，他的WooCommerce商店用英文运营了三年，表现得很好。排名稳定。流量不错。然后他们的代理商为法国和德国市场"国际化"了这个网站。六周后，英文排名下降了40%。法文和德文页面被索引了，但谷歌对为哪个查询服务哪个版本感到困惑。没人碰过hreflang标签。没人考虑过URL结构。"翻译"只是在同一域上复制的内容，使用了类似?lang=fr的查询字符串。
我花了两个周末来理清那个烂摊子。所以让我为你节省同样的痛苦。
一旦你理解谷歌实际需要什么，翻译WordPress网站真的不难。问题在于大多数教程都在"安装插件，添加你的语言，完成"就停止了。SEO破坏正是从这里开始的。
---
翻译为什么会破坏SEO（以及为什么大多数人不会立即注意到）
搜索引擎对重复内容很挑剔。当你添加一个法文版的主页，它放在yourdomain.com/?lang=fr，而不是yourdomain.com/fr/或fr.yourdomain.com时，谷歌常常会把这两个URL视为内容略有不同的同一个页面。两个版本的排名都不好。你现有的英文页面可能开始失去权威性，因为信号被稀释了。
第二个问题：hreflang。这是一个HTML属性，它告诉谷歌"这个法文页面是那个英文页面的等价物"。搞错了，你会产生谷歌自己称之为"return tag"错误的情况，hreflang链被破坏，谷歌忽略整个情况。
我在2023年的一个Seahawk项目中见过这种情况，一个SaaS客户。他们通过插件添加了11种语言，但插件仅为它翻译的页面生成hreflang标签。未翻译的页面没有自引用hreflang标签。结果：谷歌开始对这些页面的英文版本去索引，因为它认为它们是孤立的重复。不是恶意的，只是粗心的配置。
修复并不复杂。但你必须从第一天开始就故意为之。
---
在接触任何插件之前选择正确的URL结构
这是锁定你的架构的决定。你有三个选项。
- 子目录：
yourdomain.com/fr/、yourdomain.com/de/，这是我对大多数网站的默认建议。 - 子域名：fr.yourdomain.com、de.yourdomain.com，如果你想在Search Console中将每种语言视为一个独立属性，效果很好。
- 单独域名（ccTLD）：yourdomain.fr、yourdomain.de，最强的地理定位信号，但昂贵且复杂。
对于我构建的90%的网站，子目录都是赢家。它们继承域名权威，在一个WordPress安装中管理更简单，谷歌处理得很好。只有当客户有严肃的地理定位需求和每个市场的专业团队时，我才会选择子域名或ccTLD。
在安装任何翻译插件之前选择你的结构。稍后更改意味着301重定向、更新的hreflang、更新的网站地图，以及至少几周的排名波动。我在2020年在一个酒店客户的网站上以艰苦的方式学到了这一点，我们在项目中期从子域名切换到了子目录。很痛苦。
---
选择不会与你的SEO冲突的翻译插件
有三个值得关注的插件。其他的都是噪音。
WPML
WPML是我在Seahawk几乎所有专业多语言构建中使用的。它不是免费的（基础许可证从大约$39/年开始），但它生成干净的hreflang标签，正确处理URL结构，与WooCommerce无缝集成，并且有一个字符串翻译模块，用于导航标签和小部件文本等内容。
你必须做的一件事：进入WPML > Languages > Language URL format，选择"Different languages in directories"（即子目录选项），除非你有具体的理由不这样做。默认值有时设置为查询字符串。更改它。
Polylang
Polylang是免费替代方案，对于较简单的网站来说确实很坚实。免费版本处理URL结构和基本hreflang。如果你运行WooCommerce或需要翻译管理功能，你需要Pro版本（$99/年）。我去年在一个小型非政府组织网站上使用它，它在三种语言下表现完美。
TranslatePress
TranslatePress 采用不同的方法：你可以在前端直接进行翻译，从视觉上操作。这对想要自己管理翻译的客户来说很不错。SEO 包附加组件（付费）处理 hreflang 和元数据翻译。没有这个附加组件，你翻译的页面会有重复的元标题和描述。别跳过这一步。
避免自动翻译作为你唯一的层级。来自 DeepL 或 Google Translate 的机器翻译可以作为初稿，但在发布前需要人工审阅。质量差的翻译内容排名很差，而且会造成糟糕的用户体验。我总是告诉客户：如果你翻译的内容读起来像是由不懂这种语言的人写的，Google 也会发现这一点。
---
正确设置 Hreflang
Hreflang 是大多数开发人员搞错的部分。这里是规则，很明确：
- 每个页面都需要一个 hreflang 标签，用于该页面的每个语言版本，包括它本身。
- 你必须包含
x-default，指向当没有语言偏好匹配时要提供的版本。 - hreflang 值必须与有效的 BCP 47 语言标签匹配。这意味着
en-gb而不是en-GB（小写、用连字符连接、区域代码在语言后）。 - 关系必须是相互的。如果
/fr/通过 hreflang 指向/en/，那么/en/必须指回/fr/。
WPML 大多数会自动处理这一点。但我总是在设置后使用 Aleyda Solis 的 Hreflang Tags Checker 进行手动验证。它是免费的，大约需要三分钟运行。完全值得。
一个边界情况：如果你有尚未翻译的页面。不要让它们没有 hreflang。要么将 x-default 指向英文版本，要么为英文添加自我引用的 hreflang，直到翻译准备好。hreflang 链中的间隙造成的伤害比你想象的要大。
---
网站地图、Search Console 和抓取预算
一旦翻译的页面上线，Google 看到它们之前，你需要搞定三件事。
- 提交一个包括所有语言版本的网站地图。WPML 和 Polylang 与 Yoast SEO 或 Rank Math 结合时都会自动生成多语言网站地图。在提交任何内容之前，检查
yourdomain.com/sitemap.xml的网站地图是否真的列出了你的/fr/和/de/URL。 - 如果你想要每种语言的粒度性能数据，在 Google Search Console 中将每个语言子目录添加为单独的资源。或将它们作为前缀添加到同一根域资源中。两种方法都可以，但单独的资源能让你获得更清晰的数据。
- 考虑抓取预算。对于有 500 个页面和 5 种语言的网站，你突然会有多达 2,500 个可索引 URL。Google 的抓取胃口是有限的。确保你翻译的页面不会隐藏在不必要的 JavaScript 渲染后面，没有从暂存遗留的 noindex 标签，并且加载速度合理。我的工作目标是移动端下 3 秒。
关于 Rank Math 的快速说明：它的多语言 SEO 模块与 WPML 和 Polylang 配合得很好，让你可以从熟悉的 Rank Math 界面中为每种语言设置翻译的元标题和描述。我去年三月把一个客户从 Yoast 换到 Rank Math 就是为了这个原因，工作流改进了很多。
---
处理翻译的元数据和页面 SEO
翻译的 URL slug 很重要。/fr/a-propos/ 对法语搜索者的表现比 /fr/about/ 更好。它向用户和 Google 都表明这是一个真正本地化的页面，而不是直接复制。
WPML 让你设置翻译的 slug。Polylang 也是如此。使用它们。我知道这是额外的工作。还是要做。
元标题和描述需要为每个市场翻译和重写，而不仅仅是通过翻译器逐字运行。搜索意图因语言而异。法语用户搜索你的产品时可能会使用与英语用户不同的措辞。每种语言的关键词研究，即使是使用 Google Keyword Planner 或 Ahrefs 的基本研究，也会对翻译页面的表现产生真正的影响。
图像 alt 文本经常被完全遗忘。你翻译的页面应该有目标语言的 alt 文本。包含文本字段的任何结构化标记也一样。
还有一件事会让人困惑：WordPress 菜单。如果你的导航中英文是"About Us"，你在法文中需要一个翻译的菜单项指向 /fr/a-propos/。WPML 有一个菜单同步功能，会提示你翻译菜单项。使用它。否则你会得到带有英文导航的法文页面，看起来很草率，也会让爬虫器困惑。
---
上线前的测试
不要跳过这一步。我在每次多语言构建前都会快速检查一遍清单，然后再切换到生产环境。
- 至少检查首页、一个内部页面和每种语言的一个产品或博客页面的 hreflang 标签。查看源代码或使用 SEO Meta in 1 Click 等浏览器扩展。
- 用 Screaming Frog 爬取网站。在 Hreflang 选项卡中按
hreflang筛选。任何"非 200"或"缺少返回标签"错误在发布前都需要修复。 - 确认 XML 网站地图列出了所有语言 URL，并在搜索控制台中提交。
- 在隐私浏览窗口中测试语言切换，确保 Cookie 或地理位置重定向没有将用户发送到错误的版本。
- 验证翻译后的页面返回 200 状态码，而不是 301 或 404。
整个检查清单在中等规模的网站上大约需要 90 分钟。这 90 分钟让我在这些年里至少避免了四次发布后的恐慌。
---
FAQ
翻译我的网站能保证我在其他国家排名吗？
不能。翻译是前提条件，不是保证。你仍然需要来自相关本地域名的反向链接、真实的本地搜索需求，以及在该市场中真正服务用户意图的内容。翻译打开了大门。每种语言的 SEO 工作会带你走过去。
我可以用 Google Translate 或 DeepL 自动翻译整个网站吗？
你可以用它们作为初稿。WPML 和 TranslatePress 都有与 DeepL 的集成以进行机器翻译。但发布未经人工编辑的原始机器翻译是个坏主意。内容读起来很生硬，这会增加跳出率，谷歌的质量评估员也会评估较大网站上的翻译质量。
每种语言应该有自己的 Google 搜索控制台属性吗？
这取决于你的 URL 结构。如果你使用子目录（yourdomain.com/fr/），搜索控制台中的一个根域属性涵盖一切，但为 /fr/ 专门添加 URL 前缀属性能给你更清晰的按语言分类的数据。如果你使用子域名，你会需要单独的属性。对于国家代码顶级域名，没有选择，它们是单独的域。
如果我只想翻译几个页面，而不是整个网站怎么办？
这没问题。只要确保那些翻译后的页面有指向英文版本的正确 hreflang，并且英文页面指向翻译版本。部分翻译是一种合理的方法，特别是对于只在外国市场针对产品或落地页部分的网站。
值得雇用专业翻译还是机器翻译就够了？
对于任何面向公众的内容，我总会说至少让人工翻译进行审查。对于有 10 页的小宣传册网站，成本很低。对于大型 WooCommerce 目录，你可能会对大量内容使用机器翻译，对产品描述、结账流程和法律页面等高价值页面进行人工审查。这种分工方法在实践中效果很好。
---
做对翻译是那种无声地复利的事情之一。你设置一次架构，Google 干净地索引一切，在 12 到 18 个月里，你在新市场的自然流量足迹增长，而无需重建任何东西。如果架构弄错了，你就得和 Google 无限期地较劲。插件工作是简单的部分。结构性决策、URL 格式、hreflang、翻译后的元数据，那才是真正的工作所在。花额外的一个下午把这些做对。你的未来自己会感谢你。