サーバー運用

Apacheで.htaccessリダイレクトが動かない時の対策

2026-05-02 読了7分 3PV
Apacheで.htaccessリダイレクトが動かない時の対策

こんにちは、AIシステムズです。
この記事は、代表コバが現場で対応してきたWebサーバー運用の知見をもとに、AIを活用して構成・執筆し、弊社にて最終チェックを行ったものです。

.htaccess にリダイレクトのルールを書いたのに、ブラウザでアクセスしても古いURLのままで反映されない」——サーバー移管やサイトリニューアルの直後に頻発するトラブルです。原因の大半は「.htaccess自体が読まれていない」「mod_rewriteが無効」「ルールの優先順位」のいずれかに集約されます。

  • .htaccessリダイレクトが動かない主要原因
  • AllowOverride・mod_rewriteの確認
  • RedirectとRewriteRuleの使い分け
  • ルール順序による事故
  • ブラウザキャッシュという落とし穴

目次

  1. .htaccessリダイレクトが動かない原因
  2. AllowOverrideとmod_rewriteを確認
  3. RedirectとRewriteRuleの使い分け
  4. ルール順序の落とし穴
  5. こういうサイトに向いている/向いていない
  6. 再発防止チェックリスト

.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が読まれない場合があり、別の方法が必要です。

再発防止チェックリスト

  • AllowOverrideAll または必要な範囲に設定されているか
  • mod_rewrite が有効になっているか
  • カスタムリダイレクトがWordPressブロックの外に書かれているか
  • 本番投入前は302で動作確認しているか
  • サーバー構成(Apache単体かnginx前段か)を把握しているか

まとめ

.htaccessのリダイレクトが効かないときは、まず「.htaccessが読まれているか」「mod_rewriteが有効か」を確認するのが鉄則です。ルールの記述よりも、サーバー設定とルール順序が原因であることのほうが多いと覚えておくと、切り分けが早くなります。

本記事は、代表コバが中小企業のWebサーバー運用の現場で対応してきた知見をもとに、AIを活用して構成・執筆し、弊社にて最終確認を行っています。サーバー移管、サイトリニューアル時のURL移行、SEOを維持したリダイレクト設計について、具体的な状況をふまえた相談を承っています。費用感だけ知りたい方も、お気軽にご相談ください。

AI Systemsへの無料相談はこちら

「何から始めればいいか分からない」段階からでも、お気軽にご相談ください。
まずは、お話を聞かせていただくだけでも大丈夫です。

無料で相談する
コバ

コバ

AI活用 / Web制作 / 業務自動化支援

中小企業さま向けに「お手頃に・早く・成果が出る」開発支援を行っています。AI・Web・自動化の3分野を、まとめてサポートしています。

この記事をシェアする

一覧へ戻る