如何修复 Google Search Console 中的 404 错误(2026)

修复 Search Console 中的“未找到 (404)”:何时可忽略、何时做 301 重定向、何时恢复页面,附决策表和验证修复步骤。

常见问题

404 错误会影响我在 Google 的排名吗?

404 本身不会。Google 的“网页编入索引”文档指出,如果页面被删除且没有替代页面,返回 404 不一定是问题,并把“已删除页面返回 404”列为 URL 未被编入索引的正常原因之一。真正值得修复的,是你自己站内链接指向的、或写在站点地图里的 404 网址。

已删除的页面应该返回 404 还是 410?

对 Google 搜索来说,实际上没有区别。Google 的 HTTP 状态码文档对除 429 以外的所有 4xx 错误一视同仁:内容会被视为不存在,已编入索引的 URL 会从索引中移除,Google 对该 URL 的抓取频率也会逐渐降低。用你的平台最方便实现的那个即可。

404 错误的“验证修复”要多久?

Google 表示验证通常最多需要约两周,但也可能久得多。在当前验证成功或失败之前,请不要再次点击“验证修复”。只要 Google 发现仍有一个未修复的实例,验证就会终止。

为什么已经修复的 URL 还显示在“未找到 (404)”报告里?

Google 会在一段时间内持续尝试抓取已不存在的 URL,所以修复后它仍可能留在列表中。另外,报告中的示例列表最多只显示 1,000 行,也不保证列出所有 URL。请先解决根源问题(失效链接、站点地图条目),再发起验证并耐心等待。

要把所有 404 都重定向到首页吗?

不要。Google 的建议是:页面已迁移到新页面时,返回 3XX 重定向。没有真正替代页面的,最好保持 404。把毫不相关的 URL 全部跳转到首页,既给访客提供了他们没想要的内容,也会让你看不到真正的问题。

简短回答:在 Search Console 中打开 编入索引 > 网页(Indexing > Pages),点击 未找到 (404)(Not found (404)),然后把每个 URL 归入三类之一。如果页面是有意删除的,且没有任何链接指向它,就忽略。如果页面已迁移或有相近的替代页面,就添加指向该替代页面的 301 重定向。如果页面本该存在,就把它恢复。接着修复所有指向该失效 URL 的内部链接或站点地图条目,再点击 验证修复(Validate fix)。

Search Console 里的大多数“404 错误”根本不需要修复,所以这项工作的关键是分类判断,而不是修补。

“未找到 (404)”到底是什么意思

“网页编入索引”报告列出了 Google 尝试抓取但未能编入索引的 URL。“未找到 (404)”表示服务器对该请求返回了 404 状态码。仅此而已,它并不代表这个 URL 很重要。

Google 自己的排查建议很明确:只修复你自己链接到的、或列在站点地图中的 404 错误;如果页面已迁移,就返回指向新页面的 3XX 重定向。Google 还把“你已删除且没有替代页面的页面返回 404”列为页面合理地未被编入索引的原因之一。

如果你还没有设置这个工具,可以先看我们的 Search Console 指南,或者参考如何在 Google Search Console 中验证网站。

第 1 步:导出列表,找出每个 404 的来源

打开 Search Console,选择你的资源(property)。
进入 编入索引 > 网页(Indexing > Pages)。
滚动到“网页未被编入索引的原因”表格,点击 未找到 (404)。
查看示例 URL。该表格最多显示 1,000 行,也不保证列出所有 URL,所以如果你的网站很大,请把它当作样本。
如果想在电子表格中处理,可以导出数据。
点击某个 URL,使用 检查网址(Inspect URL)查看 Google 是如何发现它的。引荐页面和站点地图信息会告诉你这个链接是不是你自己的。

发现来源是关键。如果 Google 是通过你自己的导航或站点地图发现某个 404,那就是真正的缺陷。如果是通过旧的外部链接或别人网站上的拼写错误发现的,通常只是噪音,除非该链接确实给你带来了真实访客。

第 2 步:判断是忽略、重定向还是恢复

对报告中的每一组 URL,都用下面这张表来判断。

情况	表现	操作
有意删除的页面,没有替代页,没有内部链接	旧产品、已过期的活动、测试页	忽略。保留 404(或 410)。
页面已删除,但有相近的替代页	已停售的产品、指南的新版本	301 重定向到最接近的对应页面。
URL 已变更(修改 slug、移动文件夹、更换域名或迁移到 HTTPS)	内容相同,地址不同	将旧 URL 301 重定向到新 URL,一跳到位。
页面本该存在,却被误删或误取消发布	在线服务页、重点文章	恢复页面,确认返回 200,然后验证。
你自己的菜单、页脚或正文链接指向它	指向失效 URL 的内部链接	修复链接(如果页面已迁移,则做重定向)。
列在你的 XML 站点地图中	站点地图包含已删除的 URL	从站点地图中移除,再决定重定向还是忽略。
来自垃圾信息或奇怪参数的无用 URL	随机字符串、采集器特征	忽略。如果看起来像被注入的,请检查网站安全(见下文)。

如果替代页面并不是很贴切,就不要强行指定。Google 的重定向文档把重定向描述为将用户和 Google 引导到页面新位置的方式;而没有新位置的页面,也就没有可指向的目标。

第 3 步:正确添加重定向

对于永久迁移,Google 建议尽可能使用永久性的服务器端重定向。301 和 308 状态码都表示页面已永久移动。Google 表示,只有在无法使用服务器端重定向或 meta refresh 重定向时,才使用 JavaScript 重定向。

实用规则:

重定向到唯一最匹配的 URL,不要绕多跳。
目标页面应返回正常的 200 响应,而不是另一个重定向或错误。
同时把内部链接更新为新 URL,这样就不必永远依赖重定向。
在 WordPress 上,可以用重定向插件或主机商的重定向规则来实现。其他平台则使用服务器或 CMS 的重定向或重写设置。

下面是一份重定向映射示例,你可以交给开发人员,或粘贴到重定向工具中:

`` /old-pricing -> /pricing /blog/2022/seo-tips -> /blog/seo-tips /services/web-design -> /services/website-design ``

第 4 步:测试修复,然后验证

在通知 Google 之前,先自己检查这个 URL。

在浏览器中打开旧 URL,或运行一次响应头检查,确认它返回 301 并跳转到一个 200 页面。
在 Search Console 中,把 URL 粘贴到顶部搜索栏并运行 检查网址(Inspect URL),再使用实时测试查看 Google 获取到的内容。
确认该 URL 已不在站点地图中,也没有任何内部页面链接到它。

然后开始验证:

在“网页编入索引”报告中打开 未找到 (404) 问题。
点击 验证修复(Validate fix)。
关注状态。在验证成功或失败之前,不要再次点击“验证修复”。
如果失败,点击 查看详情(See details),修复剩余的 URL,然后重新开始。

Google 表示验证通常最多需要约两周,但也可能久得多。只要发现哪怕一个遗留实例,验证就会停止,所以请在整组问题都修复后再验证。Google 文档里有一个小技巧:针对受影响 URL 的子集进行验证可以更快完成,做法是用一个只包含重点页面的站点地图来筛选报告。

补充一点:Google 对 404 URL 是逐步处理的。对于返回 404 的 URL,它表示索引流水线会把曾被编入索引的 URL 从索引中移除,新发现的 404 页面不会被处理,抓取频率也会逐渐降低。所以你保留为 404 的 URL 会自行慢慢消退。

第 5 步:排查“看似 404 其实不是”的情况

有两种类似情况需要不同的处理方式:

软 404(Soft 404)。页面返回 200 状态码,却显示空白页或错误信息,Search Console 将其报告为软 404。修复方法是返回真正的 404 状态码,或者在页面上放入真实内容。
被黑或被注入的 URL。如果突然出现大量指向奇怪文件名或垃圾路径的 404,可能说明网站已被入侵。如果你的情况与某个 CMS 吻合,请阅读我们针对 WordPress、Joomla 或 Drupal 的修复指南,然后重新检查报告。

可复制的分类检查清单

[ ] 已从编入索引 > 网页导出“未找到 (404)”URL
[ ] 已为每个 URL 标记来源:你自己的链接、你的站点地图、外部链接或未知
[ ] 已忽略没有替代页且没有内部链接的已删除页面
[ ] 已为迁移的页面添加 301 重定向,一跳到位,指向 200 页面
[ ] 已恢复被误删的页面
[ ] 已修复指向失效 URL 的内部链接
[ ] 已从 XML 站点地图中移除失效 URL
[ ] 已用检查网址抽查样本
[ ] 已点击一次验证修复,并等待结果

预防下一批 404

大多数反复出现的 404 都源于网站改版、修改 slug 以及删除文章却没有重定向方案。在任何迁移之前,先列出旧 URL,并为每一个对应好新地址。如果你本来就要重建一个小型网站,We.Inc 的免费计划允许你使用现成模板发布最多三个网站;而能根据提示词生成网站的 AI 构建器,则从 Starter 方案起,每月 $20。你可以在这里注册。无论哪种方式,都请保留好新旧 URL 映射表,因为它正是让这份报告保持干净的关键。

想进一步了解这个工具,请参阅 Google Search Console 新手入门。

免费开始 · 无需信用卡

Umair Ali Sadaqat

We.Inc 创始人

Umair 是 We.Inc 的创始人。他撰写有关 AI 建站、代理机构以及经营网站工作室的文章。

准备好打造出色的作品了吗？

加入 15,000+ 家使用 We.Inc 在一个平台上完成上线、增长和自动化的企业。