WordPress 404 與轉址管理，Redirection 規則整理、SEO 風險、常見錯誤排查
- 最後更新日期：
🚀 讀者專屬工具
立即開啟 →
在開始閱讀前，先用 AI 自動生成您的網站架構圖？
網站改版或搬家後，最常見的不是「流量突然掉」，而是你以為都轉好了，結果使用者還是一直撞到 404。更麻煩的是，WordPress 轉址如果規則寫錯，可能把 SEO 權重分散在轉址鏈裡，或做出軟 404，讓 Google 以為你在敷衍。
把轉址當成交通指揮就好理解了，路口指錯一次，車就會繞遠路，塞車，最後乾脆不來。本篇用偏實作的方式，整理狀態碼怎麼選，Redirection 外掛怎麼設，Regex 怎麼寫比較安全，最後給一套可以照做的排查流程。
先把狀態碼用對，404 才不會越修越糟
多數 404 不是「要不要轉」的問題，而是「該回什麼狀態碼」。狀態碼像對搜尋引擎的回覆口氣，口氣不對，後面做再多都會出現誤判。
| 狀態碼 | 什麼時候用 | 對 SEO 的含意 |
|---|---|---|
| 200 | 真有內容且正常顯示 | 可被索引與累積訊號 |
| 301 | 舊網址永久改到新網址 | 權重通常可傳遞，最常用 |
| 302 | 短期活動或暫時替代 | 可能不會把權重完全轉移 |
| 307 | 暫時轉址且保留方法(較嚴格) | 多用在技術情境 |
| 404 | 內容不存在或打錯 | 長期存在會浪費爬行資源 |
| 410 | 內容已刪除且不會回來 | 通常更快從索引移除 |
兩個容易踩雷的觀念要先釘死：第一，不要把大量 404 一律導向首頁，那常被判成軟 404，使用者也會覺得被騙。第二，刪除且確定沒有替代內容時，請用 410，不要硬轉到相近但不相關的文章。
常見情境可以用下表快速對照，先定策略再寫規則，比「看到 404 就加一條 301」更穩。
| 情境 | 建議做法 | 典型例子 |
|---|---|---|
| 改網址(同內容) | 301 舊到新，並更新內鏈 | /about-us 改成 /about/ |
| 合併兩篇內容 | 301 較弱頁到主頁 | 舊教學併入新版 |
| 刪文且無替代 | 回 410 | 過期活動頁 |
| 產品下架但有接替款 | 301 到接替款或分類頁(需相關) | A 型號下架換 B |
| 參數頁面亂噴 | 規則化保留必要參數，其餘正規化 | ?utm= 追蹤參數 |
| 媒體檔更名 | 301 舊檔到新檔，或修正引用來源 | PDF 改版 |
如果你需要快速確認 301/302 的差異與用途，可以參考這篇整理得很完整的 WordPress 301 重定向教學，但真正關鍵仍是「替代內容是否等價」。
外掛 vs 伺服器層，WordPress 轉址規則怎麼選才不會失控
轉址可以做在外掛，也可以做在伺服器層(.htaccess 或 Nginx)。選擇不是立場問題，是管理成本與風險控管。
| 方法 | 優點 | 缺點 | 適合誰 |
|---|---|---|---|
| 外掛(例如 Redirection) | 介面好管，有 404 與轉址 log，方便批次 | 規則太多可能增加 PHP 負擔 | 內容團隊與一般站長 |
| .htaccess(Apache) | 效能好，早期就攔截 | 規則錯會全站炸，回滾麻煩 | 有維運流程的團隊 |
| Nginx 設定檔 | 效能與可控性佳 | 需部署權限，語法不同 | 有後端與 DevOps |
| CDN/反向代理層 | 最快，適合全站導向 | 規則分散，容易跟原站衝突 | 有 Cloudflare 類配置經驗 |
以 2026 常見的 WordPress 6.4 以上環境來看，很多團隊會用 Redirection 先把規則「整理成可讀的清單」，再視流量與效能把高頻規則下放到伺服器層。Redirection 的官方資訊可見 Redirection 外掛頁面。
Redirection 操作要點與規則示例(含 Regex)
操作上建議先做三件事：建立群組(例如「改版 2026Q1」)、開啟 404 記錄、每條規則都寫清楚備註。你未來會感謝現在的自己。
一般 301 範例
來源：/old-page/
目標：/new-page/
狀態碼：301
Regex 範例(目錄搬家)
來源：^/blog/(.*)$
目標：/articles/$1
勾選：Regex
狀態碼：301
Regex 的注意事項很實際：
**加上 ^ 與 $**避免誤匹配，(.*) 也別亂用，遇到多層路徑常會把你不想轉的也吃掉。規則上線後，先用外掛的 log 看「命中次數」和「來源 URL」，再決定要不要收斂條件。
Apache 與 Nginx 等價規則(附註解)
以下用同一個「舊頁到新頁」示範，方便你對照。上線前請先在測試環境跑，並保留回滾方式。
Apache
.htaccess(301 單頁轉址)
RewriteEngine On(啟用重寫)
RewriteRule ^old-page/?$ /new-page/ [R=301,L](舊頁轉到新頁)
Nginx(301 單頁轉址)
location = /old-page/ {(精準匹配舊路徑)
return 301 /new-page/;(回傳 301)
}
如果你在 CDN 或反向代理後面，還要留意兩件事：第一，HTTPS 與 www/non-www 可能已在 CDN 做導向，你在原站再做一次就容易變成轉址鏈。第二，快取會讓你以為規則沒生效，所以每次改規則後要做對應的快取清除。
想了解外掛選用時該看哪些功能(像匯入匯出、條件式規則、記錄與批次處理)，可參考這篇偏整理向的 重定向外掛選用重點。
排錯手冊：從 GSC 404 清單到 curl 驗證，順便把 SEO 風險一起清掉
轉址管理最怕的不是缺規則，而是「規則造成新問題」。下面這些 SEO 風險，很多站都中過。
- 轉址鏈：A 轉 B，B 再轉 C，爬蟲和使用者都走冤枉路。修法是把 A 直接改轉 C，並清掉中間那條。
- 軟 404：回 200 但內容像不存在，或全部導首頁。修法是回真 404/410，或導到真正等價頁。
- 錯用 302：永久改址卻用 302，訊號可能不穩。修法是改 301，並檢查快取層是否覆寫。
- 全部導首頁：看似「沒有 404」其實是把問題藏起來。修法是按類型導向，無替代就 410。
- 參數清洗不當：把必要參數也洗掉，導致追蹤與功能壞掉。修法是保留必要參數，其他做正規化。
- 忽略 410：大量過期頁留著 404，拖很久才退出索引。修法是明確 410，並更新站點地圖。
可直接照做的排查流程(照順序跑)
- 從 GSC 匯出 404 清單，先分類(改版、刪文、參數、外部亂打)。
- 看伺服器日誌或 Redirection log，抓到真正的來源 URL 與 Referer，確認是內鏈造成，還是外站連結。
- 逐條檢查規則，特別是 Regex，確認沒有吃到不該吃的路徑，也沒有互相打架。
- 用 curl 驗證，至少檢查三件事：是否回對狀態碼，是否只有一次跳轉，最後落點是否 200。例：
curl -I https://example.com/old-page/ - 更新內鏈與站點地圖，內文、選單、麵包屑、站內搜尋頁都要改，別只靠轉址撐場。
- 在 GSC 重新提交與驗證修正，並在 1 到 2 週後回來看是否還有新增 404。
如果你的站規模大，或規則分散在外掛、Nginx、CDN 三個地方，建議把「轉址清單」集中成一份可追蹤的規格表。需要有人接手時，就不會變成考古工作。想把這套流程變成固定維運機制，也可以直接交給 WPTOOLBEAR 協助做改版轉址盤點、規則落地與監控，避免流量在你看不到的地方慢慢漏掉。
結語：轉址不是補洞，是內容與結構的承諾
轉址做得好，使用者不會發現你改過網址，搜尋引擎也能把累積的訊號接續到新頁。轉址做得差，網站就像路標亂貼的商場，人會迷路，爬蟲也會降低信任。把狀態碼用對，規則寫得可回滾，再用 log 與 curl 驗證，WordPress 轉址就能從救火變成可控的日常。
要點摘要
- 301 用在永久改址，刪文無替代時用 410，比硬轉更乾淨。
- 別用「全部導首頁」掩蓋 404，容易變軟 404，體驗也差。
- Redirection 適合先整理規則與看 log，高頻規則可下放到伺服器層。
- Regex 一定要加錨點並縮小匹配範圍，上線後看命中紀錄再調整。
- 排查要走完 GSC 清單、log、規則、curl、內鏈與站點地圖，最後再提交驗證。
你可以立刻做的 5 件事
- 把 GSC 的 404 匯出，先挑流量最高的 20 條處理。
- 盤點「被刪除且無替代」的頁面，改回 410，不要亂轉。
- 把轉址鏈抓出來，改成一步到位的 301。
- 用
curl -I抽查 10 條新規則，確認狀態碼與跳轉次數。 - 把站內選單與熱門文章內鏈更新到新網址，減少靠轉址硬撐的比例。
