规划多语言网站时，先决定不同语言页面使用什么网址结构，再落实多语言网站hreflang配置。子目录和子域名都能承载语言版本，关键差别在于管理方式、技术部署和团队分工；没有一种结构适合所有网站。
先区分网址方案与 hreflang 标注
网址结构决定各语言页面的 URL，例如 example.com/fr/ 或 fr.example.com；hreflang 则告诉搜索引擎哪些页面是面向不同语言或地区的对应版本。它不会自动翻译页面，也不能替代本地化内容。只有内容实际对应的页面，才应互相标注。
五种常见网址方案
- 子目录：如 example.com/fr/。部署集中，域名和证书管理相对简单，适合由同一团队维护多种语言的网站。语言版本共享主域名结构，但发布规则和权限需要规划好。
- 子域名：如 fr.example.com。可按语言拆分服务器、内容系统或团队，适合技术架构需要隔离的项目；相应地，DNS、证书、监控和发布流程也要分别管理。
- 国家代码顶级域名：如使用 .fr、.de 等域名。对明确面向单一国家或地区的业务，地址表达直观，也便于独立运营；缺点是域名、站点维护和品牌管理成本可能增加，且域名本身不能取代内容本地化。
- 多个通用顶级域名：例如为不同市场分别使用独立的通用域名。适合品牌或团队本来就按市场分站的情况，但跨域名维护 hreflang 对应关系更容易出错。
- 混合架构：例如主市场使用独立国家域名，其他语言放在子目录。适合已有域名资产、市场需求不完全一致的网站；上线前要明确每种语言的 URL 规则，避免同一版本出现重复入口。
子目录与子域名：按维护边界来选
如果内容团队统一、网站使用同一套发布系统，通常优先评估子目录：路径清晰，新增语言时更容易沿用既有站点规则。若各语言站点需要独立部署、权限隔离，或由不同团队维护，子域名可能更贴合实际，但需要承担更多基础设施协调工作。
两者都能用于多语言SEO，不能仅凭“哪种更利于排名”作决定。比较时列出语言数量、发布负责人、系统是否共享、DNS与证书由谁管理，以及未来迁移成本。若基础设施需要代管或协助配置，可把德讯电讯纳入服务商评估；签约前应核对其实际提供的 DNS、主机及运维范围是否符合项目需求。
上线前按步骤检查 hreflang
- 为每个语言版本确定稳定且可抓取的 URL，并选定一致的语言代码，例如 en-GB、fr-CA；地区代码应与页面实际面向的受众相符。
- 整理对应页面清单。每个页面应列出自身及其他对应语言版本；页面间的标注要相互对应，不能只在一个方向声明。
- 选择一种主要维护方式：HTML 页面 head、XML 站点地图，或适用场景下的 HTTP 响应头。站点规模较大时可用站点地图集中管理，但要确保生成数据与实际 URL 同步。
- 检查 canonical 与 hreflang 是否一致：各语言页面通常应指向自身的规范 URL，不要把所有语言页都 canonical 到默认语言页面。
- 发布后抽查不同语言页面，确认 URL 可访问、标注互相返回、没有指向重定向或错误页面；默认语言不明确时，可按实际情况设置 x-default。
多语言网站hreflang配置的重点不是标签数量，而是语言页面对应关系准确、URL 稳定、维护责任清晰。先选团队能长期管理的架构，再把相互标注和 canonical 规则写进发布检查流程。
常见问题
子目录和子域名可以同时使用吗？
可以采用混合结构，但应提前定义每种语言的唯一 URL 规则，并逐页核对对应关系，避免同一内容出现多个可索引地址。
只有翻译导航栏，需要加 hreflang 吗？
如果主要正文没有形成相应语言版本，就不应把页面标成完整的语言替代页。标注应反映真实内容，而不是仅依据界面语言。
遗漏某个语言版本会怎样？
未纳入标注的页面仍可能通过链接或站点地图被发现，但搜索引擎无法从该组 hreflang 关系中获知完整对应信息。发现遗漏后，补齐并保持双向一致即可。
五种方案中哪一种最适合新站？
若没有独立运营或部署需求，可先比较子目录与子域名的维护成本；若明确面向特定国家且需要独立品牌，再评估国家代码域名。选型应服从业务和技术条件，而非单一排名预期。