hreflang 与站点地图网址不一致:TranslatePress 排查指南

你的翻译页面都能正常访问,但 SEO 审计显示:页面的 hreflang 标签和 XML 站点地图中的语言网址不一样。一个列出的是当前地址,另一个似乎用的是旧别名、错误的语言目录,或原始首页。
应该修正哪一个?
首先,确认每种语言的可用地址。然后比较描述同一语言版本的条目,找出是哪个插件生成了错误信息。站点地图只列出原始语言页面,与两个来源声明互相冲突的语言目标,是两种不同的情况。
本指南介绍在 TranslatePress 中进行这些检查的方法,并说明 LingoWP 如何保持页面级语言链接的一致性,以及它在站点地图支持方面的局限。
由 LingoWP 发布。外部指南核对于 2026 年 10 月 6 日。本文描述的 LingoWP 行为基于其 1.5 版的开发评测。
应该比较什么?
hreflang 用来标明页面的语言或地区版本。站点地图列出页面网址,也可以包含语言备选条目。
关键的区别在于:站点地图中列出的页面与该页面所附带的语言备选项。
例如,站点地图可能列出英语页面,而页面的 HTML 标明了它的法语对应页面。这两个地址用途不同,所以它们不同本身并不是错误。
要确认真正的不一致,应比较同一内容的同一语言版本所对应的目标地址。
| 你发现的情况 | 含义 |
|---|---|
| 站点地图列出英语页面,其 HTML 链接到法语版本 | 地址不同是正常的。 |
| HTML 和站点地图都标明了法语版本,但地址不同 | 检查两者是否都指向预期的当前法语页面。 |
| 站点地图把原始的英语首页标为法语首页 | 该目标并不代表预期的译文。 |
HTML 使用 en,站点地图使用 en-GB |
在把它当作网址错误之前,先检查预期的地区定位和集成设置。 |
**不要为了匹配站点地图中的错误条目而修改一个可用页面的地址。**请先确定正确的目标。
hreflang 一定要出现在站点地图中吗?
Google 接受三种声明语言备选项的方法:HTML 标签、HTTP 标头和站点地图标注。它们是等效的;不需要三种都用,同时使用也不会带来额外的搜索收益。
因此,只包含原始语言的站点地图本身并不会让 HTML 中的 hreflang 失效。站点地图中的翻译网址可能有助于被发现,但条目缺失和声明冲突是两个不同的问题。
通用标签和地区标签也可以合理共存。例如,en 和 en-GB 可以指向同一个合适的页面。问题在于它们是否表达了你预期的定位,并指向了正确的内容。查看 Google 关于本地化页面的指南。我们关于 TranslatePress 中的重复 hreflang 标签的指南说明了通用条目和地区条目在什么情况下是有效的。
为什么 TranslatePress 和站点地图插件会不一致
页面的语言标签和它的站点地图可能来自不同的插件或集成。当这些组件使用不同的网址信息,或对语言设置的理解不同时,就可能出现不一致。
可能的原因包括:
- 页面别名或翻译别名改了,但某个输出仍在使用旧地址。
- 站点地图集成没有遵循自定义的语言配置。
- 首页的处理方式与普通页面不同。
- 某个内容插件控制着活动、商品或分类的网址基础路径。
- 缓存的 HTML 或 XML 仍反映着之前的设置。
仅凭错误信息无法判断是哪个组件造成的。
一个有记录的例子:SureRank 与 TranslatePress
在一次 WordPress 支持讨论中,一位网站所有者报告:TranslatePress 的 HTML 使用了他配置的 en 代码,而 SureRank 的站点地图使用的是 en-GB。站点地图还把英语首页的备选项指向了原始首页,而不是 /en/。
SureRank 技术支持复现了所报告的行为,并承认首页处理问题出在他们那边。他们还解释说,站点地图是从底层的区域设置推导地区代码的,而不是匹配 TranslatePress 的 hreflang 配置。
这是一个有用的诊断案例,但并不能证明当前每个安装都有同样的缺陷。阅读报告和技术支持的回复。
如何诊断和修复不一致
1. 记录一个受影响的页面及其语言目标
从审计中挑选一个具体页面。如果警告涉及首页,就从首页开始;不要以为博客文章没问题就说明首页也没问题。
打开每个语言版本,记录它当前可用的地址,并确认它以预期语言包含对应的内容。
举例说明:
| 语言版本 | 已核实的可用网址 |
|---|---|
| 英语联系页面 | https://example.com/contact/ |
| 法语联系页面 | https://example.com/fr/contactez-nous/ |
以这些地址作为比较的起点。你的网站使用未翻译的别名也是合理的;地址中有没有翻译后的词,并不是判断页面是否可用的标准。
2. 比较 HTML 和 XML 中的条目
打开受影响的页面,选择查看网页源代码,搜索 hreflang,记录每个相关语言代码对应的网址。
然后从 SEO 插件或 Search Console 的站点地图报告中打开站点地图网址。如果它是站点地图索引,就进入相关的页面或文章站点地图,找到受影响的条目。
查找两样东西:
- 页面的主网址,通常显示在
<loc>条目中。 - 任何把语言代码与另一个网址关联起来的备选条目。
你不需要编辑 XML,只是在检查两个来源是否正确描述了同一个目标。
| 来源 | 法语目标 | 结论 |
|---|---|---|
| 可用页面 | /fr/contactez-nous/ |
预期的当前地址 |
| HTML hreflang | /fr/contactez-nous/ |
一致 |
| 站点地图中的法语备选项 | /fr/contact/ |
需要排查 |
这是一个示意比较,并不是复现出的 TranslatePress 缺陷。最后一个地址可能会重定向、出错或提供另一个页面;在决定如何修正之前,请先检查它。
3. 检查网址本身
利用审计工具中的响应信息,查看列出的地址是直接打开还是重定向到别处。也要检查内容:一个网址可能加载成功,却显示了错误的语言或页面。
如果某个条目使用了旧地址,就修正生成该条目的组件。保留从旧地址到替代地址的有用重定向,让旧链接继续可用。hreflang 指向重定向的指南逐步介绍了这项修正。
还要检查规范网址(canonical)设置。规范网址标明页面的首选地址,不应与你打算发布的目标相矛盾。Google 建议在站点地图中包含首选的规范网址。阅读它的站点地图指南。
4. 检查 TranslatePress 的站点地图和语言设置
TranslatePress 的文档说明,多语言站点地图支持通过付费的 SEO Pack 提供,并与受支持的 SEO 插件配合使用。如果你预期站点地图中有翻译网址和备选条目,请确认该扩展已启用,并且你的站点地图插件集成支持你的配置。查看 SEO Pack 文档。
接下来,检查设置 → TranslatePress → 高级:
- Exclude translated links from sitemap 控制在 SEO Pack 启用时,是否从 SEO 插件的站点地图中排除翻译链接。如果这些链接是有意排除的,它们不出现就是正常的。
- Remove duplicate hreflang 提供国家格式、与地区无关的格式或两者兼有。在比较 HTML 和 XML 中的语言代码之前,先确认你选择了哪种格式。
这个设置的名称并不意味着通用标签和地区标签不能同时存在。请选择适合你受众的格式,并确认站点地图集成按预期处理它。TranslatePress 在这里说明了这些选项。
不要只为了消除一条警告就在线上网站修改语言目录名称。先确定问题出在网址、语言代码,还是两者都有。
5. 修正产生错误条目的组件
如果 HTML 正确而站点地图错误,就排查站点地图插件及其与 TranslatePress 的集成。如果站点地图正确而 HTML 指向旧地址,就排查该页面的语言网址配置。
对于活动、商品或归档页的网址,请把定义这些地址的插件也纳入排查。查看相关的更新说明,并尽可能先在测试副本上测试更新。
联系技术支持时,请提供受影响的页面、正确的语言网址、错误的条目以及已启用插件的版本。例如:
法语联系页面可以在 /fr/contactez-nous/ 正常访问,它的 HTML hreflang 也使用这个地址,但站点地图中的法语备选项用的是 /fr/contact/。附上站点地图网址,以及我的 TranslatePress、扩展和 SEO 插件版本。
请修正产生问题的设置或集成,而不要手动编辑生成的站点地图文件,因为它可能会在下次更新时被替换。
6. 刷新并验证公开输出
修正之后,如有需要,通过生成插件刷新站点地图,并清除相关的 HTML 或站点地图缓存。然后在未登录状态下检查公开页面。
单独检查首页,并检查一个普通页面和任何受影响的自定义内容类型。
最终检查包括:
- 每个已发布的语言目标都指向预期的当前页面。
- 网址可以直接访问,页面能按预期被抓取和编入索引。
- HTML 和站点地图中的备选声明描述了相互兼容的语言关系。
- 规范网址设置与预期的页面地址一致。
- 各语言对应页面提供预期的返回链接。
使用 Search Console 检查站点地图的处理情况和相关的索引信息。站点地图状态为成功,表示 Google 已获取并处理了该文件,但并不能证明每个语言对应关系都正确。查看 Google 站点地图报告的文档。
LingoWP 能帮你保持哪些内容一致
对网站所有者来说,修改一个页面不应意味着要在语言切换器、内部链接和语言标注中分别维护它的地址。
LingoWP 的开发评测描述了一种共用的方式,为 hreflang、切换器、内部链接、规范标签和重定向生成语言地址,并在构建这些目标时使用当前的页面信息。
实际好处是,当你在一个工作区中管理内容和译文时,LingoWP 的页面级链接能保持一致。这减少了为同一页面维护多套独立地址映射的需要。
选择之前需要了解的站点地图限制
在评测的 LingoWP 1.5 行为中,插件不会把翻译网址添加到 XML 站点地图中,站点地图仅包含原始语言页面。
因此,LingoWP 在页面级的网址处理并不能保证外部站点地图插件会生成对应的翻译条目。如果在站点地图中列出翻译网址是你网站的硬性要求,请在迁移之前确认有受支持的解决方案。LingoWP 与 TranslatePress 对比一文介绍了更全面的差异。
你仍然可以使用正确实现的 HTML hreflang 来标明各语言版本。需要考虑的是:在存在这项站点地图限制的情况下,LingoWP 的翻译工作流程和页面级一致性是否能满足你的需求。
了解 LingoWP,看看它的翻译工作区,并评估它是否适合你的多语言网站。
常见问题
我该相信 hreflang 还是站点地图?
先检查实际可用的页面。确认它的语言、内容、最终地址和规范设置,然后修正对它描述不准确的那一方。两个来源都可能包含过时或错误的信息。
安装 TranslatePress 的 SEO Pack 能修复所有不一致吗?
SEO Pack 提供有文档说明的多语言站点地图功能,但某个具体的不一致可能涉及站点地图插件、自定义语言设置、路由或缓存。请找出受影响的集成,并在修改后验证结果。
我应该删除站点地图来消除冲突吗?
先修正错误的条目。如果你选择用 HTML 作为 hreflang 的实现方式,仍然可以保留一个普通的站点地图,用于页面发现。删除语言标注和删除整个站点地图是两回事。