2026年6月3日

Apache .htaccessの書き方と活用方法｜WordPressで安全に使う基本

Webサーバー・Apache

.htaccess は、Apache の設定をディレクトリ単位で上書きするためのファイルです。サーバー本体の設定ファイルを触れないレンタルサーバーでも、リダイレクト、アクセス制限、キャッシュ用ヘッダーなどを追加できます。この記事では、.htaccess が効く仕組み、WordPress の自動生成ブロックとの付き合い方、よく使う書き方の例、500エラーを出したときの戻し方までを順に説明します。

.htaccess が効く仕組みを先に知っておく

.htaccess は Apache がリクエストを受けるたびに読み込むファイルです。たとえば /var/www/html/blog/ 以下のファイルへアクセスがあると、Apache は上位の /var/www/html/ から順に .htaccess を探し、見つかったものを上から下へ重ねて適用します。下の階層に置いたファイルほど後から適用されるため、サブディレクトリだけ設定を変えることができます。

ただし、.htaccess が読まれるかどうかはサーバー本体の設定にある AllowOverride で決まります。Apache 2.4 では AllowOverride の既定値が None（.htaccess を読まない）になっており、VPS で Apache を入れた直後は、.htaccess を置いても何も起きないことがあります。

# /etc/apache2/sites-available/example.conf（Debian/Ubuntu系の例）
<Directory /var/www/html>
    AllowOverride All
    Require all granted
</Directory>

All は手軽ですが、許可範囲が広くなります。WordPress のパーマリンクに必要なのは主に FileInfo（mod_rewrite 等）で、認証を使うなら AuthConfig、ディレクトリ一覧の制御なら Indexes や Options も要ります。用途が決まっている VPS なら、必要な分だけを並べるほうが安全です。変更後は sudo apachectl configtest で構文を確かめてから sudo systemctl reload apache2（RHEL系は httpd）で反映します。

もうひとつ知っておきたいのが性能面です。.htaccess は毎リクエスト読まれるため、本体設定に書くより処理が増えます。Apache の公式ドキュメントも、本体設定を編集できるならそちらに書くことを勧めています。.htaccess は「本体設定を触れない環境」や「WordPress が自動で書き換える部分」のための仕組みと考えると使い分けやすくなります。

WordPress の自動生成ブロックには手を入れない

WordPress を Apache で動かすと、パーマリンク設定を保存したときに .htaccess へ次のようなブロックが書き込まれます。

# BEGIN WordPress
<IfModule mod_rewrite.c>
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]
</IfModule>
# END WordPress

# BEGIN WordPress から # END WordPress までは WordPress が管理する領域で、パーマリンク設定の保存やプラグインの操作で書き直されます。ここに自分のルールを足すと、次の保存で消えてしまいます。自作のルールはこのブロックの外、多くの場合は上に書きます。

上に書く理由は処理順です。WordPress のブロックは「実在しないファイルへのリクエストをすべて index.php に回す」内容なので、リダイレクトやアクセス拒否をその下に書くと、先に index.php へ回されて期待どおりに動かないことがあります。なお、HTTP_AUTHORIZATION の行はアプリケーションパスワードなどの認証ヘッダーを PHP に渡すためのもので、比較的新しいバージョンの WordPress で加わりました。古いサイトでは無い場合もありますが、それ自体は問題ではありません。

キャッシュ系やセキュリティ系のプラグインも、# BEGIN 〇〇 のような独自の目印つきブロックを書き込むことがあります。それらも各プラグインの管理領域なので、編集はプラグインの設定画面から行うのが原則です。

よく使う書き方の例

ここからは WordPress サイトでよく使う設定を紹介します。どれも Apache 2.4 の書式です。古い記事に出てくる Order deny,allow / Deny from all は Apache 2.2 の書式で、2.4 では互換モジュールが無いと動かないため、新しく書くなら Require を使います。

wp-config.php など重要ファイルへの直接アクセスを拒否する

<Files wp-config.php>
    Require all denied
</Files>

<FilesMatch "^(readme\.html|license\.txt|xmlrpc\.php)$">
    Require all denied
</FilesMatch>

wp-config.php は PHP として実行されるため通常は中身が見えませんが、PHP が止まったときに平文で表示される事故を防ぐ意味があります。xmlrpc.php は Jetpack や一部のアプリ連携が使うことがあるので、拒否する前に利用状況を確認してください。

ディレクトリ一覧を表示させない

Options -Indexes

index ファイルが無いディレクトリにアクセスされたとき、ファイル一覧が表示されるのを防ぎます。AllowOverride で Options か Indexes が許可されていないと、この行自体が500エラーの原因になります。

アップロードフォルダで PHP を実行させない

wp-content/uploads/ に次の内容の .htaccess を置くと、万一 PHP ファイルが紛れ込んでも実行されません。

<FilesMatch "\.(php|phtml|phar)$">
    Require all denied
</FilesMatch>

wp-login.php にベーシック認証をかける

<Files wp-login.php>
    AuthType Basic
    AuthName "Restricted"
    AuthUserFile /home/example/.htpasswd
    Require valid-user
</Files>

AuthUserFile には公開ディレクトリの外にあるファイルをフルパスで指定します。パスワードファイルは htpasswd -c /home/example/.htpasswd ユーザー名 のように作成し、パスワードはコマンドの入力欄で対話的に入れます（コマンドラインに直接書くと履歴に残ります）。wp-admin/admin-ajax.php まで認証をかけると、フロント側の機能が壊れることがあるので、保護の対象は wp-login.php に絞るのが無難です。

セキュリティ関連のレスポンスヘッダーを付ける

<IfModule mod_headers.c>
    Header always set X-Content-Type-Options "nosniff"
    Header always set Referrer-Policy "strict-origin-when-cross-origin"
</IfModule>

mod_headers が有効なら、PHP を書き換えずにヘッダーを足せます。<IfModule> で囲んでおくと、モジュールが無い環境でも500エラーにならずに無視されます。ただし、囲むことで「効いていないのに気付かない」状態にもなるため、反映後は後述の curl で実際のヘッダーを確かめてください。

リダイレクト（http→https、www の統一、URL変更）も .htaccess の代表的な用途ですが、mod_rewrite の書き方とつまずきどころが多いため、別記事のテーマとして扱っています。

編集前の準備と、反映の確認

.htaccess は1文字の誤りでサイト全体が500エラーになります。編集前に次の準備をしておくと、問題が起きても数十秒で戻せます。

現在の .htaccess をダウンロードし、htaccess_20261018.bak のような名前で手元に保存する
FTP・SFTP かサーバーのファイルマネージャーで、すぐ上書きできる状態にしておく
可能ならステージング環境で先に試す
文字コードは BOM なしの UTF-8、改行は LF で保存する

BOM 付きで保存すると、ファイル先頭の見えない文字が不正な命令として扱われ、500エラーになることがあります。Windows のメモ帳などで編集する場合は保存形式に注意してください。

反映の確認には、ブラウザよりもコマンドのほうが確実です。ブラウザはリダイレクトやキャッシュを覚えていることがあり、変更前の結果を見てしまう場合があります。

# ステータスコードとヘッダーだけを表示する
curl -I https://example.com/
curl -I https://example.com/wp-config.php

拒否したファイルが 403 Forbidden、通常ページが 200 OK になっていれば想定どおりです。なお、apachectl configtest はサーバー本体の設定ファイルだけを検査し、.htaccess の中身は確認しません。.htaccess の誤りは、実際にアクセスして初めて分かります。

500エラーになったときの読み方と戻し方

.htaccess を変更した直後に500エラーが出たら、まずは保存しておいたバックアップで上書きしてサイトを戻します。原因の調査は、サイトを戻してから落ち着いて行えば十分です。

原因はサーバーのエラーログで確認できます。VPS なら /var/log/apache2/error.log（RHEL系は /var/log/httpd/error_log）、レンタルサーバーなら管理画面のログ機能を見ます。よく出るメッセージと意味は次のとおりです。

Invalid command 'RewriteEngine', perhaps misspelled or defined by a module not included in the server configuration：綴りの誤りか、そのモジュール（ここでは mod_rewrite）が読み込まれていません。VPS なら sudo a2enmod rewrite（Debian/Ubuntu系）で有効にします。
... not allowed here：その命令が AllowOverride で許可されていません。本体設定で許可するか、行を削除します。
Options FollowSymLinks or SymLinksIfOwnerMatch is off which implies that RewriteRule directive is forbidden：.htaccess で mod_rewrite を使うには、シンボリックリンク関連の Options が有効になっている必要があります。

ログに何も出ない場合は、エラーが PHP 側で起きている可能性があります。そのときは .htaccess をいったん WordPress の自動生成ブロックだけに戻し、追加したルールを1つずつ戻して原因の行を絞り込みます。

Nginx・LiteSpeed 環境での注意

.htaccess は Apache の仕組みです。Nginx は .htaccess を読まないため、Nginx 単体のサーバーに置いても効果はありません。同じことを Nginx でやるには、サーバー設定ファイルに書き直す必要があります。

LiteSpeed は .htaccess の多くの書式を解釈しますが、Apache と挙動が違う命令もあります（2026年10月現在）。レンタルサーバーによっては、前段に Nginx、後段に Apache という構成で、.htaccess は効くものの一部のヘッダーが前段で上書きされることもあります。自分のサーバーがどの構成かは、契約しているサーバー会社のマニュアルで確認してください。

まとめ

.htaccess は毎リクエスト読まれるディレクトリ単位の設定で、AllowOverride で許可された命令だけが使える
WordPress の # BEGIN WordPress ～ # END WordPress は自動で書き直されるので、自作ルールはその外（多くは上）に書く
Apache 2.4 では Require の書式を使い、モジュールに依存する命令は <IfModule> で囲む
編集前にバックアップを取り、反映は curl でステータスとヘッダーを確かめる
500エラーはまずバックアップで戻し、エラーログのメッセージから原因を特定する