个人网站 404 暴增，我才发现问题不在代码，而在外链路径

这几天我看 XBSTACK 后台，最刺眼的不是访问量低，而是 404 开始变多。

一开始我以为是 Astro 路由写错了，或者某次部署把页面打丢了。后来翻 Cloudflare 记录才发现，很多请求根本不是站内用户点出来的，而是从知乎、掘金、搜索引擎缓存、历史外链里，带着错误路径冲进来的。

404 这个东西很阴。

它不像 500 那样炸得明显，也不像首页打不开那样马上能发现。它更像一个漏水点：用户来了，撞墙，走了；搜索引擎来了，撞墙，降低信任；我自己只看到访问量，就是不知道流量漏在哪里。

所以这次我没有继续写新的 AI Agent 教程，而是停下来查网站本身。

404 不是技术小问题，是流量漏斗问题

少量 404 很正常。任何公开网站都会被爬虫、扫描器、旧链接、错误输入打到不存在的路径。

但如果 404 持续增多，就不能只当成“互联网上的正常噪音”。尤其是个人网站，流量本来就不多，每一个有效访问都很贵。一个从知乎点进来的读者，本来可能会看完一篇文章，再顺手进入 AI 开发总入口 或 站内搜索；如果他第一眼看到的是 404，大概率就直接关掉。

搜索引擎也一样。

它不会因为一个随机垃圾路径就否定整个网站，但如果某些旧路径长期被 sitemap、外链、站内链接指向，却一直返回 404，那就说明这个站点的发现路径不干净。对 XBSTACK 这种内容已经写到一百多篇、栏目又比较多的网站来说，404 不是一个单点错误，而是内容资产系统里的裂缝。

我之前写过一篇 XBSTACK 内容质量审计构建日志，里面主要查的是封面、内链、重复选题、Pagefind、sitemap 和 robots。那次审计证明站内结构没有明显高危问题。但线上 404 增多提醒我：站内干净，不代表站外路径也干净。

我先排除了“全站路由崩了”

排查 404，第一步不是马上写重定向，也不是直接怀疑框架。

我先看几个基础事实：

首页：正常
AI 总入口：正常
LangGraph / MCP / Workflow 专题页：正常
文章详情页：正常
sitemap-index.xml：可访问
sitemap-0.xml：可访问
Pagefind 搜索索引：构建正常

这说明问题不是全站构建失败，也不是 Astro 动态路由整体失效。

如果是全站路由崩了，现象会更明显：大量正常文章打不开，sitemap 对应路径批量失效，搜索页面也可能无法加载。但这次不是。问题集中在一些具体路径上，而且这些路径往往带着旧 slug、错误拼写、截断链接或者历史外链痕迹。

也就是说，这不是“网站挂了”，而是“有些入口指错了”。

404 的来源通常不止一个

我把这类个人网站 404 分成五种。

第一种是站内旧链接。比如以前文章里写过一个路径，后面改了 slug，但正文没有同步改。读者从旧文点进去，就会撞到不存在的页面。

第二种是外部平台错误链接。知乎、掘金、CSDN、小红书、公众号转载，任何一个地方复制路径时多了一个字符、少了一个斜杠，都会长期制造 404。外链不像站内链接，我改完网站以后，外部平台不会自动更新。

第三种是搜索引擎缓存旧路径。旧页面被抓过，后来我迁移分类或者改了 slug，搜索引擎短期内还会继续访问老地址。

第四种是 sitemap 历史残留。理论上 sitemap 应该只放真实存在的 URL，但如果生成脚本或者部署缓存没有及时刷新，就可能继续告诉搜索引擎去抓旧路径。

第五种是垃圾扫描。比如有人扫 /wp-admin/、/phpmyadmin/、/.env、/admin/login。这种 404 不需要修，保留 404 反而是正确结果。

关键在于：不要把这五种混在一起处理。

如果把垃圾扫描也全部 301 到首页，看起来 404 少了，实际上是在污染日志。以后我再看后台，就分不清到底是真用户撞墙，还是脚本乱扫。

Cloudflare 日志要看什么

Cloudflare 这类边缘层日志最大的价值，不是告诉我“有 404”，而是告诉我“谁从哪里打到了哪个路径”。

我会按四个字段看。

path       请求路径
referer    来源页面
user-agent 请求客户端
count      相同路径出现次数

如果一个路径的 Referer 来自知乎或掘金，而且重复出现，就要优先处理。说明这不是垃圾扫描，而是有真实外链在导流。

如果 User-Agent 是 Googlebot、Bingbot、Baiduspider，并且路径像旧文章 slug，就要检查 sitemap 和旧外链。搜索引擎不是敌人，它只是沿着某条旧线索找了过来。

如果路径是 /.env、/wp-login.php、/phpmyadmin，那就不用紧张。这种请求直接保留 404，最多在 Cloudflare WAF 做频率限制。

我最怕的是另一种：路径看起来像正常文章，但实际不存在。

/ai/langgraph-observability/
/ai/n8n-webhook-hardening/
/ai/xbstack-content-audit/
/tools/compound-calculator/

这种路径不是黑客扫出来的，而是人或平台复制出来的。它离正确路径只差一点点，却足以让用户撞墙。

Astro 网站最容易出现的路径问题

Astro 静态站本身很稳，但路径治理要靠人。

我现在重点看这几类问题。

第一，trailing slash 不一致。

有的地方写 /ai/foo，有的地方写 /ai/foo/。如果站点配置没有统一规范，外链平台再做一次截断或转码，就可能变成不同路径。

第二，slug 改名后没有重定向。

内容站最常见的情况是：早期标题写得粗糙，后面为了 SEO 改标题、改 slug，但忘了给旧 slug 做 301。站内看起来干净，站外旧链接全坏了。

第三，中文标题转 slug 后被截断。

一些平台复制链接时，会自动处理中文、空格、标点或尾部斜杠。如果文章 slug 本身太长，或者路径里混过特殊字符，错误概率会明显变高。

第四，栏目迁移。

XBSTACK 早期有些内容从 archive、lens、ai、horizon 之间迁移过。迁移本身没问题，但迁移后要有旧路径兜底。否则搜索引擎和旧外链还在走老路。

第五，sitemap 与真实页面不同步。

如果 sitemap 里还有旧 URL，就等于我自己在邀请搜索引擎访问不存在的页面。这个问题比普通外链更值得修，因为它是站点主动释放的错误信号。

哪些 404 必须修，哪些可以不管

我现在不会追求把 404 清零。那是不现实的，也没必要。

我只处理三类。

第一类，有真实外链来源的 404。比如 Referer 来自知乎、掘金、CSDN、公众号中转页，且路径明显对应站内已有文章。这类要么修外部原文，要么在站内做 301。

第二类，有搜索引擎访问痕迹的旧路径。尤其是 Googlebot、Bingbot、Baiduspider 多次访问的路径，如果它能对应到一篇现存文章，就应该建立重定向。

第三类，站内旧链接造成的 404。这个必须修正文，不要只靠重定向兜底。站内链接是我能完全控制的资产，不能让它长期错误。

剩下的可以不管。

/wp-admin/
/wp-login.php
/phpmyadmin/
/.env
/server-status
/random-test-path

这些不是流量，是噪音。把噪音修成入口，才是真正的错误。

我的 404 修复清单

这次我会按这个顺序处理。

1. 从 Cloudflare 导出最近 7 天 404 路径
2. 按 count 排序，找出高频路径
3. 按 referer 分组，识别知乎、掘金、搜索引擎来源
4. 用站内搜索确认这些路径是否对应现有文章
5. 有对应文章：建立 301 或修正外链
6. 无对应文章但有真实需求：考虑补一个专题页或兜底页
7. 垃圾扫描路径：保留 404，不做跳转
8. 重新生成 sitemap 并检查旧路径是否残留
9. 检查文章正文和专题页的内部链接
10. 让 404 页面提供搜索、AI 总入口、Tools 入口，而不是只有一句 Not Found

其中第 10 条很重要。

404 页面不是墓碑，它应该是救援入口。用户撞到不存在的路径以后，至少应该能继续去 全部文章、站内搜索、AI Engineering 或 Tools 找东西。

如果 404 页面只是冷冰冰的一句 Not Found，那就是把用户往外赶。

重定向规则不要贪多

很多人修 404 会走向另一个极端：看见不存在路径就往首页跳。

这不对。

重定向应该尽量精确。

/old-ai-agent-url/  -> /ai/ai-agent-architecture/
/old-n8n-webhook/   -> /ai/n8n-webhook-production-hardening/
/old-content-audit/ -> /ai/xbstack-content-quality-audit-builder-log/

如果找不到明确对应页面，就不要硬跳到首页。因为用户本来想看的是某个具体问题，不是首页。搜索引擎也能看出这种不相关跳转，长期会削弱页面信号。

我的原则是：能一对一，就 301；不能一对一，就让 404 页面承担导航功能；明显垃圾，就继续 404。

这件事给我的提醒

个人网站写到一定阶段以后，真正的工作不再只是“今天发什么”。

还要定期回头看：哪些文章被外部引用了，哪些路径改过，哪些旧入口还在被搜索引擎访问，哪些页面虽然存在但用户进来以后没有下一步。

这也是我现在越来越强调内容库存的原因。

XBSTACK 已经有 LangGraph、MCP、Workflow 这些专题，也有 复利计算器、AI 财报助手、Lunest 这些工具页。文章越来越多以后，路径就是资产的一部分。

标题可以改，结构可以优化，页面可以重构，但旧路径不能随便丢。

因为搜索引擎记得，外部平台记得，读者收藏夹也记得。

发布前检查清单

以后每次发布或改 slug，我都会多做几步。

- 新文章 slug 是否短、稳定、无特殊字符
- sitemap 是否包含新 URL
- 旧文章是否需要补内链
- 是否存在相近旧题导致重复
- 外链分发时是否复制了最终 URL
- 改标题是否不改 slug，除非必须
- 改 slug 时是否同步 301
- Cloudflare 是否能按路径查到异常访问
- 404 页面是否有搜索和核心入口

这些动作都不复杂，但它们决定了一个个人网站到底是在堆文件，还是在堆资产。

继续阅读

• Web Builder Log：个人网站、Astro、Cloudflare 与 Search Console 复盘
• 个人网站写到 160 篇，我才发现没流量的原因
• Search Console 有曝光没点击，我才发现问题不在收录，而在标题和入口
• SEO 自动化实战：构建可审计的索引与增长流水线
• XBSTACK V3 重构日志
• Cloudflare Serverless 实战：构建零成本、全球加速的 AI 全栈架构
• AI 开发总入口：Agent、LangGraph、MCP 与 Workflow 的系统索引

404 最可怕的地方，不是页面不存在。

是我以为网站没人来，其实人来过，只是撞墙走了。

对个人网站来说，404 排查不是运维洁癖，而是在把漏掉的流量一条条捡回来。