UCAMC
← 回到 Blog
WordPress約 3 分鐘閱讀

WordPress 固定連結 404 排查紀錄：從 rewrite rules、快取到 301 留下證據

Updated 2026/08/24Leon
分類WordPress網站經營SEO
標籤#WordPress#固定連結#404#rewrite rules#SEO#維護紀錄
WordPress 固定連結 404 排查 cover，顯示文章 URL、rewrite rules、curl header、301 轉址與 200 OK 驗證流程

WordPress 文章已經發布，後台預覽也看得到，但正式網址卻回 404，是內容站常見又容易誤判的問題。它可能是固定連結設定、rewrite rules 沒刷新、快取/CDN 回舊頁、SEO 外掛轉址規則、語系或分類 slug 改動，也可能只是測錯了 URL。

我會把固定連結 404 當成一條路由證據鏈：先確認使用者拿到的是哪個網址，再確認文章狀態、canonical slug、rewrite rules、快取層與轉址規則。這樣可以避免一遇到 404 就亂按「儲存固定連結」、清全站快取或大量改 slug，最後反而讓 SEO 問題更難追。

先保存出問題的 URL 與回應狀態

第一步不是修改設定，而是把實際症狀記錄下來。尤其要分清楚：是單篇文章 404、整批文章 404、分類頁 404，還是舊網址沒有轉到新網址。

Permalink symptom record
- requested URL: https://example.com/sample-post/
- expected canonical: https://example.com/sample-post/
- response: 404
- affected scope: one post / all posts / category archive / old migrated URLs
- first seen: 2026-08-24 09:10 +08:00
- destructive action before record: none

同時用 curl 留下 status、content-type 與 cache header，比只看瀏覽器畫面更可靠：

curl -I https://example.com/sample-post/
curl -I https://example.com/wp-json/
curl -I https://example.com/sitemap.xml

如果 /wp-json/ 正常、首頁正常，通常不是整站掛掉；如果 sitemap 還列著文章 canonical，但文章頁 404，就要往 rewrite、快取或模板層排查。

確認文章狀態與 canonical slug，不要先改網址

很多 404 其實來自文章狀態或 slug 不一致。例如文章是 draft、private、排程未發布，或遷移時保留了舊 slug，但前台連結已改成新 slug。排查時可以用 WP-CLI 或後台資訊確認，不要直接改 canonical URL。

wp post list \
  --post_type=post \
  --post_status=publish,draft,private,future \
  --fields=ID,post_title,post_name,post_status \
  --format=table

wp post get 123 \
  --field=post_name

我會把觀察結果寫成一小段 evidence，而不是只說「後台看起來正常」：

Post status evidence
- post ID: 123
- post_name: sample-post
- post_status: publish
- sitemap URL: https://example.com/sample-post/
- frontend response: 404 before rewrite flush

這能保護 SEO：如果 canonical slug 原本正確，就不應該為了解決 404 而改成另一個網址。

Rewrite rules 要先觀察，再刷新

WordPress 固定連結依賴 rewrite rules。外掛啟停、custom post type、主機搬遷或 .htaccess/Nginx 設定變動後，rewrite rules 可能沒有正確更新。排查時可以先列出規則，再決定是否刷新。

wp rewrite list \
  --match=sample-post \
  --format=table

wp rewrite flush --hard

wp rewrite flush --hard 不是破壞性資料操作，但它會改寫 rewrite 設定或 .htaccess，所以我仍會把它記錄為 change record：

Rewrite change record
- before: sample-post route not matched in rewrite list
- action: wp rewrite flush --hard
- after: sample-post route matched post permalink rule
- verification: curl -I returns 200
- rollback: restore previous .htaccess / server rewrite config if needed

如果是 Nginx 或託管平台，.htaccess 不一定生效，這時要檢查主機層 rewrite，而不是重複刷新 WordPress 設定。

分開看快取、CDN 與轉址外掛

固定連結 404 也可能不是 WordPress 即時產生，而是快取層回舊頁。特別是文章剛發布、slug 剛調整、或從舊 WordPress 遷移到新架構時，CDN、頁面快取外掛與 SEO redirect 外掛都可能持有舊狀態。

curl -I https://example.com/sample-post/
curl -I 'https://example.com/sample-post/?cache-bust=20260824'
curl -I https://example.com/123-sample-post/

紀錄時我會把 header 分層，而不是只寫「清快取」：

Cache / redirect evidence
- canonical URL: /sample-post/ -> 404, x-cache: HIT
- cache-bust URL: /sample-post/?cache-bust=20260824 -> 200
- legacy URL: /123-sample-post/ -> 301 Location: /sample-post/
- redirect plugin: no matching manual rule found
- purge action: purge single URL, not full-site purge

如果 cache-bust URL 是 200，但正式 URL 是 404，優先處理 cache purge；如果 legacy URL 沒有 301，才去補轉址規則。

301 驗證要只針對舊網址，不要亂轉新網址

內容遷移時常見需求是把舊 ID-prefixed URL 轉到新 canonical，例如 /123-sample-post/ 到 /sample-post/。這種 301 是保護 SEO 的措施；但不要把所有看起來像錯的 URL 都轉到新網址，否則會掩蓋真正的 routing 問題。

curl -I https://example.com/123-sample-post/

# Expected
# HTTP/2 301
# location: /sample-post/

驗證紀錄至少要包含：舊 URL、目標 canonical、status code、Location header、以及 canonical 本身是否 200。如果只確認舊 URL 有轉址，但目標仍然 404，SEO 問題仍未解決。

我會用這份順序收斂問題

固定連結 404 的排查順序可以固定成 observe / change / verify：

  1. 保存出問題 URL、status、header 與畫面。
  2. 確認文章狀態、slug、sitemap 是否一致。
  3. 檢查 rewrite rules 與主機 rewrite 設定。
  4. 檢查快取/CDN 是否回舊頁。
  5. 檢查 SEO/redirect 外掛是否攔截。
  6. 只對舊網址補 301，canonical URL 本身要保持乾淨。
  7. 用同一組 curl -I、瀏覽器與 sitemap 再驗一次。

這份紀錄的重點不是把所有問題都歸咎於固定連結，而是讓每一次 404 都能被定位：到底是內容狀態、rewrite、快取、轉址還是使用者拿到錯誤 URL。對長期經營的技術 Blog 來說，保留這些證據，比快速按一次「儲存固定連結」更有價值。