站内頁面被刪除、商品下架、栏目合並之後，很多站点只處理了“頁面看不到”這一层，却没有處理“服務器告诉蜘蛛什么”這一层。结果就是頁面對用戶顯示找不到内容，HTTP 狀態碼却依然是 200。這種頁面在搜尋引擎眼里是正常可抓取的頁面，只是内容空洞——也就是常说的软 404。
狀態碼是给机器看的說明书
用戶看到的是頁面，爬虫先看到的是响應头。狀態碼不统一，後面的抓取、去重、索引判断都會跟着偏。
- 200：内容正常，用戶和蜘蛛看到的是同一份有效内容。
- 301：内容永久搬家，新地址明确且唯一。
- 302 / 307：临时跳轉，适合活動頁或短期調整。
- 404：内容不存在，且没有合适的替代地址。
- 410：内容已永久刪除，明确告知不必再来。
- 403 / 401：訪問受限，常用于登入後或付費可见的内容。
- 500 / 503：服務端異常或暂时不可用，503 建议配合 Retry-After 使用。
软 404 常见的几種来源
内容下架了，模板還在
商品刪除、文章下线後只從列表里移除，詳情頁模板仍會渲染出一個空壳，狀態碼依舊是 200。這類地址數量往往很多，且會随着時間不断累积。
空列表頁與空詳情頁
某個标簽、某個分類下暂时没有内容时，頁面上只剩标题和“暂無資料”，但狀態碼正常。對用戶来说是空狀態，對爬虫来说是一個内容极薄的有效頁面。
搜尋無结果頁與篩選空頁
站内搜尋、多條件篩選在無匹配结果时，如果统一返回 200，很容易被大量參數组合放大成成千上萬個薄頁面。
服務器把错誤頁重寫成 200
部分配置為了“友好错誤提示”，把 404 頁面通過内部重寫返回成 200，浏览器看起来一切正常，响應头已经在说谎。
單頁應用的前端路由
前端路由接管後，服務端對所有路径都返回 200 和同一個入口文件，實际的内容是否存在只有脚本执行後才知道。
怎么自查
- 命令行看响應头：對目标地址执行 curl -I，第一行的狀態碼才是重点，不要只看頁面里寫了什么。
- 浏览器開發者工具的 Network 面板，勾選保留日誌，確認看到的是服務端返回碼，而不是前端渲染後的结果。
- 日誌分析：篩選狀態碼分布，看 404、410 是否集中在某些目錄或參數下，是否存在大量 200 的空頁面請求。
- 清單比對：把已下线的 URL 清單和真實返回碼做一次對照，逐一確認是 301、404 還是仍然 200。
- 抽查歷史地址：随机取几十個半年前存在、現在可能已失效的地址，看它們今天返回什么。
治理时的顺序建议
- 先把頁面分類：有明确替代内容的做 301，一次跳轉到位，不要串成長鏈條。
- 彻底刪除且没有替代的返回 404；確認不會再有同類内容的，可以考虑 410。
- 空資料頁要么改為 404，要么给出有效的推荐内容並保留 200，但不要两套逻辑互相打架。
- 清理站内入口：相關栏目、導航、正文内鏈里的失效連結一並去掉，別让蜘蛛顺着舊入口反复撞墙。
- 维護期使用 503 並附带 Retry-After，不要用返回 200 的“维護中”頁面。
- 改完之後再跑一遍抽查，確認狀態碼與頁面内容已经一致。
几個容易踩的坑
- 把 404 頁面 302 到首頁，會让所有失效地址都指向同一個入口，容易形成大量重复路径。
- 404 頁面返回 200，等于把死鏈当成正常頁長期保留在站内。
- 同一個地址今天 404、明天 200，反复横跳會消耗爬虫對站点的耐心。
- 測試域名或調试參數混進正式环境，狀態碼正常，但内容本不该對外出現。
- 用 200 處理所有異常，监控报表看上去很健康，問题却全部藏在内容层。
狀態碼不是给用戶看的装饰，而是站点與爬虫之間的约定。约定越清晰，後續的结构調整和内容下线才越容易收尾。
建议先在团队内部固定一套規則：什么情况用 301，什么情况用 404，什么情况用 410，维護期统一用什么狀態碼。規則寫下来之後，模板改動、内容下架、服務器配置調整才有统一的判断依據，而不是每個開發各按习惯處理。