多语言网站不是简单把页面文字翻译成几种语言。真正可长期维护的方案，通常要同时处理数据库模型、URL 结构、前端路由、API 返回、缓存策略和 SEO 标记。本文结合这张“最优多语言架构（数据库 + URL + SEO）”图，梳理一套更适合内容站、产品站和国际化业务站点的设计思路。
这套方案的核心原则可以概括为一句话：同一份内容有统一身份，不同语言有独立版本；URL 清晰表达语言，SEO 标记告诉搜索引擎各语言页面之间的关系。
整体架构：从访问路径到内容输出
图中把多语言网站拆成浏览器/用户、前端应用层、API 服务层、业务服务层、数据库层、静态资源/CDN 和缓存层。用户访问 /zh/xxx、/en/xxx、/ja/xxx 这样的语言路径后，前端负责路由解析、语言识别、SSR/SSG 页面渲染，并输出 SEO 需要的 hreflang 等信息。
API 服务层则根据 locale 与 slug 获取对应语言内容；业务服务层负责权限控制、内容管理、多语言管理、缓存服务和日志监控；数据库层存放主内容表、多语言表、分类/标签表以及站点/语言配置。这样的分层方式，比把所有语言字段硬塞进同一张表更清楚，也更便于扩展。
URL 结构：优先推荐子目录模式
图中推荐使用子目录模式，例如简体中文走 /zh/about，英文走 /en/about-us，日文走 /ja/about。这种方式对大多数单站点项目更友好：域名权重相对集中，部署和缓存规则更统一，搜索引擎也更容易理解语言分区。
不推荐把语言参数放在 query 中，例如 /about?lang=zh，也不建议不同语言共用同一个 URL。原因很直接：搜索引擎需要看到每个语言版本的稳定地址，用户分享和站内链接也需要明确指向具体语言页面。
多域名模式如 zh.example.com、en.example.com 也可以使用，但更适合大型多国家站点。对多数内容站来说，子目录模式通常是成本和 SEO 效果之间更稳的选择。
数据库设计：主内容和语言内容分离
图里的推荐结构是主内容表 content 只保存语言无关的信息，例如内容类型、全局 slug key、状态、发布时间、创建时间等；多语言内容表 content_i18n 保存语言相关字段，例如 locale、标题、slug、摘要、正文、SEO 标题、SEO 描述、OG 标题等。
这种设计的好处是，一条主内容记录代表一个内容身份，不同语言只是它的多个版本。比如同一篇文章可以有中文、英文、日文三个版本，它们共享同一个 content_id，但各自拥有不同的标题、slug 和 SEO 描述。
图中还建议为 content.slug_key、content_i18n.content_id + locale、content_i18n.locale + slug 建立唯一索引。这样既能保证同一内容下语言版本不重复，也能避免同语言下 slug 冲突。
API 设计：用 locale 和 slug 获取内容
多语言 API 不应该只返回一份“默认语言内容”。更合理的做法是围绕 locale 和 slug 设计接口，例如根据语言和 slug 获取页面内容、获取同一内容的所有语言版本、获取分类列表、获取站点语言配置等。
图中给出的响应示例里，同一内容可以返回各语言版本的 slug 和发布状态。这个字段很关键：前端可以据此生成语言切换链接，也能判断某个语言版本是否已发布。如果某个语言尚未翻译，前端应返回 404、noindex，或者显示“暂未翻译”，而不是直接拿其他语言内容硬填充。
SEO 落地：hreflang、canonical 与 sitemap
多语言 SEO 的关键不是“页面上有翻译”，而是搜索引擎能不能识别这些页面是同一内容的不同语言版本。图中列出的最佳实践包括：每个语言页面声明自己的 hreflang，同时包含其他语言版本和 x-default；每个页面的 canonical 指向自己；站点地图按语言生成或在同一个 sitemap 中明确列出各语言 URL。
这里尤其要注意 canonical 的方向。不要把所有语言页面 canonical 到中文页或英文页，否则可能导致其他语言页面不被独立收录。多语言页面之间的关系应通过 hreflang 表达，而不是通过 canonical 合并。
发布流程：先建主内容，再补语言版本
图中的发布流程建议是：先创建语言无关的主内容记录，再为各语言填写标题、正文和 slug，之后进入翻译/校对，最后按语言独立发布。发布后，系统同步生成页面、更新缓存和 sitemap。
这种流程能避免一个常见问题：某篇文章只有中文完成，英文还在翻译，但系统却把英文 URL 也当作可访问页面放出去。更稳妥的做法是使用 is_published 控制每个语言版本的发布状态，未完成语言不要生成可索引页面。
总结
一套可靠的多语言网站架构，应该把“内容身份”和“语言版本”分开，把“URL 结构”和“SEO 标记”放到同等重要的位置。数据库负责清楚表达内容关系，前端负责根据路径和语言渲染页面，API 负责按 locale 返回正确版本，SEO 层负责告诉搜索引擎不同语言页面之间的对应关系。
如果项目还在早期，建议优先采用子目录 URL、主内容表 + 多语言内容表、按语言独立发布、hreflang + canonical + sitemap 组合这几项基础设计。它们不花哨，但足够清晰，也更适合后续扩展更多语言和更多内容类型。
