如何翻译 Astro 网站:i18n 路由与 SEO
通过 i18n 路由、内容集合、本地化 SEO 标签、支持 hreflang 的站点地图以及 MDX 编辑工作流,为 Astro 各语言版本提供可抓取的 URL。

Astro 以静态优先的架构天然适合多语言营销网站,前提是团队将 i18n 路由、内容集合和 SEO 标注视为核心工程工作。Astro 开发者常常部署了结构漂亮的语言版本目录后,才发现缺少 hreflang、页面布局中的通用界面元素仍是英文,或混合渲染中的岛屿组件在客户端显示了未翻译的文本。
本指南介绍如何翻译 Astro 网站,涵盖可抓取的各语言版本 HTML、井然有序的内容集合、本地化布局与 SEO 标签、支持 hreflang 的站点地图、混合渲染注意事项,以及 Markdown 和 MDX 的编辑工作流。所有内容均以 Google 的多语言要求为依据,不杜撰任何排名因素。
本指南将解答的问题
- Astro i18n 路由如何让各语言版本可被抓取?
- 如何按语言组织内容集合?
- 如何本地化 Astro 布局中的通用界面元素和 SEO 标签?
- 如何为 Astro 的静态输出生成 hreflang?
- 多语言 Astro 网站何时需要混合渲染?
- 如何将翻译工作流与 Markdown/MDX 内容集成?
- Astro 多语言网站有哪些常见错误?
- Astro 团队何时应采用翻译平台?
简要结论:各语言版本的静态 HTML 是 Astro 的 SEO 优势
简要回答:使用 Astro i18n 路由,为各语言版本的独立 URL 预渲染完全本地化的 HTML,包括导航、元数据和主要内容,然后在对应的语言版本之间添加相互指向的 hreflang 标注。
为各语言版本的 URL 预渲染 HTML,十分契合 Google 对语言版本可抓取且拥有独立 URL 的偏好。Astro 可在构建时为每个语言版本输出静态文件,让抓取工具获得与用户相同的特定语言文档,无需依赖客户端语言切换。
Google 建议为每种语言版本提供不同的可抓取 URL,而不是仅依赖 Cookie 或浏览器语言。只要为每个语言版本生成独立的输出路径,Astro 的 astro:i18n 路由(或类似的语言前缀模式)就能支持这一模式。
Astro i18n 路由与 URL 设计
在 Astro 中明确配置支持的语言区域和默认语言区域。常见的 URL 模式包括:
- 为默认语言版本添加前缀(
/en/about、/fr/about)——清晰明确,便于添加标注。 - 隐藏默认语言版本前缀(英语使用
/about,法语使用/fr/about)——主要市场的 URL 更简洁;需在 hreflang 中注明对应关系。
在 astro.config.mjs 中,根据你的语言区域配置设置 i18n.locales、i18n.defaultLocale 和 i18n.routing。每个路由文件都应通过 Astro API 获取当前语言区域,以便模板渲染正确的语言。
Google 主要根据可见内容判断页面语言;各语言版本的内容和导航应以同一种语言为主。将导航组件接入能识别语言区域的翻译词典,确保页眉和页脚与正文语言一致。
避免根据推测的语言或位置自动重定向。Google 不建议使用自动重定向,而是建议提供用户可见的语言选择器,链接到其他语言版本的 URL。
如需了解语言定位与国家定位的策略背景,请阅读国际 SEO 与多语言 SEO 的区别。
按语言版本组织内容集合
Astro 内容集合可用于管理博客、文档和落地页文案。组织多语言内容时,应做好规划:
- 为每个语言版本设置独立的集合目录(
src/content/blog/en/、src/content/blog/fr/),并共用数据结构定义。 - 内容量较小时,可在 frontmatter 中设置语言区域字段,在单个集合中按该字段筛选。
- 通过符号链接或自动生成的索引,仅列出各语言版本中已有的内容,避免发布空的语言版本占位页。
每份本地化文档都应引用适合该语言版本的资源和内部链接。法语文章若链接到仅有英文版的文档,会损害用户信任并破坏语言一致性。
如果某个语言版本没有对应内容,不要虚构 hreflang 对应版本:要么补齐对应译文,要么在内容就绪前不声明这一关系。
本地化布局、SEO 和 Open Graph
将布局中的通用界面元素集中到能识别语言区域的组件中:
BaseLayout.astro读取Astro.currentLocale(或你的 i18n 辅助函数),并从 JSON 或 TS 词典中选取文本。<title>和元描述来自每个页面的 frontmatter 或 CMS 字段,而不是硬编码的英文。- Open Graph 和 Twitter 标签与本地化后的标题和描述保持一致。
html lang属性与当前语言区域一致(有助于无障碍访问并明确语言信息;Google 仍通过可见内容判断语言)。
每个语言版本 URL 都应有独立的本地化 SEO 标题和元描述。如果只是浅层地翻译通用界面文本,例如导航已翻译而文章正文仍为英文,就会形成质量欠佳的语言版本。
生成 hreflang 和站点地图
当存在其他语言版本时,Astro 网站仍应通过 HTML、HTTP 标头或站点地图,在各语言版本 URL 之间输出相互指向的 hreflang 标注。在构建时,根据内容关系图生成语言版本对应表:
- 针对每个逻辑页面,列出其所有已发布语言版本的 URL。
- 在每个静态 HTML 文件的
<head>中输出<link rel="alternate" hreflang="..." href="..." />,或者 - 生成 XML 站点地图,为每个 URL 条目添加
xhtml:link对应语言版本。
XML 站点地图有助于搜索引擎发现各语言版本;若选择通过站点地图实现 hreflang,也可以在其中加入 xhtml:link hreflang 标注。
每个语言版本的 URL 都应明确指定同语言的规范网址(canonical)。Google 的规范网址指南同样适用于静态网站和动态网站。
将站点地图生成流程集成到 CI 中——@astrojs/sitemap 配合自定义序列化钩子效果很好——确保内容变化时 hreflang 也能同步更新。
参阅多语言 SEO 基础,了解编辑团队如何配合工程输出管理这些标注。
混合渲染中的岛屿组件与动态内容注意事项
Astro 的岛屿架构允许你选择性地对 React、Vue 或 Svelte 组件进行水合。多语言场景下需注意:
- 仅在客户端运行的小组件可能在 JavaScript 加载完成前显示英文,不利于语言识别,也影响用户体验。
- 尽可能在服务端以正确的语言区域渲染岛屿的初始 HTML。
- 动态路由(
output: 'server'或hybrid)需要通过中间件传递语言区域信息,确保服务端渲染的 HTML 与 URL 前缀一致。
何时需要混合渲染?当内容需要个性化展示、登录后访问或在请求时获取时,应使用混合渲染或服务端渲染;但对于需要获得搜索排名的营销页面,仍应输出可供抓取的静态本地化页面框架。营销页面的各语言区域版本应默认采用静态生成,动态渲染则留给需要身份验证的应用区域。
MDX 和 CMS 内容的编辑工作流
对许多团队而言,Markdown 和 MDX 仍是最易于维护的 Astro 内容层:
- 将界面框架的源字符串存放在翻译文件中(
src/i18n/fr.json)。 - 对于长篇内容,在各语言区域的独立文件中维护 Frontmatter。
- 按语言区域分批提交拉取请求,并进行术语表检查。
- 对于大型文档集,导出至 CAT 或 TMS,再重新导入
src/content。
Google 的实用内容指南强调以用户为先的页面;未经审核就直接发布机器翻译内容,会导致本地化体验单薄、质量不足。
设定发布门槛:如果缺少必填的语言区域字段、内部链接跳出了当前语言区域,或抽样检查的 hreflang 配对未通过双向对应检查,则不得合并。
实施清单
常见错误
- 本地化路由使用仅有英文的布局框架。
- 手动维护静态路径,导致遗漏 hreflang。
- 隐藏默认语言区域,却未声明其他语言版本,导致双向对应关系失效。
- 使用客户端渲染的语言切换控件,却没有独立的 URL。
- 合并未完成的翻译,导致MDX 中混杂多种语言。
- 发布尚未完成的语言区域版本,其中仍含有 lorem 占位文本或英文占位内容。
- 大型静态网站未提供站点地图,导致页面被发现的速度变慢。
- 不慎将canonical 指向其他语言的页面。
Bing 网站管理员指南同样强调内容应可供抓取、对用户有用,且网站结构清晰,以便在不同市场中被索引。
传统搜索与答案引擎的共同基础
无论面向 Google、Bing 还是答案引擎,Astro 静态本地化 HTML 和内容集合都需要相同的基础:可供抓取的各语言版本、明确的实体、有证据支持的主张、如实反映内容的结构化数据,以及真正的本地化,而非仅有英文的页面框架。以下指南从不同平台的角度,阐释同一套多语言交付标准。
平台指南: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 如何发挥作用
Astro 团队应在何时采用翻译平台?当术语表执行、各语言区域的审核队列和 hreflang 矩阵已无法靠手动处理 JSON 和 MDX 拉取请求来有效管理时。
工程团队可以实现完善的 Astro i18n 路由,但本地化仍然需要术语表、审核队列和严格的发布管理。了解 GlotEO 网站本地化,将需求说明、翻译工作流和质量检查关卡接入静态网站内容流水线,让 MDX 和词典更新始终与 Astro 构建生成的 hreflang 及 SEO 元数据保持一致。
当翻译量超出手动编辑 JSON 所能应对的范围时,可比较 GlotEO 的价格与套餐,并使用多语言 SEO 工作流工具,让开发人员和内容团队都能清楚掌握语言区域矩阵及编辑要求。
如果需要在实施前先确定语言与国家策略,可将本篇 Astro 教程与国际 SEO 与多语言 SEO 的区别搭配阅读。
参考文献
- 为本文引用的建议提供依据(Bing 网站管理员指南)
- 为本文引用的建议提供依据(如何使用 rel=canonical 及其他方法指定规范网址)
- 为本文引用的建议提供依据(创建实用、可靠、以用户为本的内容)
- 为本文引用的建议提供依据(告知 Google 您网页的本地化版本)
- 为本文引用的建议提供依据(管理多区域和多语言网站)
- 为本文引用的指导建议提供依据(了解站点地图)