一个客户在2021年找到我，他们有一个针对七个国家的WordPress电商网站。他们雇用了一个翻译公司，把所有内容都插入WPML，然后就认为完成了。其中五个市场的自然流量基本上是零。不是低。是零。德语页面正在蚕食英语页面。阿拉伯语页面上任何地方都没有dir="rtl"属性。那些hreflang标签呢？指向被301重定向到完全不同页面的URL。
那是一个三个月的恢复工作。我的账单是公平的，但从那以后我一直在想这个问题，因为该网站上的每个问题都可以通过在启动前运行一个得体的清单来预防。
所以这是我的清单。我处理它的确切顺序、我实际打开的工具，以及仍然会让经验丰富的开发人员犯错的事情。
---
从URL结构开始（在你接触任何其他东西之前）
这个决定是永久的。或者说永久得足以让你这样对待它。我见过代理商在运营中的多语言网站上改变URL结构，然后眼睁睁看着六个月的链接权益蒸发掉。
你有三个选择：子目录（/fr/）、子域名（fr.）或国家代码顶级域名（site.fr）。Google自己关于国际化定向的文档很明确，这三种都可行，但权衡是真实存在的。
对于我的大多数客户，我会选择子目录。一个域名，一个权限池，一个爬虫预算来管理。当你有完全独立的团队在运营独立的业务时，子域名才有意义（Seahawk曾有一个SaaS客户，美国和欧盟的产品实际上是不同的监管产品，子域名就很合适）。国家代码顶级域名适合拥有强大本地品牌存在和预算的企业，可以分别为每个域名建立域名权限。
选一个。记录下来。在任何人写一行模板代码之前先获得签名批准。
我一直看到的一个子文件夹错误
人们把默认语言嵌套在/en/下，但没有从根目录设置适当的重定向。所以site.com/返回200但没有hreflang，site.com/en/有所有内容，Google把两者都索引为单独的薄页面。根据Accept-Language头将你的根目录设置为重定向到适当的区域语言，或者直接让根目录提供默认区域语言。别让它悬空。
---
Hreflang：做对它或根本别做
Hreflang是让大多数开发者紧张的地方。有理由。它很挑剔。
Google的hreflang规范告诉你使用语言-地区代码（en-GB、fr-FR）、让标签自我引用（每个页面都引用自己），并让关系是双向的（如果/fr/指向/en/，那么/en/必须指回/fr/）。漏掉其中任何一个，整个事情就会无声地崩溃。Google不会发起手动操作。它只是忽略你的标签并猜测。
这是我的实际工作流程：
- 先在电子表格中构建完整的URL矩阵。每个语言版本，每个对应的页面URL。
- 尽可能通过
<head>而非网站地图来实现。网站地图可以用，但<head>实现更容易通过查看源代码进行审计。 - 在暂存网站上运行Screaming Frog，启用hreflang审计功能。导出问题报告。
- 与Ahrefs的网站审计交叉检查，查找任何孤立的语言版本页面（某种语言的页面没有hreflang指向其他语言的对应页面）。
- 手动抽查10-15个页面。只需查看源代码。寻找该模式。
一个人们经常搞错的地方：x-default。它不是"英文版本"。它是针对用户语言与你的任何语言标签都不匹配时的备选项。如果你明确针对 en-GB 和 en-US，加拿大英语使用者需要一个落地页面。那就是 x-default。将其指向你最相关的兜底页面，通常是根目录或语言选择器页面。
---
抓取预算和索引
在小型网站上这不太重要。在拥有8种语言、50,000个页面的网站上，这绝对很重要。
数学很简单：如果你的英文网站有6000个页面，再加上7种语言，你可能需要处理48000个页面，这些页面都需要被爬虫抓取和索引。大多数网站没有足够的权威度或内部链接结构来有效支持这样的规模。
我的做法：
- 审核哪些页面值得翻译。并非所有页面都需要。2017年的博客文章如果每月英文版本只有3次访问，就不需要法文版本。
- 使用分别的区域特定网站地图（sitemap-fr.xml、sitemap-de.xml），然后在sitemap-index.xml中引用它们。Google Search Console让你能分别提交和监控每个，这样排查问题要简单得多。
- 如果你使用子域名或国家代码顶级域名，在Search Console中检查每个属性的爬虫统计。如果在同一域名的子目录中，使用按URL路径筛选的覆盖率报告。
- 对那些你还没审核过的薄页面或机器翻译页面设置Noindex。说真的。Google索引为垃圾内容质量的页面会伤害整个域名。
早在2019年，一个旅游行业的客户上线了12种语言版本，全部由DeepL机器翻译，没有人工审核。英文版本流量稳定，但在其他语言中8周内就完全崩溃了。DeepL是个很棒的工具（我仍然用它做初稿），但大规模未审核的输出是个信任信号噩梦。
---
翻译与创意转录
这个区别比大多数技术SEO从业者承认的要重要得多。
翻译是转换词汇。转录创意是转换意图、语气和文化背景。对于着陆页、产品描述，以及任何你花钱排名的内容，你需要的是转录创意。
这里的实际检查清单项目是：对于每个目标市场，让一个母语使用者审查至少前20个有流量潜力的页面。不仅仅是语法。还要检查文案是否听起来像那种语言的真实人类，或者像从教科书学习该语言的机器。
关键词研究按地区分别进行。我用Ahrefs来做这件事。德语关键词不只是英文关键词的德文翻译。搜索行为不同。有些市场的用户搜索更正式。有些市场则使用直译中不会出现的缩写或俚语。建立地区特定的关键词映射。这需要更长时间。但值得。
如何处理你无法适当进行转录创意的市场
对自己诚实。如果你现在无法正确处理德语，就不要推出德语版本。一个平庸的多语言存在比没有多语言存在还糟。谷歌搜索引擎机器人不会因为你努力了就给你加分。
---
每个地区的技术页面检查
这部分没什么花样。但这就是赢得胜利的地方。
- `<html>` 元素上的 `lang` 属性。应该与页面的地区匹配。
<html lang="fr-FR">。检查每个模板，不仅仅是首页。 - RTL语言的 `dir` 属性。阿拉伯语、希伯来语、乌尔都语、波斯语：
<html dir="rtl">。并检查你的CSS是否真正支持它，而不仅仅是HTML属性。 - 规范标签。每个本地化页面应该自我规范化。法文页面应规范到自身，而不是英文版本。我见过这种错误的次数多到数不清。
- Meta标题和描述。根据地区进行翻译和调整。不能留在英文。不能使用[页面名称] | [网站名称]模板自动生成，配上机器翻译的标语。
- 结构化数据。如果你使用Schema.org标记，inLanguage属性应该反映页面的语言。对于电商，检查priceCurrency是否与地区预期的货币相符。
- 图像alt文本。需要翻译。经常被忽视，因为它不可见。但我总是会检查。
我使用一个简单的Google表格，这些都是列标题。每个地区一行。验证时打勾。与客户共享，让他们了解检查了哪些内容。
---
本地搜索和Google商业档案
对于在多个市场拥有实体位置的客户，多语言SEO不仅限于网站。
Google商业档案支持多种语言的商业描述和服务列表。每个位置应正确设置主要语言。如果你在巴黎有办公室，该位置的GBP应该使用法文，配上法文描述，而不是直接从英文总部档案复制。
NAP一致性（名称、地址、电话）在本地引文目录中的市场相关性也很重要。在德国，这意味着确保在Das Örtliche和Gelbe Seiten上的列表正确，而不仅仅是Google。在法国是PagesJaunes。每个市场都有自己的引文生态系统。花一个下午为每个目标国家绘制前10个引文来源是值得的。
---
发布后监控
发布不是终点。这是发现你遗漏内容的开始。
我针对多语言网站的发布后监控设置：
- 为每个语言版本分别设置 Google Search Console（使用子域或国家代码顶级域），或在 URL 前缀属性中按子目录路径设置。
- 在 Search Console 的"旧版工具"下检查"国际定位"报告。它会在发布后几周内显示 hreflang 错误。
- 在 Ahrefs 中按语言版本设置排名追踪，使用正确的国家/语言定位。在"英语，美国"中追踪的关键词会给出与在"德语，德国"中追踪的同一关键词不同的排名位置。
- 前 6 个月内每月监控爬虫覆盖率。新语言版本的页面有时会卡在"已发现，未编入索引"状态数周。通常是爬虫预算或内部链接问题。
- 每季度检查一次关键词蚕食现象。两个语言版本的页面在同一国家争夺同一查询，说明 URL 或 hreflang 设置有问题。
我在与一个金融科技客户的痛苦经历后添加到清单中的一项：检查基于 IP 的重定向是否覆盖了 hreflang。如果你的 CDN 或服务器根据 IP 地理位置重定向用户，Googlebot（通常从美国 IP 爬取）可能永远看不到你的非英文页面。那个金融科技客户的 CloudFront 规则积极地重定向非美国 IP。我们花了两周时间诊断为什么欧洲页面的索引编制为零。
---
常见问题
我需要为每种语言分别创建一个 Google Search Console 项目吗？
不一定。如果你在同一域名下使用子目录（例如 site.com/fr/），可以为每个子目录创建一个网址前缀属性，或者直接使用根域名属性并按网址路径筛选。如果你使用的是子域名或单独的国家代码顶级域名，创建单独的属性虽然增加了管理工作，但值得这样做，因为你能获得更清晰的按市场划分的数据。
2024 年机器翻译对 SEO 来说足够好吗？
作为初稿，可以。作为未经人工审查就发布的最终版本，不行。DeepL 和 Google Translate 确实变得很不错，但它们生成的内容在语法上是正确的，却在语调上显得平淡生硬。搜索引擎越来越能区分那些用某种语言自然表达的内容和被翻译过的内容。使用机器翻译来加快速度，然后在索引前让母语使用者审查高价值页面。
如何处理只有部分翻译覆盖的市场？
对未翻译或部分翻译的页面进行 noindex 处理，直到它们准备好为止。不要仅为了让某个语言的页面上线就发布半成品的本地化页面。某种语言中由薄弱内容造成的信任信号损害比晚点推出更难挽回。
最常见的 hreflang 错误是什么？
缺少自指标签。每个页面都需要一个 hreflang 标签指向自己，同时还要指向其所有等效页面。开发人员经常正确地实现了交叉引用，却忘记了自指引用。用 Screaming Frog 大约 30 秒内就能发现这个问题，在每次上线前都要运行一次检查。
我应该翻译 URL 还是保持英文？
翻译它们。/fr/chaussures/ 在法语搜索中的表现优于 /fr/shoes/，因为 slug 对相关性信号有贡献。对法语使用者来说，这看起来也更值得信赖。额外的实现工作（你需要在 CMS 中进行特定语言环境的路由和 slug 翻译）对任何你认真考虑的市场来说都是值得的。
---
多语言 SEO 不是你勾选一次就完事的复选框。这是一门学科。上面的检查清单让我避免了多次昂贵的上线后救火，我必须承认次数比我想承认的还要多，而且它仍在不断演变。每一次新的构建都教会我一些东西。最近：在你声称一个网站已准备好之前，始终检查 CDN 对非默认语言环境请求的处理。始终检查。