2026 年如何把网站做成多语言

答案很少是"全部都上"。每新增一个 locale 都意味着持续的内容维护、SEO 监控、翻译审校和访客响应。上 10 个维护不过来的 locale，不如上 2 个维护得好的。

从真实受众出发：看现有流量的国家与语言、看客户说什么语言、看竞对覆盖了你没有的 locale。"受众在哪里"与"你能在哪里保证质量"的交集就是你的 locale 短名单。多数服务企业选两个：主业语言加一个社区语言；跨境业务两到四个。

例如：服务华人社区的美国牙医选英语加中文；面向美国、中国和拉美的顾问选英语、中文加西班牙语。软件和内容站可以在单位经济模型跑通后，再扩展到四到十个 locale。

多语言网站常见的 URL 结构包括带语言前缀的子目录、语言子域名和独立国家域名。Google 建议不同语言使用独立、可抓取的 URL，但并未保证子目录比其他结构排名更高；应根据受众、基础设施和维护方式取舍。

子目录常见的优势是不同语言共用一套主机和代码，维护更方便。Google 支持子目录、子域名和国家域名，并未承诺使用子目录一定获得排名加成。应优先确保每种语言有独立、可抓取的 URL，并选择能够长期维护的结构。

子域名适合由不同团队运营或需要区分基础设施的语言版本，独立国家域名可以提供更清晰的地区定位，但运维成本通常更高。外链、索引和搜索表现受到多种因素影响，不能简单断言子域名必然损失 SEO 权重。

各语言版本应使用独立 URL，并通过受支持的 hreflang 或站点地图标注关联；URL 结构应根据可抓取性、维护成本和业务需求选择。旧版国际定位报告已弃用，不能再用它检查 hreflang。

子域名和独立域名可以适用于独立团队或区域业务，不能一概判断为 SEO 权重损失。Cogo Site 目前不会为租户网站自动生成 hreflang 标签或站点地图 alternate，语言切换也不会更改页面 URL。

翻译质量决定多语言网站是复利还是互相蚕食。三种方案，按成本和质量排序：

方案 A——人工翻译与审校。适用于法律、医疗等对准确性要求较高的内容，但价格与周期取决于语言组合、专业性、内容规模和质量要求。请按实际项目询价，不要将单一每词报价当作普遍标准。

方案 B——AI 翻译加母语审校。AI 起草，母语者审校首页与转化关键页，是多数服务企业的最佳选择。

方案 C——不经人工审校的 AI 翻译。适合低风险初稿，但可能漏掉文化语境或重要事实。Google 不会仅因为用了机器翻译就自动处罚页面；规模化内容滥用政策针对的是主要为操纵排名而批量制造、对读者价值很低的内容，不论其由 AI 还是人工制作。

混合方案可以先用 AI 起草，再由母语者审核首页、定价页和转化关键页。质量和成本受语言、专业领域与审校深度影响，不能承诺固定的人工质量比例或成本节约幅度。

每个多语言页面需要三件套：自指 hreflang、所有其他 locale 的备用声明，以及为无匹配搜索者准备的 x-default。同时，每个 locale 的标题、描述、URL slug 都要用该语言撰写——正文翻译了但 SEO 元数据留在英文，会被 Google 判定为低投入翻译。

站点地图要包含每个 locale 的 URL 并带正确的 hreflang 标注；结构化数据中的可译字段（FAQ 问题、文章标题、面包屑名称）也应翻译。

站点地图：每个 locale 的 URL 都应进入 XML 站点地图。现代 CMS 会自动生成带正确 hreflang 标注的多语言站点地图；手工管理的话，给每个 URL 条目补上 hreflang 标注。

结构化数据：每个 locale 页面的 JSON-LD 应在适用处使用该语言（FAQ 问题、文章标题、面包屑名称翻译）。完整规范参见我们的 hreflang 指南。

翻译只完成一半工作，另一半是区分"真多语言"与"翻译站"的细节。

日期与时间格式：美国用 MM/DD/YYYY，世界多数地区用 DD/MM/YYYY，ISO 标准是 YYYY-MM-DD。按每个 locale 的惯例选择，不要全球统一。

电话与地址：按当地邮政惯例格式化。美国地址是"123 Main St, San Francisco, CA 94101"，中文地址是倒序（国、省、市、区、街道、门牌）。

货币与单位：en-US 用美元，zh-CN 用人民币，es-MX 用比索。不要自动换算——展示该 locale 的真实货币。

社交证明：zh-CN 展示微信/微博/QQ 的客户评价，en-US 展示 Facebook/Twitter/Yelp 的评价。中文页面上出现英文社交证明会传递"外来运营者"的信号。

表单标签与校验：电话校验规则不同（美国10位、中国大陆11位）、邮编不同（美国5位、中国6位）、姓名字段不同（西方的名/姓与中文的姓/名顺序相反）。按 locale 校验。

字体栈也要按 locale 处理：中文需要 CJK 字体（Noto Sans CJK、PingFang、Microsoft YaHei），英文用拉丁字体，混排需要回退栈。

上线后，用 Search Console 的效果报告和网址检查分别监控各语言页面，并通过分析工具观察流量与转化；可用爬虫或站点审计验证 hreflang。旧版“国际定位”报告已弃用，但 Google 仍支持 hreflang。

常见问题与处置：hreflang 报错立即修；某 locale 页面未被收录用网址检查排查；错误版本在错误地区排名就核实 hreflang；某 locale 互动低就复查翻译质量与 UX 细节。每季度重新审计一次 hreflang——站点地图变更和内容迁移都可能让它悄悄失效。

基于数据迭代。如果 zh-CN 的流量是 en-US 的十倍，说明受众在中文世界——优先投入该 locale。如果 es-MX 流量高但转化低，可能是翻译生硬或定价不对——修它。多语言站是活的系统，上线只是开始。

每季度重新审计 hreflang。站点地图变更、内容迁移和 CMS 升级都可能让 hreflang 悄悄失效。每季度用 Ahrefs 或 Sitebulb 全站爬取一次，在排名受损前抓住问题。

错误一：一次性发布太多 locale。每个 locale 都是维护承诺，10 个维护不过来的不如 2 个维护好的。先做价值最高的，验证模式后再扩展。

错误二：把 URL 结构当作排名捷径。子目录、子域名和国家域名各有适用场景。应根据受众、团队管理、基础设施和维护成本选择独立、可抓取的语言 URL，而不是相信某种结构必然带来 SEO 权重红利。

错误三：只翻译正文，不翻译元数据。应按需本地化标题、描述、图片替代文本和结构化数据，让访客和搜索引擎更容易理解各语言页面。这是内容质量改进，不等于自动提升排名。

错误四：机器翻译不做母语审校。AI 翻译很好但不完美，首页和转化关键页一定要母语者过一遍。成本很小，质量收益很大。

错误五：所有 locale 共用同一套 UX 细节。日期、电话、货币、社交证明、表单校验都需要按 locale 处理——"一套走天下"的 UX 等于告诉访客"我们其实不了解你所在的地区"。

错误六：忘记百度和 Bing。Google 主导西方，百度主导中国大陆，Bing 在部分企业和教育场景仍然重要。确保 hreflang 和站点地图对三者都成立。