站点运营

站点运营:404 与软 404 自查,别让空壳页面留在抓取路径上

内容下架、栏目合并、参数写错,都会在站内留下打不开的地址。本文区分硬 404 与软 404,梳理筛选无结果、临时维护、旧地址迁移等场景,给出可执行的自查清单和处理方式,让服务器状态码与页面内容保持一致,减少蜘蛛在空页面上的无谓回访。

站点运营

站点运营:404 与软 404 自查,别让空壳页面留在抓取路径上

站点跑久了,出现 404 是常态:文章下架、栏目合并、商品停售、外部链接写错,都会留下打不开的地址。真正需要运营操心的,不是“有没有 404”,而是这些 404 有没有被正确表达出来,以及有没有一批页面明明没有内容,却仍然返回 200,让抓取程序以为那里还有东西可看。

404 要解决的是“告诉对方这里没有”

当用户或搜索蜘蛛请求一个地址,服务器至少要给出明确态度:存在就返回 200,永久搬家就返回 301,确实没有就返回 404 或 410。含糊不清的后果是,蜘蛛会反复回来确认,把抓取时间花在一批永远不会出现内容的地址上。

先分清硬 404 与软 404

硬 404

服务器直接返回 404 状态码,页面里放一段友好的提示,再给出返回首页、站内搜索、相关栏目的入口。这是最干净的做法:状态码说明事实,页面内容负责把人留住。对于确认不再提供的页面,410 语义更明确,但不是必须。

软 404

软 404 指的是:页面实际上不存在,但服务器返回 200,页面上写一句“内容已删除”或“暂无相关结果”。对访问者来说区别不大,对搜索蜘蛛来说差别很大,它会把这个地址当成正常页面收下,然后一次次复查为什么内容始终是空的。常见形态包括:

  • 筛选或搜索无结果时,仍然渲染完整框架的空列表页;
  • 文章撤下后保留模板,只把正文换成一句提示,状态码仍是 200;
  • 单页应用路由没有命中,前端渲染出一个空白组件;
  • 参数错误或 ID 不存在时回落到首页内容,但 URL 和状态码都没变。

一份可以照着做的自查清单

不需要复杂工具,用浏览器开发者工具看响应头,或者用命令行把地址请求一遍就能查。重点覆盖这几类:

  • 已下架内容的原始 URL,确认返回的是 404 还是 200;
  • 栏目列表翻到超出范围的页码;
  • 站内搜索输入一个几乎没有结果的关键词;
  • 带错误参数或不存在 ID 的详情页;
  • 移动端与桌面端同一地址的状态码是否一致;
  • 404 提示页本身能否正常访问,有没有被 robots 规则误挡。

按情况分开处理

  1. 内容永久下线:返回 404 或 410,页面给出相关栏目和搜索入口,不要自动跳首页,那会引出另一类问题。
  2. 页面换了地址:用 301 指到新地址,尽量一步到位,别串成多级跳转。
  3. 筛选、排序、分页参数无效:让服务端识别出无效组合,返回 404,或重定向到不带参数的干净列表。
  4. 搜索无结果:可以返回 404,也可以正常返回 200 并明确标注无结果,关键是别让它看起来像一页有内容的页面。
  5. 临时维护:用 503 配合 Retry-After,不要用 404,免得把正常页面误判成不存在。

别把 404 当万能开关

反过来也有坑:为了“清理”而批量 404 掉仍有访问、仍有外部链接的页面,等于主动放弃已经积累的入口。改版或合并栏目时,先整理一份新旧地址对照表,能映射的做 301,确实没有对应内容的再走 404。

站内自己写错的链接、搜索索引里残留的旧地址,也要一并更新。否则蜘蛛会在一堆死胡同之间来回走,真正有价值的页面反而被排在后面。

把结果记下来,定期回看

建议按周看一次 404 的 TOP 地址:哪些是外部误链,可以联系对方或忽略;哪些是站内模板写错,需要开发修改;哪些是本该做 301 的旧地址,需要补规则。长期没人访问、也没人链接的,就让它安静地留在 404 就好,不必强行给它安排去处。