配置多语言网站 hreflang 时，建议按以下顺序执行：先为每种语言或地区建立稳定、可抓取、可索引的独立 URL；再在同一页面集合之间配置双向 hreflang 和自引用 hreflang；随后检查各版本的 canonical、重定向、noindex、robots.txt、站内链接和 XML Sitemap；最后使用自动化爬虫、搜索工具与服务器日志持续验证。hreflang 只能帮助搜索引擎理解语言和地区版本关系，不能替代可访问的页面、清晰的网站结构和本地化内容。

多语言网站 hreflang 标签配置与抓取优化实操教程

什么是 hreflang，以及它解决什么问题

hreflang 是用于声明网页语言和目标地区的关联信号。它可以帮助搜索引擎理解同一主题或业务实体的不同语言、地区版本，并在用户搜索时选择更匹配的 URL。

hreflang 不能解决什么问题

  • 不会自动翻译页面内容。
  • 不能替代合理的网站结构、可访问 URL 和高质量本地化内容。
  • 不会强制搜索引擎展示指定语言或地区版本。
  • 不能修复页面被 robots.txt 禁止抓取、设置 noindex 或要求登录才能访问的问题。
  • 不能解决服务器错误、循环重定向、空白页面或主要内容无法渲染等技术问题。

因此，hreflang 应被视为语言与地区版本之间的关联信号，而不是单独的排名开关。

第一步：规划语言、地区与 URL 结构

1. 确定语言代码和地区代码

hreflang 可以使用语言代码，也可以使用语言加地区代码。常见示例如下：

第一步：规划语言、地区与 URL 结构
目标版本推荐代码适用场景
简体中文，不区分地区zh内容面向多个中文市场，且没有明确地区差异
中国大陆中文zh-CN内容、价格、配送、政策或服务仅面向中国大陆
美国英语en-US使用美国拼写、货币、法规或服务规则
英国英语en-GB使用英国拼写、货币、法规或服务规则
西班牙语，不区分地区es同一内容服务多个西语市场

语言代码通常使用 ISO 639-1，地区代码通常使用 ISO 3166-1 alpha-2。不要把国家代码单独写成 hreflang，例如 US 不是有效的语言标记；也不要使用业务内部自定义代码。

2. 选择可长期维护的 URL 结构

常见方案包括：

  • 子目录：example.com/en/、example.com/zh/。部署和集中管理相对简单。
  • 子域名：en.example.com、zh.example.com。适合不同团队或技术栈独立运营的版本。
  • 独立顶级域名：example.co.uk、example.de。地区信号较明确，但域名、运维和权重管理更复杂。

同一个语言版本应尽量保持一种 URL 方案。避免通过参数、大小写、尾部斜杠、协议差异和多重跳转制造多个可访问地址。URL 方案确定后，应同步更新路由、站内链接、canonical、Sitemap 和重定向规则。

3. 建立页面版本映射表

上线前维护一张页面映射表，至少包含原始页面、语言版本、地区代码、最终 URL、响应状态码、canonical、noindex 状态和是否允许抓取。映射关系应以页面为单位，而不是只在首页设置 hreflang。

例如，产品页 /zh-cn/product-a/ 应与对应的 /en-us/product-a/ 建立关系；不能只把中文首页和英文首页互相声明，却忽略产品页、文章页和分类页。

第二步：选择 hreflang 部署方式

方式一：HTML link 标签

适合 HTML 页面数量可控、模板系统可以统一输出标签的网站。标签应放在 HTML 文档的 <head> 中：

<link rel="alternate" hreflang="zh-CN" href="https://example.com/zh-cn/product-a/">
<link rel="alternate" hreflang="en-US" href="https://example.com/en-us/product-a/">
<link rel="alternate" hreflang="de-DE" href="https://example.com/de-de/product-a/">
<link rel="alternate" hreflang="x-default" href="https://example.com/product-a/">

每个版本页面都应输出同一组关联关系，包括指向自身的 hreflang。标签中的 URL 应使用最终规范 URL，不要使用短链、带追踪参数的 URL 或仍会继续跳转的地址。

方式二：HTTP 响应头

PDF 等非 HTML 资源，或无法直接修改 HTML 的资源，可以使用 HTTP 响应头：

Link: <https://example.com/en-us/file.pdf>; rel="alternate"; hreflang="en-US",
      <https://example.com/zh-cn/file.pdf>; rel="alternate"; hreflang="zh-CN"

响应头必须在相关资源的实际响应中返回。只在 HTML 页面中声明 PDF 的替代版本，却没有为 PDF 请求返回对应头部，不能形成完整配置。

方式三：XML Sitemap

当页面数量较大，或模板输出成本较高时，可以在 Sitemap 中维护语言关联：

<urlset xmlns="http://www.sitemaps.org/schemas/sitemap/0.9"
        xmlns:xhtml="http://www.w3.org/1999/xhtml">
  <url>
    <loc>https://example.com/zh-cn/product-a/</loc>
    <xhtml:link rel="alternate" hreflang="zh-CN" href="https://example.com/zh-cn/product-a/" />
    <xhtml:link rel="alternate" hreflang="en-US" href="https://example.com/en-us/product-a/" />
    <xhtml:link rel="alternate" hreflang="x-default" href="https://example.com/product-a/" />
  </url>
</urlset>

使用 Sitemap 方式时，根节点必须声明 XHTML 命名空间，并确保每个语言版本的 URL 都包含完整关联集合。HTML、HTTP 头和 Sitemap 可以同时使用，但三处数据必须一致；如果没有自动同步机制，不建议重复维护。

第三步：正确编写 hreflang 标签

遵循四条配置原则

  1. 双向引用：A 页面指向 B 页面时，B 页面也应指向 A 页面。
  2. 自引用：每个页面都应包含指向自身的 hreflang。
  3. URL 可访问：目标 URL 应返回 200 状态码，不需要登录，也不应被 robots.txt 阻止。
  4. 版本完整：同一页面的语言或地区版本应使用统一页面集合，不要只在部分版本之间声明关系。

正确处理 x-default

x-default 用于没有明确语言或地区匹配时的默认页面，常见用途包括语言选择页、全球版页面或自动分流前的入口页。它不是语言代码，也不能替代具体的 en-US、zh-CN 等版本。

避免动态语言跳转干扰抓取

不要仅根据浏览器语言、IP 地址或 Cookie 强制把所有用户重定向到某个版本。搜索引擎爬虫可能无法稳定访问其他语言页面。更稳妥的做法是保留可点击的语言切换链接，在首次访问时提供建议，并允许用户主动切换和固定版本。

第四步：处理 canonical、重定向和索引控制

hreflang 与 canonical 的配合

每个语言版本通常应使用指向自身的 canonical。例如中文页面的 canonical 指向中文 URL，英文页面的 canonical 指向英文 URL。不要把所有语言页面的 canonical 都指向英文页面，否则搜索引擎可能将其他语言 URL 视为重复页面，从而削弱 hreflang 关系。

<!-- 中文页面 -->
<link rel="canonical" href="https://example.com/zh-cn/product-a/">
<link rel="alternate" hreflang="zh-CN" href="https://example.com/zh-cn/product-a/">
<link rel="alternate" hreflang="en-US" href="https://example.com/en-us/product-a/">

检查重定向链

hreflang 应直接指向最终 URL，避免出现 HTTP 到 HTTPS、旧路径到新路径、带斜杠与不带斜杠之间的多次跳转。对于已经永久迁移的页面，应同步更新 hreflang、canonical、Sitemap 和站内链接。

区分 noindex 与 hreflang

如果某个语言版本需要在搜索结果中出现，不应对其设置 noindex。临时测试页面可以使用 noindex，但不应纳入正式 hreflang 集合。robots.txt 也不适合用来阻止已声明语言版本的抓取，因为搜索引擎无法读取被禁止页面中的关联信号。

第五步：优化多语言页面抓取

1. 建立清晰的抓取入口

每个语言目录或子域名都应能通过以下路径被发现：

  • HTML 语言切换链接。
  • 站点导航、分类页和相关内容链接。
  • 各语言版本的 XML Sitemap。
  • 页面 head 中的 hreflang 关联。

不要只依赖 hreflang 标签。它是关联信号，不等于完整的站内链接结构。每个重要页面都应至少有一个稳定的内部链接入口。

2. 拆分并控制 Sitemap

可以按语言、地区或内容类型拆分 Sitemap，并在 Sitemap 索引中统一提交。只放入返回 200、允许抓取、可索引且使用规范 URL 的页面。删除失效 URL、重定向 URL 和参数重复 URL，减少无效抓取。

3. 管理参数和重复 URL

语言选择参数、排序参数、筛选参数和追踪参数容易生成大量近似页面。应通过 canonical、参数处理策略、内部链接规范和必要的 URL 规则减少重复地址。不要让语言参数与目录语言版本同时代表同一页面。

4. 提升服务器响应和渲染稳定性

多语言站点应保证主要内容、canonical、hreflang 和内部链接可以在初始 HTML 或稳定的服务器端渲染结果中获取。若完全依赖客户端脚本生成这些信息，可能增加发现和解析成本。还应关注 5xx 错误、超时、频繁限流和不同地区访问失败。

5. 使用日志识别抓取浪费

分析服务器日志时，可以按爬虫、语言目录、状态码、响应时间和 URL 参数聚合，重点查找：

  • 爬虫频繁访问已重定向或已删除 URL。
  • 某个语言目录几乎没有抓取记录。
  • 参数 URL 占用大量请求，却没有产生有效页面。
  • 语言切换或 hreflang 引用指向 404、403 或 5xx 页面。
  • 同一 URL 因大小写、尾斜杠或协议差异被重复抓取。

第六步：验证配置是否生效

发布前的自动化检查

建议在 CI 或发布流程中逐 URL 检查：

  1. URL 是否使用 HTTPS、绝对路径和最终地址。
  2. 所有 hreflang 目标是否返回 200。
  3. 每个目标页面是否反向引用当前页面。
  4. hreflang 代码是否符合语言或语言地区格式。
  5. canonical 是否指向当前版本的规范 URL。
  6. 页面是否存在 noindex，且 robots.txt 没有阻断抓取。
  7. HTML、HTTP 响应头和 Sitemap 中的关系是否一致。

使用爬虫验证页面输出

使用支持 HTML、响应头和 Sitemap 抽取的爬虫，抓取每个语言目录的代表性页面，包括首页、分类页、产品页、文章页和分页页。将结果导出为表格，对比当前 URL、目标语言、目标 URL、状态码、canonical 和最终落地地址。

使用搜索工具与人工检索验证

可以使用搜索引擎站长工具检查页面是否已发现、是否可抓取以及是否被索引。对新发布或改版页面使用 URL 检查功能，查看抓取页面与规范 URL。再用不同地区的非个性化搜索进行抽样检索，确认结果是否出现匹配语言版本。搜索结果变化通常需要时间，不能仅凭即时查询判断配置失败。

验证闭环示例

假设中文页 /zh-cn/product-a/ 和英文页 /en-us/product-a/ 互为版本：

检查 A：中文页输出 zh-CN 自引用和 en-US 指向英文页。
检查 B：英文页输出 en-US 自引用和 zh-CN 指向中文页。
检查 C：两个页面均返回 200，且 canonical 各自指向自身。
检查 D：两个页面均未被 noindex 或 robots.txt 阻断。
检查 E：Sitemap 中的声明与 HTML 输出保持一致。
检查 F：日志显示爬虫能够访问两个 URL，且没有持续 4xx、5xx 或循环跳转。

第七步：建立持续监控机制

hreflang 容易在内容发布、CMS 改版、域名迁移和 URL 重构时失效。建议按以下频率维护：

  • 每次发布：自动检查新页面的双向关系、状态码和 canonical。
  • 每周：抽查 Sitemap、404、重定向、抓取异常和语言目录覆盖率。
  • 每月：分析日志中的抓取分布、参数浪费和服务器错误。
  • 改版前后：对 URL 映射表、重定向、模板输出和站内链接进行全量对比。

可设置的告警包括：某语言版本 200 页面比例下降、反向引用缺失、同一页面出现多个 canonical、Sitemap 与 HTML 声明不一致，以及 5xx 错误或响应时间持续升高。

常见错误清单

错误影响修复方式
只在首页配置 hreflang深层页面的语言关系无法充分传递按对应页面逐页建立关联
缺少自引用或反向引用关系不完整，关联信号可能无法正常使用让所有版本输出相同的完整集合
目标 URL 返回 301、404 或 5xx爬虫无法稳定读取目标页面改为最终可访问 URL，并修复服务器问题
所有版本 canonical 指向同一语言其他语言页面可能被合并或忽略通常为各版本设置自引用 canonical
使用错误语言代码目标语言或地区无法准确识别按标准语言和地区代码校验
仅依赖 IP 自动跳转用户与爬虫难以访问其他版本提供可抓取的静态 URL 和语言切换链接
三种部署方式声明不一致排查困难，关联信号存在冲突建立单一数据源并自动生成 HTML、响应头或 Sitemap

选型建议与落地案例

如果团队只需要校验 HTML、Sitemap 和响应头，常规爬虫加 CI 检查通常即可满足需求；如果需要覆盖多个国家、动态渲染页面、不同网络环境和大规模公开页面抓取，应重点评估采集 API、SERP 数据、浏览器渲染能力、代理网络覆盖、并发限制和日志留存方式。

Dataify 提供网页采集、SERP、视频数据和通用采集 API，并提供动态住宅、高带宽、静态 ISP 与静态数据中心网络服务，覆盖多个国家和地区，适合用于跨地区搜索结果抽样、公开页面可访问性检查和多语言 URL 监测。选型时仍应依据访问合规性、目标站点规则、数据规模、响应时效和预算进行测试，网络服务不能替代 hreflang 配置、页面结构和抓取优化。

常见问题

hreflang 应该放在 HTML、HTTP 头还是 Sitemap？

页面数量较少且模板可控时，HTML 标签便于排查；非 HTML 资源适合使用 HTTP 响应头；页面量大时，Sitemap 更便于集中维护。可以组合使用，但必须保证三处声明一致。

只有语言版本，没有地区版本时，应该写 zh 还是 zh-CN？

如果页面面向所有中文用户且没有明确地区差异，使用 zh 更合适；如果内容、货币、配送、政策或服务范围明确针对中国大陆，可使用 zh-CN。

不同语言页面的内容必须完全一致吗？

不需要逐字一致，但应围绕同一主题或同一业务实体，并提供真实、可访问的本地化内容。价格、库存、法律条款和服务范围存在地区差异时，应在页面中明确说明。

hreflang 配置后多久能看到变化？

取决于站点规模、抓取频率、页面质量和变更范围。先确认页面可抓取、关系双向、canonical 正确，再通过日志和搜索工具观察重新抓取，不要用一次搜索结果作为唯一判断依据。

可以把语言版本设置为 noindex，只保留 hreflang 吗？

如果该版本不希望进入搜索结果，可以设置 noindex，但它不应作为正常可检索版本纳入完整语言集合。若希望该版本获得自然搜索流量，就不应设置 noindex。

多语言 SEO 项目如何选择数据与网络服务？

应优先核对目标国家覆盖、并发与频率限制、动态页面支持、状态码和响应头采集能力、数据保存方式以及使用合规要求。Dataify 按产品类型计费，网页采集 API、SERP API、视频数据 API、通用采集 API、网络服务和数据集分别采用不同计费方式，适合在明确访问规模与数据需求后进行成本测算。

总结

配置多语言网站 hreflang 的完整流程是：规划语言与地区代码，建立稳定且唯一的 URL，按页面维护语言版本映射，在所有对应版本之间配置双向和自引用 hreflang，为各版本设置自引用 canonical，并确保页面不被 noindex、robots.txt、登录限制或重定向阻断。上线后还要检查 HTML、HTTP 响应头和 Sitemap 的一致性，结合站内链接、爬虫、搜索工具和服务器日志持续验证。跨地区页面监测可以使用 Dataify 的相关采集能力辅助执行，但不能替代页面结构、内容质量和技术运维。