国际化网站架构：可扩展的 URL 结构

国际化网站架构是所有多语言、多区域 SEO 项目的底层决策基础。在委托翻译、配置 hreflang、按国家拆分产品目录之前，你需要先确定一种 URL 结构，让搜索引擎能够抓取、用户能够收藏，并让团队在未来多年持续维护。Google 的文档列出了几种针对不同语言和地区的 URL 方案，但没有任何一种能保证排名。它们的价值在于清晰：每个语言和市场版本都有独立、可被发现的地址，并配有一致的标注。

本指南将 Google 文档中列出的 URL 结构与实际规划决策相结合，说明 ccTLD、子域名和子目录各适用于哪些情况，为什么不应将参数作为主要的地理位置定位方式，以及为什么应先确定架构，再配置 hreflang 和规范网址（canonical），而非反过来。关于语言定位与国家定位背后的策略概念，请参阅国际 SEO 与多语言 SEO。

本指南将解答的问题

• Google 文档为国际化和多区域网站列出了哪些 URL 结构？
• 团队应在什么情况下选择 ccTLD、子域名或子目录？
• 为什么不建议使用 URL 参数来划分地理位置定位？
• 仅按语言定位与按国家定位的网站，架构应有何不同？
• hreflang 和规范网址（canonical）如何与 URL 架构选择相互配合？
• 除了 URL 路径，还有哪些重要的语言和地区信号？
• 团队应如何在不同的国际化 URL 结构之间进行迁移？
• 哪些架构错误会阻碍搜索引擎抓取语言或地区版本？

简要解答：根据市场矩阵确定架构

先建立国家 × 语言矩阵，而不是先想文件夹名称。在每个单元格中，写明该市场用户的需求：语言理解、本地货币、履约规则、法律条款，或以上所有内容。这个矩阵会告诉你，需要的是仅按语言划分的路径（/de/）、仅按国家划分的路径（/us/）、结合语言和地区的路径（/en-ca/），还是独立的 ccTLD（example.de）。

Google 建议为每个语言版本使用不同的 URL，而不是通过 Cookie 或浏览器设置在同一个 URL 上切换语言。动态切换会让部分版本无法被发现，因为 Googlebot 抓取时通常不带 Accept-Language，而且往往从美国的基础设施发起抓取。因此，架构首先关乎能否被抓取，其次才是品牌决策。

矩阵确定后，选择一种工程和本地化团队在未来几年都能持续运营的结构。在单个通用顶级域名（gTLD）下使用子目录，通常是维护成本最低的默认方案。如果法律、品牌或托管条件要求严格分隔不同市场，ccTLD 就是合理选择。子域名则是介于两者之间的折中方案。Google 文档也列出了 URL 参数，但不建议用它来划分地理位置定位。

Google 文档列出的 URL 结构

Google 的多区域和多语言网站文档列出了四种针对不同语言和地区的 URL 模式。每种模式都为各个版本提供独立地址，这是让搜索引擎能够抓取不同语言和地区版本的基本要求。

这些模式都不能单独决定排名。Google 将它们视为呈现不同语言和地区版本的方式，而非自动提升排名的手段。

如何选择 ccTLD、子域名或子目录

采用团队能在设计评审中充分说明理由的决策标准：

国家和地区代码顶级域名（ccTLD）能传递强烈的国家定位信号，但可能成本高、限制多，且仅限于单个国家。Google 指出，部分 ccTLD 会被视为通用顶级域名，因此，在认定所选顶级域名具备国家定位作用之前，请先确认其分类。

子域名（de.example.com）可灵活分离站点，并可映射到不同的后端。Google 明确提醒，子域名代码不会被用于确定目标受众，除非您通过 hreflang 和一致的页面信号等方式明确标示目标受众。

子目录（example.com/de/）通常是单主机上最容易部署的方案，后续维护成本也较低。代价是含义可能不够明确：/de/ 可能表示面向全球的德语内容、面向德国的英语内容，或面向德国的德语内容。在确定文件夹名称之前，应先在规划矩阵中明确其用途。

为什么参数不适合作为主要的地理定位方式

Google 在文档中将 URL 参数列为一种语言和地区设置方式，但不建议用它来进行地理定位划分。规模扩大后，参数会带来一些可预见的问题：

1. 重复抓取。同一路径搭配多个 ?loc= 值会产生多种参数组合；除非对参数处理进行细致配置，否则可能分散信号。
2. 用户侧信号较弱。收藏、分享和印刷材料更适合使用稳定的路径。参数会让分析数据和客服工单中的语言及地区信息难以辨认。
3. 页面发现不完整。内部链接、站点地图和 hreflang 集群都需要绝对 URL。大量依赖参数的架构在上线时，往往未配置完整的替代版本集合。
4. 迁移债务。日后从 ?lang=fr 迁移到 /fr/，需要为每个已被索引的 URL 变体建立重定向映射。

参数仍可用于追踪或需身份验证的页面视图，但不应作为主要的划分方式。

仅按语言划分与按国家划分的架构

即使共用底层 CMS，仅按语言划分和仅按国家划分的方案也需要不同的 URL 结构。

仅按语言定位（多语言 SEO）回答的是：这位用户应该阅读哪种语言？常见形式包括：

• /en/、/es/、/ja/ 子目录
• en.example.com、es.example.com 子域名
• 一个全球英语站点，加上逐步新增的语言文件夹

hreflang 值通常仅使用语言代码：hreflang="en"、hreflang="es"。当各个 URL 对应的都是同一页面的实际译文时，规范网址（canonical）策略就比较简单。

按国家定位（多区域 SEO）回答的是：这位用户应该获得哪个市场的体验？常见形式包括：

• 每个国家使用独立的 ccTLD（example.co.uk、example.com.au）
• 按国家设置子域名或文件夹（uk.example.com、example.com/us/）
• 当语言和国家均有差异时，使用结合两者的语言地区文件夹（/en-us/、/en-gb/、/fr-ca/）

hreflang 值通常采用语言加地区的形式：hreflang="en-US"、hreflang="en-GB"。当多个国家 URL 使用同一语言且内容高度相似时，Google 建议选定一个首选版本，并将 rel="canonical" 与 hreflang 配合使用。

更广泛的多语言 SEO 方案设计属于本 URL 层面指南的上层规划；本文聚焦于这些方案所依赖的架构选择。

架构中的 hreflang 与 canonical

hreflang 和 canonical 不能取代 URL 架构，它们只是为您选定的 URL 添加标注。Google 支持通过 HTML 链接标签、HTTP 标头或站点地图设置 hreflang，这些方式的效果相同。每个本地化 URL 都应列出自身及其替代版本，使用包含完整域名的 URL，并确保各版本相互链接。如果两个页面没有相互指向，hreflang 标签可能会被忽略。

由架构决定的 hreflang 规则：

• 集群中每种语言或语言地区变体各对应一个 URL
• 使用与用户所见规范地址一致的绝对 URL
• 使用 x-default 处理未匹配的语言，通常指向语言选择页或全球默认页面
• 仅使用语言代码（de）或使用语言加地区代码（de-AT），并与规划矩阵保持一致

与 canonical 的配合：使用 hreflang 时，应指定同一语言的规范网址；如果不存在同语言的规范网址，则选择现有语言中最合适的替代版本。对于多个区域 URL 上相似的同语言内容，例如 example.de 和 example.com/de/ 上的德语内容，应选择一个首选 URL，并结合使用 canonical 和 hreflang，让 Google 搜索能够展示正确的区域 URL，而不会将所有重复版本都视为无序重复内容。

只有当主要内容仍未翻译时，本地化版本才会被视为存在问题的重复内容。同一语言中细微的地区差异，属于合理的替代页面情形。

本文仅从架构层面概述 hreflang。回链、无效地区代码、站点地图与 HTML 方式的取舍，以及集群质量检查机制，均在配套文章《将 hreflang 集群机制作为独立技术工作流》中深入介绍。当您从 URL 设计进入标注实施阶段时，可阅读该文。

路径之外的语言和地区信号

URL 结构是必要条件，但仅有它还不够。Google 会综合多种信号来判断目标语言和地区：

Google 在进行地理定位时会忽略 geo.position 等位置元标签。地理定位并非完全准确，因此应提供可见链接，让进入错误版本的用户自行选择地区或语言。Google 还指出，定位特定国家可能改善在该国的搜索表现，但也可能牺牲其他地区的表现——这是一种权衡，并不意味着全球曝光度一定会提高。

语言识别遵循不同的规则：Google 根据可见内容判断语言，而不是根据 URL、lang 属性或 hreflang。因此，网站架构必须确保页面内容和导航都以同一种语言为主。

站点地图与大规模页面发现

随着语言和地区版本数量增加，站点地图会与内部链接一起，成为发现页面的主要途径。Google 站点地图可以声明其他语言和地区版本，帮助爬虫找到那些可能深藏于多维筛选菜单中的 URL。

仅纳入规范 URL，在目标市场发生变化时及时更新站点地图，并确保站点地图中的 hreflang 条目与 HTML 或 HTTP 标头中的注释一致。如果不同 ccTLD 分属不同账号，应在 Search Console 中按资源分别提交站点地图。在 URL 和注释的基础配置稳定后，为各语言和地区版本配置结构化数据，可让内容发现不再局限于简单的 URL 列表。

不同架构之间的迁移模式

团队很少能在首次上线时就把架构设计得尽善尽美。常见的迁移路径包括从子目录转向 ccTLD（出于法律层面的分离需求）、从参数转向目录（恢复可抓取性）、合并子域名，以及重命名目录。每种迁移都需要为每个已编入索引的语言和地区版本 URL 制定重定向映射，而不只是首页；同时，还要在同一次发布中更新 hreflang 和 canonical 标记。

迁移原则：先锁定矩阵，优先采用直达目标的 301 重定向，立即将语言切换器指向新 URL，并在第一个月每周验证一次双向引用。Google 并未公布固定的恢复时间表；应记录技术实施是否完整，而不是承诺流量恢复。

导致语言和地区版本难以被发现的架构错误

以下问题会妨碍抓取，或使语言和地区信号混乱：

代价最高的错误，是把架构当成表面功夫：界面元素已翻译上线，URL 对应的正文却仍只有一种语言；或是划分了国家版本，却没有更新页面上的履约信息。用户和搜索系统读取的都是页面上可见的内容。

实施清单

• 制定未来 12–24 个月的国家 × 语言矩阵
• 将每个单元格标注为仅针对语言、仅针对国家，或同时针对两者
• 选择 ccTLD、子域名或子目录，避免主要依靠参数进行地理定位
• 为每个语言或地区版本分配一个可抓取的 URL
• 根据矩阵的定位意图命名目录（有意识地区分 /en-us/ 与 /en/）
• 规划 hreflang 集群，使用相互引用的绝对 URL
• 为同一语言在多个国家版本中的重叠内容制定规范网址策略
• 添加用户可见的语言／地区切换器，并禁用强制语言或地区重定向
• 本地化主要内容和导航，而不只是通用模板文本
• 发布包含规范网址和备用版本注释的站点地图
• 上线后验证索引情况和 hreflang 双向关联
• 使用 ccTLD 时，为每个资源规划 Search Console 监测

搜索引擎抓取与索引

Googlebot 和 Bing 爬虫需要稳定且可通过链接访问的语言或国家/地区网址，无论采用 ccTLD、子域名还是子目录。架构选择会影响抓取预算、规范网址集群和 hreflang 映射。各语言和地区版本应提供爬虫可直接获取的 HTML，而不是依赖不透明的纯客户端路由。使用 Google Search Console 和 Bing Webmaster Tools，按主机或目录监测索引覆盖情况。

答案引擎的访问、来源选择与多语言理解

答案引擎通常也需要能够像用户一样打开网址。如果某个语言版本只能通过身份验证、被拦截的脚本或不稳定的参数访问，就不太适合作为引用来源或被纳入信息来源。应优先采用稳定的语言和地区路径、明确的页面用途，以及跨语言一致的实体信息，让助手能够识别法语、德语或日语内容中所指的是同一家组织。架构并不能保证获得引用；它的作用是消除意外造成的访问和理解障碍。

后续计划：针对 Google、Bing、ChatGPT、Claude、Gemini、Perplexity 和 Microsoft Copilot 分别推出平台优化指南。

针对 Google Search 进行优化

选择 Google 能够抓取并通过 hreflang 建立映射的网址结构：稳定的主机或目录、HTML 语言版本，以及各语言和地区版本之间清晰的内部链接。明确记录已知限制：不要编造排名因素，并将传统索引指标与答案引擎引用检查分开。

针对 Bing 进行优化

确保 Bingbot 同样能够抓取，并在 Bing Webmaster Tools 中验证各语言和地区版本的主机与路径。明确记录已知限制：不要编造排名因素，并将传统索引指标与答案引擎引用检查分开。

平台指南：ChatGPT

助手需要能够访问各语言和地区版本的网址。如果纯客户端语言切换器隐藏了其他版本的 HTML，就会阻碍对来源内容的访问。明确记录已知限制：不要编造排名因素，并将传统索引指标与答案引擎引用检查分开。

平台指南：Claude

权威的本地化文档必须能通过服务器访问；如果架构将内容困在应用内部，就会削弱 Claude 获取来源内容的能力。明确记录已知限制：不要编造排名因素，并将传统索引指标与答案引擎引用检查分开。

平台指南：Gemini

可被索引的多语言和地区版本架构，仍是 Google 生态系统中 AI 体验的实用基础。明确记录已知限制：不要编造排名因素，并将传统索引指标与答案引擎引用检查分开。

平台指南：Perplexity

与仅靠参数切换语言和地区的变通做法相比，稳定的语言网址有助于让引用更持久有效。明确记录已知限制：不要编造排名因素，并将传统索引指标与答案引擎引用检查分开。

平台指南：Microsoft Copilot

当 Copilot 的内容发现与 Bing 索引相关时，应保持多语言架构可被 Bing 索引，而不是编造 Copilot 专属的排名因素。明确记录已知限制：不要编造排名因素，并将传统索引指标与答案引擎引用检查分开。

GlotEO 如何发挥作用

架构决策由工程和 SEO 负责人制定，但如果没有相应的内容工作流程，确保每个语言和地区版本的网址与翻译页面、注释及质量检查清单保持一致，这些决策就难以落实。GlotEO 的多语言 SEO 解决方案为多语言和国际化项目提供这方面的编辑支持，帮助团队按照所选的网址结构发布可供抓取的语言版本，但并不替代上述矩阵规划与迁移工作。

为持续监测效果，应规划 Search Console 资源的拆分方式、hreflang 报告，以及各语言和地区版本的索引覆盖检查。待基础稳定后，再规模化部署结构化数据。

需要统一管理各语言和地区版本编辑工作的团队，可以使用 GlotEO 的多语言 SEO 平台，并进一步比较GlotEO 的价格与套餐。