网页会自动重定向：这一状态何时掩盖了问题

Search Console 中的“网页会自动重定向”表示 Google 请求了某个 URL，服务器将其转到了别处，于是 Google 考虑将目标网页而不是列表中显示的这个 URL 编入索引。大多数时候，这只是重定向在按您的设计正常工作，比如迁移到 HTTPS、确定是否使用 www，或更改 URL 之后。只有当目标网页有误或未编入索引，或者您自己的 sitemap、链接和 canonical 标记仍在把 Google 引向旧地址时，它才成为问题。

Google 对这一状态的解释

Google 的“网页索引编制”报告文档（2026 年 10 月核对）将其描述为“会重定向到其他网页的非规范网址”，并补充说该网址“不会被编入索引”，而目标网址“可能会被编入索引，也可能不会，这取决于 Google 对该目标网址的判断”。

从这段说明可以得出两个推论：

• 这一状态针对的是来源 URL，而不是目标网页。 在列表中看到 http://example.com/pricing，并不能说明 https://www.example.com/pricing 是否已编入索引。目标网页需要单独检查。
• 重定向类型很重要。 Google 的重定向文档（2026 年 10 月核对）将重定向分为 2 类。永久重定向（HTTP 301 和 308、设为 0 秒的 meta refresh 或 HTTP refresh，以及 JavaScript location 重定向）会被当作“目标网页应为规范网页”的信号，搜索结果中显示的也是目标网页。临时重定向（302、303、307，以及有延迟的 meta refresh 或 HTTP refresh）会被跟随，但不会被当作这种信号，因此搜索结果中显示的是来源 URL。JavaScript 重定向只有在 Google 成功渲染网页后才会被发现。

它与“重定向错误”是两个不同的状态。后者是 Google 用于无法完成的重定向的状态：重定向循环、重定向链过长、重定向后的网址超出最大网址长度，或者链中存在错误或空的网址。

会重定向的 URL 从何而来

在一个健康的网站上，此列表中的大多数 URL 都来自以下正常来源：

1. 协议和主机规范化。 从 http:// 到 https://，以及从根域名到 www 或反过来。
2. 末尾斜杠规范化。 从 /blog 到 /blog/，由平台或服务器的默认设置决定。
3. 迁移和 URL 变更。 新域名、新的路径结构、重命名的产品。例如，在 WordPress 中修改文章的别名（slug）后，它会把旧别名用 301 重定向到新的固定链接。
4. 把已下线的网页合并到替代网页中。 例如把一篇旧指南合并到一篇较新的指南中。

问题模式则都是您自己网站造成的：

1. 您的 sitemap 中列出了会重定向的 URL。 SEOReport 在 2026 年 5 月至 10 月间抓取了 29 个外部网站的 sitemap 页面，其中 6 个（21%）的 XML sitemap 中列出了会重定向到其他地址的 URL。
2. 您的内部链接、canonical 标记或 hreflang 注解仍在使用旧 URL。 导航模板、正文中的旧链接，以及硬编码为 http:// 的 canonical 标记，会持续把会重定向的地址交给 Google。
3. 重定向指向了错误的地方。 Google 的网站迁移指南（2026 年 10 月核对）警告说，把大量旧 URL 重定向到同一个不相关的网页（例如首页），“可能会被视为软 404 错误”。
4. 重定向形成了链，或本应永久却用了临时重定向。 需要多次跳转才能到达目标网页，或者在一次永远不会回退的迁移之后，仍然留着 302。

在该样本的 3 种矛盾信号中，重定向是最常见的一种。每一个这样的条目，都是在请求 Google 编入索引一个您已经告诉 Google 并非真正网页的 URL。

这是问题吗？不处理、修复还是观察

flowchart TD
    A["URL 被列为“网页会自动重定向”"] --> B{"您是有意重定向它的吗？"}
    B -->|否| C["删除重定向或恢复该网页"]
    B -->|是| D{"目标网页是正确的替代网页吗？"}
    D -->|否| E["重定向到最接近的对应网页，或返回 404 或 410"]
    D -->|是| F{"只跳转一次，且为永久重定向吗？"}
    F -->|否| G["合并为一次 301 或 308"]
    F -->|是| H{"您的 sitemap、链接或 canonical 是否仍使用旧 URL？"}
    G --> H
    H -->|是| I["把所有引用更新为最终 URL"]
    H -->|否| J{"目标网页已编入索引吗？"}
    I --> J
    J -->|是| K["不处理"]
    J -->|否| L["检查目标网页自身的状态"]

如何确认是哪一种原因

先用 sitemap 筛选器。 在“网页索引编制”报告顶部，把筛选器从“所有已知网页”切换为“所有已提交的网页”，然后再次打开“网页会自动重定向”。仍然列在这里的每个 URL，都是由您的某个 sitemap 提交的、会重定向的 URL。示例表格最多只有 1,000 行，因此对于大型网站，还应直接测试 sitemap（见下文）。

检查几个 URL。 Google 的网址检查文档指出，已编入索引的结果反映的是您输入的 URL，而不是其重定向目标。有两个字段能指向问题的来源：“引荐网页”显示 Google 可能用来发现该 URL 的网页，“站点地图”则显示列出该 URL 的所有 sitemap。如果引荐网页在您自己的网站上，就说明有内部链接需要更新。如果它在其他网站上，那么重定向正在发挥应有的作用。

亲自追踪跳转。 同一文档指出，实际网址测试（“测试实际网址”）会悄无声息地跟随重定向，也不会显示它最终测试的是哪个 URL。而终端会显示每一次跳转：

curl -sIL http://example.com/old-page | grep -iE '^(HTTP/|location)'

一个 301 或 308 之后紧跟一个 200，就是干净的重定向。出现两行或更多重定向，就是重定向链；在永久迁移中出现的 302 或 307 则应当修改。

单独检查目标网页。 把最终 URL 粘贴到网址检查工具中。如果它未编入索引，问题就出在那个网页上，而它自身的状态会告诉您该从哪里查起：带有 noindex 的目标网页，请参阅此网址带有“noindex”标记；Google 抓取了却没有收录的，请参阅已抓取 - 尚未编入索引。

找出您自己的哪些文件仍在引用旧 URL

Search Console 只展示部分发现来源，而您自己的文件能展示全部。逐个测试 sitemap 中列出的每个 URL，并输出那些没有返回 200 的：

curl -s https://www.example.com/sitemap.xml \
  | grep -o '<loc>[^<]*</loc>' | sed -e 's/<loc>//' -e 's/<\/loc>//' -e 's/&amp;/\&/g' \
  | while read -r url; do
      code=$(curl -s -o /dev/null -w '%{http_code}' "$url")
      [ "$code" != "200" ] && echo "$code $url"
    done

输出中的 301、302、307 或 308 就是会重定向的条目。如果该文件是 sitemap 索引文件，请对其中列出的每个子 sitemap 运行同样的循环，并先解压所有 .xml.gz 文件。然后检查所有网页共用的模板，因为页眉中的一个链接会在每个 URL 上重复出现：

curl -s https://www.example.com/ \
  | grep -oE '(href|content)="[^"]+"' \
  | grep -E 'http://|//example\.com'

请把最后一个匹配模式替换为您已弃用的旧协议、主机或路径。在 WordPress 中，旧的绝对 URL 通常存在于文章内容里，在做任何修改之前，可以先用 WP-CLI 统计它们的数量：

wp search-replace 'http://example.com' 'https://www.example.com' --dry-run

正式执行时，请先备份数据库，并加上 --skip-columns=guid，让文章的 GUID 保持原值。

如何逐一修复这些原因

sitemap 条目。 只用最终 URL 重新生成 sitemap：每个条目都应返回 200，并将自身声明为规范网址。Google 的 sitemap 文档（2026 年 10 月核对）要求您收录希望出现在搜索结果中的 URL，而会重定向的 URL 并不属于此类。Google 关于规范化的文档还补充说，sitemap 中列出的每个网页都会被视为建议的规范网页。我们的 XML sitemap 指南介绍了干净 sitemap 的其他要求。

内部链接、canonical 标记和 hreflang。 把它们更新为目标网页的 URL。Google 关于规范化的文档（2026 年 10 月核对）建议链接到规范网址而不是重复网址；而指向会重定向 URL 的 canonical 标记，等于要求 Google 把信号合并到一个并不承载该网页的地址上。canonical 标记指南解释了这些信号如何组合，重复网页（用户未选定规范网页）则讨论了主机和协议变体完全没有重定向的情况。

目标网页有误。 把每个旧 URL 指向与之最接近的对应网页。如果某个网页没有替代网页，返回 404 或 410 才是如实的回答，也能避免 Google 对“重定向到不相关网页”所描述的软 404 处理。

重定向链和临时重定向。 写一条从入口 URL 直达最终 URL 的规则，使用 301 或 308。重定向链：如何产生，以及如何将其扁平化通过一个 4 次跳转的示例做了讲解，重定向与 URL 规范化指南则把协议、主机和斜杠规则放在一起介绍。

重定向本身要保留。 Google 的网站迁移指南建议尽可能长时间地保留重定向，一般至少 1 年。即使您自己的引用都已清理干净，外部链接和书签仍会在很长时间内访问旧 URL。

如何验证修复

1. 重新运行 sitemap 循环。 它应当不输出任何内容。
2. 对一部分旧 URL 重新追踪跳转：应该是一次永久跳转，然后返回 200，并到达正确的网页。
3. 在 Search Console 的“站点地图”报告中重新提交 sitemap，请 Google 重新读取它。
4. 关注“所有已提交的网页”筛选结果。 Google 重新读取您的 sitemap 并重新抓取这些 URL 后，会重定向的 URL 应当从中消失。Google 关于重新抓取的文档指出，抓取可能需要几天到几周不等，而且按 Google 的计划进行，而不是按您的计划。
5. 只对已删除的重定向使用“验证修复”。 验证会重新抓取受影响的 URL，检查每一个是否仍存在该问题，而有意设置的重定向按设计仍然会重定向。Google 的文档指出，验证通常最多需要约 2 周，某些情况下会久得多。

Search Console 会告诉您哪些 URL 会重定向。完整的 SEOReport 诊断会审计网站本身，列出您不该再对外宣告的重定向：sitemap 所列网页中会重定向的 URL（逐一附上其目标网页）、会重定向的首页规范目标或其他语言版本目标，以及当您提交的地址需要多次跳转时的每一次跳转。它不会测试内部链接是否重定向，因此请对内部链接运行上文的模板检查。

常见问题

会重定向的 URL 最终会从报告中消失吗？

它们可能会在“所有已知网页”视图中停留很长时间，因为 Google 会持续重新抓取它已知的 URL，包括其他网站链接到的 URL。如果重定向是有意的，且目标网页已编入索引，这就是正确的最终状态。真正应当减少的，是其中由您自己的 sitemap 提交的那部分 URL。

我的首页被列为“网页会自动重定向”，这是坏事吗？

通常列出的 URL 是某个变体，例如 http://example.com/，它会重定向到您首选的 https://www.example.com/。请检查首选的首页 URL：如果它已编入索引，说明这个变体的行为是正确的。如果首选 URL 本身出现在列表中，说明您的首页重定向到了您意料之外的地方，需要修复。

我应该用 canonical 标记代替重定向吗？

如果旧 URL 不应再向任何人显示它自己的网页，请使用重定向。如果两个 URL 都需要继续正常访问，例如同一产品列表的某个筛选视图，请使用 canonical 标记。一个保持可访问、但 canonical 指向别处的 URL，在 Google 认可该 canonical 时，通常会被报告为“备用网页（有适当的规范标记）”，这无需任何处理。