第 17 章 国际、多语言与多地区 SEO

17.1 学习目标：让正确的人进入正确的版本

完成本章后，你应当能够把语言、文字体系、国家或地区、货币、业务覆盖范围分别建模；选择可维护的国际站地址结构；设计和测试 hreflang；判断一个页面应该翻译、改写、合并，还是根本不发布。更重要的是，你应当能解释：一个页面在某地区没有点击，究竟是没有需求、没有被发现、没有进入索引、版本匹配错误，还是产品本身无法服务当地用户。

国际 SEO 的目标不是把中文网站批量变成几十种语言，而是让不同市场的人能够发现并完成任务。翻译是其中一道工序。假设你经营一个 Go 日志分析工具，英文读者可能需要安装命令、部署限制和计费说明；一个英语页面可以服务许多国家。但如果你销售实物，同一语言下不同地区的库存、配送、插头规格和退款流程可能不同。这时，仅有语言选项不足以表达业务差异。反过来，把一个全球可用的开源工具复制成二百个国家版本，也可能制造维护负担，而没有新增用户价值。

Google 将多语言网站和多地区网站分开讨论，建议不同语言使用独立 URL，并用明确链接让人选择版本。[E01] 这给工程设计一个简单起点：先确定你承诺维护哪些版本，再确定版本之间的关系，而不是先购买域名或安装翻译插件。

17.2 四个不能合并的维度

语言是内容使用什么语言，例如中文、英语和法语。文字体系是语言如何书写，例如简体与繁体中文。地区是页面面向哪里的使用场景，例如加拿大或新加坡。商业市场则是你实际能销售、交付、支持和承担责任的范围。这四个维度经常相关，却不能互相替代。

一个人在德国使用英语搜索，并不意味着他要看面向美国的价格和配送页面。一个在美国工作的中文开发者，可能更喜欢简体中文文档。一个繁体中文页面也不应自动被理解为只适用于某一个地区。你的系统如果只有 country 字段，会把语言偏好硬塞进地理模型；如果只有 language 字段，则难以正确表达同语言下的履约区别。

建议至少分开保存 content_language、script、market、currency、availability 和 support_language。是否全部成为 URL 维度，要另行判断。例如文档的 market 可以为空；价格页的 market 可以有值；货币可以是一个可切换显示偏好，但不能掩盖实际结算币种。这样编辑、计费、分析系统才能使用同一套定义。

语言标签也有两层规范。网页国际化常使用 BCP 47，W3C 说明语言、文字和地区子标签承担不同作用，应只增加确有区分价值的部分。[E04] 搜索引擎某个功能的支持范围可能比标准更窄。Google 的 hreflang 文档支持特定语言、地区和文字代码；例如英语面向英国写 en-GB，简体中文不限定地区可以写 zh-Hans。Google 不支持 es-419，也不把 UK、EU 这样的地区部分当作有效定位代码，不能只以 BCP 47 校验通过作为上线标准。[E02] 工程上最好分别建立“页面语言合法性检查”和“搜索标注支持检查”，不要共用一个只要能解析就算成功的校验器。

没有业务差异时，优先考虑语言级版本。出现实际差异时，再论证地区级版本。论证材料应包括客户需求、履约规则、产品差异、维护负责人和退出方案，而不是“竞争对手也有”。国家人口、收入水平或对某语言的刻板印象，都不能替代你的真实产品研究。

17.3 从市场研究到版本立项

把国际扩张做成一个小型研究项目。第一步列出现有能力：工具支持的运行环境、客服能处理的语言、交付地区、文档更新频率、当地客户能否完成购买。第二步收集需求证据：既有网站按国家和页面的表现、客户主动提问、公开搜索结果、当地同类产品的功能解释。第三步请真正熟悉目标语言和任务的人检查关键词与页面草稿。

关键词研究不能只翻译词表。中文“日志分析”可能覆盖故障排查、数据看板、安全审计等不同任务。翻译成英语以后仍然需要区分 log analyzer、log monitoring 和 log parser 对应的结果类型。这里列出的词只是教学候选，不表示已验证搜索量或排名机会。验证时要记录查询、语言设置、地区设置、日期、设备，以及结果到底偏向教程、工具、产品还是讨论。搜索结果会变化，单次截图只能说明那个时点的观察。

不要把某个国家当成单一用户群。开发者、采购人员、学生和小型商家可能使用不同术语。做十次访谈也只能支持被访谈群体的线索，不能证明全国偏好。可以先选择一个具体细分场景，例如“使用 Go 服务并需要本地处理日志的小团队”，再研究他们用什么语言描述敏感信息脱敏和错误聚合。这比泛泛研究“海外用户喜欢什么”更可执行。

版本优先级可以使用一个内部评分表，但分数必须来自可解释判断。需求证据强度、产品适配度、内容差异、维护成本和风险分别打分，不要把它包装成预测流量的算法。假设你有两种候选：英文文档只需新增术语审校，而某地区电商页需要新的仓储与客服。即使后者潜在人群更多，前者也可能是更合理的第一步。

立项时写清停止条件。例如经过一个完整的发布、抓取和用户反馈周期，主要问题仍是不能提供当地支付，就应该先解决商业能力，而不是继续翻译文章。如果需求存在但术语不匹配，修改研究假设。如果用户愿意使用产品但重要教程缺失，则补全使用路径。SEO 数据应该帮助你定位问题，而不是让团队不停扩充页面数量。

同一引擎，不同地区的结果也会不同

Google 判断结果语言时会综合查询语言、界面与设备设置、位置和内容是否有帮助；把界面切换成一种语言，并不意味着结果被严格限制在该语言。[E45] 因此，本地研究要把查询语言和地理位置分开记录。人在法国、界面使用法语、输入英语技术词，是完全合理的组合，不能仅凭所在地把英语结果判为错误。

搜索页面的模块也有地区差异。Google 的地区体验文档列出欧洲经济区的部分聚合商与供应商模块，以及土耳其、南非适用的某些专门功能。[E46] 这是功能与资格范围的差异，不是某个地区的人天生喜欢某种页面。一个地区看到的轮播、筛选项或展示机会，不应直接复制成全球项目的要求。

做竞对研究时，除了记录谁排在前面，还应记录页面上有哪些模块、站点以什么身份参与、你的业务是否符合资格。若同行以商品供应商出现，而你只是教程作者，就不能因为两者讨论同一主题而期待相同外观。先查看该功能的当前官方资格，再评估是否值得投入；不要为一个不适用的模块改造整站。

17.4 域名、子域名与子目录怎么选

常见结构有国家或地区顶级域名，如 example.de；子域名，如 de.example.com；子目录，如 example.com/de/。Google 官方将这些视为不同组织方式，并指出部分看似国家域名的后缀会按通用域名处理。[E01] 因此，购买某个后缀之前要核验它的实际分类、注册条件和品牌意义，不能从字母外观推断排名优势。

对一个人员很少、使用同一套 Go 服务和内容系统的工具站，子目录通常便于统一部署、模板、监控和内容映射。这是维护上的建议，不是“子目录天生排名更高”的断言。如果不同业务单位必须分开部署、发布节奏或责任主体，子域名可能更清晰。独立地区域名则要求你承担更多证书、资产验证、重定向、品牌防冒用和续费管理工作。

选择时问五个问题：是否需要独立团队发布；是否需要独立商业主体；是否有不同产品目录；是否能够同步公共文档；未来合并或退出有多困难。不要为了一个无法量化的所谓权重优势，破坏整个组织的可维护性。一个结构理论上很好但经常漏发修订，比简单、稳定、可审计的结构更危险。

地址中语言与地区的顺序也要稳定。可以选择 /en/ 和 /zh-hans/ 服务语言版本，只有真正独立的市场才增加 /en-gb/。也可以用 /gb/en/ 表示市场后接语言。两者都需要后台明确映射。不要让 /de/ 有时代表德语、有时代表德国；这种歧义会传进导航、分析报表和客服截图。

路径应描述内容身份，不应依赖用户当前会话。一个被别人分享的德语安装指南，重新打开仍应是德语安装指南。登录状态可以改变个人信息，但不要把公开页面主体完全交给 Cookie 决定。Google 对地区自适应页面的说明提示：依赖 IP 或语言请求头的变化，可能让部分版本无法被完整抓取。[E03] 对开发者而言，这意味着缓存、路由和版本选择必须一并设计。

17.5 hreflang：一个页面家族的关系声明

hreflang 用来说明哪些 URL 是同一内容的语言或地区替代版本。它不是翻译器、访问控制器或排名保证。可以把它理解为一个图：节点是可访问的页面，边表示版本关系。一个“安装指南”家族不能随便混入法语首页；否则你声明的替代关系与用户任务不一致。

Google 支持在 HTML、HTTP 响应头或站点地图中表达这些关系；选择一种易维护的方法即可。核心检查是完整地址、自包含、相互返回以及有效代码。[E02] 自包含指每个版本也列出自己；相互返回指甲声明乙，乙也能对应声明甲。对于一个小型内容站，直接在服务端渲染 HTML 头部较容易检查；对于大量非 HTML 文件，响应头可能更适合。

以下是原创演示，不是任何实际网站的配置。假设日志工具的同一篇安装文档有英文和简体中文版本，英文页的头部可以写成：

<link rel="canonical" href="https://example.com/en/docs/install/">
<link rel="alternate" hreflang="en" href="https://example.com/en/docs/install/">
<link rel="alternate" hreflang="zh-Hans" href="https://example.com/zh-hans/docs/install/">
<link rel="alternate" hreflang="x-default" href="https://example.com/en/docs/install/">

中文页的 canonical 改为中文页自身，alternate 集合保持对应关系。这里让英文文档充当缺省回退，是本站的一项产品选择，不意味着所有国际网站都必须使用英文。x-default 用于未匹配语言或地区的回退场景，也可用于合理的语言选择入口。[E06] 它并不等于英语，也不应该被理解为“把所有全球权重汇集到这里”。

不要根据字符串拼接猜测翻译地址。英文 slug 是 install，中文 slug 可以是 anzhuang，也可以保留 install；决定关系的是内容映射表。如果某个翻译尚未完成，就暂时没有那个节点。不要为了填满矩阵，把所有缺失版本都指向该语言首页。一个可被用户理解的“此文暂无译文”选择器，胜过机器宣称存在但实际上不存在的替代页。

17.6 canonical 和 hreflang 不应互相打架

规范网址声明，也就是 canonical，表达的是一组重复或相似页面中希望采用哪个代表地址；hreflang 表达的是语言或地区替代关系。Google 的规范化说明要求：使用 hreflang 时，应尽量选择同语言的规范页面，并让站内链接、站点地图和规范声明保持一致。[E05]

假设英文教程已经完整译成中文，你却把中文页的 canonical 指向英文页，同时又希望中文页在中文搜索中展现。团队给出了两个不同方向的信号：一个说中文是独立版本，另一个又把它归到英文代表地址。先问中文页是否值得独立存在。如果译文完整、用户确实需要，就让它作为自己的规范版本参与语言家族。不要用跨语言 canonical 省略翻译维护。

同语言地区页需要更细的判断。两页如果只有导航角落的货币符号不同，正文、商品、配送和结算实际完全相同，也许不需要两个可索引地址。如果两地存在真实库存、价格、尺寸或服务承诺差异，则先把差异准确呈现在页面上，再评估规范化。不能机械规定“国际站永远自引用”，也不能机械规定“相似英文页永远合并”。页面是否代表不同需求，比模板看起来是否相似更重要。

另一个常见问题是把带追踪参数的地址放进 alternate，再把 canonical 指向干净地址。用户看起来都能访问，实际却增加了映射的不确定性。设计时让内容映射表保存正式、稳定的规范 URL，追踪参数只在必要的传播场景使用。生成标注时从这份表读取，可以减少模板作者自行拼接造成的差异。

17.7 翻译上线以后，谁负责更新

一本安装指南的英语版改了命令，中文页仍保留旧参数，搜索标注即使完全正确，用户也会失败。因此国际内容管理必须记录版本关系，而不仅记录翻译文件是否存在。可以为每篇内容保存稳定 content_id、源内容修订号、各语言的审核状态、适用产品版本、发布日期和最后事实核对日期。

翻译工作可以分为术语准备、初稿、专业审校和任务测试。术语准备先确定产品名称、命令、按钮名称和关键概念的统一写法；初稿可以借助机器，但要保护代码、路径和变量；专业审校检查事实、表达和当地使用习惯；任务测试则让读者真的根据页面安装或购买。语法正确并不代表教程能用。

最需要人工核对的往往不是长段介绍，而是短句中的条件。例如“支持离线使用”是否只适用于桌面工具，“免费”是否有调用额度，“数据留在本地”是否排除了崩溃报告。翻译把限定词漏掉，会让页面承诺发生变化。营销段落、错误提示和价格细则也应进入同一审校流程，不能只审核文章正文。

对机器辅助翻译，建议采用受控发布：只有通过检查的版本才进入导航、站点地图和 hreflang。没有完成的页面留在非公开预览环境。不要依靠“先放出十万页再慢慢修”的策略，把审校成本转嫁给搜索用户。即使页面能获得短期访问，错误知识仍会增加客服负担，并损害品牌可信度。

过期译文也不必一律删除。如果旧版产品仍有用户，可以明确标注版本，并链接到当前文档。若它会造成严重误导，就先撤下失效内容或提供准确说明，再安排修订。修订是否需要保留原 URL，取决于任务是否仍然相同。只改发布日期不能解决知识过期，更新时间应与实际变更记录相符。

17.8 原创案例：把一个 Go 工具扩展成两种语言

下面是一项假设项目，不含真实流量或商业结果。站点原来只有中文，提供命令行工具、在线演示、定价和二十篇教程。团队能支持中文和英语，但没有按国家区分的产品。因此第一阶段决定只增加英语，不创建美国、英国、加拿大等重复目录。

团队先选一条完整任务路径：了解工具解决什么问题，确认操作系统是否支持，下载、安装、导入日志，最后了解付费限制。首页和安装教程不是孤立翻译，而是同批交付。暂时没有翻译的高级教程继续保留中文，并在英语文档中清楚标注链接语言。这样不会把英语用户一路带进无法理解的关键步骤。

内容表中，安装教程的 content_id 固定为 docs-install，不随标题或 slug 改动。中文和英文各有正式 URL。构建任务先校验译文已审核，再生成语言选择器、alternate 集合和分语言站点地图。标题、摘要、主导航、表单错误和下载按钮均由对应语言包输出；命令和示例日志独立维护，避免翻译人员误改命令标志。

发布前建立六个测试场景：直接打开中文深层页；直接打开英文深层页；清除 Cookie 后再次打开；从另一语言切换；使用不存在的路径；在没有语言请求头时抓取。每次记录状态码、实际页面语言、canonical、alternate、主要链接和结算币种。页面语言选择器应尽量切换到同一任务的对应版本，而不是让用户重新从首页找内容。

发布后，团队按语言路径分别看展现、点击和真实注册，并检查英语用户是否在安装步骤退出。如果英语页被发现但很少注册，先查看产品适配、文档清晰度和表单错误，而不是立即添加更多国家标签。假设英语页在某些非英语国家产生使用，也不必急着把这些人重定向到别的语言。他们已经表达了自己的选择。

第二阶段才考虑地区定价。只有当支付、税费展示或商业合同确实需要不同页面时，团队才新增 market 维度。这种顺序让每次复杂度增长都有明确原因，也让数据更容易解释：第一阶段检验语言需求，第二阶段检验地区差异，不把两种变化混在一起。

17.9 出现错版结果时，按顺序排查

“日本用户看到了英语页”并不足以证明 hreflang 错误。先确认该用户的查询语言、实际搜索界面、页面是否有日语替代版本，以及英语页是否恰好更符合查询。国际搜索并不是按国界严格隔离的列表，版本声明也无法消除所有情境差异。

如果你确定应有另一个版本，先查页面本身：是否返回成功状态，是否存在访问限制，正文是否真的翻译，是否能从普通链接发现。再查索引资格：是否被 noindex 排除，canonical 是否指到意外地址，机器人能否获取主体。然后才检查代码格式、返回关系和内容家族。这个顺序能避免花一天研究一个字母大小写，却漏掉整个目录被阻止抓取的问题。

批量排查时，生成一个以 content_id 为行、语言版本为列的矩阵。标出缺页、非成功响应、跳转、错语言、规范网址冲突和缺少返回关系。不要只报告“有三千个 hreflang 错误”，而应归类为可修复原因。例如一条路由规则可能造成两千个错误，另外五百个来自尚未翻译的旧内容；两类问题需要不同负责人。

还要检查缓存。一个 CDN 如果没有正确区分公开 URL，可能把英语响应缓存到中文路径。此时后台数据库和模板都正确，用户仍然拿到错版。比对不同时间、不同请求头的响应主体，记录缓存命中信息。修复时先消除跨版本污染，再检查搜索系统重新抓取后的变化；不能仅以浏览器刷新一次作为验收。

17.10 国际站的迁移与衡量

改变语言目录是一次 URL 迁移。例如从 /cn/ 改成 /zh-hans/，需要逐页建立旧新映射，同时更新站内链接、站点地图、规范声明和语言家族。不要把整个旧目录都重定向到新首页。用户收藏的教程仍应通向同一任务，否则迁移同时破坏了访问路径和内容关系。

上线可以分批进行，但每批应有明确边界。保留旧新地址映射和回滚配置，先用少量代表页检验状态码、内容和索引信号。如果同时重写内容、改域名、换框架和增加语言，即使流量变化也难以知道原因。能够分开的高风险变化，尽量分开。

衡量时建立三个视角。语言视角回答哪种内容被需要；市场视角回答哪些地区能够顺利完成业务；版本匹配视角回答用户是否进入合适页面。不要把所有英语页面流量视为某一个国家的成绩。也不要把货币转换造成的营收差异当成 SEO 增长，收入比较应使用一致口径，并写明汇率和统计期。

小样本尤其容易误导。一个地区本周只有两次转化，下周四次，看似翻倍，却不足以证明新标签有效。先观察抓取、索引和版本分布是否符合设计，再看更长时间的任务完成情况。真正值得记录的可能是“英语用户终于可以完成安装”，而不是某个尚不稳定的排名截图。

17.11 练习、参考解答与上线检查

练习一：一家全球线上软件站只有简体中文和英语，没有地区价格差异。开发者建议为每个国家生成相同英语页面。你会如何修改方案？参考解答是先使用语言版本，保留用户自主选择；只有可验证的产品、交易或内容差异出现后，才新增地区页。人口或国旗数量不构成发布理由。

练习二：德语页面指向英语 canonical，英语页声明德语 alternate，德语页没有返回关系。你会先改什么？先确认德语内容是否完整、是否应该独立索引；再协调规范网址和替代关系，并检查正式响应。只补一个标签可能掩盖更大的内容决策错误。

练习三：一个页面只有菜单翻译，正文仍是中文，语言选择器把它标成英语。参考解答是修正用户承诺：完成真实翻译后再作为英语版本发布，或明确说明正文语言。不能指望语言标签替用户理解中文内容。

发布前用一条真实访问路径完成最后检查：从搜索用户可能进入的深层页开始，阅读正文、切换语言、下载或询价，并返回。确认地址稳定、内容适用、必要限定准确；确认版本映射来自内容数据而非路径猜测；确认每个公开版本有更新负责人；确认监测能够区分语言与地区。完成这些以后，再把配置加入自动化测试，下一次发布就不必靠记忆守住质量。

本章参考来源

[E01] Managing multi-regional and multilingual sites | https://developers.google.com/search/docs/specialty/international/managing-multi-regional-sites | 访问 2026-10-13 | 独立语言 URL、域名结构与地区信号。 [E02] Tell Google about localized versions of your page | https://developers.google.com/search/docs/specialty/international/localized-versions | 访问 2026-10-13 | hreflang 方法、返回关系、语言代码支持边界。 [E03] How Google crawls locale-adaptive pages | https://developers.google.com/search/docs/specialty/international/locale-adaptive-pages | 访问 2026-10-13 | IP、语言请求头和地区自适应抓取限制。 [E04] Choosing a language tag | https://www.w3.org/International/questions/qa-choosing-language-tags | 访问 2026-10-13 | 语言、文字、地区子标签的区别。 [E05] How to specify a canonical URL | https://developers.google.com/search/docs/crawling-indexing/consolidate-duplicate-urls | 访问 2026-10-13 | 规范网址、同语言选择与信号一致性。 [E06] Introducing x-default hreflang for international landing pages | https://developers.google.com/search/blog/2013/04/x-default-hreflang-for-international-pages | 访问 2026-10-13 | 缺省版本概念；历史介绍，现行实现同时核对 E02。

[E45] How Google knows what language to show in search results | https://support.google.com/websearch/answer/13511324 | 访问 2026-10-13 | 查询语言、位置、界面与设备设置的区别。 [E46] Regional differences in Search experience | https://developers.google.com/search/docs/appearance/aggregator-features | 访问 2026-10-13 | 地区搜索展示模块与资格范围；页面实际更新日期2026-09-18。