Webクラス

WordPressのリダイレクトループを直す方法｜ERR_TOO_MANY_REDIRECTSの原因と復旧手順

WordPressのリダイレクトループの原因と直し方を示すアイキャッチ

WordPressで「ERR_TOO_MANY_REDIRECTS」や「このページは正常に動作していません」と表示され、サイトや管理画面が開けなくなることがあります。

このエラーは、URLの転送処理が繰り返されるリダイレクトループ（転送先が循環する状態）によって発生します。原因はWordPressのURL設定だけでなく、SSL、Cloudflare、プラグイン、サーバー側の転送ルールなどさまざまです。

ここでは、最初に確認する項目から管理画面に入れない場合の復旧方法まで、変更による影響を抑えながら順番に説明します。

 

目次

WordPressのリダイレクトループを直すための早見表

まずはエラーが発生したタイミングと範囲を確認してください。直前に変更した設定から調べると、原因を絞り込みやすくなります。

症状・発生条件 考えられる原因 最初に確認すること
HTTPS化した直後に発生 SSL設定や転送ルールの競合 SSL証明書とHTTPからHTTPSへの転送設定
Cloudflare導入後に発生 暗号化モードとサーバー設定の不一致 CloudflareのSSL/TLS設定
プラグイン更新後に発生 リダイレクト設定やプラグインの競合 直前に変更したプラグイン
管理画面だけ開けない ログインURL、Cookie、HTTPS設定の問題 別ブラウザーでの再現とURL設定
ドメイン変更後に発生 WordPressアドレスとサイトアドレスの不一致 WordPressの一般設定
特定ページだけ開けない 個別のリダイレクトルール 転送元と転送先の設定

設定ファイルの編集やプラグインの停止を行う前に、サイトのファイルとデータベースをバックアップしてください。 公開中のサイトでは、可能であればステージング環境（公開サイトに影響させず検証する複製環境）で原因を確認します。

 

リダイレクトループとは？エラーが発生する仕組み

リダイレクトとは、アクセスしたURLから別のURLへ自動的に転送する仕組みです。WordPressではHTTPからHTTPSへの切り替えや、変更したページURLへの転送などに使用されます。

正常なリダイレクトでは、転送先に到達すると処理が終了します。しかし、複数の設定が矛盾すると、転送が繰り返されることがあります。

正常なHTTPからHTTPSへの転送とWordPressのリダイレクトループの違いを示す図

例えば、次のような状態です。

  1. 利用者が「https://example.com」にアクセスします。
  2. サーバー側の設定が「http://example.com」へ転送します。
  3. 別の設定が再び「https://example.com」へ転送します。
  4. 同じ処理が繰り返され、ブラウザーがエラーを表示します。

この場合、ページそのものが削除されたわけではありません。転送の設定を修正すれば、コンテンツを消さずに復旧できる可能性があります。

なお、リダイレクトループと404エラーは別の問題です。ページが見つからない場合は、WordPressの404エラーの直し方も確認できます。

 

設定変更前に確認する3つのこと

1. 別のブラウザーやシークレットウィンドウで開く

最初に、通常のブラウザーとは別の環境でサイトへアクセスします。

  1. シークレットウィンドウを開きます。
  2. 問題のURLへ直接アクセスします。
  3. 同じエラーが発生するか確認します。

通常のブラウザーだけでエラーが発生する場合は、Cookie（サイトがブラウザーに保存する情報）やキャッシュ（再表示を高速化する一時データ）の影響が考えられます。

その場合は、問題のドメインに限定してCookieやサイトデータを削除し、再度アクセスしてください。Cookieを削除するとログイン状態が解除されることがあります。

別の環境でも同じエラーが発生する場合は、WordPressやサーバー側の設定を調べます。

 

2. エラーが発生するURLの範囲を確認する

サイト全体が開けないのか、管理画面や特定ページだけで発生するのかを確認します。

  • トップページと個別記事の両方で発生する場合は、サイト全体のURL設定やSSL設定を優先します。
  • 管理画面だけで発生する場合は、ログイン処理や管理画面のHTTPS設定を調べます。
  • 特定ページだけの場合は、そのURLに適用される転送ルールを確認します。

 

3. 直前に変更した設定を洗い出す

エラーの発生直前に、ドメイン変更、SSL化、Cloudflare導入、プラグイン更新、サーバー移転などを行っていないか確認してください。

変更履歴が分かれば、すべての設定を初期化する必要はありません。原因が疑われる箇所を一つずつ検証することが、安全な復旧につながります。

 

対処法1：WordPressのURL設定を確認する

WordPressには、サイトの表示先とWordPress本体の設置先を管理する2種類のURL設定があります。

管理画面に入れる場合は、「設定」→「一般」を開いてください。

設定項目 役割
WordPress アドレス（URL） WordPress本体のファイルが設置されている場所
サイトアドレス（URL） 訪問者がサイトへアクセスするためのアドレス

通常のルートディレクトリ設置では、両方に同じURLを設定する構成が一般的です。ただし、WordPress本体をサブディレクトリに設置している場合などは、異なるURLが正しいこともあります。

そのため、2つのURLを無条件に同じ値へ変更しないでください。 実際の設置構成と公開URLを照合します。

HTTPS化したサイトでは、SSL証明書とサーバー設定が正常に機能していることを確認したうえで、URLのスキーム（httpまたはhttpsの部分）を点検してください。

 

管理画面に入れない場合はwp-config.phpを確認する

WordPress公式ドキュメントでは、wp-config.phpを使ってURLを指定する方法が案内されています。

サーバーのファイルマネージャーまたはSFTP（暗号化されたファイル転送方式）でWordPressの設置ディレクトリへアクセスします。

設定ファイルをバックアップしたうえで、既存のWP_HOMEとWP_SITEURLの定義がないか確認してください。

WordPress本体と公開サイトが同じ場所にあり、正しい公開URLが「https://example.com」である場合の記述例は次のとおりです。

define( 'WP_HOME', 'https://example.com' );
define( 'WP_SITEURL', 'https://example.com' );

実際には自分のドメインへ置き換え、wp-config.phpの「That’s all, stop editing!」というコメントより前に記述します。既存の定義がある場合は重複させないでください。

この設定はデータベース内のURLを直接修正するものではありません。設定を削除すると、保存済みのURL設定へ戻るため注意が必要です。

問題が解消したら、恒久的なURL設定を確認し、不要になった一時的な定義を整理します。

公式資料：WordPress公式のサイトURL変更手順

 

対処法2：CloudflareとSSL設定の競合を確認する

Cloudflareを利用している場合、SSL/TLS（通信を暗号化する仕組み）の設定が原因でリダイレクトループが発生することがあります。

特に注意したいのは、Cloudflareの暗号化モードが「Flexible」で、接続先サーバーがHTTPSへの転送を強制している場合です。

Flexibleでは、利用者とCloudflare間はHTTPSでも、Cloudflareから接続先サーバーへはHTTPで通信します。

接続先サーバーがHTTPをHTTPSへ転送すると、両者の設定が競合して転送を繰り返す可能性があります。

 

CloudflareのSSL/TLSモードを確認する

  1. Cloudflareのダッシュボードへログインします。
  2. 対象ドメインを選択します。
  3. 「SSL/TLS」の「Overview（概要）」を開きます。
  4. 現在の暗号化モードと接続先サーバーのSSL設定を照合します。
モード 接続先サーバーとの通信 確認ポイント
Flexible HTTP サーバー側のHTTPS強制転送と競合しないか
Full HTTPS 接続先サーバーがHTTPS通信を受け付けるか
Full (strict) HTTPS 接続先サーバーの証明書が有効で、Cloudflareの検証条件を満たすか

Cloudflare公式は、Flexibleとサーバー側のHTTPS強制転送が競合する場合、適切な証明書を用意したうえでFull以上へ変更する方法などを案内しています。

ただし、証明書の状態を確認せずにモードを切り替えると、別のSSLエラーが発生する可能性があります。

Full (strict)を利用する場合は、接続先サーバーの証明書がCloudflareの検証条件を満たしている必要があります。

公式資料：Cloudflareのリダイレクトループ対処方法

 

対処法3：プラグインによるリダイレクトを確認する

WordPressのリダイレクト関連プラグインやセキュリティプラグインが、別の転送設定と競合することがあります。

管理画面に入れる場合は「プラグイン」→「インストール済みプラグイン」を開き、直前に更新・設定変更したプラグインから確認してください。

  1. 現在のプラグイン構成と設定を記録します。
  2. 直前に変更したプラグインを一時的に無効化します。
  3. エラーが改善するか確認します。
  4. 改善した場合は、転送ルールや他の設定との競合を調べます。

一時停止によってログイン保護やセキュリティ機能が無効になる場合もあるため、公開サイトでは影響を確認してから実施してください。

 

管理画面にログインできない場合

管理画面が開けない場合でも、サーバー側からプラグインを一時的に停止できる場合があります。

  1. SFTPまたはサーバーのファイルマネージャーでWordPressの設置先を開きます。
  2. 「wp-content/plugins」ディレクトリへ移動します。
  3. 問題が疑われるプラグインのフォルダー名を一時的に変更します。
  4. サイトを再読み込みしてエラーの変化を確認します。

例えば、対象フォルダーがredirect-pluginなら、検証中はredirect-plugin-disabledのような名前に変更します。

改善がなければ元の名前へ戻し、次の原因を調べます。フォルダー名を戻した後も、必要に応じて管理画面で有効化状態を確認してください。

原因を切り分けられない場合は、バックアップと影響範囲を確認したうえで、プラグイン全体を一時停止する方法もあります。

プラグインの役割や代替機能を確認したい場合は、WordPressの無料プラグイン一覧もご覧ください。

 

対処法4：.htaccessのリダイレクト設定を確認する

Apache（Webサーバーソフトウェア）を利用している場合、.htaccessに記述された転送ルールが原因となることがあります。

特にHTTPからHTTPSへの転送、wwwあり・なしの統一、旧URLから新URLへの転送を複数の場所で設定している場合は注意が必要です。

 

.htaccessの確認手順

  1. サーバーのファイルマネージャーまたはSFTPでサイトの設置先を開きます。
  2. 隠しファイルの表示を有効にし、「.htaccess」を探します。
  3. 元ファイルをダウンロードしてバックアップします。
  4. Redirect、RewriteRule、RewriteCondなどの設定を確認します。
  5. 循環している転送ルールが特定できた場合に限り、該当箇所を修正します。

例えば、HTTPからHTTPSへ転送するルールと、HTTPSからHTTPへ戻すルールが同時に存在すると、循環が発生する可能性があります。

.htaccessを削除したり、内容をすべて標準設定へ置き換えたりしないでください。 WordPress以外のセキュリティ設定やアクセス制御が含まれていることがあります。

修正後に問題が悪化した場合は、バックアップから元の内容へ戻します。

なお、Nginx（別方式のWebサーバーソフトウェア）では、通常.htaccessを使用しません。Nginxの転送設定はサーバー側の設定ファイルや管理画面で確認します。

 

対処法5：転送先が再び転送元に戻っていないか確認する

特定ページだけでリダイレクトループが発生する場合は、個別の転送ルールを調べます。

例えば、旧URLから新URLへ転送する設定と、新URLから旧URLへ戻す設定が同時に存在していないか確認してください。

また、正規表現（文字列の一致条件を指定する記法）を使うリダイレクトでは、転送元の条件が広すぎることで、転送先にも同じルールが適用される場合があります。

Kinstaの公式資料では、転送元の末尾を明確に指定しないことによるループの例が紹介されています。

例えば、特定パスだけに一致させる必要がある場合は、次のように末尾を指定する方法があります。

^/blog/about$

ただし、実際の修正方法は利用しているサーバーやリダイレクト機能によって異なります。

転送ルールの修正後は、対象URLだけでなく、関連する旧URLや新URLも確認してください。

公式資料：Kinstaのリダイレクト設定ガイド

 

対処法6：リバースプロキシのHTTPS認識を確認する

Cloudflare以外にも、ロードバランサーやリバースプロキシ（利用者とWebサーバーの間で通信を中継する仕組み）を利用している環境では、WordPressが実際の接続方式を正しく認識できないことがあります。

例えば、利用者はHTTPSでアクセスしていても、中継先のWordPressにはHTTPとして接続される構成です。

この状態でWordPress側がHTTPSへ転送すると、転送が繰り返される可能性があります。

WordPress公式のHTTPSドキュメントでも、リバースプロキシ環境における無限リダイレクトへの注意が示されています。

サーバー管理者は、信頼できるプロキシから渡されるX-Forwarded-Protoなどのヘッダー（通信に付加される情報）と、WordPressが認識するHTTPS状態を照合してください。

外部から送られたヘッダーを無条件に信用する設定は避け、信頼できる中継サーバーに限定して構成する必要があります。

公式資料：WordPress公式のHTTPS設定

 

修正後に確認すること

エラー画面が消えても、転送設定が正しくなったとは限りません。修正後は次の項目を確認してください。

  • トップページと主要な記事が正常に表示されること。
  • WordPress管理画面にログインできること。
  • HTTPからHTTPSへの転送が意図したとおりに動作すること。
  • wwwあり・なしのURLが意図した正規URLへ到達すること。
  • 旧URLから新URLへの転送が循環せず終了すること。

ブラウザーの開発者ツールにあるNetwork（通信履歴）から、各リクエストのHTTPステータスコード（サーバーが返す応答番号）やLocationヘッダー（転送先を示す情報）を確認すると、転送経路を調べられます。

301や302などの応答については、HTTPステータスコード一覧も参照できます。

URLを変更した場合は、内部リンク、サイトマップ、canonical（検索エンジンへ正規URLを示す指定）なども必要に応じて確認してください。

 

リダイレクトループが直らない場合

ここまで確認しても改善しない場合は、レンタルサーバー側の転送設定やキャッシュ、SSL構成、セキュリティ設定などが関係している可能性があります。

サーバーのサポートへ問い合わせる際は、次の情報を整理すると原因を伝えやすくなります。

  • エラーが発生するURLと、発生しないURL。
  • エラーが始まった日時と直前に変更した設定。
  • Cloudflareなどの中継サービスの利用有無。
  • 確認済みの転送設定と実施した対処。
  • 可能であればHTTP応答の転送履歴。

サーバー側で管理されている設定は、WordPressの管理画面だけでは変更できない場合があります。原因が不明なまま複数の設定を同時に変更するより、調査結果を整理して問い合わせる方が安全です。

 

まとめ

WordPressのリダイレクトループは、URL設定やHTTPSへの転送、プラグイン、サーバー設定などが競合すると発生します。

最初は別ブラウザーで再現するか確認し、続いてエラーの発生範囲と直前の変更履歴を調べてください。SSL化直後ならHTTPS設定、Cloudflare導入直後なら暗号化モード、プラグイン変更後なら該当プラグインを優先します。

バックアップを確保し、一度に変更する設定を一つに絞って検証することが重要です。 修正後はサイトの表示だけでなく、管理画面や関連URLの転送先まで確認してください。

あわせて読みたい記事
次に知りたいことや、役立つ情報をまとめました。
関連記事の一覧を見る

PR記事一覧

【WordPress】エラー対策の最新記事8件

Ads Blocker Image Powered by Code Help Pro

広告ブロックを検出しました！

ブラウザの拡張機能を使用して広告をブロックしていることが検出されました。

ブラウザの広告ブロッカーなどの機能を無効にして「更新」をクリックして下さい。

You cannot copy content of this page

Menu