很多站点在服務器返回 200 的情况下，頁面其實是空的：站内搜尋没有结果、商品已经下架、分頁翻過头、标簽下没有任何内容。這類地址在訪問日誌里和正常頁面長得一样，狀態碼正常、响應体也不算小，但它對搜尋蜘蛛来说是一條死胡同。數量积累起来，抓取频次會被大量無效入口分走，真正需要更新的頁面反而等不到回訪。
软 404 的常见形態
先明确一点：软 404 不是指服務器配错了，而是指頁面在业務上已经没有内容，但依然以 200 返回。常见的几種：
- 站内搜尋無结果頁，URL 带查询參數，仍返回完整模板
- 商品或文章下架後，詳情模板保留，正文区域為空
- 分頁超出實际范围，如 page=99 返回空列表
- 篩選條件组合没有命中，只渲染出篩選條和一句提示
- 标簽、分類未绑定任何内容，只剩标题和一段說明文字
- 活動結束後頁面未下线，只留下已過期的文案框架
為什么它在抓取层面是负担
從 URL 發現的角度看，這些地址並不缺曝光：它們大多来自站内搜尋框、篩選组件、分頁連結和标簽云，連結位置還往往比較靠近首頁。搜尋蜘蛛顺着這些入口抓過去，拿到的是一個没有獨特内容、也没有下一跳有效連結的頁面。结果有三层损耗：
- 抓取频次被摊薄，同样的配額要分给更多低價值地址
- 内鏈结构失真，大量空壳地址與正常頁面混在一起，路径层級看起来變深了
- 判断依據被污染，做入口梳理时，很难一眼分清哪些地址是真正有内容的
更麻烦的是，很多软 404 是由參數组合生成的，理论上可以無限扩展，一個篩選组件就能产出成百上千個變体。
排查顺序建议
- 先從訪問日誌抽样。筛出狀態碼為 200、但响應体長度明顯偏小、或大量 URL 正文高度相似的记錄。响應体字节數是很好的第一個筛子，比人工点開頁面快得多。
- 核對模板與判断逻辑。找到對應的頁面模板，看它在資料為空时會走到哪個分支，是否只是渲染了空容器而没有做狀態處理。
- 检查邊界场景。分頁的最後一頁往後、篩選的极端组合、已刪除對象的歷史 URL，這几類要單獨测一遍，它們往往是软 404 的主要来源。
- 区分服務端與前端渲染。有些頁面服務端返回的是空壳，内容靠脚本补；如果脚本拿不到資料，最终呈現就是空白。這類需要從原始 HTML 层面確認，而不是看浏览器截图。
- 確認規范化與索引指令。同一個空狀態頁如果還带着 self canonical，等于在向搜尋引擎確認這就是正式版本，處理时要一並調整。
處理策略怎么選
處理方式取决于這個地址未来還會不會有内容：
- 确定不再有内容：直接返回 404，必要时用 410。比返回 200 空頁更清晰。
- 暂时無内容但會恢复：可以返回 404 或保留頁面但收敛入口，不建议長期挂着空頁。
- 參數组合生成的空頁：從源头收敛，比如限制篩選组合的可抓取范围，或對無结果狀態不輸出可抓連結。
- 确實有少量内容但重复度高：優先考虑合並到上一級頁面，而不是保留獨立地址。
用 noindex 處理软 404 是一種折中，但它並不等于問题消失：地址仍然會被發現、被抓取，只是不再進入索引。如果目标是减少無效抓取，404 通常比 noindex 更直接。
處理後的观察方式
改完之後不要只看一次日誌。可以按周對比三件事：同一路径下的 200 响應數量是否下降、404 數量是否相應上升、以及有内容的頁面回訪間隔有没有缩短。同时检查 Sitemap 和内鏈中是否還残留這些地址——如果入口還在，抓取請求就不會停。
另外可以留意服務器错誤率的變化。把空狀態頁改成 404 之後，如果 404 占比短期明顯上升，属于预期内現象，重点是確認它不是由新的路径規則错誤引起的。