リダイレクトループの原因切り分けと直し方｜htaccess対処

「このページは動作していません」「ERR_TOO_MANY_REDIRECTS」と表示されて、サイトが真っ白になっていませんか。リダイレクトループは、放置するとGoogleにインデックスされず検索順位も落ちる、地味に深刻なトラブルです。

この記事は、WordPressや自社サイトを自分たちで運用している中小企業の担当者に向けて、リダイレクトループの原因を切り分ける順番と、.htaccessやCMS設定の直し方を具体的に解説します。読み終わる頃には、どこで無限転送が起きているかを自分で特定し、安全に直す道筋が立てられる状態を目指します。

SSL化やサーバー移転の作業がまだの方は、先に.htaccessでhttpをhttpsへ301リダイレクトする手順を確認しておくと、この記事の内容がつながりやすくなります。

Contents / 目次

1. まず結論。原因を5タイプに切り分けてから直す
2. 原因を切り分ける手順。上流から5分で確認する
3. 原因別の直し方。htaccessとWordPress設定の具体策
4. 直したあとに確認すること。再発を防ぐチェック
5. よくある失敗と回避法
6. 業者に頼む前に知っておきたい現場の落とし穴
7. よくある質問

まず結論。原因を5タイプに切り分けてから直す

リダイレクトループとは、AがBへ、BがまたAへと転送し合い、ブラウザが行き先を決められずに止まってしまう状態のことです。だから直し方の前に、まず「どこで転送がぶつかっているか」を切り分けるのが最短ルートになります。いきなり.htaccessを書き換えると、別の原因だった場合に傷口が広がります。

原因はおおむね次の5タイプに分かれます。上流（サーバー側）から下流（ブラウザ側）へ順番に疑っていくのがコツです。

原因タイプ	よくある症状	主な対処
.htaccessの記述ミス	サイト全体で発生。SSL化やwww統一の直後から	リダイレクト記述を見直す
WordPressのURL設定	WordPress全体が表示不能。管理画面も入れない	アドレス設定とwp-config.phpを確認
プラグイン・テーマ	特定機能の追加後に発生	1つずつ無効化して切り分け
SSL・サーバー環境	HTTPS化後、常時SSLの二重設定で発生	転送設定を1か所に一元化
キャッシュ・CDN・ブラウザ	自分だけ再現、他の人は正常	キャッシュ削除・シークレットで確認

ポイント。ループが「サイト全体」で起きているか「一部ページだけ」かを最初に見極めましょう。全体なら.htaccessかWordPressのURL設定、一部だけならプラグインやページ個別のリダイレクト設定が疑わしくなります。

ここで大事なのは、原因を1つに決めつけないことです。SSL化とサーバー移転を同時にやったあとなど、複数タイプが絡んでループしているケースは現場でよく見かけます。だからこそ、次に説明する「順番に確認する切り分け手順」が効いてきます。

原因を切り分ける手順。上流から5分で確認する

切り分けは「上流のサーバー側」から「下流のブラウザ側」へ順に確認していきます。この順番を守ると、無駄な設定変更をせずに原因へたどり着けます。以下のステップで進めましょう。

ステップ1。本当にループか、範囲はどこかを確認する

最初に、症状の範囲を確定させます。ブラウザに「リダイレクトが繰り返し行われました」「ERR_TOO_MANY_REDIRECTS」と出ていればループで確定です。

次に、トップページだけなのか、全ページなのか、特定の1ページだけなのかをメモします。範囲が分かるだけで、上の表のどのタイプかがかなり絞れます。全ページなら共通設定（.htaccessやCMSのURL）、1ページだけなら個別のリダイレクト設定が原因、という当たりがつきます。

ステップ2。自分の環境のせいかを切り分ける

「自分だけ」の問題かどうかを先に消し込みます。ここを飛ばすと、サーバーは正常なのに設定をいじってしまう事故が起きます。

• シークレットモードで開く：Chromeなら新しいシークレットウィンドウで同じURLを開く。ここで正常なら原因はキャッシュか拡張機能側
• 別の回線・別端末で開く：スマホの4G/5G回線でも試す。他の人は正常に見えているかを聞く
• Cookieとキャッシュを削除する：そのサイトのCookieを消してから再アクセスする

これで直るなら、サイト側は正常でブラウザ側の一時的な問題だった、という結論になります。逆に、シークレットでも別端末でもループするなら、サーバー・CMS側の設定が原因で確定です。次のステップに進みます。

ステップ3。リダイレクトチェッカーで経路を可視化する

サーバー側が原因と分かったら、転送が実際にどう回っているかを目で見ます。「リダイレクトチェッカー」と検索すると、URLを入れるだけで転送経路とステータスコード（301や302）を一覧表示してくれる無料ツールが見つかります。ブラウザの拡張機能で経路を表示するタイプもあります。

ここで見たいのは、たとえば「http://→https://→http://→…」のように、httpとhttpsを行ったり来たりしていないか、あるいは「wwwあり→wwwなし→wwwあり」で往復していないか、という点です。往復が見えたら、その2か所のどちらかの設定が余計だと分かります。

ステップ4。Google Search Consoleでエラーを確認する

公開中のサイトなら、Google Search Consoleでインデックスの状況も見ておきます。クローラーがページを正しく取得できているか、転送まわりで報告されている問題がないかを確認できます。うまく取得できていないURLは、検索結果から落ちている可能性が高いので、直したあとに再登録をリクエストします。再登録の具体手順はインデックス未登録の原因と再登録の手順で解説しています。

ステップ5。直す前にバックアップを取る

原因の当たりがついても、いきなり直さないでください。.htaccessやwp-config.phpを触る前に、必ず元ファイルをダウンロードして手元に保存します。WordPressなら、バックアップ系プラグインで一式を取ってから作業すると安全です。「設定を戻せば元に戻る」状態を作ってから初めて、次の直し方に進みましょう。

原因別の直し方。htaccessとWordPress設定の具体策

ここからが実際の修正です。切り分けで絞ったタイプごとに、直し方を具体的に見ていきます。コードはコピペして使えますが、ドメイン名などは自社の値に必ず書き換えてください。

SSL化のhttp→httpsが往復している場合

HTTPS化の直後にループが起きたら、まずこれを疑います。原因の多くは「サーバー管理画面の常時SSL設定」と「.htaccessに手書きしたhttps転送」が二重にかかっていることです。片方に絞れば直ります。

.htaccessでhttpsへ転送する場合、ロードバランサーやCDNをはさむサーバーでは、次のようにプロトコルの判定を二重にしておくとループを防げます。

# HTTPからHTTPSへ301リダイレクト（プロキシ・CDN環境でのループ回避版）
# 設置場所 = ドキュメントルート直下の .htaccess、WordPressなら # BEGIN WordPress より前
<IfModule mod_rewrite.c>
RewriteEngine On
RewriteCond %{HTTPS} off
RewriteCond %{HTTP:X-Forwarded-Proto} !https
RewriteRule ^(.*)$ https://%{HTTP_HOST}%{REQUEST_URI} [R=301,L]
</IfModule>

ポイントは2行目の条件です。CDNやロードバランサーの内側では、サーバーから見ると通信がhttpに見えることがあります。そのまま転送するとhttpsにしたつもりが延々とループします。「X-Forwarded-Proto」がhttps以外のときだけ転送する、という条件を足すと、内側がhttp扱いでも往復しなくなります。

サーバーの管理画面に「常時SSL化」「無料独自SSL」のワンクリック設定がある場合、それと上のコードが両方効くと二重転送になります。どちらか一方にしてください。管理画面側で完結するなら、.htaccessの手書き転送は削除するのが安全です。

wwwあり・なしが往復している場合

「www.example.com」と「example.com」を統一しようとして、片方だけの設定を意図せず二重にかけるとループします。統一の記述は次のように1回だけにします。wwwなしに寄せる例です。

# wwwあり → wwwなし に統一（httpsもまとめて寄せる）
<IfModule mod_rewrite.c>
RewriteEngine On
RewriteCond %{HTTP_HOST} ^www\.example\.com$ [NC]
RewriteRule ^(.*)$ https://example.com/$1 [R=301,L]
</IfModule>
# ↑ example.com の部分を自社ドメインに書き換える

www統一の設定は、httpsへの転送と考え方が近く、混ざりやすい部分です。設定の順番や重複でつまずいたら、wwwあり・なしをhtaccessで統一する手順と注意点で条件の書き方を確認してください。

WordPressで管理画面にも入れなくなった場合

WordPress全体が表示できず、管理画面（wp-admin）にすら入れないなら、URL設定の不一致を疑います。原因は、管理画面の「WordPress アドレス」と「サイトアドレス」がhttpとhttpsでズレている、あるいは片方だけwww付きになっている、というパターンです。

管理画面に入れないときは、wp-config.phpに次の2行を書いて強制的にURLを固定します。ファイルの上のほう、「/* 編集が必要なのはここまでです */」より前に追記します。

// WordPressのURLを一時的に固定してループを止める
// example.com は自社ドメインに変更。http/https・www有無を実態に合わせる
define('WP_HOME','https://example.com');
define('WP_SITEURL','https://example.com');

これで表示が戻ったら、管理画面の「設定」→「一般」を開き、2つのアドレスが完全に同じ表記になっているかを確認します。両方をhttps・wwwなしなど1つの形にそろえるのが基本です。落ち着いたら、上のwp-config.phpの2行は消しても構いません（残しても動きます）。

もう1つ、CDNやリバースプロキシ環境のWordPressでは、サーバー側がhttpと認識してリダイレクトが暴走することがあります。その場合はwp-config.phpに次を追記すると安定します。

// プロキシ経由でもHTTPSと正しく認識させる（ループ対策）
if (isset($_SERVER['HTTP_X_FORWARDED_PROTO']) && strpos($_SERVER['HTTP_X_FORWARDED_PROTO'], 'https') !== false) {
    $_SERVER['HTTPS'] = 'on';
}

プラグインが原因の場合

特定の機能を追加した直後にループが始まったなら、プラグインが怪しいです。リダイレクト系・SSL系・キャッシュ系のプラグインは、.htaccessやサーバー設定と機能が重なってぶつかりやすい傾向があります。

管理画面に入れるなら、怪しいプラグインを1つずつ無効化して、どれで直るかを確認します。管理画面に入れない場合は、FTPやサーバーのファイルマネージャーで「wp-content/plugins」フォルダの中の該当プラグインのフォルダ名を一時的にリネームすると、そのプラグインだけ強制停止できます。直ったら、そのプラグインの設定を見直すか、機能が重複している別の設定を外します。

直したあとに確認すること。再発を防ぐチェック

ループが消えても、それで終わりにしないでください。「たまたま自分の画面で直って見えるだけ」で、検索エンジンや他のユーザーにはまだループが残っているケースがあるからです。直後に次を確認します。

• シークレットモードで全経路を再確認：キャッシュの影響を消した状態で、トップと主要ページを開く
• リダイレクトチェッカーで転送回数を見る：目的のURLへ301が1回で着地しているか。2回以上の転送（チェーン）が残っていないか
• Search Consoleで再登録をリクエスト：ループが起きていたURLを再検査に出す

特に見落とされがちなのが「リダイレクトチェーン」です。ループは直ったけれど、httpからhttpsへ、さらにwwwなしへ、と転送が2回3回と連なっている状態のことです。これは無駄な転送が増えるぶん、ページ表示が少し遅くなる原因になります。理想は、どのURLからでも最終形のURLへ「301が1回」で着地する形です。

表示速度の観点で気になる場合は、Core Web Vitalsを自分で測って直す手順もあわせて確認すると、転送の無駄が体感速度にどう効くか分かります。

再発防止の基本。リダイレクトの設定場所は「.htaccess」「サーバー管理画面」「プラグイン」「wp-config.php」と複数あります。どこで何を設定したかを1枚のメモに残し、転送は1か所に集約するのが、いちばん効く再発防止策です。

よくある失敗と回避法

現場で実際にやりがちな失敗を、起きる状況ごとに整理します。同じ穴にはまらないように、先回りで潰しておきましょう。

失敗1。SSL化のとき転送を二重にかけてしまう

サーバー管理画面の「常時SSL化」をオンにしたうえで、さらに.htaccessにもhttps転送を手書きしてしまうパターンです。両方が効くと、httpsにしたはずの通信をまたhttpsへ転送し続けてループします。回避法はシンプルで、https転送は必ずどちらか1か所だけにすること。管理画面で完結できるなら.htaccessの手書きは入れない、と決めておくと事故が減ります。

失敗2。直す前にバックアップを取らずに.htaccessを触る

.htaccessはサイト全体の入り口を握るファイルです。1文字間違えるとサイトが真っ白になり、しかも元がどうだったか思い出せず、余計に泥沼化します。この状況は「とりあえず直そう」と焦っているときほど起きます。回避法は、修正の直前に必ず元ファイルをダウンロードして手元に残すこと。戻せる状態を作ってから触れば、失敗しても数十秒で復旧できます。

失敗3。リニューアル時に全ページをトップへ転送する

サイトを作り直したとき、旧URLをまとめて新トップページへ301転送してしまう失敗です。一見きれいに見えますが、旧ページと新トップが条件次第で転送し合ってループしたり、旧ページの評価はトップに引き継がれず（Googleはこうした一括転送を評価の引き継ぎ対象とはみなしません）、個別ページが検索から消えたりします。回避法は、旧ページと新ページを1対1で対応させて転送すること。手間はかかりますが、これが評価を引き継ぐ唯一の正攻法です。移転作業そのものはWordPressのサーバー引っ越し手順も参考にしてください。

失敗4。テスト環境のnoindexや転送を本番で消し忘れる

制作中のテスト環境に入れておいた「本番へ飛ばす転送」や検索避けの設定を、公開後に消し忘れるパターンです。本番同士で転送が絡んでループしたり、検索に載らないままになったりします。回避法は、公開直後のチェックリストに「テスト用の転送・noindexを外したか」を必ず入れておくこと。公開作業と撤去作業をセットにしておくと抜けません。

業者に頼む前に知っておきたい現場の落とし穴

ここは教科書には載りにくい、現場で見えた本音の部分です。自分で直すか、プロに任せるかを判断する材料にしてください。

まず率直に言うと、リダイレクトループは「原因が1つなら自分で直せる、複数絡むと一気に難しくなる」トラブルです。SSL化だけ、www統一だけ、といった単純な原因なら、この記事の手順で十分に直せます。一方で、サーバー移転とSSL化とCDN導入を同時にやった直後のループは、設定が何層にも重なっていて、切り分けだけで半日以上かかることも珍しくありません。

次に、コストの見落としです。自分で直す場合、費用はゼロに見えますが、実際には「サイトが止まっている時間」というコストが発生しています。

BtoBサイトなら、問い合わせの入り口が数時間止まるだけで、機会損失は決して小さくありません。触った経験が少ない状態で本番の.htaccessを何度も試行錯誤するより、早めに詳しい人へ相談したほうが結果的に安く済む、という場面は現実にあります。

業者に頼むときの見極めも一言添えます。「とりあえず全部トップへ転送しておきますね」と言う相手には注意が必要です。前述のとおり、これはSEO評価を捨てる直し方です。旧URLと新URLを1対1で対応させる作業を、面倒がらずに提案してくれるかどうかが、信頼できる相手かの分かれ目になります。

「自分で直せそうだけど、本番でいきなり試すのは怖い」という感覚は正しい判断です。入り口を握る.htaccessやDNSまわりは、失敗の影響がサイト全体に及びます。自信が持てない箇所は、無理に本番で試さず、詳しい人に確認してもらってから進めるのが安全です。

よくある質問

まずは今すぐ、自社サイトのURLをシークレットモードで開き、ループが自分の環境だけの問題かどうかだけ確認してみてください。それだけで原因の切り分けが一段進みます。SSL化やドメイン統一の設定に不安が残る方は、httpからhttpsへ301リダイレクトする手順もあわせて読むと、転送設定の全体像がつかめます。

ここまで読んで、原因が複数絡んでいそう、本番でいきなり触るのは怖い、と感じた方は、無理をせず一度ご相談ください。コレットラボのAIで作るサイト・運用の伴走支援では、リダイレクトやSSLまわりの設定整理から、自社で直せる体制づくりまでお手伝いしています。現状を整理するだけの相談でも大丈夫です。まずはお話を聞かせてください。AI業務システム化の詳細はこちらからご覧いただけます。