React 网站翻译：超越 i18n 库，打造可抓取的多语言版本

React i18n 库解决了字符串加载问题，但多语言 SEO 还要求在不同语言版本的独立 URL 下提供可索引的 HTML。在单个 SPA 路由上仅通过客户端切换语言，会让 Google 无法发现其他语言版本，还常常导致水合时出现语言闪烁。

简明答案：为每个语言版本的 URL 提供可索引的 HTML

要让 React 网站的翻译版本适合搜索引擎抓取，关键是为每个语言版本设置独立 URL，并提供完整的 HTML。Google 建议为不同语言提供各自可抓取的 URL，而不是仅依赖 Cookie 或浏览器语言。react-i18next 等库虽不可或缺，却仍不够——你还需要制定路由和渲染策略。

如果主要内容只有在 JavaScript 检测语言后才会显示，爬虫可能无法看到完整的语言版本。SSR、SSG、预渲染或元框架（Next.js、Remix）可以弥补这一缺口。

为什么 SPA 语言切换无法满足 SEO 需求

传统的 create-react-app 单页应用（SPA）只返回一个内容很少的 index.html，再在客户端通过水合填入翻译后的字符串。爬虫抓取的是一个 URL，并不一定会执行所有语言分支。各语言版本需要独立、可抓取的 URL；在单个 URL 上仅通过客户端切换语言，不符合 Google 的多语言网站指南。

对于公开的营销页面，如果在 /app/dashboard 上通过 Cookie 或 localStorage 设置语言区域，却不改变 URL，也会产生同样的问题。如果主要内容在 JavaScript 检测语言后才被注入，就会影响索引收录。

避免根据推测的语言自动重定向。应提供清晰可见的语言选择器，分别链接到 /en/pricing 和 /de/preise。有关策略背景，请参阅国际 SEO 与多语言 SEO 的区别。

React 的语言区域路由模式

使用 React Router（或所用框架的路由器）配置语言区域前缀：

• /en/products, /fr/produits
• 将子域名路由映射到同一路由树
• 为静态网站的各语言版本分别构建

Google 根据可见内容判断页面语言——每个路由的内容应以一种语言为主，包括导航和页脚。尽可能让 URL 路径中的可读名称与对应语言区域一致，以便用户理解。

SSR、SSG 和预渲染方案

对于公开页面，翻译后的文案必须在水合前就出现在 HTML 响应中。客户端组件可以承载交互功能；价值主张和标题应在服务端或预渲染阶段完成渲染。

本地化元数据与结构化数据

为每个语言版本的路由设置 <title>、元描述、canonical、Open Graph 和 Twitter 标签。在 SSR 中使用 React Helmet 时，应在服务端输出标签。使用 Next.js 时，则采用 generateMetadata。本地化的标题和元描述不应依赖客户端替换。

结构化数据（WebSite、Product、常见问题）中的字段需要翻译，并设置正确的 inLanguage。确保 JSON-LD 与可见文案一致——两者不符会让爬虫和用户产生困惑。

Hreflang 与 canonical 标签

为每个路由在文档头部添加 hreflang 链接元素，列出包括自身在内的所有语言版本。同一组语言版本之间必须通过 hreflang 相互引用。存在重复页面时，canonical 标签应指向同一语言下的首选 URL。

对于路由数量庞大的 SPA，可通过构建脚本或站点地图中的 xhtml:link 条目生成 hreflang。我们的多语言网站 SEO 优化指南提供了审核清单。XML 站点地图有助于搜索引擎发现页面，也可以包含 hreflang 注释。

i18n 库之外的内容工作流

i18n 库负责管理键，但不会强制落实术语表、翻译记忆库（TM）或审校流程。还需引入翻译平台或计算机辅助翻译（CAT）工作流：

• 定期导出 JSON/PO 文件
• 在术语表中锁定产品术语
• 在各语言版本的预发布环境 URL 上进行审校
• 英文内容变更后重新导出

Google 的实用内容指南强调以用户为本；即使路由设置正确，内容空洞的语言版本也无法达到这一标准。

实施清单

• 所有公开路由的每个语言版本均有独立 URL
• 通过 SSR、SSG 或预渲染生成营销页面的 HTML
• 初始响应中包含本地化元数据（通过查看页面源代码验证）
• hreflang 相互引用，各语言版本分别设置 canonical 标签
• 各语言版本的站点地图条目已提交至 Search Console
• 提供清晰可见的语言选择器（不按 IP 自动重定向）
• 已测试水合过程，确保不会短暂闪现英文内容
• 核心内容页面采用术语表并经过审校

Bing 网站管理员指南同样强调内容应可供抓取、具有实用价值，并具备清晰的结构。

常见错误

实现 i18n 却未设置语言区域路由——只有一个 URL，其他语言版本无法被发现。

仅在客户端使用 Helmet——查看页面源代码时，标题为空。

翻译版路由的 canonical 指向英文版——传递错误信号。

根据 Accept-Language 自动重定向——给爬虫和用户带来阻碍。

导航框架未翻译——传递混杂的语言信号。

仅预渲染首页——爬虫访问深层链接时，看到的仍是空白页面。

未经审核就发布机器翻译——本地化内容质量不足。

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

对于采用 SSR/SSG、为不同语言区域提供独立 URL，而非仅在客户端切换语言的 React 网站，Google、Bing 和答案引擎看重的基础要求依然相通：可抓取的各语言版本、明确的实体、有证据支持的主张、如实反映内容的结构化数据，以及真正的本地化，而不是仅有英文的页面框架。下方指南从各平台的角度出发，解读同一套多语言内容交付标准。

平台指南：Google Search

对于 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 如何发挥作用

当 React 团队的多语言需求不再局限于切换 JSON 文件时，就需要术语表管理、翻译审核和 SEO 验证。GlotEO 可对接现代技术栈，同时让工程师继续掌控语言区域路由。在规划 React 多语言上线时，可了解 AI 网站翻译与本地化及网站翻译定价。