有些頁面在浏览器里顯示的是“没有找到”“该内容已下架”，但服務器返回的狀態碼却是 200。這類頁面通常被称為软 404。它不像硬 404 那样明确告诉搜尋引擎“這里没有内容”，反而會让抓取程序把一個空壳或错誤提示当作正常頁面處理。收錄核對时，這類頁面往往是最容易被忽略的一類。
软 404 為什么會被收進去
從抓取的角度看，狀態碼是判断頁面是否有效的第一道信号。返回 200 时，搜尋引擎會繼續讀取頁面内容；如果内容里又有可索引的文字、标题和内鏈，它就可能進入索引。至于頁面實际展示的是错誤提示，抓取程序不一定能像人一样立刻判断。
常见的软 404 来源包括：參數错誤但未做拦截的詳情頁、商品或文章下架後仍返回 200 的模板頁、地区限制或登入限制導致的空内容頁、JS 渲染失敗後只剩骨架的頁面，以及 CMS 預設生成的空白分類頁。
先判断這個 URL 應该是什么狀態
處理软 404 的第一步不是改代碼，而是先分類。不同性质的 URL，正确狀態並不一样。
- 内容永久移除：适合返回 404 或 410。410 表達更明确，但 404 同样能被识別，不必為了追求 410 而大動模板。
- 内容迁移到新地址：用 301 指向新 URL，並确保新舊頁面主题一致，不要跳到首頁或栏目頁。
- 暂时不可用：如果只是短期维護，返回 503 並带上重试時間，比返回 200 的错誤頁更合适。
- 頁面本身應该正常：那問题不在狀態碼，而在内容渲染或資料缺失，需要修复頁面本身。
识別软 404 的几個入口
不想靠猜，可以從几個地方交叉核對：
- 抓取日誌里返回 200、但响應体長度明顯偏短的 URL。
- 搜尋後台的软 404 报告，以及已编入索引但内容為空的頁面样本。
- 站内搜尋、篩選參數、排序參數生成的结果頁，尤其是無结果时仍返回 200 的頁面。
- 下架内容的列表頁和詳情頁，检查它們是否還保留着可索引的标题與正文。
把這些 URL 按模板归類，比逐個處理更高效。同一模板的問题，通常一次調整就能覆盖一批頁面。
處理顺序：先收内鏈，再改狀態碼
顺序弄反是常见問题。如果先改狀態碼，站内却還有大量連結指向這些 URL，抓取程序會反复回訪，索引移除也會被拖慢。比較稳妥的顺序是：
- 先從站点地图中移除這些 URL，避免繼續主動提交。
- 清理站内連結：導航、侧栏、相關推荐、列表頁里的入口，能去掉的去掉，能指向替代頁面的改為 301。
- 確認頁面确實没有保留價值後，再把返回狀態改為 404 或 410。
- 保留一段時間的日誌观察，確認回訪频次下降、狀態碼稳定。
- 如果頁面已经進入索引，等待搜尋引擎自然刷新；不要频繁在 noindex 與 404 之間来回切換。
两件容易弄反的事
一是把 noindex 和 404 叠加使用。頁面既然要返回 404，就不需要再挂 noindex；反過来，如果頁面還要保留给用戶訪問，只想让它登出索引，那就用 noindex，而不是返回错誤狀態碼。两種信号混在一起，會让抓取程序难以判断。
二是把 404 当成萬能清理工具。有些頁面只是内容暂时缺失，或者渲染依赖接口返回資料，直接改成 404 會把本可以恢复的頁面一起清掉。先確認頁面的真實意图，再决定狀態碼。
狀態碼是给抓取程序的第一层說明。頁面想表達什么，最好和狀態碼保持一致；不一致时，搜尋引擎只能按自己的規則去猜。
處理後的核對
調整完成後，可以定期抽查：抓取日誌中這些 URL 的返回碼是否稳定、站内是否還有指向它們的連結、站点地图是否已经清理干净、搜尋後台的软 404 數量是否在缓慢下降。收錄狀態的變化通常有延迟，短時間内反复修改反而會延長观察周期。
软 404 本身不是特別嚴重的問题，但它會持續占用抓取资源，也會让索引里混入没有實际内容的頁面。把它当成一次常規的 URL 清理工作来做，按模板归類、按顺序推進，比零散修补更省力。