WordPressの常時SSL化設定とリダイレクトループ解消完全ガイド｜ERR_TOO_MANY_REDIRECTSとMixed Contentの直し方

WordPressサイトをHTTPからHTTPS（常時SSL）へ移行した直後、ブラウザに「ERR_TOO_MANY_REDIRECTS」や「リダイレクトが多すぎます」というエラー画面が表示され、サイトはおろか管理画面にすらアクセスできなくなってしまうトラブルは後を絶ちません。

常時SSL化は、現在のWebサイト運営において検索エンジンからの評価（SEO）や訪問者のセキュリティ保護、改ざん防止の観点から絶対に避けて通れない必須の設定です。しかし、WordPress特有の転送ロジックやサーバー・CDNのインフラ構成が絡み合うことで、予期せぬ無限リダイレクト（リダイレクトループ）に陥ることが頻繁に発生します。

本記事では、WordPressの常時SSL化直後に発生するリダイレクトループの根本原因をわかりやすく解説したうえで、管理画面に入れない状態から最短3分で復旧する緊急手順、主要サーバーやCloudflare・AWS ALBなどの環境別コピペ設定コード、そしてSSL化後に直面しやすい「混在コンテンツ（Mixed Content）」の完全解消手順までを網羅して詳しくお届けします。

なお、常時SSL化はサイトセキュリティの最も基本的かつ重要な土台です。WordPressサイト全体の総合的な防御策については『WordPressセキュリティ対策 完全ガイド』をあわせてご覧ください。

なぜ起きる？WordPressの常時SSL化でリダイレクトループ（ERR_TOO_MANY_REDIRECTS）が発生する仕組み

ブラウザでWebサイトを閲覧しようとした際、「ERR_TOO_MANY_REDIRECTS」と表示されるのは、ページAからページBへ、ページBからページAへと際限なく転送要求が繰り返され、ブラウザが処理の上限（通常20回前後）に達してアクセスを強制切断したためです。

常時SSL化においてこの無限ループが発生する典型的な流れは、以下の図のようになっています。

【リダイレクトループ発生のメカニズム】
1. ユーザーがブラウザで「https://example.com」にアクセス
   ↓
2. サーバー側（またはリバースプロキシ）の判定と、WordPress本体の判定が食い違う
   ↓
3. 一方が「この通信はHTTPだからHTTPSへ転送（301）」と命令
   もう一方が「内部的にはHTTPだから、正規URLへ再転送（301）」と命令
   ↓
4. ブラウザが両者の間で右往左往（HTTP ⇄ HTTPS の無限往復）
   ↓
5. ブラウザ側で「ERR_TOO_MANY_REDIRECTS」エラーを吐いて停止！

WordPressサイトにおいて、この競合が発生する主な要因は大きく分けて次の2つに集約されます。

WordPress本体のリダイレクト機能（canonical redirect）とサーバー設定の競合

最も初歩的かつ初心者が直面しやすいのが、WordPressのデータベースに登録されているURLと、サーバー側（.htaccessなど）の転送ルールの不一致です。

WordPressには、設定された正規URL（canonical URL）と異なるURLでアクセスされた場合に、正しいURLへと自動的に転送する機能（redirect_canonical）が標準で組み込まれています。

• 管理画面の「設定」→「一般」にある「WordPress アドレス (URL)」および「サイトアドレス (URL)」が http://example.com のままになっている
• サーバー側の .htaccess や Webサーバー設定で「すべてのアクセスを https://example.com へ強制転送する」というリダイレクトルールを記述した

この2つの条件が同時に揃うと、次のような無限転送が即座に発生します。

1. ユーザーが https://example.com にアクセスする。
2. WordPress本体が起動し、「登録されている正規URLは http://example.com なので、HTTPへ転送しよう」と判断して http://example.com へリダイレクト（301）を返す。
3. ブラウザが http://example.com に再接続する。
4. サーバーの .htaccess が「HTTPでのアクセスは許可しない。HTTPSへ転送せよ」と判断して https://example.com へリダイレクト（301）を返す。
5. 2に戻り、以降ブラウザがエラーを吐くまで永遠に繰り返される。

このように、「サーバーはHTTPSを強制したい」のに「WordPress本体はHTTPに戻そうとする」というルールの衝突が、初心者のSSL化トラブルの第一の原因です。

リバースプロキシ・CDN（Cloudflare・AWS ALB・ConoHa等）における「SSL終端」の罠

一方、Webサイト制作者やエンジニア、中級者が最もハマりやすいのが、リバースプロキシやCDNを挟んだ構成における「SSL終端（SSL Termination）」によるトラブルです。

現代のホスティング環境では、高速化やセキュリティ向上、負荷分散を目的として、WordPressサーバーの手前にリバースプロキシ（CDNやロードバランサー、キャッシュサーバー）を配置する構成が一般的です。代表的な例として以下が挙げられます。

• CloudflareなどのグローバルCDN
• AWS ALB（Application Load Balancer）やCloudFront
• ConoHa WINGやお名前.com レンタルサーバーなどの高機能共有サーバー（内部でNginxリバースプロキシを採用）
• KinstaやWP EngineなどのWordPress専用マネージドホスティング

これらの環境では、ブラウザとリバースプロキシの間は暗号化されたHTTPSで通信しますが、リバースプロキシから背後のWordPressサーバー（オリジンサーバー）への通信はHTTP（ポート80）で行われる構成（SSL終端）が採用されているケースが多々あります。

【SSL終端による誤認識の構図】
[ブラウザ] ──(HTTPS通信 / 暗号化)──> [リバースプロキシ / CDN]
                                               │
                                      (ここでSSLを復号・終端)
                                               ↓
                                     [WordPressオリジンサーバー]
                                     (HTTPで届くため「HTTP通信だ」と誤認！)

このとき、WordPressはPHPの標準環境変数である $_SERVER['HTTPS'] を参照してアクセスが暗号化されているかを判定します。しかし、オリジンサーバーに届いたパケットはHTTPであるため、PHP環境変数は $_SERVER['HTTPS'] = 'off'（または未定義）となります。

結果として、WordPress本体は「訪問者がHTTPでアクセスしてきた」と完全に誤認し、「正規URLであるHTTPSへ転送せよ」とリダイレクト指示を出します。ユーザーのブラウザは指示通りHTTPSで再度CDNへアクセスしますが、CDNは再びオリジンへHTTPでリクエストを投げるため、全く同じ判定が繰り返されてリダイレクトループに陥るのです。

【最短3分】管理画面に入れない状態からの緊急復旧ステップ

「リダイレクトループが発生して、WordPressのダッシュボード（管理画面）にアクセスできない！」「設定を変更しようにもログイン画面すら開かない！」という状況に陥った場合でも、焦る必要はありません。

データベースを直接操作することなく、FTPソフト（FileZilla等）またはサーバーのファイルマネージャーからファイルを2つ編集・確認するだけで、最短3分で管理画面へのログイン権限を取り戻すことが可能です。以下の手順を順番に実行してください。

※万が一、パスワード間違いやセキュリティプラグインによるブロックなど別の原因で締め出されている場合は、『WordPressにログインできない時の対処法』も参考に原因を切り分けてください。

ステップ1：wp-config.phpにURL上書き定数（WP_HOME / WP_SITEURL）を記述してアクセス回復

まず最初に行うべきは、データベースに保存されているURL設定を強制的に上書きして、一時的にアクセスを復旧させることです。

WordPressの公開ディレクトリ直下にある設定ファイル wp-config.php は、データベースの設定値よりも優先される強力な定義を行うことができます。

1. FTPソフトまたはサーバー管理画面のファイルマネージャーを開き、WordPressのインストールディレクトリ（通常 public_html やドメイン名フォルダ直下）へアクセスします。
2. wp-config.php をローカルPCにダウンロードし、バックアップとして複製を1つ保存しておきます。
3. テキストエディタで wp-config.php を開き、/* That's all, stop editing! Happy publishing. */（日本語環境では「編集が必要な部分はここまでです」）という行を探します。
4. その行の直前に、以下の2行を追記して保存・アップロードします。

// サイトURLを強制指定してリダイレクトループを遮断
define('WP_HOME', 'https://example.com');
define('WP_SITEURL', 'https://example.com');

※https://example.com の部分は、ご自身のサイトの正しいドメイン名（SSL証明書が有効なHTTPSのURL）に置き換えてください。サブディレクトリ運用の場合は https://example.com/wp のように指定します。

この2行を記述すると、WordPress管理画面の「設定」→「一般」画面でグレーアウト表示となり、強制的に https:// のURLで起動するようになります。データベースを直接SQLで書き換える必要がないため、最も安全かつ迅速な復旧手段です。

ステップ2：.htaccessを一時的に初期化（バックアップ退避）して強制リダイレクトを停止

ステップ1を実施してもループが止まらない場合、サーバー側の .htaccess に記述された転送ルールが暴走している可能性が極めて高いです。

サーバー側の強制転送を一時的に停止させるため、.htaccess を一旦退避させて初期化します。

1. WordPressのルートディレクトリにある .htaccess を .htaccess_backup などの名前に変更してバックアップします。
2. 新規に空の .htaccess ファイルを作成し、以下のWordPress標準のデフォルトコードのみを記述してアップロードします。

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

これにより、プラグインや手動で追記されたSSL転送コード、余計なリライトルールがすべて無効化され、WordPress本来のルーティングのみが動作するクリーンな状態に戻ります。

※なお、.htaccess の編集時に構文ミス（全角スペースの混入やタグ閉じ忘れ）があると、サイト全体が「500 Internal Server Error」で真っ白になることがあります。万が一500エラーが表示された場合は、『500 Internal Server Errorの解決手順』を参考に直前の変更を差し戻してください。

ステップ3：ブラウザキャッシュとCookie・HSTSキャッシュをクリアして確認

サーバー側のファイルを修正したにもかかわらず、ブラウザで相変わらず「ERR_TOO_MANY_REDIRECTS」が表示されるケースがあります。この原因の9割は、ブラウザ内部に記憶された301リダイレクトキャッシュです。

HTTPステータスコード「301 Moved Permanently」は「恒久的な転送」を意味するため、Chromeなどの現代のブラウザは一度受け取った301転送ルールを強力にローカルストレージへキャッシュします。サーバー側を正しく直しても、ブラウザがサーバーに問い合わせず過去のエラー結果を即座に適用してしまうのです。

この問題を解消するために、以下の3つの確認作業を行ってください。

1. シークレットウィンドウ（プライベートブラウズ）で開く：キャッシュの影響を一切受けないシークレットモード（Chromeなら Ctrl + Shift + N / Macなら Cmd + Shift + N）で該当URLにアクセスし、管理画面が開くか確認します。
2. ブラウザキャッシュとCookieを削除する：Chromeの「閲覧履歴データの削除」から、Cookieとキャッシュされた画像をクリアします。
3. ChromeのHSTSキャッシュをクリアする：過去にHSTS（Strict Transport Security）を有効にしていた場合、ブラウザの内部HSTSデータベースに登録されていることがあります。Chromeのアドレスバーに chrome://net-internals/#hsts と入力し、「Delete domain security policies」の入力欄に対象サイトのドメイン名を入力して「Delete」ボタンをクリックしてください。

ここまでの3ステップを行うことで、ほとんどすべてのリダイレクトループ状態から管理画面（https://example.com/wp-admin/）への正常なアクセスを取り戻すことができます。

【環境別コピペOK】リダイレクトループを解消するwp-config.php・.htaccess設定コード

アクセスが復旧した後は、根本的な原因を取り除く恒久設定を行いましょう。お使いのホスティング環境やCDN・ロードバランサーの構成に応じて、適切なコードスニペットをコピペして設定してください。

Cloudflare / AWS ALB / Nginxリバースプロキシ環境用のwp-config.phpコード（HTTP_X_FORWARDED_PROTO）

CloudflareなどのCDNや、AWSのロードバランサー（ALB / ELB）、社内Nginxリバースプロキシ配下でWordPressを運用している場合、最も確実にループを解消する決定打となる設定です。

リバースプロキシは、クライアントからの接続プロトコル（HTTPかHTTPSか）を判断し、背後のサーバーへ渡すHTTPリクエストのヘッダーに X-Forwarded-Proto: https を付与します。これをWordPress側で明示的に検知して、PHPの $_SERVER['HTTPS'] = 'on' を強制設定します。

wp-config.php の最上部付近（define('DB_NAME', ...); よりも前、またはファイルの先頭 <?php の直後）に、以下のコードを記述してください。

// リバースプロキシ・CDN（Cloudflare/ALB等）のSSL終端ループ解消コード
if (
    (isset($_SERVER['HTTP_X_FORWARDED_PROTO']) && $_SERVER['HTTP_X_FORWARDED_PROTO'] === 'https') ||
    (isset($_SERVER['HTTP_X_FORWARDED_SSL']) && $_SERVER['HTTP_X_FORWARDED_SSL'] === 'on')
) {
    $_SERVER['HTTPS'] = 'on';
}

【⚠️ 記述場所に関する絶対厳守の注意点】
このコードは、必ず require_once ABSPATH . 'wp-settings.php'; よりも前に記述してください。wp-settings.php が読み込まれた時点でWordPressのURL判定処理が完了してしまうため、ファイルの末尾に書いても全く効果がありません。

なお、Cloudflareをお使いの場合は、Cloudflare管理画面の「SSL/TLS」設定メニューで暗号化モードが「Flexible（フレキシブル）」になっていないかを必ず確認してください。「Flexible」モードはCloudflareとオリジン間を強制的にHTTPで通信するため、WordPress側のSSL転送と無限に衝突します。オリジンサーバー側に無料のSSL証明書（Let’s Encrypt等）またはCloudflare Origin CA証明書をインストールし、モードを「Full」または「Full (strict)」に変更することが根本的な解決策です。

ConoHa WING / お名前.com RSプラン等でループする場合のwp-config.php設定

国内のレンタルサーバーである「ConoHa WING」や「お名前.com レンタルサーバー（RSプラン）」は、高速化のためにWebサーバーの前段に独自のNginxプロキシを採用しています。

無料独自SSLを有効化してWordPressアドレスを https:// に変更した際にリダイレクトループが発生する場合、プロキシが引き渡すヘッダーをWordPressが認識できていないことが原因です。

この場合も、wp-config.php の先頭付近に以下の判定コードを追加することで一発で解消します。

// ConoHa WING / GMO系サーバー用 HTTPS強制認識コード
if (isset($_SERVER['HTTP_X_FORWARDED_PROTO']) && $_SERVER['HTTP_X_FORWARDED_PROTO'] === 'https') {
    $_SERVER['HTTPS'] = 'on';
    $_SERVER['SERVER_PORT'] = 443;
}

ConoHa WINGでは、管理画面の「サイト設定」→「応用設定」→「.htaccess設定」において、独自のリライトルールが自動挿入されることがあります。上記PHPコードを追加したうえで、サーバーコントロールパネルから「かんたんSSL化」のスイッチが「ON」になっているかを再確認してください。

エックスサーバー・さくら等（標準Apache）の.htaccessによる常時SSL 301リダイレクト記述

エックスサーバー（Xserver）、さくらのレンタルサーバ、ロリポップ！などの標準的なApache環境では、.htaccess を用いてHTTPリクエストをHTTPSへ恒久転送（301リダイレクト）するのが最も安全かつSEO上推奨される正統派の手法です。

WordPressの自動生成コード（# BEGIN WordPress）を壊さないよう、# BEGIN WordPress よりも上の行に以下のコードを追記してください。

# --- HTTPからHTTPSへの常時SSL 301リダイレクト ---
<IfModule mod_rewrite.c>
RewriteEngine On
RewriteCond %{HTTPS} off
RewriteRule ^(.*)$ https://%{HTTP_HOST}%{REQUEST_URI} [R=301,L]
</IfModule>

# BEGIN WordPress
# （以下、WordPress標準コード）

この記述により、「%{HTTPS} off（暗号化されていないアクセス）」の場合のみ、URLのパスやクエリ文字列を完全に保持したまま https:// の同一URLへと1度だけ301リダイレクトされます。これにより検索エンジンのインデックスや被リンクのSEO評価を失うことなく、スムーズに常時SSLへ完全移行できます。

管理画面（/wp-admin/）だけがリダイレクトループする場合の専用対処法

「サイトのトップページや記事ページは問題なくHTTPSで閲覧できるのに、なぜか https://example.com/wp-admin/ にアクセスした時だけリダイレクトループが発生してログイン画面に到達できない」という特殊なトラブルに見舞われることがあります。

この原因の多くは、WordPressに備わっている管理画面専用のSSL強制定数 FORCE_SSL_ADMIN の誤作動です。

WordPressでは、セキュリティを高めるために wp-config.php で以下の記述を行うことが推奨されています。

define('FORCE_SSL_ADMIN', true);

しかし、前述のリバースプロキシ構成やSSL終端環境下において、WordPress本体が「現在はHTTPSでアクセスされている」と判定できていない場合、この定数が悪影響を及ぼします。

1. 管理画面へアクセスする。
2. FORCE_SSL_ADMIN が有効なため、WordPressは「管理画面はHTTPSでなければならない。HTTPSへ転送せよ」とリダイレクトを発行する。
3. サーバーがプロキシ経由で受け取った際、WordPressが再び「現在はHTTPだ」と誤認識する。
4. 2と3が無限に繰り返され、管理画面だけが「ERR_TOO_MANY_REDIRECTS」で開けなくなる。

【対処手順】

1. 一次復旧（ループ停止）：
   wp-config.php を開き、define('FORCE_SSL_ADMIN', true); を探して define('FORCE_SSL_ADMIN', false); に変更するか、行頭に // を付けてコメントアウトします。これで管理画面へのアクセスが可能になります。
2. 根本解決（プロキシ判定コードの追加）：
   前述の HTTP_X_FORWARDED_PROTO 判定コードを wp-config.php の先頭に追加します。このコードが存在していれば、WordPressは管理画面へのアクセスがHTTPSであることを正しく検知できるため、再び define('FORCE_SSL_ADMIN', true); に戻してもループすることなく安全に運用できます。

SSL化したのに鍵マークがつかない？混在コンテンツ（Mixed Content）の完全解消法

リダイレクトループが無事に解消してサイトがHTTPSで表示されるようになっても、アドレスバーのURL横に「保護されていない通信」や「！」マークが表示され、安全な鍵マーク（🔒）がつかないというトラブルが頻発します。

これは「混在コンテンツ（Mixed Content / ミックスドコンテンツ）」と呼ばれる状態で、HTTPSで保護されたページの中に、依然として http:// で始まる非暗号化の画像・スクリプト・スタイルシートが混ざり込んで読み込まれていることが原因です。

Google Chromeなどの主要ブラウザは、セキュリティ保護のため非暗号化スクリプトを自動的に読み込みブロックします。その結果、デザインが大きく崩れたり、機能が動かなくなったり、訪問者に「危険なサイト」という強い不信感を与えて離脱率を高めてしまう重大なリスクがあります。

混在コンテンツをゼロにして、すべてのページで完全な鍵マークを表示させるための3ステップを解説します。

ブラウザのデベロッパーツール（Console）で警告・ブロック要素を特定する

まずは、どの画像やファイルが http:// のまま読み込まれているのかを突き止めます。これにはブラウザ標準の「デベロッパーツール（検証機能）」を使うのが最も手軽で確実です。

1. Google Chromeで鍵マークがつかない該当ページを開きます。
2. キーボードの F12 キー（Macは Cmd + Option + I）を押すか、ページ上で右クリックして「検証」を選択します。
3. 上部タブから「Console（コンソール）」をクリックします。
4. 画面内に赤色または黄色の文字で以下のようなエラーログが出力されていないか確認します。

Mixed Content: The page at 'https://example.com/sample-post/' was loaded over HTTPS, but requested an insecure element 'http://example.com/wp-content/uploads/image.jpg'. This request was automatically upgraded to HTTPS, or this request has been blocked; the content must be served over HTTPS.

このメッセージの後方に表示されているURL（上記例なら http://example.com/wp-content/uploads/image.jpg）が、混在コンテンツを引き起こしている犯人です。画像のURLなのか、外部から読み込んでいるJavaScriptやフォントファイルなのかを確認しましょう。

データベース内のhttpリンクを一括置換する手順（Better Search Replace活用法）

過去に執筆した記事本文内の画像パスや内部リンクは、WordPressのデータベース（wp_posts テーブル等）の中に http://example.com/... の文字列としてそのまま保存されています。記事数が数百本ある場合、手動で1記事ずつ修正するのは現実的ではありません。

ただし、WordPressのデータベースには「シリアライズデータ（文字列の長さ情報を保持した配列データ）」が多数含まれており、通常のSQL文（REPLACE文）やテキストエディタで一括置換するとデータ構造が壊れ、サイト設定やウィジェットが消し飛ぶ危険があります。

そこで活用すべき定番の無料プラグインが「Better Search Replace」です。シリアライズデータを自動計算しながら安全にデータベース内を一括置換できます。

1. プラグインのインストール：
   WordPress管理画面の「プラグイン」→「新規追加」から「Better Search Replace」を検索し、インストールして有効化します。
2. 事前バックアップの取得：
   置換作業の前に、必ずデータベースのバックアップ（UpdraftPlusなどのプラグイン利用またはphpMyAdminエクスポート）を取得しておきます。
3. 置換設定の入力：
   管理画面の「ツール」→「Better Search Replace」を開き、設定画面で以下を入力します。
   • Search for（検索対象）：http://example.com（旧HTTPのサイトURL）
   • Replace with（置換文字列）：https://example.com（新HTTPSのサイトURL）
   • Select tables（対象テーブル）：すべてのテーブルを選択（Windowsなら Ctrl + A、Macなら Cmd + A）
   • Case-Insensitive?（大文字小文字を区別しない）：チェックなしでOK
   • Replace GUIDs?：通常はチェック不要（RSSリーダー等の既読フラグに関わるため）
   • Run as dry run?（テスト実行）：必ずチェックを入れる！
4. テスト実行（Dry Run）：
   「Run Search/Replace」ボタンをクリックします。Dry Run中は実際のデータ変更は行われず、「何件のセルが置換対象として見つかったか」の集計結果のみが表示されます。
5. 本番実行：
   テスト結果に問題がなければ、「Run as dry run?」のチェックを外し、再度「Run Search/Replace」を実行します。

置換が完了したら、プラグイン「Better Search Replace」はセキュリティ上、作業後に停止・削除しておくことをおすすめします。

テーマ・ウィジェット・外部CSS/JSの直接参照をhttpsへ修正

データベース内の置換を行っても鍵マークがつかない場合、テーマのテンプレートファイル（header.phpやfooter.php）やウィジェット、テーマカスタマイザーの設定に直接 http:// がハードコード（直書き）されているケースが疑われます。

• サイトのロゴ画像・ファビコン：
  「外観」→「カスタマイズ」→「サイト基本情報」等で設定されているロゴ画像が http:// のまま保存されていることがあります。一度画像を削除し、メディアライブラリから再選択して保存し直してください。
• ウィジェット内のバナーやHTML：
  「外観」→「ウィジェット」のカスタムHTMLやテキストブロック内に、外部バナーやアフィリエイトリンクが http:// で貼られていないか点検します。
• 子テーマのスタイルシートやテンプレート：
  子テーマの functions.php や style.css 内で、外部Webフォント（Google Fonts等）や外部JSライブラリを http:// から読み込んでいないか確認し、すべて https:// に書き換えます。
• プロトコル相対URLの注意：
  昔よく使われていた //example.com/script.js のような「プロトコル相対URL」は、現在のWeb標準では非推奨です。明示的に https:// を記述してください。

初心者でも失敗しないWordPress常時SSL化の正しい手順（事前準備〜完了）

ここまでリダイレクトループや混在コンテンツのトラブルシューティングを詳しく解説してきましたが、そもそも正しい手順と順番を守って作業を進めれば、トラブルの99%は未然に防ぐことができます。

今後別のサイトを常時SSL化する際や、知人に手順を案内する際は、以下の「王道の4ステップ」に沿って作業を行ってください。

【WordPress常時SSL化の王道4ステップ】
ステップ①：サーバー側で無料独自SSLを発行し、ブラウザで開けるか事前確認
    ↓
ステップ②：WordPress管理画面で「アドレス（URL）」をhttpsへ書き換える
    ↓
ステップ③：.htaccessに「HTTP→HTTPS」の301リダイレクト設定を追記する
    ↓
ステップ④：混在コンテンツ（Mixed Content）の解消と鍵マークの点検

【ステップ①：サーバー側での無料独自SSL発行と開通確認】
最も重要な鉄則は、「サーバー側でSSL証明書が有効になる前に、WordPressの設定をいじらないこと」です。
エックスサーバー、ConoHa WING、ロリポップ！などのコントロールパネルから無料独自SSL（Let’s Encrypt）を申し込みます。発行申請から反映までには数分〜数時間かかります。必ずブラウザのアドレスバーに手動で https://example.com と打ち込み、証明書エラー（「この接続ではプライバシーが保護されていません」）が出ずにサイトが表示されることを確認してから次のステップへ進んでください。

【ステップ②：WordPress管理画面でのURL変更】
管理画面の「設定」→「一般」を開きます。「WordPress アドレス (URL)」と「サイトアドレス (URL)」の2箇所を、http:// から https:// へ変更し、「変更を保存」をクリックします。
保存した瞬間にログアウトされ、HTTPSのログイン画面に自動遷移します。再度ログインできることを確認します。

【ステップ③：.htaccessによる301リダイレクト転送の追加】
ステップ②まででは、従来の http:// にアクセスしてきたユーザーが暗号化されないまま表示されてしまいます。前述した .htaccess の301リダイレクトコードを追記し、すべてのアクセスを自動的に https:// へ転送するように設定します。

【ステップ④：混在コンテンツの解消と各ページの鍵マーク点検】
トップページだけでなく、投稿記事、カテゴリーアーカイブ、お問い合わせフォームなど主要なページを巡回し、ブラウザのアドレスバーに安全な鍵マークが点灯しているかを最終確認します。

常時SSL化完了後に必ずやるべきSEO・セキュリティ必須設定

サイトがHTTPSで表示されるようになったら、SSL化の作業は終わりではありません。検索エンジンへの評価引き継ぎ（SEO対策）やアナリティクス解析、セキュリティの更なる強化のために、以下の必須設定を速やかに完了させてください。

1. Google Search Consoleのプロパティ登録とサイトマップ送信：
   Google Search Consoleでは、http:// と https:// は「完全に別のサイト」として扱われます。
   ドメインプロパティ（DNS認証）で登録している場合は自動的に合算されますが、URLプレフィックスプロパティで登録している場合は、新しく https://example.com のプロパティを追加作成する必要があります。追加後、XMLサイトマップ（sitemap.xml）を送信し、GoogleクローラーにHTTPS版のクロールを促しましょう。
2. Googleアナリティクス（GA4）のデータストリームURL更新：
   GA4の管理画面から「データストリーム」を開き、該当するウェブストリームの詳細設定で「ウェブサイトのURL」を http:// から https:// に変更します。測定ID自体は変わらないためタグの貼り替えは不要ですが、レポートの整合性を保つために必ず更新しておきましょう。
3. SNSシェア設定（OGP）や外部サービスの登録URL変更：
   Twitter（X）カードやFacebook OGPの設定、各種ASP（アフィリエイトサービス）、決済サービス（StripeやPayPal等）のWebhook URLや登録サイトURLを https:// へ順次更新します。
4. HSTS（HTTP Strict Transport Security）ヘッダーの導入検討：
   HSTSとは、ブラウザに対して「今後このドメインへの接続は、たとえユーザーが http:// と入力しても、初回から必ずHTTPSで接続せよ」と命令するセキュリティヘッダーです。
   初回接続時の中間者攻撃（SSL Strip攻撃）を完全に防ぐ強力なセキュリティ対策ですが、万が一HTTPSが利用できなくなった際にサイトが一切開けなくなるリスクもあります。まずは短い期間（例：max-age=300）からテストし、安定稼働を確認したうえで max-age=31536000（1年間）などの本番設定を適用するのが安全です。

🔍 WordPressサイトのSSL設定・セキュリティリスクを今すぐ無料診断

まとめ：リダイレクトループは仕組みを理解すれば即座に解決できる

WordPressサイトの常時SSL化に伴うリダイレクトループ（ERR_TOO_MANY_REDIRECTS）は、突然画面が開かなくなるため非常にショッキングなトラブルですが、「サーバー側の設定」と「WordPress本体の認識」のズレを解消すれば、100%確実に解決できるエラーです。

最後に、本記事の重要ポイントを振り返ります。

• 緊急復旧：まずは wp-config.php に WP_HOME と WP_SITEURL を追記し、.htaccess を初期化して管理画面のアクセス権を取り戻す。
• リバースプロキシ対策：CloudflareやAWS ALB、ConoHa WING環境では、wp-config.php に HTTP_X_FORWARDED_PROTO の検知コードを必ず wp-settings.php より前に追加する。
• 301転送：Apache環境では .htaccess の先頭で安全にHTTPSへ301リダイレクトし、SEO評価を引き継ぐ。
• 混在コンテンツの根絶：「Better Search Replace」プラグインでDB内の http:// を安全に一括置換し、完全な鍵マークを表示させる。
• 事後対応：Search ConsoleのHTTPSプロパティ登録やサイトマップ送信を忘れずに行う。

暗号化通信は、サイトに訪れるユーザーのプライバシーと信頼を守るための第一歩です。正しい知識と設定手順で安全なHTTPSサイト運用を実現しましょう。

関連記事・あわせて読みたいセキュリティ対策ガイド