こんにちは、AIシステムズです。
この記事は、代表コバが現場で対応してきたWebサーバー運用の知見をもとに、AIを活用して構成・執筆し、弊社にて最終チェックを行ったものです。
「.htaccess にリダイレクトのルールを書いたのに、ブラウザでアクセスしても古いURLのままで反映されない」——サーバー移管やサイトリニューアルの直後に頻発するトラブルです。原因の大半は「.htaccess自体が読まれていない」「mod_rewriteが無効」「ルールの優先順位」のいずれかに集約されます。
- .htaccessリダイレクトが動かない主要原因
- AllowOverride・mod_rewriteの確認
- RedirectとRewriteRuleの使い分け
- ルール順序による事故
- ブラウザキャッシュという落とし穴
目次
- .htaccessリダイレクトが動かない原因
- AllowOverrideとmod_rewriteを確認
- RedirectとRewriteRuleの使い分け
- ルール順序の落とし穴
- こういうサイトに向いている/向いていない
- 再発防止チェックリスト
.htaccessリダイレクトが動かない原因
弊社が中小企業のサーバー保守で対応してきた事例では、原因は次のいずれかです。
- Apacheの設定で
AllowOverride Noneになっており、.htaccessが完全に無視されている mod_rewriteモジュールが無効化されている- ルールの記述順が悪く、別のルールに先に引っかかって意図したリダイレクトに到達していない
- 301リダイレクトをブラウザが強くキャッシュしていて、新しいルールが効いていないように見える
- そもそもApacheではなくnginxが前段にいて、.htaccessが読まれない構成になっている
AllowOverrideとmod_rewriteを確認
1. AllowOverrideの確認
Apacheの設定ファイル(/etc/httpd/conf/httpd.conf または /etc/apache2/apache2.conf)で、対象ディレクトリのDirectoryブロックを確認します。
<Directory /var/www/html>
AllowOverride All
</Directory>
AllowOverride None のままでは、.htaccessは存在しても完全に無視されます。All、または少なくとも FileInfo を許可する必要があります。
2. mod_rewriteの確認
apachectl -M | grep rewrite
rewrite_module が出力されればOKです。出力されない場合は有効化します。
sudo a2enmod rewrite # Debian/Ubuntu系
sudo systemctl restart apache2
# RHEL系は標準で有効。設定ファイルでLoadModuleを確認
3. 設定変更後はApacheを再起動
AllowOverride の変更はApache本体の再起動が必要です。.htaccess内のルール変更だけなら再起動不要ですが、効かないときは念のため再起動して切り分けます。
RedirectとRewriteRuleの使い分け
単純なURL移行はRedirect
Redirect 301 /old-page.html https://example.com/new-page/
パス1対1の移行はこの形式が読みやすく、十分です。
パターンマッチが必要ならRewriteRule
RewriteEngine On
RewriteRule ^old/(.*)$ /new/$1 [R=301,L]
R=301 でリダイレクト、L でルール処理を打ち切ります。
HTTPS強制
RewriteEngine On
RewriteCond %{HTTPS} off
RewriteRule ^(.*)$ https://%{HTTP_HOST}%{REQUEST_URI} [R=301,L]
ロードバランサ配下では %{HTTPS} がoffに見えるため、%{HTTP:X-Forwarded-Proto} で判定するほうが確実です。
ルール順序の落とし穴
.htaccessは上から評価されるため、WordPressのフロントコントローラへのリライト(index.phpへのRewriteRule)より前にカスタムリダイレクトを書く必要があります。
# BEGIN カスタムリダイレクト
RewriteEngine On
RewriteRule ^old-page$ /new-page/ [R=301,L]
# END カスタムリダイレクト
# BEGIN WordPress
RewriteEngine On
RewriteBase /
RewriteRule ^index\.php$ - [L]
RewriteCond %{REQUEST_FILENAME} !-f
RewriteCond %{REQUEST_FILENAME} !-d
RewriteRule . /index.php [L]
# END WordPress
WordPressのブロック内に書くと、サイトヘルスチェックや自動更新で上書きされて消えるので注意します。
ブラウザキャッシュという落とし穴
301リダイレクトは「永続的」を意味するため、ブラウザは強くキャッシュします。一度301を設定したURLは、ルールを直しても古いリダイレクト先に飛び続けることがあります。
切り分け時はシークレットウィンドウで確認するか、開発者ツールのNetworkタブで「Disable cache」を有効にします。本番投入前は、リダイレクトをまず302で動作確認し、確定後に301に変更するのが安全です。
こういうサイトに向いている/向いていない
.htaccessリダイレクトは、Apacheで動いている中小企業のWordPressサイトやレガシーCMS、コーポレートサイトのリニューアル時のURL移行に直接効きます。nginxが前段にいる構成や、WordPressのHosting系(WP Engineなど)では.htaccessが読まれない場合があり、別の方法が必要です。
再発防止チェックリスト
AllowOverrideがAllまたは必要な範囲に設定されているかmod_rewriteが有効になっているか- カスタムリダイレクトがWordPressブロックの外に書かれているか
- 本番投入前は302で動作確認しているか
- サーバー構成(Apache単体かnginx前段か)を把握しているか
まとめ
.htaccessのリダイレクトが効かないときは、まず「.htaccessが読まれているか」「mod_rewriteが有効か」を確認するのが鉄則です。ルールの記述よりも、サーバー設定とルール順序が原因であることのほうが多いと覚えておくと、切り分けが早くなります。
本記事は、代表コバが中小企業のWebサーバー運用の現場で対応してきた知見をもとに、AIを活用して構成・執筆し、弊社にて最終確認を行っています。サーバー移管、サイトリニューアル時のURL移行、SEOを維持したリダイレクト設計について、具体的な状況をふまえた相談を承っています。費用感だけ知りたい方も、お気軽にご相談ください。