WordPressがリダイレクトループする原因と対処法

WordPress エラー・不具合対処 2026年5月29日読了 11分

WordPressサイトを表示しようとしたときに「このページではリダイレクトが繰り返し行われました」と表示され、サイトが開けなくなる症状を「リダイレクトループ」と呼びます。本記事では、発生原因の典型パターンと、優先度順での対処手順を整理しております。

この記事でわかること

リダイレクトループが起こる主な5つの原因パターン
ブラウザ・コマンドラインからの原因切り分け方法
wp-config.php・データベース・.htaccess の3層からの対処手順
HTTPS化作業に伴うリダイレクトループの解消方法
プラグイン無効化による問題切り分けの実践手順

リダイレクトループとは何か
起こる典型的な5つの原因
ブラウザとコマンドラインでの状況把握
対処1：WordPressのURL設定を確認する
対処2：.htaccess を見直す
対処3：HTTPS化に伴うリダイレクト設定
対処4：プラグインの干渉を切り分ける
関連事例としての学び
まとめ

リダイレクトループとは何か

リダイレクトループとは、ブラウザが特定のURLを開こうとした際に、サーバーが別のURLへ転送する処理を延々と繰り返してしまい、最終的なページにたどり着けなくなる状態を指します。Chromeでは「ERR_TOO_MANY_REDIRECTS」、Safariでは「Safariはこのページを開けません。リダイレクトが多すぎます」などのメッセージが表示されます。

WordPressサイトでこの症状が発生すると、フロント側だけでなく管理画面（/wp-admin/）も同じように開けなくなることが多く、復旧対応に焦りが生じやすいトラブルでございます。実際、弊社がご相談を受けるWordPressトラブルの中でも、白画面や500エラーと並んで頻度の高い症状の一つです。

ループが「危険」とされる理由

リダイレクトループの厄介な点は、ブラウザのキャッシュに不正なリダイレクト先が記憶されてしまうことです。一度ループに陥ったサイトは、サーバー側で問題を修正したあとも、訪問者のブラウザがキャッシュした古いリダイレクト情報を参照し続けることで、症状が継続して見えるケースがございます。

この特性のため、対処後の動作確認は「シークレットウィンドウ」または「別のブラウザ」から行うことを強く推奨いたします。普段使われているブラウザでテストすると、サーバー側は直っていても「直っていないように見える」ことがあるためです。

起こる典型的な5つの原因

WordPressサイトでリダイレクトループが発生する原因は、概ね次の5つに集約されます。発生の頻度が高い順に並べております。

① WordPressのURL設定（site_url / home）の不一致

WordPress本体は、サイトのURLを2つの設定（siteurlとhome）でデータベース上に保持しています。これらの値が、実際にアクセスされているURLと食い違っていると、WordPressが「正しいURLへ転送しよう」とし、それを延々と繰り返してリダイレクトループになります。

典型的な発生パターン：

HTTPS化後にデータベースの値がhttpのまま残っている
サイトURLを「https://example.com」に変更したいのに「https://www.example.com」のままになっている
サブディレクトリ運用からルート運用に切替えた後の値が古い

② .htaccess のリライトルールの循環

Apacheサーバーで動作するWordPressサイトでは、.htaccessファイルにURL書き換えのルールが記載されています。HTTPS化のため、または独自のリダイレクト設定のために、ここに追加した RewriteRule が他のルールと干渉して、転送がループする場合がございます。

特に注意すべきは、「http→https」と「www→非www」の両方のリダイレクトを別々に書いた場合の順序です。記述順や条件が適切でないと、無限ループに陥ります。

③ HTTPS化作業の不完全

常時SSL化（HTTPS化）を行う際、サーバー側でリダイレクト設定をしたものの、WordPress本体のURL設定が古いまま残っている場合があります。サーバーは「httpはhttpsに転送」とし、WordPressは「https→http」と判断してしまう、というように転送先がぶつかってループします。

④ キャッシュ系プラグインの古いキャッシュ

WP Fastest Cache、W3 Total Cache、WP Super Cacheなど、ページをキャッシュするタイプのプラグインが、リダイレクト指示そのものをHTMLとしてキャッシュしてしまっている場合があります。サーバー側で設定を直しても、キャッシュが残っている限り古い挙動が継続いたします。

⑤ SEO・セキュリティプラグインの設定干渉

Rank Math、Yoast SEO、Redirection、Really Simple SSL、SiteGuard WP Plugin といった、URLや認証に関わるプラグインが独自のリダイレクト処理を行っている場合があります。これらが複数同時に動作していると、それぞれが異なる転送先を指示してループに陥ることがございます。

ブラウザとコマンドラインでの状況把握

原因を絞り込むには、まず「どのURLからどのURLへ、何度転送されているか」を客観的に把握することが第一歩です。

ブラウザでの確認

Chromeをご利用の場合、F12キーで開発者ツールを開き、「Network」タブを表示した状態でページを再読み込みしてください。リダイレクトが発生していれば、301や302のステータスコードを返すリクエストが連続して並びます。それぞれのリクエストの「Location」ヘッダーを確認することで、どこからどこへ転送されているかが分かります。

コマンドラインでの確認（推奨）

サーバーへのSSHアクセスが可能な場合、curlコマンドを使うとリダイレクトの連鎖を端的に確認できます。

curl -sL -o /dev/null -w "%{url_effective} %{http_code}\n" -I https://example.com/ --max-redirs 20

このコマンドは最大20回までリダイレクトを追跡し、最終的にどのURLでどのステータスコードが返るかを表示いたします。ループしている場合は、20回のリダイレクト上限に達したことが分かります。

より詳細に確認したい場合は、各リダイレクトの中継先をすべて表示するオプションもございます。

curl -sIL https://example.com/ 2>&1 | grep -iE "^(HTTP|Location)"

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

最も頻度が高い原因が「URL設定の不一致」であるため、最初に確認するのはこの項目でございます。

wp-config.php からの強制指定

管理画面が開けない状態でも、サーバー上のwp-config.phpを編集することで、URL設定を強制的に上書きできます。FTPまたはSSHで該当ファイルを開き、/* That's all, stop editing! */ という行の直前に次の2行を追加してください。

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

これにより、データベース上の値よりもwp-config.phpの指定が優先される動作となり、ループから脱出できる可能性が高まります。example.comの部分は、ご自身のドメインに置き換えてください。

データベースから直接修正する

長期的には、データベース上の値そのものを正しい状態に修正することが必要です。WP-CLIをご利用の場合は、次のコマンドが最も簡単で確実です。

wp option update home 'https://example.com'
wp option update siteurl 'https://example.com'

WP-CLIが使えない環境では、phpMyAdminからwp_optionsテーブルを開き、option_nameがhomeおよびsiteurlの行を直接編集することで対応可能です。

弊社が支援しているクライアントサイトでも、サーバー移転後のsiteurl 値が旧サーバー由来のままで残っていたケースを多数経験しております。移転作業の最終チェック項目として、この2つの値の確認は欠かせません。

対処2：.htaccess を見直す

サーバーのドキュメントルート（WordPressをインストールしたディレクトリ）にある.htaccessファイルを確認します。リダイレクトループの原因がこのファイルにある場合、独自に追加したRewriteRuleやRewriteCondの記述順が問題となっていることが大半です。

WordPressの標準ブロックは保護する

.htaccessには、必ず次のような「WordPressの標準ブロック」が含まれています。このブロックは絶対に削除や改変をなさらないでください。

# BEGIN WordPress
<IfModule mod_rewrite.c>
RewriteEngine On
RewriteBase /
RewriteRule ^index\.php$ - [L]
RewriteCond %{REQUEST_FILENAME} !-f
RewriteCond %{REQUEST_FILENAME} !-d
RewriteRule . /index.php [L]
</IfModule>
# END WordPress

独自リダイレクトの記述順

HTTPS化や www の正規化のために独自リダイレクトを追加されている場合は、次のようにWordPressブロックよりも前に記述してください。

# 独自のリダイレクト（WordPressブロックより前）
<IfModule mod_rewrite.c>
RewriteEngine On
RewriteCond %{HTTPS} off
RewriteRule ^(.*)$ https://%{HTTP_HOST}/$1 [R=301,L]
</IfModule>

# BEGIN WordPress
...
# END WordPress

原因の切り分けが難しい場合は、いったん.htaccessをリネーム（例：.htaccess_backup）して、WordPress管理画面の「設定 → パーマリンク設定」を一度保存し直すことで、標準の.htaccessを再生成できます。これにより、独自記述による干渉を一旦リセットして切り分けが可能になります。

対処3：HTTPS化に伴うリダイレクト設定

常時SSL化を行った直後にリダイレクトループが発生するケースは非常に多くございます。原因は、サーバー側のhttp→https転送と、WordPress側のURL設定が整合していないことが大半です。

整合させるべき3つの設定

HTTPS化を完了させるには、最低でも次の3点が「すべてhttps」で揃っている必要があります。

WordPressのhomeおよびsiteurlがhttpsで始まっている
サーバー側（.htaccessまたはサーバー設定）でhttp→httpsへの恒久リダイレクトが設定されている
記事本文・テーマ・プラグイン内の絶対URLがすべてhttpsに置き換わっている

記事本文の絶対URLは、WP-CLIのsearch-replaceコマンドで一括変換できます。

wp search-replace 'http://example.com' 'https://example.com' --all-tables --skip-columns=guid

--skip-columns=guidを指定する点が重要でございます。投稿のGUIDは識別子として使われており、ここを書き換えるとRSSフィードの購読者に重複配信される等の副作用が生じます。

対処4：プラグインの干渉を切り分ける

URL設定も.htaccessも正常な場合、最後に疑うのはプラグインによる干渉です。リダイレクト機能を持つプラグインが複数同時に動作していると、互いに転送先を指示し合ってループに陥ります。

FTPからのプラグイン無効化

管理画面が開けない状態でも、FTPまたはSSHから/wp-content/plugins/ディレクトリの名前を一時的に変更することで、すべてのプラグインを強制的に無効化できます。

cd /path/to/wordpress/wp-content/
mv plugins plugins_disabled

この状態でサイトにアクセスし、リダイレクトループが解消すれば、原因はいずれかのプラグインにあると確定します。ディレクトリ名を元に戻したのち、管理画面で1つずつプラグインを有効化していき、どのプラグインで再発するかを特定する手順となります。

疑うべきプラグインの種類

リダイレクトループの原因となりやすいプラグインの傾向は次の通りです。

常時SSL化系：Really Simple SSL、SSL Insecure Content Fixer
リダイレクト管理系：Redirection、301 Redirects、Safe Redirect Manager
SEO系：Rank Math、Yoast SEO（リダイレクト機能を有効にしている場合）
セキュリティ系：SiteGuard WP Plugin、Wordfence
キャッシュ系：WP Fastest Cache、W3 Total Cache（古いリダイレクト指示をキャッシュしている場合）

まとめ

WordPressのリダイレクトループは、原因の8割以上が「URL設定の不一致」「.htaccessのリライトルール」「プラグインの干渉」のいずれかに集約されます。対処の優先順位としては、次の流れが効率的でございます。

シークレットウィンドウまたはcurlでリダイレクトの連鎖を確認
wp-config.phpにWP_HOME・WP_SITEURLを強制指定して脱出
データベースのhome・siteurlを正しい値に修正
.htaccessの独自記述を確認、必要に応じてリネームして再生成
プラグインを一括無効化して、原因の切り分け

復旧後は、必ずブラウザのキャッシュをクリアしたうえで、複数の端末・ネットワークから動作確認を行うことを推奨いたします。再発防止策として、リダイレクト系プラグインの設定一覧を運用記録として保管しておくと、サーバー移転や大規模リニューアル時に役立ちます。

ご自身での切り分けが難しい場合は、無理に対処せず、サーバーのバックアップを確保した状態でご相談いただくのが安全でございます。