建立多语言和/或多国家网络存在以将您的业务范围扩大到更广泛的国际受众需要深入了解您的目标市场以及国际 SEO 知识以在您的站点中正确反映您想要的目标网络结构，技术配置、内容开发、优化和推广工作。

关于上述要素缺乏专业知识，这就是为什么国际 SEO 流程出现各种问题并不少见的原因，其中许多问题会导致次优的用户体验，而国际 SEO 流程无法获得期望的结果。这就是为什么在进行国际活动时必须牢牢掌握技术搜索引擎优化。

虽然营销人员应该知道许多规则，但这里有一些最常见的问题和在国际 SEO 中失败的方法（以及如何避免它们）：

1. 不要为每个国际网络版本使用不同的 URL {#1--not-using-different-urls-for-each-of-your-international-web-versions}

至关重要的是，您的每个语言或国家/地区页面都通过其自己特定且可访问的 URL 显示，以便它们可以被 Google 抓取、索引和排名。此选项优于依赖于区域设置自适应爬行，后者会尝试识别访问者的语言和/或国家并通过相同的 URL 显示该内容版本。

正如谷歌在其官方文档中提到的那样："谷歌可能不会针对不同的区域设置对您的所有内容进行抓取、索引或排名。这是因为 Googlebot 抓取工具的默认 IP 地址似乎位于美国。此外，爬虫在发送 HTTP 请求时没有在请求头中设置 Accept-Language。"

这就是为什么您应该为您的每个国际版本建立一个单独的 Web 结构，无论是使用 ccTLD、子目录或子域（如果您是国家定位），还是使用子目录或子域（如果您是语言定位）。它们各有利弊，应根据您自己的特点、目标和限制评估各种选项，以选择最佳的国际 Web 结构。

同样重要的是，在访问者登陆或选择转到该版本时，始终如一地向访问者显示与语言或国家/地区相关的页面的实际 URL 版本。这种策略比像 Entrepreneur 这样的网站所做的要好；在下面的示例中，当他们发现用户使用的是西班牙语浏览器时，他们选择通过与英语相同的 URL (https://www.entrepreneur.com/) 显示主页的西班牙语版本。

这是不必要的，因为 Entrepreneur 实际上有一个西班牙语版本的主页，通过它自己的 URL ( https://www.entrepreneur.com/es ) 显示，如下所示。在这种情况下，这将是要显示的相关 URL，以避免提供令人困惑的体验，允许讲西班牙语的用户链接或共享它。

2.自动将您的用户重定向到国际网络版本而不提供选择它的选项 {#2--automatically-redirecting-your-users-to-an-international-web-version-without-giving-the-option-to-select-it}

尽管您可能希望将您的用户引向他们的相关国家或语言版本，但不建议使用重定向自动执行此操作。这些重定向对于可能特地查看其他语言或特定国家/地区版本的内容的用户来说可能是一种混乱和侵入性的体验。

关于谷歌的快速说明 {#a-quick-point-about-google}

此时，Googlebot 的大部分 IP 仍来自美国；Google 尚未从所有国家/地区抓取（抓取工具主要来自美国和其他一些国家/地区）。因此，如果我们只重定向到这些国家/地区的网站版本，那么 Googlebot 将始终被重定向并且只能看到我们网站的几个版本，而不是所有版本。

您不仅要重定向用户，还要重定向机器人。这就是为什么不仅允许用户浏览他们登陆的任何国际版本，而且允许 Googlebot 抓取任何版本而不是根据他们的 IP 重定向它。

例子 {#examples}

当重定向甚至不允许用户通过显示一个非常明显的选项切换到他们想要访问的国际版本时，会给出更糟糕的体验；这可以在一些博客或新闻网站上体验到，例如 Gizmodo，如下所示。

然后建议允许用户访问最初选择的国际 Web 版本，而不是重定向，同时根据他们的浏览器或国家 IP 通知他们可能有更相关的语言或国家版本。您可以以一种非侵入式且可见的方式执行此操作，让他们选择保留或更改版本，就像 Autodesk 所做的那样。

3. 不本地化不同网络国家版本的内容 {#3--not-localizing-the-content-of-your-different-web-country-versions}

即使您定位到使用相同语言的不同国家/地区，您也可能认为您可以在网站的不同版本中重复使用内容；你不应该。至关重要的是，每一个中的特色内容都是本地化的，针对每个国家/地区市场中的特定受众行为。即使使用相同的语言，内容也可能不同。可能不同的东西可能是用于描述季节性的特定术语或用于描述产品或服务的不同本地化词。尽管语言相同，但偏好可能因国家/地区而异。

例如，我们可以看到在美国版的阿迪达斯网站中，有一个"足球鞋"类别，在英国版中称为"足球靴"，因为它们已经本地化以连接和解决用户在每个网站中的搜索方式国家------在这种情况下是不同的，即使他们说同一种语言。

制定完整的关键字列表并对每个目标国家/地区进行竞争性研究也很重要。这些应该包括来自该特定市场的母语人士的输入、支持和验证，以便识别每个市场中受众的特定搜索行为。然后，您可以根据这些偏好优化您的 Web 内容、组织、设计和促销活动。

4. 使用单一 ccTLD 瞄准多个国家 {#4--using-a-single-cctld-to-target-many-countries}

以特定国家（通常是他们自己的国家）为目标并使用其特定 ccTLD（国家代码顶级域，如 .uk、.mx、.es、.fr 或 .de，默认情况下已经地理定位）的站点可能具有当需要进行国际扩张时，这是一个挑战。

他们将无法选择使用该初始 ccTLD 来定位其他国家/地区，而您可以使用与特定国家/地区无关的 gTLD（通用顶级域，如 .com、.org、.net）。gTLD 域可用于通过启用可通过 Google Search Console 进行地理定位的子目录或子域来定位许多国家/地区。

不幸的是，一些企业并不知道这些选项，并试图通过在 ccTLD 下为他们想要定位的不同区域启用子目录来定位其他国家，这些区域已经定位到另一个国家。我们可以在下面的示例中看到这一点，美国版本位于 .co.uk 下的子目录中（默认情况下已经定位到英国的 ccTLD）。

因此，当扩展到新的国际市场时，已经拥有 ccTLD（而不是 gTLD）的企业将需要选择使用特定国家/地区的 ccTLD 来瞄准其他国家/地区。此选项需要大量工作才能增加每个域的个人受欢迎程度。另一种选择是迁移或另外建立新 gTLD 的新存在，这将通过启用可通过 Google Search Console 进行地理定位的子目录来帮助企业更有效地定位许多国家/地区。

5. 假设 Google 支持使用 .asia 或 .eu 域或 Hreflang 中的"eu"值进行大陆定位 {#5--assuming-that-google-supports-continent-targeting-with--asia-or--eu-domains-or-“eu”-values-in-hreflang}

Google 不支持（至少现在还不支持）大陆级别的区域定位，无论是使用区域顶级域（如 .eu 或 .asia）被视为 gTLD ，还是在 hreflang 中使用区域值（如"eu"表示欧洲）因为谷歌支持他们的 ISO 3166-1 alpha-2 国家代码。

在以欧洲为目标时决定是否使用 .eu 域建立存在时，考虑这一点很重要；相反，使用具有特定子目录的 gTLD 可能会更好，这些子目录可以通过 Google Search Console 进行地理定位，并使用 hreflang 注释进行标记，以在单个级别针对特定的欧洲国家/地区。

6. 将所有国际网络版本规范化为一个版本以避免内容重复问题 {#6--canonicalizing-all-of-your-international-web-versions-to-one-to-avoid-content-duplication-issues}

有时，即使经过本地化过程，由于您的业务性质，您最终可能会在使用相同语言（如美国、英国或澳大利亚的英语）的不同国家版本中拥有非常相似的内容。

但是，如果这些国家/地区版本正确地定位到其相关市场，则这些页面的内容不应被视为重复，因为它针对不同的受众，并且需要可索引才能在每个国家/地区有效排名。您不必将这些页面上的规范放置到网站的国家/地区版本之一，因为每个版本都被认为是独一无二的，因为它针对的是不同的位置。

有时，由于在一些知名网站中可以看到跨国规范化，可能会引起混淆，例如下面的 Airbnb 示例，我们可以在其中看到他们如何将墨西哥主页规范化为西班牙语主页版本.com 域。尽管如此，我们不知道做出此配置决定的背景，另一方面，我们可以看到，在英国、法国或西班牙等他们拥有活跃业务和有机搜索业务的市场中，他们正在自我规范化它。

在这种情况下，为了有效地针对每个国家/地区版本的页面对其相关市场进行定位和排名，建议使用 ccTLD 或地理定位子目录或子域对每个页面进行地理定位------具体说明在 Google Search Console 中------以及使用 hreflang 注释来指定每个页面的语言和国家目标及其替代版本。

7. 在不遵循包含验证的过程的情况下实施 Hreflang 注释 {#7--implementing-hreflang-annotations-without-following-a-process-that-includes-validation}

关于实现 hreflang 注释时通常会犯的错误，可以写一整篇文章。事实上，我过去专门写过并介绍过它。从使用不受支持的值到在没有语言值的情况下指定国家或忘记包含返回标签或包含不可索引的 URL，等等。

一般来说，这些错误通常是由于缺少包含验证的 hreflang 实现过程而发生的，它看起来像这样：

A. 评估语言和国家实施范围

确定需要使用 hreflang 的语言和国家/地区版本，尤其是那些已识别出可能需要优先处理的国际错位搜索结果的版本。

B. 选择实现方法

根据站点和项目要求以及限制，评估最合适的 hreflang 实现方法（HTML 标头中的标签、HTTP 标头或XML 站点地图）。

C. 指定 Hreflang 代码模式

定义要在实现中使用的 hreflang 标记。您可以参考Google对所选方法的官方规范，以及支持的国家/地区和语言格式和值，以避免不受支持的展示位置、标签、属性或值。

D. 在测试环境中验证 Hreflang 实现

在发布之前在测试环境中抓取标记页面（通过站点或 XML 站点地图抓取，如果这是选择的实施方法），以识别任何潜在的标记错误。

E. 启动后 Hreflang 实施的监控和故障排除

在实时网站上启动标记页面后重新抓取它们以识别任何遗留问题并开始通过 Google Search Console International Targeting 报告监控它们。在发布新页面以及更改或删除现有页面时，还应开始持续监控以发现任何问题。并且，通过 Google Search Console Search Analytics 或新的性能报告识别 Google 搜索结果中任何潜在的新语言和国家/地区错位问题。

F. 建立要遵循的 Hreflang 最佳实践指南

记录要遵循的 hreflang 实施范围和规则，以定义基于良好做法的规则，以便在发布相关语言和/或国家/地区的页面时，或者更改或删除其 URL 时将它们考虑在内。需要此文档以确保可以相应地更新和验证 hreflang 注释。

通过这种类型的 hreflang 实施过程，应该最大限度地减少错误，如果发生错误，应迅速识别并解决。
希望这篇文章能帮助您避免这些相当普遍的国际 SEO 问题，如果您现在遇到其中任何一个问题，您现在就会知道如何解决它们。