打開 Google Search Console，看到「軟性 404」這個警告卻一臉茫然，是很多 WordPress 與 WooCommerce 站長共同的經驗。明明頁面點進去畫面好端端的，沒有跳出大大的「找不到頁面」，為什麼 Google 硬說它是 404？更麻煩的是，這些頁面常常是空分類、賣完的商品、或自動產生的標籤頁，刪也不是、留也不是。

軟性 404 不是伺服器真的回傳了 404，而是 Google 自己貼上的一張標籤。它代表「這頁回傳了 200 OK，但我判斷它其實沒有有效內容，所以當作不存在處理」。對 WordPress 與 WooCommerce 來說，這種狀況特別常見，因為這兩套系統會自動生出大量空殼頁面。這篇會帶你看清楚軟性 404 怎麼被判定、怎麼用工具確認狀態碼，並針對空分類、缺貨商品頁、空標籤頁、站內搜尋結果這幾種最常踩雷的情境，逐一給出該回 404、該回 410、該 301、還是該補內容的具體判斷。

軟性 404 到底是什麼，跟一般 404 差在哪

軟性 404 指的是頁面看起來像錯誤頁、或根本沒有實質內容，但伺服器卻回傳 200 OK 狀態碼的頁面。一般 404 是伺服器明確告訴瀏覽器與爬蟲「這個網址找不到對應資源」，回傳的是 404 Not Found；軟性 404 則是伺服器嘴上說「一切正常（200）」，但頁面實際呈現的是「查無資料」「沒有商品」「分類是空的」這類內容。

這個矛盾就是問題所在。Google 期待看到的結果（一個有內容的正常頁面）跟實際抓到的結果（一個空頁面）對不起來，於是它用機器學習分類器在算繪頁面之後判斷：這頁雖然回 200，但內容形同錯誤頁，索引它只是浪費資源。Google 便不把它收進索引，並在 Search Console 標記成軟性 404。

要記住一個關鍵差別。狀態碼是伺服器給的承諾，內容是頁面實際的樣子。一般 404 是「承諾」與「內容」一致（都說沒有），軟性 404 是兩者打架（承諾說有、內容說沒有）。Google 信的是內容，不是承諾，所以一旦判定矛盾，受傷的是你的網站。

為什麼 WordPress 跟 WooCommerce 特別容易產生軟性 404

WordPress 與 WooCommerce 容易出現軟性 404，是因為它們會依分類法（taxonomy）自動產生大量封存頁，而這些頁面在沒有內容時通常仍回傳 200。問題不在你刻意建了壞頁面，而在系統的預設行為。

最典型的例子是空標籤頁。在 WordPress 後台新增一個標籤、不掛任何文章，直接前往那個標籤頁，打開瀏覽器的開發者工具，你會看到頁面回傳 200 狀態，畫面卻顯示「找不到符合的內容」。這就是一個現成的軟性 404。分類頁、作者頁、日期封存頁同理，只要底下沒有文章，又沒有設定不索引，就是潛在的軟性 404 來源。

WooCommerce 把這個問題放得更大。它的商品分類、商品標籤、屬性頁（如尺寸、顏色）都會各自生成封存頁；商品下架、搬移、改分類之後，舊的分頁網址（例如某分類的第 3 頁）可能還活著但已經沒有商品；站內搜尋若有人搜了沒有結果的關鍵字，搜尋結果頁也常以 200 回傳一個空畫面。這些頁面數量可以非常可觀，是電商站軟性 404 的主要溫床。

軟性 404 對 SEO 的傷害主要不在「直接被懲罰」，而在拖垮檢索效率。Google 每次造訪你的網站都有檢索預算，當爬蟲一再撞上要算繪、分析、然後丟棄的空頁面，真正重要的新商品、新文章反而被延後抓取，收錄變慢、整體網站品質評價也會被拉低。

怎麼確認一個頁面是不是軟性 404

判斷軟性 404 的第一步，是把「畫面看起來怎樣」跟「伺服器實際回什麼狀態碼」分開檢查，因為兩者經常不一致。最快的方法有三種，由淺入深。

第一、用 Google Search Console 的網頁索引報表。報表裡會列出「提交的網址疑似為軟性 404」這類項目，點進去就能看到 Google 認定有問題的頁面清單。這是最權威的來源，因為標籤本來就是 Google 貼的。

第二、用瀏覽器直接驗狀態碼。打開該頁面，按 F12 開啟開發者工具，切到「Network（網路）」分頁，重新整理頁面，點選最上面那筆主文件請求，右側就會顯示 Status Code。如果畫面是「查無資料」但狀態碼寫著 200，那它就是軟性 404 的候選。

第三、用指令列工具批次驗。如果你能操作主機或本機終端機，用 curl 看標頭最乾淨俐落：

curl -I https://example.com/product-category/empty-cat/

回應裡的第一行會直接告訴你狀態碼，例如 HTTP/2 200 或 HTTP/2 404。想一次檢查很多網址，可以把網址列成清單逐一跑，或改用 Screaming Frog 這類爬蟲工具，在 Response Codes 分頁篩出狀態碼異常的頁面。盤點時的重點不是抓出一兩個，而是建立一份完整清單，分類之後再決定每一類怎麼處理。

空分類頁與空標籤頁該怎麼處理

空分類與空標籤頁的處理原則是先判斷它「未來還會不會有內容」，再決定要補內容、設定不索引、還是直接讓它回 404。把同一種招式套到所有空頁面，往往會做錯。

如果這個分類是網站架構的一環、未來會陸續放進商品或文章（例如剛開的新分類），那就不要刪、也不要回 404。正確做法是先補一段對使用者有用的內容（分類說明、相關分類連結、熱門商品推薦），讓它從「空殼」變成「有價值的入口頁」，Google 就不會再判它軟性 404。同時把相關文章或商品的內部連結指向它，補強這頁的存在意義。

如果這個分類或標籤只是測試、重複、或當初隨手建的，未來都不會有內容，那就讓它消失得乾淨。WordPress 後台直接刪除該分類法詞彙，前台網址自然會回 404；如果你確定它是「永久移除、不會再回來」，可以更進一步讓它回 410 Gone，語意上比 404 更明確地告訴 Google「這頁是我主動拿掉的，別再來抓」。Google 對 404 與 410 的處理結果其實相同（都會逐步移出索引），但大量清理時用 410 訊號更清楚。

還有一種常見情況是分類本身有用，但你不希望它進搜尋結果（例如內部用的篩選分類、屬性封存頁）。這時別讓它軟性 404，也別硬刪，而是用 Yoast SEO 或 Rank Math 之類的外掛把它設為 noindex，並從 sitemap 移除。這等於告訴 Google「這頁給使用者用，但不必收錄」，既保留功能又不污染索引。

整理成一個簡單的判斷邏輯：

缺貨與下架商品頁該怎麼判斷

缺貨商品頁不該動，下架商品頁才需要處理，這兩者最容易被搞混。關鍵在於分清楚「暫時缺貨」與「永久停售」，因為它們對 SEO 的處置完全相反。

暫時缺貨的商品，未來會補貨、會再賣，這頁絕對要保留並維持 200 OK，不要回 404、不要轉址、不要刪除。原因很實際，這頁可能已經累積了排名與外部連結，一旦讓它消失，等補貨回來時排名得重新養。WooCommerce 預設行為其實就是對的，缺貨商品頁照常顯示。你能做的是把這頁顧好，例如顯示「補貨中」「貨到通知我」的訂閱欄位、推薦同類其他商品，讓它在缺貨期間仍對使用者有價值。頁面只要還有商品描述、規格、圖片這些實質內容，Google 通常不會把它判成軟性 404。

永久停售、不會再進貨的商品，才需要主動處理，而處理方式取決於有沒有替代品。如果有性質相近的後繼商品（例如同型號的新版本），就用 301 永久轉址把舊商品頁導到新商品頁，把原本的排名與連結權重承接過去。這裡有個常被忽略的紅線：301 只能轉到「相似頁面」，把所有下架商品一律導回首頁或某個無關分類，Google 會判定為不相關轉址，反而當成軟性 404 處理，連權重都拿不回來。

如果這個停售商品根本沒有替代品，也不要硬轉。比較專業的做法是讓它回 404 或 410，清楚告訴搜尋引擎這個商品不存在了。同時把商品頁原本的內部連結（分類頁、推薦區、相關商品）改掉或移除，避免爬蟲與使用者一直撞到失效連結。若想多挽救一點流量，可以搭配一個設計良好的 404 頁面，提供搜尋框與熱門分類入口，讓使用者不至於迷路。

簡單收束這三種情況的判斷：暫時缺貨就維持頁面別動；永久停售有替代品就 301 到相似新品；永久停售沒替代品就回 404 或 410 並清掉內部連結。

空的站內搜尋結果與分頁網址怎麼收尾

站內搜尋的空結果頁與失效的分頁網址，是 WooCommerce 軟性 404 最隱形的兩個來源，因為它們通常不在你手動建立的頁面清單裡，卻會被爬蟲與使用者意外觸發。

站內搜尋結果頁的問題在於，當有人搜了一個查無結果的關鍵字，WordPress 多半仍以 200 回傳一個「找不到相關內容」的空頁，而這類網址（帶著搜尋參數）一旦被連到或被收錄，就是現成的軟性 404。處理方向是讓搜尋結果頁整類都不要進索引：用 SEO 外掛把搜尋結果封存設為 noindex，並確認它們不在 sitemap 裡。搜尋頁是給使用者即時用的功能頁，本來就沒有被收錄的必要，noindex 是這裡最乾淨的解法。

失效分頁網址則是電商特有的坑。WooCommerce 的商品分類會自動分頁，當你把某分類底下的商品移走或減少，原本存在的後段分頁（例如某分類的第 3 頁）可能還能被存取，但裡面已經沒有商品。理想狀況下這種空分頁應該回 404，但更友善的做法是偵測到「這是一個沒有內容的分類分頁」時，自動把使用者與爬蟲導回該分類的主頁。

實作上，可以在佈景主題的 functions.php（建議用子佈景主題，避免更新被覆蓋）掛 template_redirect 事件，當判定目前是符合分類分頁格式、但內容為空的請求時，從網址抓出分類代稱，確認該分類存在，再用 wp_safe_redirect 安全導回主分類頁。這個做法的好處是讓使用者落在有商品的頁面、也讓爬蟲不再浪費資源在空分頁上。提醒兩點：一是務必先確認分類本身真的存在再轉址，否則會把真正的 404 也吃掉；二是改 functions.php 前先備份，並在測試站驗證過再上線。

如果你不想碰程式碼，退而求其次的做法是用快取或重寫規則層級的工具，把已知的空分頁批次設定 301 到主分類；或至少確保這些空分頁回的是 404 而不是 200，先止血，避免它們被當成有效頁面索引。

從盤點到收尾，軟性 404 的處理該照什麼順序走

回到一開始的場景，Search Console 跳出軟性 404 警告時，最忌諱的就是急著「全部轉址」或「全部刪掉」。正確的節奏是先盤點、再分類、最後才依情境逐一收尾。先用網頁索引報表、curl、或爬蟲工具把所有疑似軟性 404 的網址抓成一份完整清單，再把它們歸成空分類、缺貨或下架商品、空搜尋頁、失效分頁這幾類，不同類用不同處置。

判斷的核心其實只有一句話可以記：內容還在只是換位置就 301；內容會回來（暫時缺貨）就維持 200 別動；內容永久消失且沒有替代就回 404 或 410；頁面要留給使用者用但不該被收錄就 noindex；空殼但有價值潛力的入口頁就補內容。把這條邏輯套進每一個網址，就不會在轉址與刪除之間亂做決定。

軟性 404 不是一次清完就結束的工作，它會隨著商品上下架、文章調整、活動結束持續產生。比較務實的習慣是每隔一段時間回 Search Console 檢查網頁索引報表，新冒出來的就趁早處理；上架新分類時順手補一段內容，下架商品時順手決定 301 還是 404。把這些動作變成日常維護的一部分，網站的檢索預算就能花在真正重要的頁面上，搜尋表現也才站得穩。