# TranslatePress 中 hreflang 指向重定向：如何修复

> TranslatePress 中的 hreflang 指向旧网址？检查重定向、翻译后的别名和缓存，并了解 LingoWP 如何让语言链接保持最新。

- URL: https://www.lingowp.com/zh/blog/translatepress-hreflang-chongdingxiang/
- Author: Amine Sayagh
- Category: 故障排查
- Published: 2026-10-06
- Language: zh

你的翻译页面能正常打开，语言切换器看起来也没问题。然后，一次 SEO 审计告诉你：有一个 hreflang 网址发生了重定向。

这条警告通常意味着某个语言链接仍然指向一个会把访客送到别处的地址。由于浏览器会自动跟随重定向，页面看起来可能完全正常。

**修复方法是：找出该语言最终可用的网址，并修正生成旧 hreflang 地址的设置或集成。保留从旧网址出发的有用重定向，清除相关缓存，然后重新检查语言链接。**

下面介绍如何在 TranslatePress 中完成这个过程，以及 LingoWP 如何在页面地址变化时帮助这些链接保持一致。

*由 LingoWP 发布。外部指南核对于 2026 年 10 月 6 日。下文的产品说明基于 LingoWP 1.5 的开发评测。*

## “hreflang 指向重定向”是什么意思？

hreflang 告诉搜索引擎去哪里找到页面的各个语言版本或地区版本。例如，一个法语活动页面可以标明对应的荷兰语活动页面。

重定向警告意味着为其中某个版本列出的地址并不直接提供页面，而是先返回 **301** 或 **302** 之类的重定向响应，然后才到达另一个网址。

看一个示意例子：

| 你检查的内容 | 网址 | 结果 |
|---|---|---|
| hreflang 中列出的荷兰语网址 | `https://example.com/evenement/summer-concert/` | 重定向到另一个地址 |
| 当前的荷兰语活动页面 | `https://example.com/event/summer-concert/` | 直接打开目标页面 |

hreflang 条目应该使用第二行中的当前地址。

Screaming Frog 把发生重定向的备选网址归入 **Non-200 Hreflang URLs** 检查，并建议让标注指向正确的、可编入索引的规范页面。**200** 响应表示请求成功，但你仍需确认页面包含预期的内容。[查看它的说明](https://www.screamingfrog.co.uk/seo-spider/issues/hreflang/non-200-hreflang-urls/)。

## 为什么页面正常，警告却还在

打开旧网址的访客可能会被重定向到正确页面，而根本没注意到地址变了。当有人通过旧书签或旧链接访问时，这很有用。

但是，网站的语言标注本应直接指明当前的目标地址。把旧地址留在 hreflang 中会多出一个不必要的步骤，也会让各语言版本之间的关系变得不那么清晰。

仅凭这条警告，并不能说明你的排名已经下降。hreflang 帮助 Google 理解语言之间的关系，而 Google 要求相关版本之间有返回链接。审计应该在最终网址上检查这些关系。[Google 的指南说明了这些要求](https://developers.google.com/search/docs/specialty/international/localized-versions)。

实际目标很简单：每个语言条目都应直接指向同一内容的正确版本。

## 如何在 TranslatePress 中修复发生重定向的 hreflang 网址

### 1. 找到发生重定向的具体备选网址

从审计中挑一个受影响的页面开始，记录：

- 包含该 hreflang 条目的页面。
- 条目对应的语言代码。
- 条目中列出的网址。
- 重定向之后到达的最终网址。

如果需要手动检查，打开页面，选择**查看网页源代码**，搜索 `hreflang`。你只需要找出列出的地址，不需要编辑页面代码。

如果你已经在用 Screaming Frog，请查看 **Hreflang → Non-200 Hreflang URLs**。它的报告会把包含标注的页面与需要排查的目标分开列出。

### 2. 确认该语言的正确目标地址

打开最终页面，检查它是否以预期语言包含预期内容。活动应该对应到相应的活动，商品应该对应到相应的商品。

利用审计中的响应信息，确认这个最终网址**直接返回 200**。仅仅看到页面加载出来是不够的：浏览器可能又跟随了另一次重定向。

如果本应是法语的网址最后到达的是英语页面或首页，请先排查这个路由问题。把这样的目标写进 hreflang，描述的将是错误的语言关系。如果重定向链最后到达的是错误页面，请按照 [hreflang 指向 404 页面](/zh/blog/translatepress-hreflang-404/)时的步骤处理。

### 3. 找出地址中发生了什么变化

比较旧网址和当前网址，差异通常会告诉你该去哪里找。

| 差异 | 需要排查的内容 |
|---|---|
| 页面名称变了 | WordPress 别名及其翻译后的别名 |
| `/event/` 之类的分区变了 | 控制该内容网址基础路径的插件或设置 |
| 语言目录变了 | TranslatePress 的语言网址设置和现有重定向规则 |
| HTTP 变成 HTTPS，或主机名变了 | 站点网址和主机的重定向设置 |
| 只有末尾斜杠不同 | 生成的链接是否遵循网站当前的网址格式 |

这些只是可能的原因，并不是对每个 TranslatePress 安装的诊断。请从你能实际观察到的差异入手。

### 4. 修正生成过时网址的设置

对于翻译后的页面别名，请将译文与当前的 WordPress 别名进行核对。

TranslatePress 的文档把别名翻译放在付费的 **SEO Pack** 中。启用后，你可以打开**翻译页面**并选择文章别名。如果页面编辑器中找不到相应条目，也可以在 **String Translation → Slugs** 中搜索别名。[按照官方的别名翻译说明操作](https://translatepress.com/docs/translation-editor/url-slug-translation/)。

对于活动、商品、分类或其他自定义内容类型，还要检查控制其地址的插件。页面名称翻译正确，并不能修复网址中其他位置的错误分区路径。

如果设置看起来没问题但输出仍然错误，请在网站的测试副本上排查集成。记录你的 TranslatePress 版本、已启用的扩展、SEO 插件和重定向插件。在认定某个旧报告仍然适用之前，先查看 [TranslatePress 更新日志](https://translatepress.com/docs/translatepress-free-changelog/)中是否有相关修复。

如果你的 XML 站点地图列出的地址与页面的 hreflang 不同，请参阅 [hreflang 与站点地图网址不一致](/zh/blog/translatepress-hreflang-zhandian-ditu-buyizhi/)时的处理方法。

有用的支持请求应当具体：

> 在这个页面上，荷兰语的 hreflang 条目使用的是旧的活动地址，它会 301 重定向到当前的荷兰语地址。附上两个网址、受影响的页面以及我已启用插件的版本。

这样技术支持就有了一个可复现的起点。

### 5. 保留旧的重定向，并刷新受影响的输出

如果旧地址已经永久迁移，它的重定向可能仍然需要用于书签、外部链接和以前的搜索结果。请修正 hreflang 条目，让它使用当前地址，同时保留这条有用的重定向。

修正了生成设置后，清除相关的页面、主机或 CDN 缓存，让公开页面显示更新后的标注。然后以未登录访客的身份检查页面。

如果过时地址立刻又出现了，请继续排查生成它的组件。反复清除缓存并不能修正一条没有改变的网址规则。

### 6. 把各语言版本放在一起重新检查

检查原始页面及其翻译对应页面。Google 规定，各语言版本应引用自身和其他版本，相关页面之间要有返回链接。

对于受影响的页面，请确认：

- hreflang 条目使用的是预期的最终地址。
- 这些地址能直接打开并返回 200。
- 每个目标都包含正确的语言和对应内容。
- 各语言版本互相链接。
- 规范网址（canonical）设置与预期的语言页面一致。

Google 建议在使用 hreflang 时，尽可能使用同一语言的规范页面。请检查是否有自定义的规范设置把某个翻译页面指向了不合适的目标。[阅读 Google 关于规范网址的指南](https://developers.google.com/search/docs/crawling-indexing/consolidate-duplicate-urls)。

修改后重新运行审计。如果网站有很多类似的页面，除了你修好的第一个例子之外，还要检查同类型的所有页面。

## LingoWP 如何让语言链接保持最新

当你重命名页面或更新翻译后的标题时，维护语言链接应该是同一个工作流程的一部分。

LingoWP 在生成页面的各语言地址时使用 WordPress 当前的固定链接，并从翻译后的标题生成翻译别名。它的开发评测描述了在文章或别名变化时使相关网址缓存失效的机制。

对网站所有者来说，好处是地址变更后需要修正的地方更少：LingoWP 的语言链接是根据当前的页面信息生成的。

**LingoWP 1.5** 的评测报告了相关测试：hreflang 目标会避开 WordPress 的旧别名重定向，而旧别名重定向会保留访客的语言。这些测试支持本文描述的页面重命名行为。

因此，如果保持翻译地址一致已经成了反复出现的维护任务，LingoWP 值得考虑。你在中央工作区中管理页面及其译文，而插件根据当前的内容信息处理语言链接。如需更全面地了解两款插件，请阅读 [LingoWP 与 TranslatePress 对比](/zh/blog/lingowp-yu-translatepress-duibi/)。

第三方路由依然重要。评测没有测试示例中所用的那套 Events Calendar 配置，而外部重定向规则可能改变任何生成网址的行为。切换之前，请在网站副本上测试这些集成。

**[了解 LingoWP](https://lingowp.com/)**，看看它的翻译工作区，并评估它是否适合你网站的工作流程。

## 常见问题

### 为了修复 hreflang，我应该删除 301 重定向吗？

如果这条重定向正确地把旧地址引向替代地址，请保留它，并更新 hreflang 条目让它直接使用替代地址。删除有用的重定向可能会让旧链接失去可用的目标。

### Search Console 中的“网页会自动重定向”能证明 hreflang 出错吗？

不能。它描述的是一个会重定向、因此不会以该网址编入索引的地址。你需要单独检查语言标注，才能确定 hreflang 是否使用了这个地址。Google 网址检查工具的实时测试会跟随重定向，所以实时测试成功也不能证明原始网址直接返回 200。[查看网页索引编制报告的文档](https://support.google.com/webmasters/answer/7440203?hl=zh-Hans)。

### 清除缓存能消除这条警告吗？

如果底层地址已经修正，而访客收到的是旧的缓存输出，清除缓存会有帮助。如果仍有设置或集成在生成错误地址，请先修正这个原因。

### 我需要更换插件才能解决这个问题吗？

过时的别名、配置不一致或集成问题，可能在你当前的环境中就能修好。如果你同时也想要 LingoWP 的翻译工作流程及其维护语言链接的方式，可以考虑它。任何改动之后（包括迁移），都要检查受影响的网址。