WordPress 預設 .htaccess 檔案：內容是什麼、如何還原

WordPress 預設的 .htaccess 檔案，是這套軟體寫入你網站根目錄下 .htaccess 的一小段 RewriteEngine 區塊，目的是讓像 /2026/10/文章名稱/ 這樣的固定連結能被正確解析，而不是出現 404。它看起來是這樣：

# BEGIN WordPress
<IfModule mod_rewrite.c>
RewriteEngine On
RewriteBase /
RewriteRule ^index\.php$ - [L]
RewriteCond %{REQUEST_FILENAME} !-f
RewriteCond %{REQUEST_FILENAME} !-d
RewriteRule . /index.php [L]
</IfModule>
# END WordPress

這是從 WordPress 官方關於 Apache HTTP Server 的指南，以及 HelpHub 上關於美觀固定連結的頁面所記載的重寫邏輯中，原樣轉錄的確切區塊。如果你的 RewriteBase 不是 /——例如因為 WordPress 安裝在某個子資料夾中——它會改為比對那個路徑，這同樣是正常情況，也是由 WordPress 自己產生的。

重點摘要

• WordPress 只在 Apache 與 LiteSpeed 上自動產生這個區塊，條件是檔案可寫入，且你儲存了設定 > 固定連結。
• 如果檔案缺失或損毀，除了首頁之外的所有固定連結都會回傳 404，因為沒有重寫規則時只能找到首頁。
• 你或外掛新增的任何內容都必須放在 # BEGIN WordPress 上方，絕不能放在標記內部——WordPress 每次儲存固定連結時都會覆寫兩個標記之間的全部內容。

需要用你真實的路徑再加上一些額外規則重新建立這個檔案？WordPress .htaccess 產生器能直接在瀏覽器中組出一份正確的檔案。

每一行在做什麼

RewriteEngine On 為這個目錄啟用 Apache 的 mod_rewrite 模組；沒有這一行，後面的內容全都不會生效。

RewriteBase / 告訴 Apache，重寫後的路徑是相對於網站根目錄的。WordPress 會依照網站實際所在位置來設定這個值——安裝在子資料夾時會得到 RewriteBase /blog/，而不是 /。

RewriteRule ^index\.php$ - [L] 是一條沒有實際效果的保護規則：如果請求本身就是 index.php，重寫就會停止，請求原樣通過。

兩行 RewriteCond 才是真正的邏輯所在。%{REQUEST_FILENAME} !-f 與 !-d 在問：「這個請求是不是既不對應真實檔案，也不對應真實目錄？」兩者都為真才會觸發最後那條規則——這樣一來，真實的圖片、CSS 檔案或上傳的 PDF 會被直接提供，永遠不會碰到 WordPress 的路由。

RewriteRule . /index.php [L] 才是讓固定連結真正運作的那條規則：通過前兩個條件的任何內容——也就是不是真實檔案或資料夾的東西——都會被送到 index.php，然後由 WordPress 自己的路由機制（WP_Query、重寫標籤）來決定這個 URL 實際對應哪篇文章、哪個頁面或哪個封存。

WordPress 什麼時候會重新建立這個檔案，什麼時候不能

每次你開啟設定 > 固定連結並點擊儲存變更時，即使畫面上什麼都沒變，WordPress 都會嘗試自己寫入 .htaccess。這個儲存動作會觸發 flush_rewrite_rules()，它會試圖以寫入模式開啟 .htaccess，並把目前的區塊插入標記之間。

在以下情況下，這個嘗試會悄悄失敗，使檔案處於缺失或過時的狀態：

• 檔案或其上層資料夾對執行 PHP 的使用者而言不可寫入。 在許多共享主機上，PHP 執行時所用的系統使用者，與透過 FTP 上傳檔案的使用者並不相同，所以在 FTP 客戶端裡看起來正常的權限，仍然可能阻止 WordPress 寫入。
• 你使用的是 nginx。 .htaccess 只是 Apache 與 LiteSpeed 專屬的機制（Apache 自己關於 AllowOverride 的文件就解釋了原因：nginx 沒有按目錄讀取、並在每次請求時重新讀取的設定檔）。nginx 上對應的做法，是在 server 區塊內寫一條 try_files 指令，而這只有擁有伺服器存取權限的人才能編輯；WordPress 永遠無法替你寫入這條指令。
• 主要 Apache 設定中，你網站所在目錄的 AllowOverride 被設為 None。 這正是決定 .htaccess 到底能不能覆寫任何設定的開關；Apache 的文件說得很明確：在 AllowOverride None 之下，「.htaccess 檔案會被完全忽略」——WordPress 可以寫出一份完美的檔案，但在這項設定被改到伺服器層級之前，它不會產生任何效果。
• 檔案被刪除了，或者原本就不存在，而儲存過程中又沒有觸發重新建立——最常見的原因是固定連結結構本來就沒變，所以 WordPress 沒有偵測到任何需要重寫的變動。

如何手動還原它

如果文章與頁面都出現 404，而首頁仍正常運作，這正是 .htaccess 缺失或損毀的典型特徵。分兩步解決。

1. 先試試一鍵修復。 在 WordPress 後台進入設定 > 固定連結，不更動任何內容，直接點擊儲存變更。如果檔案可寫入，光是這個動作就能重新建立它，問題就解決了。

2. 如果這樣無法解決，就手動建立檔案。 透過 FTP/SFTP 或主機商的檔案管理器連線，進入安裝 WordPress 的資料夾（包含 wp-config.php 的那個資料夾），檢查 .htaccess 是否存在——這是一個隱藏檔案，部分檔案管理器預設會隱藏它；記得開啟「顯示隱藏檔案」。

• 如果檔案不存在，就建立一個名稱恰好是 .htaccess 的新檔案（不是 .txt，點號前面什麼都不加）。
• 貼上上方給出的預設區塊，若 WordPress 安裝在子資料夾中，記得相應調整 RewriteBase。
• 儲存後重新載入一篇文章的固定連結，確認它能正常運作。

如果之後仍出現 404，原因就從「.htaccess 缺失」變成「.htaccess 被忽略了」——去問主機商 AllowOverride 的設定，因為一份正確的檔案放在被 Apache 指示忽略的目錄裡，表現會和根本沒有這個檔案一模一樣。

你自己的規則與 WordPress 區塊的關係

外掛或手動編輯可能會新增自己的規則——重新導向、防盜連、快取標頭等。這是一個與 WordPress 產生的區塊完全獨立、分開的區塊，兩者永遠不應該重疊：

# 你或某個外掛新增的規則 — 放在 WordPress 標記的上方
<FilesMatch "\.(jpg|jpeg|png|gif)$">
    # 範例：防盜連、快取規則等
</FilesMatch>

# BEGIN WordPress
<IfModule mod_rewrite.c>
RewriteEngine On
RewriteBase /
RewriteRule ^index\.php$ - [L]
RewriteCond %{REQUEST_FILENAME} !-f
RewriteCond %{REQUEST_FILENAME} !-d
RewriteRule . /index.php [L]
</IfModule>
# END WordPress

放在 # BEGIN WordPress 與 # END WordPress 之間的任何內容，都會在下一次有人儲存固定連結設定頁面時被悄悄刪除，因為 WordPress 把這整段都當成自己的地盤，會原樣整段重寫。這正是「我自己加的規則怎麼不見了」這類抱怨最常見的原因——規則從來不是被故意刪掉的，只是恰好放在了 WordPress 認為歸它所有的區塊裡。關於重新導向本身，可以參考正確設定的 WordPress .htaccess 重新導向規則，了解它們該放在哪裡，以及如何避免循環。

這同樣也是編輯檔案後立刻出現突發性 500 Internal Server Error 最常見的原因：從論壇貼文複製來的、為另一個 Apache 版本寫的規則（2.2 版的 Order/Deny 語法與 2.4 版的 Require 語法混用）會破壞整個檔案的解析，包括下方的 WordPress 區塊，導致整個網站全部掛掉——而不僅僅是你改動的那一部分。

預設區塊之外

預設區塊只負責固定連結的路由。如果你還想強化對敏感檔案的存取限制，或是新增那幾條真正能縮小攻擊面的 .htaccess 規則——例如阻擋在 /uploads 中執行 PHP、拒絕對 wp-config.php 的直接請求——可以參考真正有幫助的 WordPress .htaccess 安全規則。如果固定連結因為其他原因出現 404——固定連結結構設定錯誤、快取層提供了舊規則、子目錄中的多站點衝突——無法正常運作的 WordPress 固定連結則梳理了其他幾種原因。

常見問題

WordPress 預設的 .htaccess 檔案是什麼？ 它是 WordPress 寫在 # BEGIN WordPress 與 # END WordPress 之間的 RewriteEngine 區塊，目的是讓固定連結解析到 index.php，而不是出現 404。

WordPress 預設 .htaccess 的確切程式碼是什麼？ RewriteEngine On、RewriteBase /、一條針對 index.php 的放行規則、兩條檢查請求是否為真實檔案或目錄的條件，以及最後把其餘請求全部送到 index.php 的規則。完整區塊列在本指南開頭。

為什麼除了首頁，我的所有文章都顯示 404？ 首頁在沒有任何重寫規則的情況下也能被找到；而其他所有固定連結都需要這些規則。Apache 上 .htaccess 檔案缺失或損毀，恰好就會產生這種模式。

WordPress 會自動重新建立 .htaccess 嗎？ 只有在檔案可寫入時才會——重新儲存設定 > 固定連結會觸發這個過程。如果檔案不可寫入，或在不會自動產生它的主機上缺失，又或者 AllowOverride 被關閉了，WordPress 就無法替你修復，你必須手動建立或修正這個檔案。

為什麼 nginx 沒有 WordPress 的 .htaccess 檔案？ .htaccess 只能在 Apache 與 LiteSpeed 上生效。nginx 沒有按目錄設定的檔案，會完全忽略 .htaccess；相同的路由要寫成 nginx server 區塊中的一條 try_files 規則。

儲存固定連結之後，我的 .htaccess 為什麼壞掉了？ 某條自訂規則被放在了 # BEGIN WordPress / # END WordPress 標記內部，而不是上方，於是在下一次儲存固定連結時，WordPress 把那整段內容都覆寫掉了。

---

用免費的 WordPress .htaccess 產生器建立一份乾淨、正確的 .htaccess——預設固定連結區塊，加上你真正需要的任何安全或重新導向規則。