WordPressをSSL化したのに、ブラウザで「保護されていない通信」「安全ではありません」と表示される場合、証明書そのものに問題があるとは限りません。ページ本体はHTTPSでも、画像、CSS、JavaScript、フォント、動画などをHTTPで読み込むと、Mixed Content（混在コンテンツ）になります。
安全に直すポイントは、証明書エラー、WordPressのURL設定、ページ内のHTTP資源を混同しないことです。ブラウザが示す非保護の資源URLを特定し、その発生元だけをHTTPSへ直します。
バックアップを取らずに、データベース内の「http」を「https」へ一括置換しないでください。外部サイトのURL、意図的な文字列、シリアライズされた設定まで壊すおそれがあります。
この記事では、現在の症状を見分け、Mixed Contentの場所を特定し、投稿・画像・テーマ・プラグイン・キャッシュの順に安全に修正する方法を解説します。
先に結論：保護されていない表示は7段階で直す
| 順番 | 確認すること | 目的 |
|---|---|---|
| 1 | 証明書エラーかMixed Contentかを確認 | 修正先を間違えない |
| 2 | 問題が出るURLと範囲を記録 | 全体設定か個別ページかを分ける |
| 3 | ブラウザで非保護の資源URLを特定 | 推測ではなく対象を確定する |
| 4 | WordPressアドレスとサイトアドレスを確認 | 共通URLの不整合を見つける |
| 5 | 投稿・画像・テーマ・プラグインを対象限定で修正 | 原因箇所だけを直す |
| 6 | キャッシュとCDNを更新 | 修正前のHTMLやCSSを残さない |
| 7 | 複数ページと重要機能を再確認 | 直し残しと表示崩れを防ぐ |
WordPress公式のHTTPSは、TLS/SSL証明書がWebサーバーで利用できることを前提にWordPressがHTTPSへ対応すると説明しています。一方、W3CのMixed Content仕様は、安全な文書が非安全な接続の資源を取得する状態を扱います。まずサーバー証明書とページ内資源を分けて確認します。
証明書エラーとMixed Contentの違い
| 症状 | 主な原因 | 優先する確認 |
|---|---|---|
| 接続前に強い警告画面が出る | 証明書の期限切れ、対象ドメイン不一致、信頼経路の問題 | 証明書の対象・有効期限・サーバー設定 |
| ページは開くが保護されていない表示 | HTTPSページ内にHTTPの画像・CSS・スクリプトなどがある | ブラウザのセキュリティ・ネットワーク表示 |
| URL自体がhttpのまま | HTTPSへの移行・転送・WordPress URL設定が未完了 | WordPressアドレス、サイトアドレス、転送 |
| 一部のページだけ警告 | 本文、ウィジェット、個別テンプレートの古いURL | 問題ページ固有の資源URL |
| 自分の端末だけ古い警告 | ブラウザ、WordPress、CDNのキャッシュ | 修正後の配信HTMLとキャッシュ層 |
証明書が期限切れ、別ドメイン用、未発行の場合は、本文URLを直しても解決しません。契約サーバーで証明書の状態を確認し、必要ならサポートへ依頼してください。逆に証明書が正常でも、ページ内に1件でもHTTP資源が残れば警告やブロックが起こり得ます。
Mixed Contentとは何か
ブラウザで開いたページのURLがhttps://でも、HTMLやCSSがhttp://の資源を参照していれば、ページ全体の通信が同じ強度で保護されません。たとえば、昔アップロードした画像、テーマCSSの背景画像、外部JavaScript、Webフォント、動画・地図の埋め込みが残ります。
ブラウザは資源の種類によって、自動的にHTTPSへ更新しようとしたり、読み込みを遮断したりします。結果として、鍵表示が変わるだけでなく、画像が消える、デザインが崩れる、メニューやフォームが動かないことがあります。「見えているから問題ない」と判断せず、非保護リクエストをゼロにします。
WordPressで残りやすいHTTP参照
- 投稿・固定ページ本文の画像とリンク
- 画像の
srcとレスポンシブ画像のsrcset - カスタムHTML、ショートコード、再利用ブロック
- ウィジェット、メニュー、ヘッダー、フッター
- テーマ設定、追加CSS、背景画像
- プラグインが生成するCSS・JavaScript・埋め込み
- 外部のフォント、解析、広告、動画、地図
- 移行前ドメインやテスト環境の絶対URL
画像URLを直しても、CSSの背景や外部スクリプトが残っていれば警告は消えません。反対に、全データを置換する前にブラウザで該当URLを見つければ、修正範囲を小さくできます。
手順1：問題が出るURLと範囲を記録する
- 警告が出る完全なページURL
- トップページ、記事、固定ページ、管理画面のどこで出るか
- すべてのページか一部のページか
- PCとスマートフォン、ログイン中とログアウト時の違い
- SSL化、移行、テーマ変更、プラグイン更新を行った日時
- 警告表示と欠けている画像・機能のスクリーンショット
全ページで同じHTTP資源が出るなら、ヘッダー、フッター、テーマ、共通プラグイン、WordPress URL設定を優先します。特定記事だけなら、その本文やアイキャッチ、個別埋め込みから調べます。管理画面だけなら管理用プラグインや管理画面URLの設定も候補です。
手順2：ブラウザでHTTP資源のURLを特定する
Chromeなどのブラウザでは、アドレスバー付近のセキュリティ情報や開発者ツールから、どの資源が非保護かを確認できます。Chrome公式のPrivacy and security panelは、Mixed Contentを「安全なメインページが非安全なオリジンの資源とやり取りする状態」と説明し、非安全なリクエストをNetworkパネルで確認する方法を案内しています。
Chromeでの基本的な見方
- 問題ページを開く
- 開発者ツールを開き、Security、Issues、Consoleを確認する
- Networkパネルを再読み込みし、
mixed-contentまたはscheme:httpで絞る - 非保護資源の完全なURLと種類を記録する
- Initiatorや発生元から、本文・CSS・スクリプトのどこが呼んだかを見る
Chrome DevToolsのNetworkリファレンスでは、Mixed ContentやHTTPスキームで資源を絞り込めます。ブラウザにより名称は異なりますが、必要なのは「警告を出した資源のURL」と「その資源を呼び出した場所」です。
警告を消す目的でブラウザの保護機能を無効にし、その状態を通常運用にしないでください。確認中だけ表示できても、訪問者側ではブロックされたままであり、根本修正になりません。
手順3：WordPressアドレスとサイトアドレスを確認する
WordPress管理画面の「設定」→「一般」には、WordPress本体の場所を示す「WordPress アドレス（URL）」と、訪問者が入力する「サイトアドレス（URL）」があります。WordPress公式のSettings General screenでも役割が分けて説明されています。通常の同一ドメイン運用でSSL化が完了しているなら、両方が意図したhttps://になっているか確認します。
ただし、WordPressをサブディレクトリへ置いているサイト、リバースプロキシやCDNを使うサイト、WP_HOMEやWP_SITEURLを設定ファイルで固定しているサイトでは、2項目が単純に同じとは限りません。入力欄が編集できない場合もあります。現在値を控え、構成を確認してから変更してください。
証明書とHTTPS側のサーバー設定が未完了のまま、WordPress URLだけをhttpsへ変えないでください。管理画面へ入れなくなったり、リダイレクトループになったりする可能性があります。
サーバー移行と同時にSSL化した場合は、DNS、証明書、公開先、転送、WordPress URLを順に照合します。WordPressサーバー移行の確認手順と移行前後のチェックリストを使うと、URLだけを先に変える事故を防ぎやすくなります。
手順4：投稿・固定ページ・画像を直す
特定の投稿だけで警告が出る場合は、ブラウザで特定したHTTP URLを投稿編集画面で探します。画像ブロックなら、メディアライブラリ上のHTTPS画像へ選び直す方法が安全です。カスタムHTMLやクラシックエディター由来の内容では、src、srcset、href、style属性も確認します。
自サイト画像のHTTP URLをHTTPSへ直す前に、そのHTTPS URLを新しいタブで開き、証明書警告なく表示できるか確認してください。外部画像なら、提供元がHTTPSに対応しているか、埋め込み利用が許可されているかを確認します。HTTPS版がない外部資源は、権利を確認して自サイトへ置く、別サービスへ替える、埋め込みを外す、のいずれかを選びます。
ページ内の導線や画像を整理するときは、URL変更でリンク切れを増やさないことも大切です。WordPress内部リンクの貼り方とトップページ導線の作り方を参照し、修正後に主要リンクをクリック確認します。
手順5：テーマ・追加CSS・プラグインを直す
テーマと追加CSS
全ページで同じ画像やフォントが警告になるなら、テーマカスタマイザー、ヘッダー・フッター、追加CSS、子テーマを確認します。CSSのbackground-imageや@font-faceに古いHTTP URLが残ることがあります。親テーマを直接編集すると更新で消えるため、テーマの設定機能や子テーマなど、現在の運用方法に沿って直します。
プラグインと外部サービス
フォーム、スライダー、アクセス解析、広告、地図、チャットなどが古いHTTP資源を出す場合は、プラグインやサービス側のURL設定と最新版の対応状況を確認します。ソースを直接書き換えるより、公式設定でHTTPS URLへ変更し、提供元が非対応なら代替を検討します。不要なプラグインの扱いはWordPressプラグインを安全に整理する方法が参考になります。
原因確認のため一時停止する場合も、全プラグインではなくログや資源URLから対象を絞ります。フォームや計測など停止の影響を確認し、元の有効状態を記録してください。大きなテーマ編集やプラグイン更新は、WordPressのテスト環境を作る方法で事前確認すると安全です。
手順6：データベースのURL置換は安全な方法で行う
記事数が多く、旧HTTP URLが多数残る場合は、対象を把握したうえでデータベースの検索置換を検討します。WordPress公式のMigrating WordPressは、データベース全体の単純な検索置換によりシリアライズされたデータを壊す可能性を注意しています。
WP-CLIを扱える環境では、公式のwp search-replaceがシリアライズデータを考慮して検索置換します。それでも、実行前にファイルとデータベースをバックアップし、可能なら事前確認機能で対象件数を確認し、自サイトの旧URLから新URLという限定した組み合わせで行います。作業に慣れていない場合は、サーバー会社や保守担当へ依頼する方が安全です。
「http」を含むすべての文字列を無条件で置換しないでください。外部リンク、API、名前空間、設定値まで対象になり得ます。また、SQLを直接実行すると変更を簡単に取り消せません。置換前のバックアップはWordPressバックアップの取り方に沿って確認してください。
手順7：HTTPからHTTPSへの転送を確認する
旧HTTPページへアクセスしたとき、同じパスのHTTPSページへ一度で転送されるかを確認します。転送は訪問者や検索エンジンを新URLへ導くために必要ですが、Mixed Contentの修正を転送だけに頼るのは避けます。HTMLやCSSが参照する資源URL自体をHTTPSへ直す方が、余分な通信とブラウザによる遮断を減らせます。
HTTPとHTTPSの転送規則、CDN側の常時SSL、WordPressプラグインの転送が重なると、無限ループや多段転送になることがあります。変更前の設定を控え、どの層が転送を担当するかを1つずつ確認します。URL変更後に404が出る場合はWordPressの404エラーを直す手順で公開状態と書き換え規則を分けてください。
修正後にキャッシュを更新する
元のURLを直した後、WordPressのページキャッシュ、最適化プラグイン、サーバーキャッシュ、CDN、ブラウザに古いHTMLやCSSが残ることがあります。原因箇所を直してから、配信経路に沿って必要な範囲だけを削除します。手順はWordPressキャッシュ設定の基本を参照してください。
キャッシュ削除後は、ログアウト状態またはプライベートウィンドウで問題ページを開き直します。ブラウザのNetwork記録を消して再読み込みし、HTTP資源が0件になったか、以前ブロックされていた画像・CSS・JavaScriptが正常に読み込まれたかを確認します。
公開前の確認チェックリスト
- 証明書が対象ドメインで有効
- 代表URLがHTTPSで開き、HTTPから正しく転送される
- WordPressアドレスとサイトアドレスが意図した値
- トップページ、記事、固定ページでHTTP資源が0件
- 画像、CSS、JavaScript、フォントが欠けていない
- メニュー、フォーム、検索、ログインなど重要機能が動く
- PC・スマートフォン、ログイン中・ログアウト時で確認済み
- キャッシュとCDN更新後も警告が出ない
- canonical、サイトマップ、内部リンクが意図したHTTPS URL
サイト全体をHTTPからHTTPSへ移行した場合は、表示だけでなく検索向けURLも確認します。サイトマップや内部リンクの確認にはSearch Consoleで記事を改善する見方と内部リンクの基本が役立ちます。
自分で直せないときに伝える情報
- 警告が出るページの完全なURL
- 証明書警告かMixed Contentか
- ブラウザ名と発生日時
- 非保護と判定された資源の完全なURL
- 全ページか特定ページか
- 直前のSSL化、移行、テーマ・プラグイン変更
- WordPressアドレスとサイトアドレスの現在値
- 利用中のCDN、キャッシュ、リバースプロキシ
- 実施した修正と結果
管理画面のパスワード、Cookie、秘密鍵、サーバー認証情報は送らないでください。スクリーンショットやログは機密情報を隠し、サーバー会社や保守担当が指定する窓口で共有します。
再発を防ぐ運用
- 新しい画像・リンク・埋め込みは最初からHTTPSを使う
- テーマやプラグインへ自サイトURLを直接書き込まない
- 移行やURL変更前に検索対象と置換方法を決める
- 変更前にファイルとデータベースをバックアップする
- テスト環境でMixed Contentと主要機能を確認する
- 外部サービスがHTTPS対応を継続しているか定期確認する
- 証明書の自動更新と期限通知を確認する
- 更新後に代表ページのブラウザ警告を確認する
HTTPSは一度設定して終わりではありません。テーマ変更、新しい広告・計測タグ、外部埋め込み、サーバー移行でHTTP参照が再び入ることがあります。更新作業の安全な順番はWordPress更新のやり方、日常の基本対策はWordPressセキュリティ設定の基本もあわせて確認してください。
よくある質問
鍵マークが出ればMixed Contentはありませんか？
ブラウザの表示や自動更新の挙動は変わることがあります。鍵表示だけで判断せず、開発者ツールのSecurity、Issues、NetworkでHTTP資源が残っていないか確認してください。
SSL化プラグインを入れれば全部直りますか？
一時的にURLを書き換えて表示を整えるプラグインはありますが、証明書、サーバー転送、データベース内の旧URL、テーマの直書き、外部HTTP資源をすべて解決するとは限りません。導入前に原因URLを特定し、停止したときの影響と恒久修正の方法を確認してください。
画像URLだけhttpなら放置しても大丈夫ですか？
放置はおすすめできません。ブラウザが自動的に更新して表示する場合でも、配信元がHTTPSに対応しなければ画像が欠ける可能性があります。盗み見や改ざんへの耐性もページ全体で揃わないため、HTTPS版へ修正します。
httpからhttpsへの転送があればURLを直さなくてもよいですか？
訪問ページの転送には必要ですが、ページ内資源ではブラウザが読み込みを遮断する場合があり、余分な転送も発生します。HTML、CSS、設定に保存された参照URL自体をHTTPSへ直す方が確実です。
一部の訪問者だけ警告が出るのはなぜですか？
CDNの配信拠点、ブラウザキャッシュ、ログイン状態、ABテスト、端末別テンプレートなどで受け取るHTMLが異なる可能性があります。発生したURL、端末、ブラウザ、時刻を揃え、その条件で配信された資源を確認します。
まとめ
WordPressで「保護されていない通信」と出たら、最初に証明書エラー、HTTPのままのページ、HTTPSページ内のMixed Contentを分けます。次にブラウザで非保護資源のURLを特定し、WordPress URL、投稿・画像、テーマ・プラグイン、データベース、転送、キャッシュの順に対象限定で直してください。
URLの一括置換や保護機能の無効化を初手にせず、バックアップと記録を残して一つずつ確認することが大切です。最後に複数ページと重要機能を再確認し、HTTP資源が0件になれば復旧完了です。