本地化SEO：如何在每个市场中获得排名

一个客户在2021年找到我，他们的SaaS产品已经用五种语言上线两年了。来自德国的流量：每月38次会话。来自法国的：22次。他们的英文页面排名不错，但每个本地化版本基本上都是隐形的。他们曾付钱给一家代理机构翻译副本，有人安装了WPML，然后大家都以为工作完成了。

实际上远未完成。

本地化SEO是那种把工作做对60%和做对0%几乎没有区别的领域。错过hreflang。选错URL结构。跳过本地信号。结果：Google完全忽略你的翻译页面，或者更糟的是，把它们当作重复内容处理并过滤掉。在过去九年中，我在Seahawk处理过数百个网站上的这个问题，失败模式几乎总是一样的。

那么让我们来看看什么真正有效。

---

翻译不等于本地化

这是我向每个客户说的第一件事。翻译是把词汇从一种语言转换成另一种语言。本地化是针对特定市场重新塑造页面的意图。

以我们2022年末的一个英国电商客户为例。他们销售高端厨刀。他们的德语页面是英文文案的逐字翻译，包括"非常适合周日烤肉"这样的短语。但德国人不吃周日烤肉。这份文案在语法上是正确的，实际上却完全错误。

除了文化因素，SEO影响是真实存在的。关键词搜索量无法直接转换。英文查询"best chef knife"在英国每月大约有8,100次搜索。德文对应词"bestes Kochmesser"搜索量少得多，但"Kochmesser Test"（大致意为"厨刀测试/评测"）搜索量巨大。如果你的本地化页面针对英文关键词的直译，你就是在为错误的东西做优化。

在写任何一个词的本地化内容之前，要在目标语言、目标地区运行关键词研究。使用Google Keyword Planner并正确设置国家，或使用Ahrefs并应用国家过滤器。这些不等同于运行英文研究。从关键词的角度，把每个市场当作一个新网站来对待。in the target language, in the target locale using Google Keyword Planner with the country set correctly, or Ahrefs with the country filter applied. These are not the same as running English research. Treat each market as a new site from a keyword perspective.

本地化在实际中意味着什么

用当地货币定价，包含当地支付方式说明
按该国格式化日期、地址和单位（DD/MM与MM/DD是有区别的）
能引起当地共鸣的例子、习语和参考
针对国家的信任信号（德国买家信任本地认证；法国买家对社交证明的反应与巴西买家不同）

---

URL结构：搞错这一点，其他一切都白费

我见过这个争论毁掉很多项目。ccTLD vs 子域名 vs 子目录。人们对此非常执着。

根据我构建和迁移数百个国际站点的真实经历，对大多数企业来说，子目录通常是正确的选择。比如yoursite.com/de/，而不是de.yoursite.com或yoursite.de。原因很实际：你的域名权重全部集中，在一个地方更容易管理，而且当hreflang设置正确时，Google也能很好地处理。subdirectories are usually the right call for most businesses. Something like yoursite.com/de/ rather than de.yoursite.com or yoursite.de. The reasons are practical: all your domain authority consolidates, it's easier to manage in one place, and Google handles it well when hreflang is set up correctly.

ccTLD（yoursite.de、yoursite.fr）确实能发出强烈的本地信号。如果你在某个特定市场是认真的参与者，而且能够承诺运营本质上独立分离的站点，那它们是值得的。Seahawk在2020年有一个金融科技客户坚持在六个国家使用独立的ccTLD，是的，这些站点在那些市场中表现良好。但他们的开发开销增加了三倍。对于大多数为客户构建的代理来说，这不现实。yoursite.de , yoursite.fr) do send a strong local signal. If you're a serious player in a specific market and you can commit to running essentially separate sites, they're worth it. Seahawk had a fintech client that insisted on separate ccTLDs for six countries in 2020, and yes, it performed well in those markets. But their dev overhead tripled. For most agencies building for clients, that's not realistic.

子域名（de.yoursite.com）在大多数情况下是两个世界最坏的结合。比子目录更难维护，权重信号弱于ccTLD。除非你的CMS架构真的强制了这个问题，否则我会避免使用它。de.yoursite.com) are the worst of both worlds in most cases. Harder to maintain than subdirectories, weaker authority signal than ccTLDs. I'd avoid them unless your CMS architecture genuinely forces the issue.

无论你选择什么：保持一致。不要混合结构。我接手过一些站点，既有/fr/页面，又有fr.子域名同时运行，两者都被索引。这是个噩梦。be consistent. Don't mix structures. I've inherited sites with /fr/ pages and a fr. subdomain running simultaneously, both indexed. It's a nightmare.

---

Hreflang：国际SEO中最常见的被破坏的部分

如果你只从这篇文章中吸取一件事，就让它成为这个吧。

Hreflang 告诉 Google 应该向哪个国家、哪种语言的用户展示页面的哪个版本。如果设置错误，你的美国英文页面就会在德国显示，你的德文页面根本无法排名，或者我个人最喜欢的灾难案例——你的 x-default 指向一个完全重定向到其他地方的页面。 tells Google which version of a page to show to which user in which language and country. Get it wrong and you'll have your US English pages showing up in Germany, your German pages not ranking at all, or, my personal favourite disaster, your x-default pointing to a page that redirects somewhere else entirely.

标签格式在你的 <head> 中看起来是这样的：<head>:

`` <link rel="alternate" hreflang="de" href="https://yoursite.com/de/page/" /> <link rel="alternate" hreflang="en-GB" href="https://yoursite.com/en-gb/page/" /> <link rel="alternate" hreflang="x-default" href="https://yoursite.com/page/" /> `` <link rel="alternate" hreflang="de" href="https://yoursite.com/de/page/" /> <link rel="alternate" hreflang="en-GB" href="https://yoursite.com/en-gb/page/" /> <link rel="alternate" hreflang="x-default" href="https://yoursite.com/page/" /> ``

有几件事经常让人出错：

每个页面必须引用所有备选版本，包括它自己。如果你的德文页面没有链接回英文页面，英文页面也没有链接回德文，那么实现就是破损的。 If your German page doesn't link back to the English page, and the English page doesn't link back to German, the implementation is broken.
语言代码与语言-地区代码。hreflang="en" 表示"英语，任何地区"。hreflang="en-GB" 表示"英语，特别是英国"。如果你想分别针对英国和美国，你需要地区代码。 hreflang="en" means "English, any region." hreflang="en-GB" means "English, United Kingdom specifically." If you're trying to target UK vs US separately, you need the region code.
返回标签。德文页面必须包含一个指向英文页面的标签。英文页面必须包含一个指回德文的标签。两者都要。总是都要。 The German page must contain a tag pointing to the English page. The English page must contain a tag pointing back to German. Both. Always.
与规范标签的一致性。你的 hreflang 备选 URL 和该页面的规范 URL 必须完全匹配。完全匹配。包括末尾斜杠。 Your hreflang alternate URL and your canonical URL for that page must match. Exactly. Including trailing slashes.

我在手动设置这些标签时会使用 Aleyda Solis 的 hreflang 标签生成器。之后我总是用 Screaming Frog 进行审计。总是。Aleyda Solis's hreflang tag generator when I'm setting these up manually. And I always audit with Screaming Frog after. Always.

---

本地信号：启动后每个人都忘记的那个关键因素

正确的hreflang和本地化页面也许只能让你走到一半。另外50%靠的是信号：Google有理由相信你在那个市场是真实存在的实体吗？

对大多数网站来说，这意味着：

本地反向链接。来自德国.de域名指向你的/de/页面的链接具有实质性权重。法国媒体指向你法文页面的链接，效果相同。美国博客指向你德文内容的链接帮助不如人们想象的那么大。 A link from a German .de domain to your /de/ pages carries meaningful weight. Links from French media to your French pages, same thing. Getting a link from a US blog to your German content doesn't help nearly as much as people assume.
Google商户信息。如果有任何实际存在，即使只是注册地址，也要为该位置设置GBP。完整填写。这是本地包可见性的基础。 If there's any physical presence, even a registered address, set up a GBP for that location. Fill it out properly. This is table stakes for local pack visibility.
本地schema。添加LocalBusiness schema，包含正确的国家、地址格式和电话号码格式。不要只是复制你的英文schema然后翻译描述。结构化数据需要匹配具体的本地特性。 Add LocalBusiness schema with the correct country, address format, and phone number format. Don't just copy your English schema and translate the description. The structured data needs to match the locale specifics.
托管位置。鉴于CDN的存在，重要性不如过去那么高，但如果你使用CDN（你应该使用），要确保你的边缘节点从欧洲服务器为欧洲用户提供服务。Cloudflare免费计划可以做到这点。这不是一个巨大的排名因素，但它有助于该地区的TTFB，这很重要。 Less important than it used to be given CDNs, but if you're using a CDN (and you should be), confirm your edge nodes are serving European users from European servers. Cloudflare's free plan handles this. It's not a huge ranking factor but it contributes to TTFB in that region, which matters.

2019年我有一个健康保健品领域的客户试图在西班牙排名。他们的本地化做得很好。hreflang正确。但他们没有西班牙反向链接，他们马德里地址的GBP未被认领，schema中仍然列着英国电话号码。在大约四个月内修复这三样东西，让他们的三个目标关键词从第4页升到了第1页。

---

内容深度因市场而异

这是关键词研究无法完全告诉你的东西。有些市场对信息的需求很大；有些市场则依靠简洁的产品页面进行转化。

德国以严谨著称。德国搜索者倾向于在购买前寻找详细的对比内容、规格表和清晰的退货政策。一个在英国能转化的300字产品页，在德国可能需要900字外加一个常见问题部分才能有效果。

日本也是如此。日本商业查询的搜索结果通常以极为详细的长篇内容为特色。搜索结果页面看起来不同，用户行为不同，内容预期也反映出这一点。

我不是说仅仅因为你能做到就为每个市场写2000字。我的意思是：看看那个国家、那种语言、你的目标查询中实际排名靠前的内容。打开无痕窗口，手动设置你的Google国家/地区，看看前三个结果。它们的长度是多少？有视频吗？有表格吗？有嵌入的用户评价吗？那才是你的基准，而不是英文中有效的方法。look at what's actually ranking in that country, in that language, for your target query. Open an incognito window, set your Google country manually, and look at the top three results. What length are they? Do they have video? Do they have tables? Do they have user reviews embedded? That's your benchmark, not what works in English.

---

上线前的技术审核清单

在任何国际网站从Seahawk上线前，我们按顺序进行以下检查：

确认URL结构在所有语言版本中保持一致
使用Screaming Frog验证每个页面类型（首页、分类页、产品页、博客）上的hreflang标签
检查规范标签是否与hreflang备用URL完全一致
验证 x-default 已设置并指向一个实时的、非重定向页面
在 Google Search Console 中测试地理定位设置（国际定位报告，位于旧版工具下）Google Search Console (International Targeting report, under Legacy Tools)
确认 XML 网站地图包含所有本地化 URL，如果使用单独的资源库，则按地区提交
使用 WebPageTest 从目标地区检查页面速度，使用欧洲或亚洲节点
使用 Google 的富媒体搜索结果测试工具验证 LocalBusiness schema，每个地区至少验证一个代表性页面

这不是我们进行的每项检查。但如果这八项都没有问题，基础就足够坚实了，可以开始构建了。

---

耐心之道：时间表和预期

我真希望能在每个来找我们做国际 SEO 的客户的广告牌上写下这一点：这需要比英文 SEO 长得多的时间。有时候长很多。this takes longer than English SEO. A lot longer, sometimes.

当你推出新的本地化部分时，从 Google 的角度来看，你实际上是在该市场推出一个新网站。你没有本地反向链接历史。你没有本地参与信号。你没有查询历史。Google 很谨慎。

现实的时间表：3个月才能看到任何进展，6个月才能开始得出结论，12个月才能真正评估本地化策略是否有效。我知道这不是任何人想听到的。但那些抱着这种预期进来的客户，在第4个月还没上首页时，不太可能放弃。

我开始提到的那个SaaS客户？我们在2022年第一季度重建了他们的整个国际化架构。到2022年第四季度，他们的德国流量从每月38次会话增长到约1,400次。法国达到了800次。这花了9个月的持续工作。没有捷径。只是正确的架构、真正本地化的内容，以及在每个市场中耐心的链接建设。

---

FAQ

我需要为每种语言分别创建Google Search Console属性吗？

如果你使用的是子目录就不需要。一个GSC属性可以覆盖整个域名，你可以按URL前缀过滤来查看各地区的数据。如果你使用的是国家代码顶级域名，那么是的，每个域名都需要自己的属性。子域名可以设置为单独的属性，也可以纳入域名属性。我倾向于分开设置，这样数据更清晰。

我可以使用机器翻译来制作本地化内容吗？

简短的回答：不行，至少不能作为最终输出。Google可以检测到机器翻译内容，这被列入他们的垃圾内容政策中，作为自动生成内容。使用DeepL或类似工具来制作初稿，然后让母语使用者进行适当的编辑。编辑阶段才是本地化真正发生的地方。Spam Policies as auto-generated content. Use DeepL or similar to get a first draft, then have a native speaker edit it properly. The editing pass is where localisation actually happens anyway.

我如何处理跨多个国家使用的同一种语言？比如西班牙西班牙语和墨西哥西班牙语？

你使用不同的hreflang代码：es-ES用于西班牙，es-MX用于墨西哥。理想情况下，你对每个地区都有真正不同的内容，或者至少有针对当地查询的不同元数据。不要只是将两个hreflang代码都指向同一个页面。Google会看出你在做什么。es-ES for Spain and es-MX for Mexico. And ideally you have genuinely different content for each, or at minimum different metadata targeting local queries. Don't just point both hreflang codes to the same page. Google will figure out what you're doing.

如果我的 CMS 不原生支持 hreflang 怎么办?

大多数都可以通过插件支持。WPML 和 Polylang 都能在 WordPress 上很好地处理 hreflang。对于自定义构建，你可以通过 XML 网站地图而不是 <head> 来输出标签，Google 接受这种方法。网站地图方法实际上在大规模应用时更容易维护。只需确保它验证得很干净。<head>, which Google accepts. The sitemap method is actually easier to maintain at scale. Just make sure it's validating cleanly.

---

本地化 SEO 很慢，很繁琐，而且经常资源不足。我审计过的大多数网站都有翻译内容，但技术层要么缺失要么坏了。先修复架构。然后建立本地信号。内容是容易的部分，说实话。无聊的东西才是真正起作用的。