外贸网站hreflang检查：语言配对与错误定位

针对外贸网站上线后的中英语言配对故障，提供一套可操作的hreflang检查方法。从缩小故障范围、核对双向返回与自引用，到验证目标地址状态码与可索引性，每一步都给出观察证据、具体修正和复测方法，并附有可直接填写的语言配对检查表。

先把hreflang故障缩小到一组语言页面

排查hreflang问题时，不要一开始就检查整站所有语言版本。故障往往只出现在特定的一组语言配对中，例如英文首页与中文对应页之间。先把范围缩小到一组具体的语言页面，能避免被无关页面的标签干扰，也让后续的修正和复测更清晰。

记录精确的源URL与目标URL

选择同一个产品或同一篇文章的中文地址和英文地址，逐字记录实际完整URL。不能用中文产品页与英文首页凑成一组：两者不是相同内容的语言替代。

同时记录你观察到的故障症状：是自有抓取检查发现缺少返回标签，还是搜索结果中显示了不同语言版本？症状描述要具体，例如“英文页面在中文搜索中显示”或“中文页面没有出现在任何hreflang配对中”。

区分当前访问与历史索引状态

当前访问看到的是服务器实时返回的HTML，而Google索引可能是几天甚至几周前的快照。因此，要分别记录两个时间点的状态：

当前访问：使用浏览器的“查看源代码”功能，或通过curl命令获取页面HTML，检查其中的hreflang标签。记录获取时间，因为页面可能刚被更新。
历史索引：在Google Search Console的“网址检查”中保存已收录记录、最近抓取时间，以及可用时的抓取页面信息。不要把site搜索结果当成完整索引清单。注意，Search Console的“网址检查”显示的是Google上次抓取的内容，不一定反映当前状态。

如果当前访问的hreflang标签正确，但历史索引中缺失，应继续核对抓取时间与改版时间，不能仅凭两次内容不同就排除模板故障。实时测试与已收录记录也应分开保存。

使用语言配对检查表记录证据

为了系统化地记录证据，建议使用下面的检查表。每一行对应一个检查项，填写实际观察到的内容。

检查项	源页面URL	目标页面URL	观察到的症状	当前访问时间	历史索引状态	修正动作	复测结果
双向返回
自引用
目标地址状态码
目标地址重定向
目标地址noindex
目标地址robots限制
同语言canonical
语言代码格式
CMS模板输出
缓存旧标签

这张表可以直接复制到文档或表格工具中填写。每一行代表一个检查维度，填写时确保源页面和目标页面都分别记录。

双向返回与自引用：逐端核对而不是只看一个标签

hreflang的核心要求是双向返回：如果A页面声明B页面是其翻译版本，那么B页面也必须声明A页面。同时，每个页面都应该包含指向自身的hreflang标签（自引用）。只检查一个方向是不够的，因为单向声明会被Google视为无效。

检查每个页面是否链接到自身和对应翻译页

下面使用本文的真实中英文地址说明标记格式，不是对当前线上head的逐字转录，也不是验收回执。按这一格式，两页的head使用同一组语言替代标记；应用到产品页时，应换成对应产品的真实地址。

<link rel="alternate" hreflang="en" href="https://www.shmlang.com/en/note/international-seo-hreflang-operations/" />
<link rel="alternate" hreflang="zh" href="https://www.shmlang.com/zh/note/international-seo-hreflang-operations/" />

英文页的en项指向自身，中文页的zh项指向自身；另一项指向同一产品的翻译版本。先比较产品身份与正文，再比较标签，避免“技术互指正确、内容配对错误”的漏检。

注意，每个页面都必须包含自引用标签（即指向自身URL的标签），以及指向所有其他语言版本的标签。如果英文页面只包含指向中文的标签，而没有指向自身的标签，那么自引用缺失，可能导致Google无法确认该页面的语言版本。

观察证据：逐端核对标签列表

在浏览器中分别打开两个页面，查看源代码，将每个页面的hreflang标签列表复制下来。然后逐一核对：

英文页面是否包含hreflang="en"指向自身？
英文页面是否包含hreflang="zh"指向中文页面？
中文页面是否包含hreflang="zh"指向自身？
中文页面是否包含hreflang="en"指向英文页面？

如果任何一项缺失，就记录为故障。例如，如果英文页面缺少自引用，那么即使中文页面正确返回，整个配对仍然不完整。

具体修正：补全缺失的标签

如果发现缺失，需要在对应的页面模板中添加缺失的标签。例如，如果英文页面缺少自引用，就在英文页面的head中补上指向实际英文规范地址的en项。确保URL是绝对URL，且与页面实际URL完全一致（包括协议和斜杠）。

复测与限制：修改后重新抓取并观察

修改后，不要立即认为问题已解决。需要重新获取页面HTML，确认标签已正确输出。同时，由于Google需要重新抓取页面才能更新索引，没有固定的更新时间。在复测时先核对真实HTML，再单独保存Search Console的索引记录与实时测试结果；请求编入索引的提交状态不等于标签已被Google采用。注意，即使标签正确，Google也可能因为其他原因（如canonical冲突）而不采用这些标签。

目标地址故障：状态码、跳转与可索引性

hreflang标签中的目标URL必须能够被Google正常抓取和索引。如果目标地址返回错误状态码、发生重定向，或被noindex标记，那么hreflang配对可能失效。因此，需要验证每个目标URL的最终状态。

使用GET请求而非仅HEAD请求

检查URL状态时，不要只使用HEAD请求。有些服务器对HEAD与GET处理不同。下面使用正常GET，同时保存响应头和正文；不加-I，也不把-X GET与-I混在一起。

curl -sS -L -D headers.txt -o page.html -w 'status=%{http_code} final=%{url_effective}\n' 'https://www.shmlang.com/en/note/international-seo-hreflang-operations/'

这是命令格式示例。换成实际被授权检查的地址后执行，headers.txt用于查看响应头及跳转链，page.html用于核对正文、canonical和语言替代标记。命令显示的最终状态不包含整条链的每个状态，因此还要阅读保存的响应头。Windows PowerShell中可使用curl.exe以明确调用curl程序；文件会写入当前目录，先选一个专用检查目录，避免覆盖同名资料。

记录最终URL、状态码、noindex和robots限制

对于每个目标URL，记录以下信息：

最终URL：如果发生重定向，记录重定向后的最终URL。hreflang标签中的URL应该指向最终URL，而不是重定向前的URL。
HTTP状态码：200表示正常，301/302表示重定向，404表示不存在。状态码必须是200，且页面内容可索引。
noindex：检查响应头中的X-Robots-Tag是否包含noindex，或页面HTML中的<meta name="robots" content="noindex">。如果存在，则页面不可索引，hreflang可能无效。
robots.txt限制：检查robots.txt是否禁止抓取该URL。如果被禁止，Google无法抓取页面，hreflang也无法被识别。

一次性200状态不代表稳定

即使某次请求返回200，也不能保证页面一直可访问。服务器可能间歇性故障，或者页面可能被动态生成。因此，建议在多个时间点重复检查，并观察一段时间内的稳定性。如果页面经常返回5xx错误，需要解决服务器问题。

具体修正：处理重定向和noindex

如果目标URL发生重定向，有两种修正方式：

将hreflang标签中的URL改为最终URL。
如果重定向是临时的，确保重定向链正确，并最终指向200状态的可索引页面。

如果目标页面有noindex，先确认这是否是有意限制。只对本来计划公开收录的页面修正误设；登录、测试或保密内容应保持限制，并从公开语言替代集合移除，不能为了通过检查一律开放。注意，hreflang和canonical是不同信号，Google可能选择不同的canonical，但hreflang目标页面必须可索引。

复测与限制：验证修正后的状态

修正后，重新使用GET请求检查状态码和响应头，确认返回200且无noindex。同时，在Search Console中请求重新抓取，索引记录与实时测试分开保存；不要寻找已退出的专用hreflang报告。注意，即使状态码正常，如果页面内容质量低或与其他页面重复，Google仍可能不索引，但这超出了hreflang本身的范围。

canonical冲突：区分语言替代与重复地址

观察到的证据

排查hreflang时，常发现同一页面的canonical指向不同语言版本，或指向自身但缺少回指标签。例如，英文页/en/的canonical错误指向中文页/zh/，而中文页的canonical指向自身，导致Google无法确认语言替代关系。

另一种情况是canonical指向一个重定向URL或非规范版本（如带跟踪参数），造成信号混乱。

具体修正动作

根据Google的指南，对于完全翻译的页面，应使用同语言的预期canonical。即每个语言版本都应有自己的canonical标签，指向该语言版本的规范URL。不要将翻译版本视为重复内容，也不要依赖hreflang来合并权重。

修正步骤：

检查每个语言页面的canonical标签，确保指向同语言的规范URL。
确保hreflang注释中列出的每个URL都包含自引用hreflang和canonical。
如果页面有近似替代版本（如地区变体），canonical可指向最佳替代，但需明确。

复测与局限

修正后，使用crawl工具或查看源代码，确认每个语言页面的canonical和hreflang一致。注意：Google可能选择不同的canonical，因此即使设置正确，索引结果也可能变化。

语言代码与CMS重复输出怎么定位

语言代码错误常见于：en写成eng，或使用不受支持的地区代码（如用UK代替GB）；不要把en-us与en-US的大小写形式差异直接判成失效。CMS重复输出表现为同一hreflang标签出现多次，或插件与主题同时输出不同值。

例如，WordPress站点可能因SEO插件和主题内置多语言功能，导致每个页面输出两组hreflang，一组正确一组错误。

核对Google支持的语言代码列表，确保使用正确的ISO 639-1格式。
检查CMS设置，确认启用的多语言插件或主题仅输出一次hreflang。若输出冲突，先确定负责语言映射的配置来源，仅关闭重复的标签输出，不能未经评估就停用整个多语言插件。
按本次修改涉及的缓存层清理对应页面，再比较更新前后HTML；先使用URL级失效，避免为了两页检查清空整个网站缓存。
x-default是可选的，不是必需。如果使用，确保指向预定的未匹配语言回退页，例如语言选择页，而不是一概指向默认语言首页。

修正后，用crawl工具抓取页面，检查源代码中hreflang标签的唯一性和正确性。注意：某些CMS可能自动生成hreflang，需确认其逻辑符合预期。

用一份语言配对记录完成修复验收

修复过程中，缺乏系统记录导致遗漏或重复工作。例如，某对页面（/en/和/zh/）的hreflang回指缺失，但未记录，后续复查时难以追踪。

使用以下语言配对检查表，逐项填写并验证。该表可作为修复验收的依据。

源URL	备用URL	返回标签	canonical	状态	证据时间	负责人	复测结果
假设：英文产品页	同产品中文页	缺失	错指中文页	待修正	实测时填写	指定维护人	尚未复测
（填写）	（填写）	（填写）	（填写）	（填写）	（填写）	（填写）	（填写）

填写说明：

源URL：当前检查的页面。
备用URL：hreflang中声明的替代语言版本。
返回标签：备用URL是否包含指向源URL的hreflang。
canonical：源URL的canonical指向。
状态：通过或失败。
证据时间：检查的日期和时间。
负责人：执行检查的人。
复测结果：修正后的复查结果。

复测时，需重新抓取页面，确认所有配对均正确。注意：该表仅记录技术状态，不涉及排名效果。

常见问题与修复边界

常见问题包括：部分语言内容未翻译完整，x-default误用，sitemap与HTML中的hreflang不一致，以及无法从hreflang推断排名变化。

部分语言可用：只关联已经存在且确实对应的语言页面。尚无翻译的产品不能配到另一语言首页；仅翻译导航而未翻译主体时，要另行评估主内容语言和规范网址，不能把标签当作翻译完成证明。
x-default：可选，用于未匹配语言的回退安排，但非必需。
sitemap与HTML等价：Google声明sitemap、HTML和HTTP头方法等价，选择一种即可，但需保持一致。
排名推断：hreflang不合并权重，也不直接提升排名。不要假设修正hreflang会改变排名。

修正后，使用crawl工具验证一致性。现场HTML复测可以立即进行；Google是否重新抓取以及是否采用新信号是后续独立观察，不应因此推迟技术验收。

为什么两边都是200仍然不能签字

200只是响应成功，不保证拿到的是正确正文。检查人员应把页面标题、产品编号或文章标题与预期对象对照。错误模板也可能返回200，例如英文产品地址加载了英文首页，或者登录状态下正常、匿名访问却显示空壳。对这些情况，记录“响应200、内容对象不符”，而不是把状态码涂成绿色后直接完成。

同样，浏览器看到的新标签与搜索引擎上次收到的旧标签可以同时存在。先保存匿名GET返回的HTML，再保存渲染后页面；若两者有差异，定位客户端脚本是否覆盖了head。使用HTML标记方式时，要检查标签最终位于合法head内。若采用站点地图方式，则进入包含该产品的子地图，核对每条语言URL都带有对应的替代集合，不能只看主地图返回200。

如何把一次修复交给后续维护人员

交接记录至少写清四件事：错误在哪一端、哪个配置生成了错误地址、实际改了什么、用什么证据确认修正。比如“中文模板未输出英文返回项”比“hreflang有问题”可执行；“调整对应产品的语言映射并保存两端HTML”比“已优化标签”可核查。对整个模板共同生成的错误，先验收一组，再抽查使用相同模板的其他语言对，确认不是只对一个地址做了硬编码。

不要把未复测的行预填为通过。可以先写待复测，补上检查时间和最终URL后再改变状态。遇到间歇性404，保留失败时间、响应头、请求地址与随后恢复的证据，交由服务维护人员核对同一时段日志。没有找到原因之前，结论应是“当前恢复、稳定性未确认”，不能写“标签已经修复了服务器故障”。

内容维护也会改变语言配对。产品下架、译文合并或英文slug调整后，需要更新引用这些地址的替代集合及站点地图。真正没有对应译文时，去掉错误关系比指向一个不相关的存活页面更清楚。对于重定向，应先确认新的页面仍是同一产品或主题，再决定把它作为替代项，不能仅凭它可打开就接入。

结论

通过系统化的hreflang检查，可以定位并修复语言配对问题。使用上述检查表，确保每个语言版本正确互指，并避免常见陷阱。

参考来源： Tell Google about localized versions of your page

下一步

立即使用上述语言配对检查表，对您的网站进行hreflang审计，确保多语言SEO基础无误。