一間開了多年的店換了地址，原本的店面拆了招牌，卻沒有在原地留下任何指引。常客照著舊地址走過去，只看到一片空地，愣在原地幾秒鐘，多半轉身就走，不會特地繞去打聽新址搬到哪裡。
網站的 404 頁面，做的正是這種「搬家沒留指標」的數位版。訪客點進一個曾經存在的網址，等到的卻是一片找不到內容的空白頁。WordPress 404 頁面設定要處理的，其實是連在一起的三件事：先抓出網站上正在發生的 404、把舊網址接到對的新去處，剩下真的接不到合適位置的，才輪到把 404 頁面本身做成一個留得住訪客的畫面。
先從網站為什麼會冒出 404 講起，再一項一項往下拆。
WordPress 網站為什麼會冒出 404 錯誤？
打開一個網址，瀏覽器等到的答案不只是「有」或「沒有」，而是一組三位數的狀態碼。200 代表順利拿到內容，404 則代表伺服器在自己的資源清單裡找了一輪，就是沒有這個網址對應的頁面。它是 HTTP 通訊協定裡的標準用語，不是 WordPress 專屬的錯誤，任何一種架站方式都會遇到。
這類三位數狀態碼裡，4 開頭的一整組屬於「用戶端錯誤」，代表問題出在請求的這個網址本身，不是伺服器那一端故障。Google 的搜尋說明文件把 404 歸在這一類，並指出搜尋引擎不會使用回傳 4xx 狀態碼的網址內容；已經收錄進索引的網址，如果後來開始回傳 4xx，也會被從索引中移除。
在 WordPress 網站上，404 最常見的幾個來源不脫這幾種：文章或頁面被刪除，或是搬移到別的網址；固定連結（permalink）結構整個改版，例如把網址從帶著日期的格式換成純文章名稱；使用者輸入網址時不小心打錯字；外部連結，像是其他平台的連結、書籤或搜尋結果，指向的是網站上早已經不存在的舊網址。
這些情況大多不是網站故障，而是網站在成長、調整過程裡本來就會發生的正常現象。內容搬過家、結構改過版，舊路標留在外面沒跟著更新，才會冒出 404。問題不在於它會不會發生，而在於發生之後放著不理，會讓網站付出什麼代價。
放著 404 不管，網站會流失什麼？
先看得到的那一面。訪客點進一個失效連結，大多數人不會停下來猜「這個網站是不是在維護」，而是直接按上一頁或關掉分頁。你損失的不只這一次瀏覽，還包含原本可能留下來看內容、甚至下單或填表單的機會。
再看你看不到的那一面。Google 檢索器如果持續在某個網址上碰到 4xx 回應，不只當下不會使用這個網址的內容，連原本已經收錄的紀錄也會被剔除；相對地，如果你把這個網址做成 301（永久轉址）接到新的目標，Google 會直接跟著轉址走，並把 301 當成一個強訊號，判定新網址才是真正該保留的那一個。302（暫時轉址）雖然也會被跟著走，訊號卻弱得多，如果你其實是要永久搬家卻用了 302，Google 判斷「這個新網址值得取代舊網址」的力道就會打折。
這幾種流失多半救得回來，只要先盤點清楚哪些網址在跳 404、再把該接的接上；放著不理，才是真正在浪費原本累積的流量與排名。
作法一：先抓出網站上正在流失的 404 頁面
動手設定任何一筆轉址之前，第一步不是打開外掛，而是先搞清楚網站上有哪些網址正在跳 404、有沒有真人在點。免費就能拿到這份清單的管道主要有兩個：Google Search Console 的網頁報表，以及裝在後台的轉址外掛自己內建的 404 記錄日誌。兩者角度不同，搭配著看會比只看一個更準。
但盤點回來的清單，不代表每一筆都要動手轉址；哪些值得處理、哪些放著就好，值得先講清楚判斷的準則。
Google Search Console 怎麼看出哪些網頁變成了 404？
實際查找的路徑不複雜。進到 Search Console，點開「網頁」報表，畫面會先分成「已建立索引」和「未建立索引」兩大類，404 的紀錄歸在「未建立索引」底下的「找不到（404）」這個項目裡，逐筆點開對應的網址檢查。
要留意的是，這份清單是 Google 檢索器實際爬到、回報回來的結果，免費好用，卻不是即時資料。網址已經修好了，清單上還是會殘留一段時間才更新，別看到清單還在就以為轉址沒生效。
轉址外掛內建的 404 記錄日誌，能多看到比 GSC 更即時的細節
轉址外掛自己記的日誌，補的正是 Search Console 那份清單比較弱的地方，也就是即時性。以 404 to 301 這款外掛為例，它的說明頁面寫著，每一筆 404 都會記下請求的網址、來源頁面（referrer）、IP 位址、瀏覽器（user agent）與時間戳；同一個網址被重複踩到，會自動去重計數成一列，不會變成上千筆難以整理的紀錄，還可以設定命中門檻，超過就寄一封提醒信到信箱。
這代表你隨時能看到，有沒有真人在這一刻還在點某個失效連結，比起等 Google 回報結果更貼近網站現在的狀況，適合拿來判斷一筆 404 是不是還在持續流失訪客。
哪些 404 該轉址，哪些放著就好？
清單抓出來之後，真正要花時間判斷的在這一步。原本是網站的主力頁面，例如流量長期偏高的文章或商品頁，一旦跳 404 幾乎一定要轉址；還有外部連結持續導來流量的網址，來自別的網站、書籤、社群貼文的連結，即使內容已經下架，也值得把訪客導去相關度最高的新頁面。
至於單純是使用者自己打錯字，或是本來就刻意下架、長期沒人再造訪的網址，放著不處理也沒關係。硬要把這種網址轉到一個內容其實對不上的頁面，只會製造後面會談到的另一種問題，也就是 soft 404。
作法二：用轉址外掛，把舊網址接到對的新網址
確定了哪些 404 值得處理之後，接下來是實際動手把舊網址接到新網址。這一段以 WordPress 生態圈裡最多人裝、完全免費的 Redirection 外掛示範畫面與欄位名稱，核心概念放到其他轉址外掛也通用：填「來源網址」（舊的）、填「目標網址」（新的）、選對轉址類型，301 代表永久搬移，新增之後回頭實際測一次是不是真的接得上。
轉址外掛內建功能夠用，就不必再裝新的
裝新外掛之前，先看看手上現有的 SEO 外掛本身有沒有附帶轉址管理功能。不少 SEO 外掛在固定連結重新導向這件事上已經內建基本功能，夠用就先用，不必為了一個轉址功能再多裝一款外掛，拖累後台效能。
如果現有外掛沒有這個功能，或是你需要更完整的 404 記錄日誌、正則表達式批次比對這類進階功能，再另外裝一款專門做轉址的外掛。Redirection 的說明頁面寫明，這是一款完全免費、沒有付費版本、已經維護超過十年的外掛，相容 PHP 7.4 到 8.4，不必擔心裝了之後功能受限，或哪天得付費才能繼續用。
設定一筆來源網址對應目標網址的轉址，總共要按幾步？
以下步驟示範最基本的一筆轉址怎麼設定：
- 安裝並啟用外掛，跑完第一次啟用時的初次設定精靈
- 進到後台「工具」底下的轉址設定頁面
- 在「來源網址」欄填入已經失效的舊網址
- 在「目標網址」欄填入這個網址現在該接到的新網址
- 轉址類型選擇 301（永久轉址）
- 點擊新增，讓這筆規則生效
- 回到瀏覽器，直接輸入舊網址測試，確認畫面有沒有實際跳轉到新頁面
每一步都在後台介面裡就能完成，不需要碰任何伺服器設定檔，也不需要寫一行程式碼。
整批網址搬家，用規則一次轉完，不必逐筆設定
如果只是零星幾筆網址失效，一筆一筆填是最快的做法；但遇到整個目錄搬家、或是固定連結結構整套換掉這種大規模場景，一筆一筆手動輸入會沒完沒了。
這時候可以改用正則表達式或萬用字元比對，一次設定一條規則，把整個舊目錄底下所有網址，都對應轉到新目錄下相同的路徑，還可以連查詢參數一併傳遞到目標網址，不會漏掉網址後面帶的追蹤參數或篩選條件。這種做法特別適合網站改版、或是更換固定連結結構這種一次牽動大量網址的場景。
文章網址改掉，轉址外掛能自動幫你補上
WordPress 本身常見的一種 404 來源，是編輯文章時把網址（固定連結）本身改掉，例如把標題重新下過，連帶讓網址跟著變動。Redirection 可以設定監控文章與頁面的固定連結異動，一旦偵測到有網址被改掉，就自動幫你補上一筆轉址，不必自己記得每次改網址都要手動加規則。
不過自動產生的轉址，還是建議事後回頭看一次清單，確認目標網址真的接對地方。自動化省的是手動輸入的力氣，不是省掉最後那一次檢查。
作法三：接不到合適頁面時，把 404 頁面本身做好
前面兩個作法解決得了大多數情況，但總有一部分 404 找不到剛好對應的轉址目標——內容真的已經下架，或是這個網址本來就沒有可以替代的頁面。這種情況與其硬把訪客轉到一個內容對不上的頁面，不如把 404 頁面本身做成一個還留得住人的頁面，接下來拆兩件事：頁面內容該放什麼、WordPress 又要怎麼實際去改這個樣板。
一個稱職的 404 頁面，該放哪些內容？
一個稱職的 404 頁面該做到的事其實很單純，就是不要讓訪客覺得自己被丟包在一個完全陌生的地方。至少要清楚告知這裡目前沒有內容、維持跟網站其他頁面一致的風格與導覽列，不要讓訪客感覺自己跳出到另一個完全不相干的網站；再放一個搜尋框，或列出幾篇熱門文章的連結，讓訪客有路可以繼續走，而不是直接關掉分頁離開。
拿一個賣手作商品的網路商店來說，404 頁面除了寫清楚「這個網址目前沒有對應的商品」，底下放上熱銷分類的連結，或是直接嵌入一個搜尋框，訪客通常還是願意留在網站上，不會直接放棄。
這裡有一件容易被忽略的事得提醒。頁面做得再貼心，伺服器端還是得老實回傳 404 狀態碼，不能因為畫面做得漂亮，就順手把它改回 200（成功）這種回應。頁面設計是給訪客看的，狀態碼是給搜尋引擎看的，兩件事要同時做對。
WordPress 區塊編輯器怎麼修改 404 樣板？
如果你的網站用的是區塊主題，支援全站編輯，修改路徑在後台「外觀」底下的「編輯器」。進到樣板清單，找到 404 樣板，點擊畫面上想調整的元素，就會直接進入區塊編輯畫面，可以調整文字內容、版面配置，或插入新的區塊，像是前面提到的搜尋框，改完點擊發布就會生效。
如果目前用的佈景主題不是區塊主題，沒有全站編輯功能，也可以改用視覺化頁面編輯的外掛，一樣能達到類似的效果，兩條路殊途同歸，差別只在操作介面。
為什麼不能把 404 全部導到首頁？
把所有 404 一律轉址到首頁，聽起來是最省事的做法，反正首頁一定存在，不會又跳出一個 404。
但對一個內容跟首頁完全不相關的搜尋來說，這種做法反而會製造前面提過的 soft 404。伺服器等於是用一個「內容不對」的頁面，回應了一個表示成功的狀態碼，讓 Google 誤判這個網址其實還存在、內容也沒問題，持續浪費檢索資源去爬一個實際上文不對題的頁面，也可能拖累網站上其他頁面被有效檢索的效率。
這也是為什麼前面提到，該轉址的才轉、接不到才留給自訂 404 頁面處理。把首頁當成萬用轉址目標，看似解決了問題，實際上只是換了一種方式讓問題繼續存在。
裝好轉址外掛、改完 404 樣板，不代表這件事就一勞永逸。網站只要持續在更新內容、調整結構，新的失效連結就會不斷冒出來，404 處理更像是網站維運裡的一項例行公事，而不是做一次就結束的專案。
固定抓一段時間，例如每個月，回頭看一次轉址外掛的日誌與 Search Console 的網頁報表，把新冒出來的失效連結抓出來，判斷該轉址還是留給 404 頁面接住。養成這個習慣之後，這件事只會越做越快，不再是每次都要從頭盤點一次的大工程。