WordPress 的 .htaccess 檔案將永久連結路由、固定主機 HTTPS 重新導向，以及伺服器層級的開關（例如停用目錄列表）合併在同一個 document-root 檔案中，而正確建立它的方式是將新規則合併進既有的 WordPress 區塊，而不是整個取代它。WordPress 只會在你第一次在「設定 → 永久連結」畫面點選「儲存變更」時寫入預設的 front-controller 規則，因此全新安裝的 WordPress 經常根本看不到可見的 .htaccess，或是檔案中除了註解標頭之外什麼都沒有。手動編輯這個檔案風險很高，因為單一規則放錯位置就可能讓所有永久連結離線、破壞安全性外掛的 hardening 區塊，或將重新導向迴圈送進 CDN 邊緣。Htaccess Generator 會產生一個刻意精簡的 Apache 2.4 檔案，僅處理三項 document-root 工作 — 固定主機的 HTTPS 標準化、選擇性的 Options -Indexes 行，以及選擇性的本地 ErrorDocument 路徑 — 並保持檔案其他部分完全不變。當作為合併來源而非全面取代來使用時，這個工具能為 WordPress 網站擁有者提供一組可稽核的規則，讓他們在上線前能逐行檢視。

how to create htaccess file in wordpress
how to create htaccess file in wordpress

為什麼 WordPress 使用者會尋求自訂 .htaccess

WordPress 是一個由 Apache 或 Nginx 服務的 PHP 應用程式，但其永久連結系統仰賴 mod_rewrite 將 /about/ 和 /2024/01/post/ 這類路徑的請求重寫為 index.php 的查詢字串。CMS 將這些規則保存在 .htaccess 頂端的一個 # BEGIN WordPress ... # END WordPress 區塊中，並在每次儲存永久連結時重寫該區塊。因此，全新的 WordPress 安裝在大多數 FTP 和檔案管理員用戶端中預設看不到 .htaccess，因為以點開頭的檔案預設是隱藏的。第一次有人進入「設定 → 永久連結」並點選儲存時，WordPress 才會寫入 front-controller 規則，檔案也才會變得可見。

一旦這個骨架存在，WordPress 網站擁有者仍然需要一個地方來放置不屬於 WordPress 管理區塊的規則：強制單一標準主機名稱使用 HTTPS、停用 /wp-content/uploads/ 的目錄列表，或從 /404.php 提供自訂樣式的 404 頁面，而不是 Apache 預設的純文字頁面。這些是伺服器層級的考量，而非 PHP 層級，因此它們應該放在同一個 .htaccess 中，而不是放在 wp-config.php 或 mu-plugin 中。快取、安全性和 SEO 外掛經常會在檔案更下方加入它們自己的 BEGIN/END 區塊，這就是為什麼任何編輯都必須是合併而非取代整份文件。

Htaccess Generator 實際產生的內容

這個產生器圍繞三項精簡功能打造，並拒絕進一步擴充。它接受一組無認證、不需密碼的公開網域來源，例如 https://www.example.com — 不含連接埠、路徑、查詢字串、片段或認證資訊 — 並產生一個包含三個選擇性區段的 Apache 2.4 檔案：

區段產生的指令Apache 需求
固定主機 HTTPS 重新導向RewriteEngine On、對 %{HTTPS} 與 %{HTTP_HOST} 進行跳脫的 RewriteCond，單一 RewriteRule 含 R=301,Lmod_rewrite、mod_ssl、AllowOverride 包含 FileInfo
停用目錄列表Options -IndexesAllowOverride 包含 Options
本地自訂 404 路徑ErrorDocument 404 /404.htmlFileInfo 覆寫；目標檔案必須存在於磁碟上

重新導向區塊會在負向 HTTP_HOST 條件中對主機名稱的點進行跳脫，並將目的地寫成單一固定的字面值字串，因此它不會像通用的 RedirectMatch 模式那樣回傳 Host 標頭值。R=301 旗標告訴瀏覽器和搜尋引擎，標準的 HTTPS 位置應永久取代舊位置，而 REQUEST_URI 則會由 RewriteRule 自動保留。Options -Indexes 行要求 Apache 在沒有 index 資源時不要產生目錄列表，而 ErrorDocument 規則僅接受以斜線開頭的本地 URL 路徑。外部 404 URL 和空白字元會在輸入階段就被拒絕。

產生器「不會」做的事情同樣重要：它不會偵測 Apache、讀取 AllowOverride、驗證憑證覆蓋範圍、檢查已啟用的模組，或在線上伺服器上執行 apachectl -t。它不會合成 WordPress 自己的 front-controller 區塊、不會寫入快取標頭、不會鎖定 wp-admin，也不會透過 API 代理組態變更。預期的工作流程是產生這三個區段，然後將它們與 WordPress、佈景主題和外掛所需的內容合併。

如何使用 Htaccess Generator 建立檔案

  1. 開啟 Htaccess Generator，並輸入網站應該存在的精確標準來源，例如 https://www.example.com。不要加上路徑、連接埠或查詢字串。
  2. 只有當你的主機允許在 .htaccess 中使用 Options 指令時，才勾選「停用目錄列表」。如果不確定，請將其關閉，並在啟用前詢問你的主機商。
  3. 勾選「本地自訂 404」，並提供一個以斜線開頭的本地路徑，例如 /404.php，指向你已上傳到 document root 的檔案。
  4. 產生檔案並複製或下載輸出結果。逐行閱讀：rewrite 區塊應僅包含一個 RewriteRule，而 error 指令應指向你控制的路徑。
  5. 備份既有的 WordPress .htaccess。在 cPanel、FileZilla 或 SSH 中，在進行任何變更之前，將目前的檔案複製為 htaccess-backup-YYYY-MM-DD.txt。
  6. 將產生的區段合併進既有的檔案，而不是取代它。將 HTTPS 重新導向區塊放在 # BEGIN WordPress 之上、Options -Indexes 行緊接其後，並將 ErrorDocument 規則放在接近檔案底部。
  7. 將合併後的檔案上傳到網站的 staging 複本，而不是正式上線的網域。Apache 在每次請求時都會重新載入 .htaccess，因此無效的檔案會立即引發錯誤。
  8. 若你有 shell 存取權限，請使用 apachectl configtest 驗證 Apache 組態，並檢查主機的錯誤記錄中是否有「not allowed here」或「command not allowed」訊息。
  9. 使用 curl -I 測試四種請求類型：對標準主機的純 HTTP、對替代主機的純 HTTP、對標準主機的 HTTPS，以及應提供本地 404 文件的不存在路徑。

將產生的區塊與 WordPress 既有的規則合併

WordPress 在每次儲存永久連結時都會重寫 # BEGIN WordPress 與 # END WordPress 之間的區段，因此任何放在該範圍內的規則最終都會消失。請將 HTTPS 標準化、Options -Indexes 和 ErrorDocument 放在標記區塊之外。標準的模式由上至下如下：

  1. 自訂的 HTTPS 重新導向區塊，放在檔案的最頂端。
  2. Options -Indexes 行（如果啟用）。
  3. # BEGIN WordPress 區塊，保持完全不動。
  4. 外掛區塊，例如 # BEGIN W3TC、# BEGIN Wordfence、# BEGIN WP-Optimize。
  5. 自訂 ErrorDocument 放在接近底部，且在任何外掛標記之外。

這個順序很重要，因為 mod_rewrite 規則是自上而下進行評估，直到找到符合項為止。放在 WordPress 區塊之上的標準化重新導向，會在請求到達 index.php 之前先攔截每一個請求，這正是 HTTP 至 HTTPS 以及替代主機標準化所需要的。如果將它放在 WordPress 區塊之下，對 /wp-admin/ 和既有永久連結的請求可能會在未重新導向的情況下洩漏，並損害 SEO。

對於 WordPress Multisite 網路，.htaccess 結構有所不同：wp-config.php 定義網站 ID，而 front-controller 規則使用特定網誌的路徑。Htaccess Generator 的重新導向和 404 區段仍然在 document root 運作，但任何自訂的 rewrite 邏輯都應針對網路既有的規則進行檢視，而非盲目附加。對於希望在不含 WordPress 細節的情況下深入了解純 HTTPS 流程的讀者，逐步 HTTPS 重新導向指南在非 WordPress 環境中介紹了相同的 RewriteRule。

在 staging 和正式環境中測試部署

301 重新導向會在瀏覽器、CDN 和搜尋引擎中積極快取。一旦用戶端看到 R=301，未來對舊 URL 的請求通常會完全略過伺服器，直接前往目的地。這就是為什麼在正式環境之前，staging 或可還原的維護時段是不可或缺的。最低測試矩陣涵蓋四種情境：

情境要請求的 URL預期回應
純 HTTP，標準主機http://www.example.com/301 重新導向至 https://www.example.com/
純 HTTP，替代主機http://example.com/301 重新導向至 https://www.example.com/
HTTPS，標準主機，缺少頁面https://www.example.com/nonexistent/404 狀態並附上本地 404 文件的內容
HTTPS，標準主機，既有的永久連結https://www.example.com/2024/01/post/WordPress 回傳 200，永久連結仍可運作

請使用 curl -I 執行這些測試以檢查狀態碼和 Location 標頭，並在瀏覽器的私密視窗中使用真實瀏覽器確認沒有快取方面的意外。如果任何請求發生迴圈或回傳 500 錯誤，請立即還原備份檔案，並閱讀 Apache 錯誤記錄中的「Options not allowed here」、「FileInfo not allowed」或「mod_rewrite: not found」 — 每一項都指向不同的 AllowOverride 或模組缺口。根據 Apache mod_rewrite 介紹，每個目錄的 rewrite 上下文行為與虛擬主機組態不同，因此在 document root 運作的規則，如果之後移至主要伺服器組態中，可能需要重新撰寫。

何時該停下並詢問你的主機商

有三種主機環境會阻擋產生器的輸出，即使檔案在語法上是正確的。第一，如果 document root 的 AllowOverride 不包含 FileInfo，Apache 會以 500 錯誤拒絕每一條 RewriteRule 和 ErrorDocument 行。第二，如果 mod_rewrite 或 mod_ssl 沒有載入，HTTPS 條件會失敗，導致重新導向對所有人或無人觸發。第三，如果 TLS 在反向代理或 CDN 終止，而 Apache 收到的是純 HTTP，%{HTTPS} 條件永遠不會符合，重新導向可能會陷入迴圈。Apache 自訂錯誤回應文件說明了 ErrorDocument 對 FileInfo 覆寫的需求；HTTPS 代理的情況則需要不同的條件，例如 %{HTTP:X-Forwarded-Proto} https，但這僅適用於你能控制代理並信任該標頭的情況。

若要更廣泛地了解如何在非 WordPress 技術棧中組建涵蓋 HTTPS 和自訂樣式 404 的安全 .htaccess，安全的 HTTPS 與 404 指南會在不含 WordPress 合併考量的情況下，更深入地探討同樣的三個指令。

完全隱藏 .htaccess 的託管型 WordPress 主機 — 例如 WP Engine、Kinsta、Pressable 和類似服務 — 會拒絕對 document root 的 .htaccess 變更，並可能要求透過其儀表板或 API 來表達相同的規則。在這種情況下，產生器的輸出仍可作為向主機商提出需求的明確規格，即使該檔案從未被直接上傳。