# General Translation Knowledge Base: 多语言 SEO：子目录、子域名与 ccTLD 对比
URL: https://generaltranslation.com/zh/kb/multilingual-url-structure.mdx
Docs index: https://generaltranslation.com/llms.txt
Description: 如果同一产品共用一个站点和发布流程，请使用 example.com/de/ 这样的子目录。只有 ccTLD 能指明目标国家，子域名便于独立托管；Google 不建议使用 ?lang= 参数，并会将 .io、.ai 等个性化域名视为通用域名。
Category: 多语言 SEO
Last updated: 2026-10-20
Authors: Kevin Wu, Jackie Chen
Published: 2026-10-20

本文介绍的每种结构都会为每种语言分配独立的 URL。Google 的[多地区和多语言网站指南](https://developers.google.com/search/docs/specialty/international/managing-multi-regional-sites)从定位方式和维护成本两方面对它们做了比较，但并未认定哪一种更优。因此，选择哪种结构归根结底取决于两个问题：你面向的是语言还是国家？你打算运营多少个站点？

## 四种 URL 结构对比

以下优缺点转述自 Google 官方的对比表。最后一种方式 (URL 参数) 被 Google 标注为不推荐。

| 结构                   | 示例                    | Google 列出的优点            | Google 列出的缺点                                   |
| -------------------- | --------------------- | ----------------------- | ---------------------------------------------- |
| 国家/地区代码顶级域名 (ccTLD)  | `example.de`          | 地理定位清晰；与服务器位置无关；便于拆分站点  | 成本高且有时无法注册；需要更多基础设施；部分国家对 ccTLD 有严格要求；只能定位单一国家 |
| 子域名                  | `de.example.com`      | 易于设置；可使用不同的服务器位置；便于拆分站点 | 用户无法从 URL 判断 `de` 指的是语言还是国家                    |
| 子目录                  | `example.com/de/`     | 易于设置；维护成本低 (同一主机)       | 用户可能无法从 URL 看出定位目标；只能使用单一服务器位置；较难拆分站点          |
| URL 参数               | `example.com?lang=de` | 未列出 (不推荐)               | 难以按 URL 细分；用户可能无法看出定位目标                        |

Google 指南中的两个细节让这几种方案的差距进一步缩小：

* **在各种 URL 形式中，只有 ccTLD 能指示国家。** Google 的[本地化版本指南](https://developers.google.com/search/docs/specialty/international/localized-versions)指出，`en` 或 `de` 等语言子域名不会用于判断页面的目标受众；你需要通过 [hreflang](/kb/what-is-hreflang) 显式指定。Google 并未专门提及目录，但也没有迹象表明 `/de/` 路径会被区别对待，因此同样应使用 hreflang 进行映射。
* **部分 ccTLD 被视为通用域名。** Google 将 `.io`、`.ai`、`.co`、`.me`、`.tv` 等"个性化" ccTLD 以及 `.eu` 等区域性域名视为通用顶级域名。使用 `example.io` 的初创公司，目标用户显然不是英属印度洋领地。

Google 还指出，由于网站普遍使用 CDN，服务器位置"并非决定性信号"，因此子目录"只能使用单一服务器位置"这一缺点的影响也随之减弱。

第五种方式是保持 URL 不变，通过 cookie 或浏览器请求头切换语言。Google 不建议这样做，因为其爬虫可能无法发现所有语言版本；相关取舍详见[网站应如何选择提供的语言](/kb/locale-routing-seo)。

## 各种结构的运维成本

Google 的对比表只写到“需要更多基础设施”为止。实际上，这几种结构的区别在于你需要分别维护多少项内容：

* **国家/地区域名：**每个国家/地区都要单独购买并续费域名，部分国家/地区还有本地注册要求。每个主机都需要 TLS 覆盖；一张证书可以覆盖多个名称。你需要统筹规划这些域名的归属管理、重定向和监控。
* **子域名：**只需一个域名，但每个子域名都需要一条 DNS 记录，并且要有证书覆盖。Google 的[规范化指南](https://developers.google.com/search/docs/crawling-indexing/consolidate-duplicate-urls)提醒，证书必须与完整主机名匹配或使用通配符证书，否则 Google 可能会优先选择 HTTP 版本。
* **子目录：**各语言可以共用同一个主机、TLS 配置、应用和部署流水线。这些只是常见的运维选择，并非硬性要求：反向代理可以将不同路径路由到不同的应用，分析数据也可以不依赖 URL 结构进行组织。

不要以为子目录能获得排名加成，也不要以为每个新子域名都是从零信号起步。Google 的对比并不能证明其中任何一种说法。请根据你实际部署所需的托管、归属管理和发布工作量进行比较。

## 应该按语言还是按国家定位？

Google 将**多语言**网站 (以多种语言提供相同的内容，例如一家同时提供英语和法语服务的加拿大企业) 与**多地区**网站 (针对不同国家提供不同的内容，例如一家同时向加拿大和美国发货的制造商) 区分开来。URL 结构应取决于你的网站属于哪一类：

* 如果内容对所有使用该语言的人都一样，就**按语言定位**。一个标注为 `es` 的 `/es/` 版块即可同时服务墨西哥、西班牙和阿根廷的西班牙语用户。
* 如果有内容因国家而异，例如价格和货币、配送、法律条款或消息目录，就**按国家定位**。使用 `/es-mx/` 和 `/es-es/`，或 `example.mx`，并分别标注为 `es-MX` 和 `es-ES`。

按国家定位是有代价的。Google 指出，地理定位可以提升网站在目标国家的排名，但这是"以牺牲在其他区域设置或语言中的搜索结果为代价"的；而且一个 ccTLD 只能定位一个国家。如果你确实要按国家划分，Google [建议](https://developers.google.com/search/docs/specialty/international/localized-versions)同时提供一个仅按语言区分的页面 (`es`) ，供其他地区的用户访问。关于如何在 `es` 和 `es-MX` 等代码之间做出选择，请参阅[应使用哪些区域设置代码](/docs/platform/core/guides/locale-codes)。

## 本地化 slug

区域设置前缀让当前语言版本在 URL 中一目了然；路径的其余部分也可以翻译，例如用 `/de/ueber-uns` 代替 `/de/about-us`。Google 表示，URL 中使用本地化词语没有问题，国际化域名也同样可行，前提是 URL 采用 UTF-8 编码，并且在添加链接时正确转义。像 `/de/über-uns` 这样的非 ASCII slug 在传输时会变成 `/de/%C3%BCber-uns`，因此 hreflang 和站点地图中应使用这种编码后的形式。

翻译后的 slug 在搜索结果中读起来更自然，但每个区域设置都需要额外维护一份 slug 映射；而一旦某个 slug 的译文发生变化，就需要为旧 URL 设置重定向。不使用本地化 slug 的团队可以保留 `/de/about-us`，每种语言依然拥有独立且可被索引的 URL。

## 应该选择哪种结构？

如果一个产品通过共享的站点和发布流程支持多种语言，建议先从**子目录**入手。这种方式通常可以复用路由和托管配置。当然，你仍然可以采用独立部署，CDN 也能从多个地点为同一主机提供服务。

如果每个国家实际上都是独立运营的业务 (拥有独立的法律实体、消息目录或营销团队) ，而你希望获得最强的国家信号，也愿意承担相应的维护成本，请使用**国家/地区域名**。

如果某个区域设置需要不同的托管环境或基础设施，例如某个市场必须由位于该国境内的服务器提供服务，请使用**子域名**。

不要将 **URL 参数**用作默认的语言结构，因为 Google 不推荐这种做法。URL 参数本身并不会导致页面无法被索引；报告和缓存行为取决于你的系统如何处理这些参数。

无论选择哪种结构，都应使用稳定的 URL，并通过 hreflang 标注各个对应的已发布版本。 (参见[什么是 hreflang](/kb/what-is-hreflang)。)

## General Translation 如何支持各种结构

General Translation 的 `gt-next` 支持子目录。在 App Router 中，[`createNextMiddleware`](/docs/react/nextjs/reference/functions/create-next-middleware) 会为每个区域设置添加路径前缀进行路由，例如 `/es/about`；默认区域设置是否也带前缀，请参阅[区域设置路由与 SEO](/kb/locale-routing-seo)。该中间件的 `pathConfig` 选项可将共享路径映射为各区域设置的本地化 slug，例如将 `/about` 映射为 `/de/ueber-uns`；而 `gt.config.json` 中的 `customMapping` 允许路由使用 `/cn` 之类的别名，译文则仍使用规范代码 `zh` (参见[区域设置别名 SEO 指南](/docs/react/nextjs/locale-alias-seo)) 。

`gt-next` 文档介绍的是基于路径的路由，不涉及基于主机名的路由。如需使用子域名或国家/地区域名，请在自己的代码中将每个主机映射到对应的区域设置，再传给库，例如通过 [`getLocalePath`](/docs/react/nextjs/config#request-function-paths) 设置自定义区域设置函数，或在 `gt-node` 中使用 [`withGT`](/docs/node/reference/functions/with-gt)。关于规范网址标签、hreflang 和站点地图，请参阅[如何为多语言 Next.js 应用设置 SEO？](/kb/multilingual-nextjs-seo)。

## 要点总结

* Google 在比较 ccTLD、子域名和子目录时，着眼的是定位能力和维护成本，而非排名；此外，Google 不建议使用语言 URL 参数。
* ccTLD 能提供国家/地区信号；而形似语言代码的子域名和路径本身并不提供这一信号。如需明确定位语言或地区，请使用 hreflang。Google 将 `.io`、`.ai` 和 `.co` 视为通用域名。
* 如果各个区域设置共用同一个站点和发布流程，建议先采用子目录 (`example.com/de/`) ；这种 URL 结构并不要求只能使用一个部署或一个分析属性。
* 仅当价格、配送、法律条款或消息目录存在差异时，才按国家/地区拆分 (`es-MX`) ；否则按语言定位 (`es`) 即可。
* `gt-next` 通过 `pathConfig` 提供路径前缀路由、可选的默认区域设置前缀以及本地化 slug。

## Related questions

- [什么是 hreflang？如何设置？](https://generaltranslation.com/zh/kb/what-is-hreflang.mdx): Hreflang 用于告诉 Google 哪些 URL 是同一页面的不同语言或区域版本，以便在搜索结果中展示正确的版本。你可以通过 HTML link 标签、HTTP Link 响应头或站点地图来添加它，确保所有链接相互指向，并使用有效的代码，例如 en-GB，而不是 en-UK。
- [语言重定向与 SEO：URL、cookie 还是 Accept-Language？](https://generaltranslation.com/zh/kb/locale-routing-seo.mdx): 凡是希望被搜索引擎收录的页面，都应由 URL 决定其语言，因为 Googlebot 不会发送 Accept-Language 请求头，而且大多从美国 IP 地址抓取。只有在决定 / 这类中性根路径重定向到哪里时，才应优先参考 cookie 中保存的用户选择，其次是 Accept-Language，并使用临时的 302 或 307 重定向。
- [如何为多语言 Next.js 应用设置 SEO？](https://generaltranslation.com/zh/kb/multilingual-nextjs-seo.mdx): 为每种语言提供带前缀的独立 URL，例如 /en/about 和 /es/about，然后为每种已发布的语言提供 html lang、自引用的规范网址、包含 x-default 的 hreflang 替代项、翻译后的 title 和 description，以及站点地图条目。将未发布的版本标记为 noindex。General Translation 的 gt-next 会将每种语言路由到各自的 URL，并通过 getGT 翻译标题。
- [如何让网站支持多语言？](https://generaltranslation.com/zh/kb/make-website-multilingual.mdx): 先确定译文放在哪里：代理、CMS 插件、建站工具，还是你自己的代码；然后按照 Google 的建议，为每种语言分配独立的 URL。完整翻译页面以及标题和元描述，用 hreflang 关联各语言版本，并提供语言切换器，而不是自动重定向访问者。

## Previous and next questions

- Previous question: [国际化与本地化（i18n 与 l10n）](https://generaltranslation.com/zh/kb/internationalization-vs-localization.mdx)
- Next question: [如何使用 String Catalogs 本地化 iOS 应用？](https://generaltranslation.com/zh/kb/localize-ios-app.mdx)

## Sitemap

See the [Knowledge Base sitemap](https://generaltranslation.com/zh/kb/sitemap.md) for every article.