Google Search Console 里出现 404,不代表网站一定出大问题。真正要处理的是那些还有价值、还有外链、还被站内链接指向、或者原本应该能访问的旧 URL。没有价值的废弃页面,可以正常返回 404;有替代内容的旧链接,应该用 301 重定向到最相关的新页面。
如果你做的是 WordPress 内容站、工具导航站、联盟营销站或出海项目站,404 修复不要只盯着“数量清零”。更重要的是让搜索引擎明白:哪些页面已经不存在,哪些页面已经迁移,哪些页面仍然值得抓取和收录。

先判断:这个 404 值不值得修
不是所有 404 都要重定向。乱做重定向,反而可能把搜索引擎带到不相关页面,形成软 404 或低质量信号。
可以按这几个场景判断:
- 旧文章改了 URL,但有对应新文章:301 到新文章。内容延续,用户意图一致。
- 旧工具详情页,工具仍然存在:301 到当前工具页。这样可以避免浪费旧链接和抓取记录。
- 旧分类页,有对应新分类:301 到新分类页。集合页入口还在,就应该给用户一个新落点。
- 站内正文还在链接的错误 URL:优先修正文内链接。从源头减少无效入口。
- 测试页、样例页、无价值废弃页:保持 404 或 410。不需要强行传递权重。
- 完全不相关的旧页面:不要重定向到首页。这样容易让用户和搜索引擎困惑。
Google 官方说明里,4xx 页面不会被用于索引;如果旧 URL 已经不该存在,Google 会逐步降低抓取频率并从索引里移除。相反,301 是更强的迁移信号,适合旧地址有明确新地址的情况。参考:Google HTTP 状态码文档 和 Google 重定向说明。
最常见的 404 来源
很多站长看到 Search Console 里突然冒出一批 404,会以为是 Google 抓错了。实际更常见的是网站自己历史上留下了入口。
常见来源包括:
- 改过固定链接结构,旧 URL 没有做重定向;
- WordPress 主题或导航插件生成过旧路径;
- 文章生成过程中写错了内链;
- 旧分类、旧标签、旧工具页改名后没有回收;
- sitemap 曾经提交过旧 URL;
- 外部网站或 AI 工具引用了过时链接;
- Cloudflare、WP Super Cache 等缓存还保留旧 404 页面。
对多来钱这类“文章 + 支柱页 + 工具导航”的站点,最容易出问题的是旧工具详情页和旧分类路径。比如原来是 /sites/123.html,后来变成 /sites/tool-name,如果没有重定向,Google 就会继续报告旧地址 404。
修复顺序:先重要页面,再批量规则
修 404 不要一上来就全站替换。推荐顺序是:
1. 从 Search Console 导出 404 示例 URL; 2. 把 URL 分成文章、页面、工具详情、分类、标签、测试页几类; 3. 先处理有价值的旧文章、旧工具页、旧分类页; 4. 再清理站内正文里的错误内链; 5. 最后处理无价值测试页和历史垃圾路径。

如果旧 URL 很多,可以用规则化重定向处理。例如:
/links这种旧入口,可以跳到当前工具导航页;/sites/数字.html可以查找对应工具详情页;/tools/旧分类/可以跳到新的网址分类页;/sample-page这类样例页,可以删除站内入口,不一定要追求收录。
重点是“相关”。旧文章不要全部重定向到首页,旧工具页不要全部跳到一个无关分类。搜索引擎和用户都能看出这种偷懒。
WordPress 站怎么做更稳
WordPress 站修 404,通常有三种方式:
- 用 Rank Math、Redirection 等插件添加 301;
- 在 Nginx/Apache 里写服务器重定向;
- 用 MU Plugin 写一段可回滚的规则化重定向。
如果只是十几个 URL,用插件最省事。如果是几百个规律明显的旧工具页,用 MU Plugin 或服务器规则更干净。无论用哪种方式,都要先做测试,不要直接覆盖全站路径。
对 OneNav 导航站尤其要注意:网址详情页、网址分类页、文章分类页、普通标签页不是一类东西。不要把 /category/、/favorites/、/sites/ 混着处理。否则可能把本来应该收录的工具详情页,错误地导向文章分类或首页。
修完后一定要清缓存
很多人以为自己已经修好了,Search Console 还是显示失败,于是又去改代码。其实问题可能只是缓存。
修复 404 后建议按这个顺序检查:
1. 访问旧 URL,看是否 301 到正确新 URL; 2. 再看最终落地页是否返回 200; 3. 清 WordPress 缓存; 4. 清 Cloudflare 缓存; 5. 用无痕窗口或 curl -I 复查; 6. 再去 Search Console 点“验证修正情况”。

如果响应头里还能看到旧 404 被 Cloudflare 命中,说明边缘缓存还没有清掉。这个时候 Google 再来抓,也可能继续看到旧结果。
什么时候点“验证修正情况”
不要刚写完规则就立刻点验证。先抽样确认:
- 旧 URL 能 301;
- 新 URL 最终是 200;
- 不是跳到不相关页面;
- 站内正文没有继续链接旧地址;
- sitemap 里不再出现不该提交的旧 URL;
- 缓存已经清理。
确认后再点验证,成功概率会高很多。
验证时间没有固定答案。小站可能几天内开始变化,大批量 URL 可能要等一两周甚至更久。Search Console 的报告本身也不是实时数据,所以不要用当天报告判断当天修复是否失败。
哪些 404 可以不管
这些 404 通常不需要强行修:
- 明显不存在的垃圾路径;
- 被机器人猜测出来的路径;
- 已删除且没有替代内容的测试页;
- 参数页、搜索页、无意义筛选页;
- 没有站内入口、没有外链、没有业务价值的旧页面。
让不存在的页面返回 404 是正常的。SEO 的重点不是把所有 404 都消灭,而是避免重要页面错误 404,避免站内大量无效链接,避免旧价值页面没有合理承接。
和收录有什么关系
404 修复本身不会立刻让网站收录暴涨。它解决的是“抓取阻断”和“旧信号丢失”问题。
真正影响收录的,还包括:
- 页面内容是否足够有用;
- 是否有清楚的支柱页和内链结构;
- sitemap 是否干净;
- 标题和描述是否能表达页面价值;
- 重要页面是否能从首页、支柱页、旧文章被发现;
- 服务器是否稳定返回 200;
- 页面是否被 noindex、canonical 或 robots 错误拦住。
所以修完 404 后,下一步应该回到内容质量和站内结构。可以继续看 网站内链怎么做、Bing Webmaster Tools 怎么看 SEO 问题,以及 网站 / 工具站变现。
一套简单检查清单
发布新文章或改版后,可以用这套清单:
- 新 URL 是否能直接 200;
- 旧 URL 是否有必要 301;
- 301 目标是否相关;
- 站内正文链接是否真实可访问;
- sitemap 是否只保留规范 URL;
www是否统一跳到非www;- 重要页面是否 index/follow;
- 文章是否链接到上级支柱页;
- 旧文章是否给新文章补回链;
- 缓存清完后是否再次复查。
这套动作看起来琐碎,但对小站很重要。它能让搜索引擎更快理解网站结构,也能减少“已发现但尚未编入索引”“已抓取但尚未编入索引”这类后续问题。
常见问题
Search Console 显示 404 就一定影响排名吗?
不一定。少量无价值 404 很正常。真正需要关注的是重要页面、旧文章、旧工具页和站内还在链接的 URL。如果这些页面返回 404,就应该修。
旧页面删除了,应该 301 到首页吗?
一般不建议。只有当首页确实是最相关替代页面时才考虑。更好的做法是跳到主题最接近的文章、支柱页、工具页或分类页。
修复后为什么 Google 还显示失败?
可能是 Google 还没重新抓取,也可能是缓存仍然返回旧 404,还可能是部分样本没有覆盖到。先用浏览器无痕或响应头工具抽查,再重新验证。
404 和软 404 有什么区别?
真正的 404 是服务器明确告诉搜索引擎页面不存在。软 404 通常是页面返回 200,但内容像错误页、空页面或无价值跳转页。乱把所有旧地址跳到首页,可能更接近软 404 风险。
修完 404 后还需要提交 sitemap 吗?
如果 sitemap 已经正常更新,可以重新提交或等待搜索引擎抓取。更重要的是保证 sitemap 里是规范 URL,不要继续提交旧 404 地址。
如果页面已收录但没流量,下一步看什么
404 和重定向问题修完后,不代表搜索流量会立刻起来。下一步要看页面有没有展现、排名是不是太靠后、标题点击率是否偏低,以及旧文有没有给新页面传递入口。可以继续读 新站为什么 Google 收录了也没流量,按展现、排名和点击顺序做一次诊断。



