WordPressを開いたときに「リダイレクトが繰り返し行われました」「ERR_TOO_MANY_REDIRECTS」「ページが正しく転送されていません」と表示される場合、ブラウザは移動先を何度も案内され、目的のページへ到達できていません。サイトが消えたとは限らず、Cookie、WordPressのURL、HTTPS、CDN・プロキシ、サーバーやプラグインの転送規則が食い違っている可能性があります。
最初に行うのは、転送設定をすべて削除することではありません。どのURLからどのURLへ移動し、どこで同じ場所へ戻されるかを確認します。対象ページと発生時刻、直前の変更を記録し、ブラウザだけの問題か、サイト全体の設定かを分けます。
WordPress URL、.htaccess、CDN、SSL化プラグインの設定を一度に変更しないでください。管理画面へ入れなくなるだけでなく、公開ページや検索向けURLまで別の場所へ転送されるおそれがあります。
この記事では、リダイレクトループの範囲を分け、元に戻せる一手ずつ原因を確認して復旧する手順を解説します。
先に結論：リダイレクトループは7段階で確認する
| 順番 | 確認すること | 目的 |
|---|---|---|
| 1 | 完全なURL、時刻、画面、直前の変更を記録 | 設定とログを照合できる状態にする |
| 2 | 別ブラウザ・別端末で同じURLを比較 | Cookieや端末固有の問題を分ける |
| 3 | サイト全体・ログイン・特定ページを比較 | 転送がかかる範囲を絞る |
| 4 | 転送経路とWordPress URLを確認 | ドメイン・HTTPSの往復を見つける |
| 5 | CDN・プロキシ・サーバーのHTTPS認識を確認 | 複数層の転送競合を見つける |
| 6 | プラグイン・.htaccess・Nginx規則を対象限定で確認 | 重複する転送規則を止める |
| 7 | 復旧後に主要URLと管理機能を再確認 | 別URLの転送事故を残さない |
WordPress公式のLogging Inは、「Too many redirects」の確認先として、WP_HOME・WP_SITEURL、データベースのhome・siteurl、HTTPとHTTPS、CDN・DNSプロキシ・Webサーバーの競合を挙げています。つまり、エラー文だけで一つの原因に決められません。
リダイレクトループはどんな状態？
リダイレクトは、あるURLを別のURLへ案内する仕組みです。HTTPからHTTPS、古いURLから新しいURL、ログイン前からログイン画面など、正しく使えば必要な機能です。しかし、AがBへ、BがAへ戻す設定になったり、A→B→C→Aと一周したりすると、ブラウザは安全のため処理を止めます。
| 症状 | 優先して見る場所 | 代表的な原因 |
|---|---|---|
| 自分のブラウザだけ | Cookie、キャッシュ、拡張機能 | 古いログインCookie、以前の転送情報 |
| ログイン後だけ戻される | Cookie、サイトURL、HTTPS認識 | Cookieの対象ドメイン不一致、URL設定の競合 |
| サイト全体で発生 | HTTPS、CDN、プロキシ、サーバー設定 | HTTPとHTTPS、www有無の往復 |
| 特定ページだけ | 個別転送、SEO・リダイレクト設定 | 旧URLと新URLの相互転送 |
| 移行・SSL化直後 | WordPress URL、証明書、公開先、転送 | 旧環境と新環境の設定混在 |
404はページが見つからない状態、403はアクセス拒否、500はサーバー内部の処理失敗です。表示が異なる場合は、WordPressの404エラーを直す手順、403 Forbiddenの確認順、500 Internal Server Errorの復旧手順へ進んでください。
最初に発生範囲を分ける
自分のブラウザだけで発生する
同じURLが別ブラウザや別端末では開くなら、対象サイトのCookie、ブラウザキャッシュ、拡張機能を優先します。すべての閲覧履歴を消す前に、対象ドメインのCookieだけを削除し、シークレットウィンドウで比較します。ログイン状態は解除されるため、パスワードや二段階認証の準備も確認してください。
ログイン画面・管理画面だけで発生する
公開ページは見えるのに、wp-login.phpやwp-adminだけ転送を繰り返す場合は、ログインCookie、管理画面のHTTPS強制、ログインURL変更、セキュリティ機能、キャッシュ除外を確認します。パスワード再設定を繰り返す前に、WordPress管理画面へ入れないときの確認手順で認証失敗とリダイレクトを分けてください。
サイト全体で発生する
トップページ、記事、管理画面がすべて開かない場合は、WordPress URL、HTTPからHTTPSへの転送、www有無、CDN・プロキシ、サーバー設定を優先します。直前にSSL化、ドメイン変更、サーバー移行、CDN導入をしたなら、その変更時刻と現在のDNS・証明書・公開先も確認します。
特定ページ・旧URLだけで発生する
特定URLだけなら、リダイレクトプラグイン、SEOプラグイン、サーバー転送、旧ページの転送先を調べます。旧URLから新URLへ転送し、新URLから旧URLへ戻す規則がないかを確認します。ページを削除したりスラッグを再変更したりする前に、転送元と転送先を紙やメモへ一列で書き出すと往復を見つけやすくなります。
設定変更前に残す記録
- エラーが出る完全なURL
- 発生日時とタイムゾーン
- 最初に入力したURLと最後に表示されたURL
- サイト全体・管理画面・特定ページの再現範囲
- 別ブラウザ・別端末・別回線での結果
- 直前のSSL化、移行、URL、CDN、プラグイン変更
- 現在のWordPressアドレスとサイトアドレス
- 利用中のCDN、プロキシ、キャッシュ、転送機能
ブラウザの開発者ツールやオンライン確認ツールを使う場合も、管理画面や一時URLなど非公開情報を第三者サービスへ入力しないでください。公開URLの転送経路は、ブラウザのNetworkパネルでステータスとLocationを確認する方法があります。
手順1：対象サイトのCookieを限定して確認する
ログイン後だけループする場合は、対象ドメインのCookieを削除して再ログインします。古いドメイン、www有無、HTTP/HTTPSで保存されたCookieが、現在のログイン先と合わないことがあります。別ブラウザで正常なら、サーバー設定を変える前にこの確認を優先します。
Cookie削除後もすべての端末で同じなら、端末固有ではありません。再ログインを何度も繰り返すと、ログイン試行制限やWAFで別の拒否を受けることがあるため、次のURL設定確認へ進みます。
手順2：WordPressアドレスとサイトアドレスを照合する
管理画面へ入れる場合は「設定」→「一般」で、「WordPress アドレス（URL）」と「サイトアドレス（URL）」を確認します。WordPress公式のSettings General screenでは、前者はWordPress本体がある場所、後者は訪問者がサイトへ到達するアドレスとして説明されています。
通常のルート直下運用では同じ値が多いものの、WordPressをサブディレクトリへ置く構成では異なる場合があります。WP_HOMEやWP_SITEURLをwp-config.phpで定義していると、管理画面から変更できません。データベースの値も含め、どこが現在値を決めているかを確認します。
正しい値を確認せず、検索で見つけたURLをwp-config.phpやデータベースへ上書きしないでください。公開ページと管理画面の両方へ到達できなくなることがあります。
HTTPからHTTPSへ移行した直後は、WordPressのMixed Contentを直す手順も照合してください。証明書、WordPress URL、本文内のHTTP資源は別の問題です。URL設定だけを変えて、証明書やサーバー側のHTTPSが未完了なら正常に動きません。
手順3：HTTPSとリバースプロキシの認識を確認する
CDNやリバースプロキシが訪問者とのHTTPS通信を終端し、背後のWordPressへHTTPで接続する構成では、WordPressが「現在はHTTP」と誤認することがあります。WordPressがHTTPSへ転送し、プロキシ側が再びHTTPとして渡すと、同じ処理が繰り返されます。
WordPress公式のHTTPSも、リバースプロキシ配下では初期状態で無限リダイレクトが起こり得ると注意しています。利用中のCDN・プロキシが転送するHTTPS情報と、サーバー会社が指定するWordPress側の設定を確認してください。
原因確認のためにCDNやHTTPS保護を無期限で無効化しないでください。一時比較が必要な場合も、影響範囲、開始時刻、元に戻す設定を記録し、提供元の手順に従います。
手順4：www有無・HTTP/HTTPS・末尾スラッシュの往復を探す
転送経路を確認し、wwwあり→なしの直後に別の層でなし→ありへ戻していないか、http→httpsの後にアプリ側がhttpを生成していないかを調べます。末尾スラッシュ、サブディレクトリ、言語・会員ページの正規化規則も、別の転送と組み合わさるとループすることがあります。
「正規URLはどれか」を一つ決め、CDN、サーバー、WordPress、プラグインの役割を整理します。同じ目的の転送を複数層へ重ねる必要がなければ、一つの管理場所へ集約した方が保守しやすくなります。ただし、既存の検索流入やサブドメイン構成がある場合は、削除前に全規則を記録します。
手順5：プラグインの転送・SSL・キャッシュ設定を確認する
リダイレクト、SEO、SSL化、セキュリティ、会員、言語、キャッシュのプラグインは、条件に応じてURLを変更することがあります。直前に導入・更新・設定変更した対象と、現在有効な転送機能を確認します。サーバー側の常時SSLとプラグインのHTTPS強制が重なっていないかも見ます。
管理画面へ入れない場合でも、最初から全プラグインを削除しません。直前の変更とログから対象を絞り、フォルダ名変更など提供元が案内する停止方法を使います。元の名前と有効状態を記録し、復旧後に防御機能や転送を戻します。整理の基本はWordPressプラグインを安全に減らす方法を参照してください。
手順6：.htaccess・Nginx・サーバー転送を確認する
Apache系では.htaccess、Nginxではサーバー設定、レンタルサーバーでは管理画面の転送機能に規則がある場合があります。WordPress公式のApache HTTPD / .htaccessを参考にしつつ、契約サーバー固有の仕様を優先します。
直前に編集した記録があるなら、変更前ファイルを保存し、追加した規則だけを戻します。WordPressが管理する範囲、セキュリティ用規則、独自転送を区別してください。他サイトの.htaccessを丸ごとコピーすると、設置場所やPHP実行方式の違いで500エラーやアクセス拒否を起こすことがあります。
.htaccessを確認せず削除したり、すべての転送規則を空にしたりしないでください。パーマリンク、HTTPS、アクセス制限が同時に外れる可能性があります。
サーバー移行後なら、旧サーバー・新サーバー・CDNのどこが応答しているかも確認します。WordPress移行前後のチェックリストとサーバー移行の確認手順を使い、DNS・証明書・公開先・転送を順に照合します。
修正後にキャッシュを更新する
原因となる設定を直した後、ブラウザ、WordPress、サーバー、CDNに以前の転送が残ることがあります。元の問題を直してから、対象URLのキャッシュを配信経路に沿って更新します。キャッシュの役割と安全な削除順はWordPressキャッシュ設定の基本で確認してください。
キャッシュ削除だけで一時的に開けても、別端末ですぐ再発するなら転送設定は直っていません。シークレットウィンドウとログアウト状態で、HTTP/HTTPS、www有無、トップ、記事、ログイン画面を再確認します。
復旧後に確認する9項目
- 正規URLを直接入力して一度で表示できる
- HTTPからHTTPSへ意図した回数で転送される
- wwwあり・なしが正規URLへ統一される
- トップページと複数の記事が開く
- ログイン・ログアウト・管理画面が動く
- 記事保存、画像追加、問い合わせなど重要機能が動く
- 古いURLから内容が近い新URLへ正しく転送される
- 別ブラウザ・スマートフォンでも再発しない
- アクセスログに転送の繰り返しが残っていない
URL変更後はサイト内リンクも正規URLへ直し、転送だけに依存しない状態へ整えます。内部リンクはWordPress内部リンクの貼り方に沿って確認してください。大きな転送変更は、WordPressのテスト環境で事前に再現できると安全です。
自分で直せないときにサポートへ伝える情報
- 最初に入力した完全なURL
- エラー発生日時とタイムゾーン
- サイト全体・ログイン・特定ページの発生範囲
- 転送途中に確認できたURLとステータス
- WordPressアドレスとサイトアドレス
- SSL化、移行、CDN、プラグイン変更の履歴
- 利用中のCDN・プロキシ・サーバー転送・SSL機能
- 実施した対処と結果
- 正常だった最後の日時と利用可能なバックアップ
Cookie、認証トークン、パスワード、秘密鍵を送らないでください。サーバー会社にはドメイン、時刻、転送経路を伝え、CDN利用時はオリジンサーバー側とCDN側の両方で確認してもらいます。
再発を防ぐ運用
- サイトの正規URLとHTTPS担当層を記録する
- 転送元・転送先・目的・設定場所を一覧化する
- SSL化、CDN、移行を同日に重ねる場合は手順を分ける
- URL設定変更前にファイルとデータベースをバックアップする
- サーバーとプラグインで同じHTTPS強制を重複させない
- 古いURLを新しいURLへ一方向だけ転送する
- 更新後にログイン・保存・主要ページを確認する
- 転送変更をSearch Consoleとアクセスログでも確認する
バックアップの基本はWordPressバックアップの取り方、サイト全体の保守状況はWordPressサイトヘルスの見方、防御機能の確認はWordPressセキュリティ設定の基本もあわせて参照してください。
よくある質問
Cookieを削除すれば必ず直りますか？
自分のブラウザだけで発生する場合には有効ですが、全端末で同じならWordPress URLや転送設定が原因の可能性があります。Cookie削除後に別端末でも比較し、直らなければ次の確認へ進みます。
WordPressアドレスとサイトアドレスは同じにすべきですか？
ルート直下の一般的な構成では同じことが多いですが、サブディレクトリ設置などでは異なります。現在の設置場所を確認せず同じ値へ変えるのは危険です。サーバー構成と公式説明を確認してください。
SSL化プラグインを停止すれば解決しますか？
サーバー側の常時SSLと競合している場合は候補になりますが、停止によりHTTPへ戻ったり、Mixed Contentが出たりすることもあります。証明書、サーバー転送、WordPress URLを確認し、プラグインが担当している機能を把握してから判断します。
ループが自然に消えたら調査は不要ですか？
CDNキャッシュや一時的な設定反映で戻ることはありますが、競合が残れば再発します。発生時刻のログ、直前の変更、正規URLを記録し、主要URLとログイン操作を再確認してください。
まとめ
WordPressのリダイレクトループは、Cookieだけでなく、WordPress URL、HTTP/HTTPS、www有無、CDN・プロキシ、プラグイン、Webサーバーの転送が食い違うと発生します。まずURLと発生範囲を記録し、Cookie、URL設定、HTTPS認識、転送規則の順に一つずつ確認してください。
復旧の目的はエラー画面を消すことではなく、正規URLへ一方向で到達できる状態を作ることです。修正後はトップページだけでなく、ログイン、記事保存、旧URL、別端末まで確認して完了です。