翻译 Next.js 网站：可抓取的多语言路由与 SEO

了解如何翻译 Next.js 网站：使用基于路径的多语言网址、本地化元数据、hreflang 和易于维护的术语表工作流程，而非仅依赖 Cookie 切换语言。

Grant Davies更新于

翻译 Next.js 网站：白色网格背景上的 Next.js App Router 文件夹树，其中 [locale] 节点连接到一个页面

翻译 Next.js 网站不只是使用 i18n 库的问题。搜索引擎需要每个语言版本都有独立且可抓取的 URL，并且元数据和正文文案都要在初始 HTML 响应中呈现。如果在同一个 URL 上仅通过 Cookie 或客户端切换语言，Google 就无法为各个语言版本分别建立索引。

在深入了解 App Router 路由段之前，请先记住一条原则：为每种语言提供独立且可抓取的 URL。Google 建议为不同语言或地区使用不同的 URL，而不是仅依赖 Cookie 或浏览器语言。无论是 /en/ 和 /de/ 这样的路径前缀、专用子域名，还是独立域名，都能提供可被索引的地址。在同一个 URL 上仅通过 Cookie 切换语言则无法做到这一点。

开发时，通过 Cookie 切换语言区域看起来很方便，因为无需为各个版本分别设置路由。但从生产环境的 SEO 角度看，这种方式会让抓取工具无法发现不同语言版本。基于路径的语言区域设置可以提供稳定的地址，便于将其列入站点地图、添加 hreflang 注释，并在 Search Console 中监测。如需深入了解面向市场与面向语言的策略差异，请参阅我们的国际 SEO 与多语言 SEO 对比指南。

为 Next.js 选择多语言 URL 结构

Next.js 团队通常会从以下三种可抓取的结构中选择一种：

  1. 子目录 — example.com/en/docs、example.com/fr/docs。便于在同一主机上部署，层级清晰，方便配置 hreflang。
  2. 子域名 — en.example.com、fr.example.com。适合地区团队相对独立运营的情况，但仍需设置双向 hreflang 引用。
  3. 国家和地区顶级域名（ccTLD）或专用域名 — 如果确实在独立运营不同站点，这种方式能提供最强的地理定位信号，但运维成本也最高。

Google 主要根据可见内容判断页面语言。无论选择哪种结构，每个 URL 下的内容都应以一种语言为主，包括导航、页脚链接和错误页面。除非有明确的用户体验需求，否则应避免在同一模板中混用多种语言。

不要根据推测的语言或位置自动重定向访客。Google 不建议这样做，因为这可能阻碍抓取工具访问，也会给用户带来困扰。应提供清晰可见的语言选择器，链接到其他语言区域版本的 URL。

App Router 与语言区域路由段设计

在 App Router 中，常见的做法是使用动态 [locale] 路由段：将本地化页面放在 app/[locale]/layout.tsx 下。在统一的配置对象中定义支持的语言区域，并在布局或中间件中验证 params.locale。无效的语言区域应返回 404，而不是在同一 URL 下悄悄回退为英语。

中间件可以将不带语言区域的 / 重定向到默认语言区域目录，例如 /en/，但仍需确保可以通过链接访问其他版本。静态生成营销页面时，可将中间件与 generateStaticParams 配合使用，提前构建每个语言区域的页面。

Cookie 与路径式语言区域设置对比：在同一个 URL 上通过 Cookie 或请求头协商语言，只会改变内容，不会改变地址。抓取工具通常只会对一个 URL 抓取一次，因此无法看到所有语言版本。基于路径的语言区域设置（或对应的子域名、独立域名方案）符合 Google 对不同版本使用不同 URL 的建议。用户选择语言后，仍可使用 Cookie 保存其偏好，只要公开 URL 保持独立即可。

可以使用 next-intl、next-i18next 或类似库来加载翻译文本，但公开 URL 应由路由决定，而不能仅靠 Cookie。

本地化元数据、Open Graph 和结构化数据

每个语言区域路由都需要在服务端渲染的 HTML 中包含专属的 <title>、元描述、canonical 和 Open Graph 标签。在 App Router 中，为每个页面使用 generateMetadata，从翻译文件中读取已翻译的字符串。本地化的标题和元描述不应依赖水合后在客户端切换语言来生成。

JSON-LD 也应遵循同样的原则：WebPage、Organization 和 FAQ 数据块应使用翻译后的字符串，以及适合相应语言区域的 inLanguage 值。如果输出 hreflang 链接元素，应在布局或页面元数据辅助函数中生成完整的双向引用集合；缺少反向链接会破坏 hreflang 页面组。

Next.js 的 hreflang、canonical 与站点地图

hreflang 用于告知 Google 其他语言或地区版本的 URL。同一页面组中的每个 URL 都必须使用匹配的代码引用其他所有成员，包括自身。可以在 <head>、HTTP 响应头中实现 hreflang，也可以通过 XML 站点地图中的 xhtml:link 条目实现；每个网站应统一采用一种方式。

如果存在重复页面（例如带跟踪参数的页面或打印视图），每个语言区域 URL 还需要通过 canonical 指向该语言的首选 URL。不要将法语页面的 canonical 指向对应的英语页面；canonical 用于合并同一语言下的重复页面。

为每个语言区域分别生成站点地图，或使用一个站点地图索引列出包含所有语言 URL 的站点地图。站点地图有助于发现页面，也可以包含 hreflang 注释。部署后，使用 Search Console 的网址检查工具和 hreflang 测试流程抽样验证。我们的多语言 SEO 平台概览介绍了 SEO 团队如何跨语言区域审核这些信号。

避免仅在客户端切换语言的页面空壳

Next.js 中一个常见陷阱是先渲染英语 HTML 页面框架，再在 useEffect 中替换字符串。抓取工具未必能可靠地执行这次替换，用户也会看到错误语言一闪而过。应通过服务端组件、静态生成或 SSR，在首次响应中就渲染翻译后的文案。客户端组件可以对交互部分进行水合，但营销文案和标题应放在服务端组件树中。

基于路径或子域名的语言区域路由可以创建独立且可抓取的 URL；仅靠 Cookie 切换语言区域则不符合 Google 的建议。如果使用翻译代理进行预览，请确保生产环境仍为每个语言区域 URL 提供完整的 HTML。

内容工作流程：术语表、翻译记忆库与审校

当翻译偏离产品术语时，再好的技术方案也难以在目标市场奏效。应在 Next.js i18n 文件的基础上，配套使用术语表、翻译记忆库（TM）和人工审校。Google 的实用内容指南强调以用户为本的页面；内容单薄或只有模板套话的语言版本，既不利于 SEO，也难以成为优质的答案来源。

工作流程概览：

  • 从 JSON 或 PO 文件中提取字符串，导入适配计算机辅助翻译（CAT）工具的流程。
  • 确保产品名称和界面标签严格遵循术语表。
  • 在预发布环境的 URL 上进行语言质量检查，而不只是比较源文件差异。
  • 英语源文更新时，重新同步翻译；过时的本地化内容会削弱用户信任。

实施清单

上线前，确认抓取路径、元数据和注释配置：

Bing 网站管理员指南同样强调内容应可抓取、有实用价值且结构清晰；有助于 Google 的做法，通常也有助于 Bing 建立索引。

常见错误

在同一 URL 上仅靠 Cookie 切换语言区域 — 抓取工具无法发现不同版本。

缺少 hreflang 反向链接 — 破坏双向引用关系，削弱页面组的关联。

翻译页面的 canonical 指向英语版 — 发出错误的重复页面合并信号。

仅在客户端生成元数据 — 初始 HTML 中缺少标题和描述。

根据 IP 或 Accept-Language 自动重定向——会阻碍爬虫抓取，并无视用户的选择。

未翻译的界面元素——多种语言混杂的导航会干扰语言识别。

未经审核的粗糙机器翻译——无法满足对实用内容的要求。

传统搜索与答案引擎的共同基础

对于 Google、Bing 和答案引擎而言，Next.js 多语言路由与服务端渲染 HTML 的共同基础依然重要：可供抓取的各语言版本、明确的实体、有证据支持的主张、如实反映内容的结构化数据，以及真正的本地化，而非仅有英文内容的空壳。以下指南从不同平台的角度，阐释了同一套多语言内容交付标准。

对于 Google 搜索，内容能否被发现，取决于各语言和地区版本是否拥有可抓取的 URL、HTML 内容是否使用相应语言、标题和各级标题是否准确，以及存在替代版本时是否设置了相互指向的 hreflang。技术基础包括可被索引的内容（而非仅靠 Cookie 切换版本）、本地化元数据、站点地图，以及规范使用 canonical 标记。内容质量意味着每种语言的主体内容都应以用户为本；权威性来自清晰的组织身份和可相互印证的来源，而非翻译工具的营销宣传。对多语言内容而言，这意味着每个市场或语言版本的 URL 都必须能够独立发挥作用。衡量时，应按语言和地区版本查看 Search Console 的索引覆盖情况并使用网址检查工具。已知与不确定之处：Google 对多语言及 hreflang 的运作方式有明确文档，但不保证任何 CMS 或机器翻译译后编辑（MTPE）工作流程能带来排名。

平台指南：Bing

Bing 会发现并索引可抓取、结构清晰的多语言页面，这与 Google 对网址和内容清晰度的要求类似。技术基础包括可访问的各语言和地区版本网址、有实用价值的内容，以及通过 Bing Webmaster Tools 进行监测。应优先本地化各级标题、主张和常见问题，而不是只翻译界面框架。权威性信号仍取决于可信来源和一致的实体信息。对多语言网站而言，不要将语言版本隐藏在仅由客户端控制的切换功能之后。通过 Bing Webmaster Tools 衡量索引收录情况和抓取统计数据。已知与不确定之处：Bing 指南强调内容应可抓取且有实用价值；不要凭空编造与翻译工具有关的 Bing 专属排名因素。

平台指南：ChatGPT

当语言版本清晰、内容可直接用于回答问题时，ChatGPT 可能会引用或概述公开可访问的页面。这里的内容发现机制并非传统的抓取排名；可见性体现为被选作信息来源，或在回答中被引用。技术基础仍然始于可访问的 HTML 页面 URL，而不是将文案隐藏起来的叠加式小组件。有助于被采用的内容特征包括直接的回答、常见问题解答，以及基于术语表保持一致的术语。权威性来自证据，以及各语言和地区版本中一致的实体信息。对多语言内容而言，这意味着每个语言和地区版本的页面都应能独立阅读理解。衡量方法尚不完善，应将引用检查的结果视为有待验证的假设。已知与不确定之处：目前没有文档保证 MTPE 或任何 CMS 集成能让内容获得 ChatGPT 引用。

平台指南：Gemini

一致的实体信息、准确的结构化数据，以及可编入索引的本地化页面，有助于内容在 Gemini 和相关 Google AI 体验中被理解和使用。可见性关乎内容是否被引用或识别，而不是凭空编造 Gemini 排名因素。其技术基础与 Google 搜索的可抓取性和元数据质量要求相通。每种语言的内容都应清晰呈现主张和定义。权威性取决于组织信息的一致性及佐证。对多语言网站而言，通过术语表统一产品名称可减少不同语言和地区版本之间的混淆。衡量时，可通过 Search Console 使用传统指标，并抽样查看 AI 回答进行定性评估。已知与不确定之处：Gemini 的表现不能取代 Google 搜索关于 hreflang 和语言版本的官方文档指导。

平台指南：Google AI Overviews

Google AI Overviews 可能会链接到提供支持信息的页面；判断内容是否具备入选资格，仍以以人为本、可编入索引的内容为基础。它不是语言切换工具，也不能替代 hreflang。技术基础依然是可抓取的各语言和地区版本 HTML，以及如实反映内容的结构化数据。内容应在每种语言中提供简明的答案和清晰的各级标题。权威性信号与实用内容的要求一致。对多语言网站而言，任何翻译页面都无法保证被 AI Overviews 收录。在可用的情况下，通过 Search Console 的生成式搜索报告衡量表现，并与传统索引指标分开统计。已知与不确定之处：没有任何翻译流程能够承诺内容会出现在 AI Overviews 中。

GlotEO 如何发挥作用

自行搭建的 Next.js i18n 方案适用于小型网站；随着规模扩大，还需要术语表管理、审核队列，以及针对各语言和地区版本的 SEO 验证。GlotEO 可与现代技术栈集成，让营销人员管理翻译，同时让工程师保留 App Router 结构。

将本地化视为路由和内容质量问题，而不只是替换字符串的团队，能在不破坏抓取路径的前提下更快地迭代。在译员开始工作前共享术语表，在预发布环境中结合页面上下文进行审核，并在每次新增路由时重新检查 hreflang。在 Search Console 中，按各语言和地区版本的文件夹或子域名分别衡量索引收录情况，而不是仅依赖全站汇总数据。

通过 GlotEO 网站本地化了解其网站本地化平台，并在规划上线范围时比较 GlotEO 价格与套餐。

参考文献