WordPressの.htaccessは、パーマリンクを動かすための設定ファイルです。WordPressが自動で書き込む部分と、自分で追記してよい部分があり、この区別を知らずに編集すると、設定が消えたりサイトが500エラーになったりします。この記事では、WordPress公式ドキュメントの標準ルールを確認したうえで、追記する位置、よく使う設定のApache 2.4での書き方、編集後の確認方法を解説します。
.htaccessが使える環境
.htaccessは、Apache（とApache互換のLiteSpeed）が読む、ディレクトリ単位の設定ファイルです。次の点を先に確認してください。
- Nginxでは使えません。 Nginxは
.htaccessを読まないため、同じことはNginxの設定ファイルに書きます。 - Apacheでも、サーバー側で許可されている必要があります。 Apacheの設定で該当ディレクトリの
AllowOverrideがNoneだと、.htaccessは無視されます。WordPressのパーマリンクには、少なくともAllowOverride FileInfo（まとめて許可するならAll）と、mod_rewriteの有効化が必要です。レンタルサーバーでは通常、最初から使える状態になっています。 - Apacheの再起動は不要です。
.htaccessはリクエストのたびに読み込まれるため、保存した時点で反映されます。再起動が必要なのは、/etc/apache2/などにあるApache本体の設定ファイルを変えたときです。
WordPressの標準ルール
WordPressのインストール先（wp-config.phpがあるディレクトリ）に置かれる.htaccessの標準ルールは、公式ドキュメントでは次のとおりです（単一サイトの場合）。
# BEGIN WordPress
RewriteEngine On
RewriteRule .* - [E=HTTP_AUTHORIZATION:%{HTTP:Authorization}]
RewriteBase /
RewriteRule ^index\.php$ - [L]
RewriteCond %{REQUEST_FILENAME} !-f
RewriteCond %{REQUEST_FILENAME} !-d
RewriteRule . /index.php [L]
# END WordPress各行の役割は次のとおりです。
| 行 | 役割 |
|---|---|
RewriteRule .* - [E=HTTP_AUTHORIZATION:...] |
AuthorizationヘッダーをPHPに渡す。REST APIのアプリケーションパスワードなどで使われる |
RewriteRule ^index\.php$ - [L] |
index.phpへの直接アクセスはそのまま通す |
RewriteCond ... !-f / !-d |
実在するファイル・ディレクトリ（画像やCSSなど）はそのまま返す |
RewriteRule . /index.php [L] |
それ以外のURLをindex.phpに渡し、WordPressが記事などを表示する |
WordPressをサブディレクトリ（例: /blog/）に入れている場合は、RewriteBase /blog/、最後の行がRewriteRule . /blog/index.php [L]になります。マルチサイトでは別のルールになるため、公式ドキュメントのマルチサイト用の記述を使います。
標準ルールを作り直す方法
.htaccessが壊れた、または消えた場合は、管理画面の「設定」→「パーマリンク」を開き、何も変えずに「変更を保存」をクリックします。WordPressがファイルに書き込める状態なら、標準ルールが書き直されます。書き込めない場合は、画面に表示されるルールか、上のルールを手で貼り付けます。
自分の設定は「# BEGIN WordPress」の外に書く
# BEGIN WordPressと# END WordPressの間は、WordPressがパーマリンクの保存時などに書き換える部分です。ここに自分の設定を書くと、消えることがあります。自分の追記は、マーカーの外に書きます。
置く位置の目安は次のとおりです。
- リダイレクト（httpsへの統一、旧URLからの転送など）: WordPressのブロックより前に書きます。後ろに書くと、先にWordPressのルールで
index.phpへ渡されてしまい、意図どおりに動かないことがあります。 - アクセス制限・ヘッダー・キャッシュの設定: 前後どちらでも動きますが、まとまりごとにコメントを付けて、WordPressのブロックの前に置くと管理しやすくなります。
プラグイン（キャッシュ系やセキュリティ系）も、独自のマーカーを付けて.htaccessに書き込むことがあります。プラグインのマーカーの中も手で編集せず、プラグインの設定画面から変更します。
よく使う設定（Apache 2.4の書き方）
以下は現在のApache 2.4の書き方です。古い記事にあるOrder Deny,AllowやDeny from allはApache 2.2の書き方で、互換モジュールがないと500エラーになります。Requireを使ってください。
重要なファイルへのアクセスを禁止する
公式ドキュメントで紹介されている、wp-config.php、.htaccess、.htpasswd、debug.logをブラウザから読めないようにする設定です。
<FilesMatch "^(wp-config\.php|\.htaccess|\.htpasswd|debug\.log)$">
Require all denied
</FilesMatch>ディレクトリの一覧表示を止める
index.phpなどがないディレクトリで、ファイルの一覧が表示されないようにします。
Options -Indexesサーバーの設定でOptionsの上書きが許可されていないと、この行で500エラーになります。その場合はこの行を外し、サーバー会社の管理画面の設定を使います。
ログイン画面にBasic認証をかける
wp-login.phpに、WordPressのログインとは別のパスワードをかけます。まず、パスワードファイルをSSHで作ります。公開ディレクトリの外に置くのが安全です。
# 初回だけ -c を付けて新規作成する（既存のファイルに付けると上書きされる）
htpasswd -c /home/example/.htpasswd admin.htaccessには次のように書きます。AuthUserFileは、/から始まるサーバー上のフルパスで指定します。
<Files "wp-login.php">
AuthType Basic
AuthName "Login"
AuthUserFile /home/example/.htpasswd
Require valid-user
</Files>/wp-admin/ディレクトリ全体を制限する場合は、プラグインが使うadmin-ajax.phpを除外する必要があります。詳しくは wp-adminを.htaccessでIP制限する方法 と .htaccessでディレクトリをパスワード保護する方法 で解説しています。
セキュリティ関連のヘッダーを付ける
mod_headersが有効な場合に、ほかのサイトの枠内への埋め込みを自サイトだけに限るX-Frame-Optionsと、ファイルの種類の推測を止めるX-Content-Type-Optionsを付ける例です。
<IfModule mod_headers.c>
Header always set X-Frame-Options "SAMEORIGIN"
Header always set X-Content-Type-Options "nosniff"
</IfModule>X-XSS-Protectionヘッダーは、主要なブラウザが対応をやめており、現在は付ける意味がありません。XSS対策としては、WordPress本体・プラグインの更新と、必要に応じてContent-Security-Policyを検討します。
静的ファイルのブラウザキャッシュを設定する
mod_expiresで、画像・CSS・JavaScriptにキャッシュの期限を付けます。HTMLまで長くキャッシュさせると、記事を更新しても古い表示が残るため、種類を絞って指定します。
<IfModule mod_expires.c>
ExpiresActive On
ExpiresByType image/jpeg "access plus 1 month"
ExpiresByType image/png "access plus 1 month"
ExpiresByType image/webp "access plus 1 month"
ExpiresByType text/css "access plus 1 week"
ExpiresByType text/javascript "access plus 1 week"
ExpiresByType application/javascript "access plus 1 week"
</IfModule>WordPressはCSSやJavaScriptのURLに?ver=を付けて読み込むため、テーマやプラグインを更新するとURLが変わり、新しいファイルが読み込まれます。キャッシュ系プラグインが同じ設定を書き込んでいる場合は、重複しないようにどちらか一方にします。
編集するときの手順と確認
- 編集前にコピーを取る:
cp .htaccess .htaccess.bakのように、元のファイルを残します。FTPで編集する場合は、ダウンロードしたファイルを保存しておきます。 - 少しずつ追加する: 設定は1つずつ追加し、そのたびに表示を確認します。まとめて追加すると、どの行が原因か分からなくなります。
- 応答ヘッダーを確認する: 設定が効いているかは、
curlで確かめられます。
curl -sI https://example.com/ | grep -i -E "x-frame-options|x-content-type-options"
curl -sI https://example.com/wp-config.php | head -n 11行目で追加したヘッダーが表示され、2行目で403が返れば、設定は効いています。
500エラーになったら、すぐにバックアップに戻し、Apacheのエラーログを確認します。存在しないモジュールの命令を書いた場合は「Invalid command」から始まるメッセージが出ます。モジュールに依存する設定は、上の例のように<IfModule>で囲んでおくと、モジュールがない環境でもエラーになりません。
ファイルの権限は、通常644（所有者が読み書き、ほかは読み取りのみ）にします。
まとめ
.htaccessはApache（とLiteSpeed）用の設定ファイルで、Nginxでは使えません。保存した時点で反映され、Apacheの再起動は不要です。# BEGIN WordPressから# END WordPressの間はWordPressが書き換えるため、自分の設定はその外に書きます。リダイレクトはWordPressのブロックより前に置きます。- 標準ルールが壊れたら、「設定」→「パーマリンク」で「変更を保存」すると作り直せます。
- アクセス制限はApache 2.4の
Requireで書き、Order/Denyの古い書き方は使いません。 - 編集前のバックアップ、1つずつの追加、
curlでの確認を習慣にします。