WordPressサイトをSSL化してURLが「https」になっているのに、一部のページだけ「保護されていない通信」と表示されることがあります。
サイト全体ではなく、特定の記事やページだけで警告が出る場合は、そのページ内で読み込んでいる画像や外部データのURLが「http」のまま残っている可能性があります。
これは「Mixed Content（混在コンテンツ）」と呼ばれる状態です。
私も2020年に、WordPressテーマCocoonを使っているサイトで同じ問題を経験しました。
当時の記録を確認すると、原因はCocoon設定に登録していたAMP用ロゴ画像のURLが「http」のままになっていたことでした。
ただし、現在のCocoonではAMP機能が廃止されているため、当時と同じ設定項目はありません。
この記事では、現在のWordPress・Cocoon環境で、一部ページだけ「保護されていない通信」になる原因の調べ方と直し方を、初心者向けに解説します。
一部ページだけ保護されていない原因はMixed Content
ページ自体は次のようにHTTPSで表示されていても、
ページ内の画像、動画、CSS、JavaScriptなどを次のようなHTTPのURLから読み込んでいると、Mixed Contentになります。
http://example.com/image.jpg
つまり、ページ全体はHTTPSでも、一部のデータだけが暗号化されていない状態です。
Chromeなどのブラウザは、HTTPSページ内でHTTPのデータが読み込まれていると、安全性に問題があるページとして警告したり、データの読み込みをブロックしたりします。
サイト全体ではなく、一部の記事だけで警告が出る場合は、その記事だけで使用している画像や埋め込みコードを疑いましょう。
最初にサイト全体のSSL設定を確認する
Mixed Contentを調べる前に、WordPress全体のSSL設定が完了しているか確認します。
WordPress管理画面の「設定」から「一般」を開き、次の2項目を確認してください。
- WordPress アドレス（URL）
- サイトアドレス（URL）
両方とも「https://」から始まっていれば、WordPress側の基本的な設定は完了しています。
サイト内のほぼすべてのページで警告が出ている場合は、個別記事ではなく、サーバーのSSL設定やHTTPからHTTPSへの転送設定に問題がある可能性があります。
一方で、トップページや多くの記事は正常なのに、特定のページだけ警告が出る場合は、ページ内のMixed Contentを調べます。
ChromeでHTTPのデータを見つける方法
一つずつ設定を眺めるより、Chromeのデベロッパーツールを使った方が原因を早く特定できます。
1．問題が出ているページを開く
「保護されていない通信」と表示される記事や固定ページをChromeで開きます。
2．デベロッパーツールを開く
Windowsでは、キーボードの「F12」を押します。
F12で開かない場合は、次のショートカットも使えます。
Ctrl＋Shift＋I
画面上で右クリックし、「検証」を選んでも開けます。
3．Securityを開く
デベロッパーツール上部の「Security」を選択します。
表示されていない場合は、上部にある「>>」やメニューからSecurityを探してください。
Mixed Contentがある場合は、「Non-secure origins」などの項目に、安全ではない通信元が表示されます。
4．Networkで問題のURLを確認する
「View requests in Network panel」を押すと、Network画面に移動し、問題のあるリクエストを確認できます。
「Request URL」などに、
http://
から始まるURLが表示されていないか確認します。
このURLが、警告の原因になっている画像や外部データです。
Chrome公式でも、Securityパネルから安全でない通信元を確認し、Networkパネルで該当リクエストを特定する方法が案内されています。
Cocoonで確認したい場所
原因のURLが分かったら、そのURLがどこで設定されているかを探します。
Cocoonでは、次のような場所に画像URLが保存されていることがあります。
- ヘッダーロゴやヘッダー背景画像
- サイト背景画像
- OGP画像
- アピールエリアの画像
- トップへ戻るボタンの画像
- 404ページ用画像
- ウィジェット内の画像
- プロフィール画像
- 独自に設置したバナー
CocoonをHTTP環境で設定した後にサイトをHTTPS化すると、以前登録した画像URLが「http」のまま残ることがあります。
該当する画像が見つかった場合は、一度画像設定を削除し、メディアライブラリから選び直す方法が簡単です。
URLの「http」に手作業で「s」を付けて直す方法もありますが、外部サイトのURLはHTTPSに対応していない場合があります。
自分のサイト内の画像であれば、メディアライブラリから再設定する方が安全です。
Cocoon公式でも、SSL化後はCocoon設定内の画像URLを確認し、HTTPの画像が残っている場合は再設定するよう案内されています。
記事本文の画像を確認する
特定の記事だけ警告が出る場合、記事本文に使っている古い画像が原因になっていることがあります。
特に、サイトをHTTPS化する前に作成した記事は注意が必要です。
WordPressの投稿編集画面を開き、問題がありそうな画像を選択します。
画像を一度削除し、メディアライブラリから同じ画像を挿入し直すと、現在のHTTPSのURLで登録される場合があります。
HTML編集画面を確認できる場合は、本文内を検索し、
http://
が残っていないか調べる方法もあります。
ただし、普通のテキストリンクがHTTPであるだけでは、通常はMixed Contentにはなりません。
問題になるのは、ページを表示したときにブラウザが実際に読み込む画像、動画、CSS、JavaScript、iframeなどです。
外部の埋め込みコードや広告も確認する
画像以外にも、次のようなコードが原因になることがあります。
- 古いYouTubeなどの埋め込みコード
- 外部サイトのiframe
- 古いアフィリエイトバナー
- ブログパーツ
- アクセス解析コード
- ウィジェットに直接貼ったHTML
- 追加CSSや子テーマ内の画像URL
特に、何年も前に取得した広告コードやブログパーツには、HTTPの画像が含まれていることがあります。
原因が外部サービスのコードだった場合は、現在の管理画面から新しいコードを取得し直します。
すでにサービスが終了していたり、HTTPSに対応していなかったりする場合は、埋め込み自体を削除した方が安全です。
修正後はキャッシュを削除する
URLを修正しても、ブラウザやWordPressに古い情報が残っていると、すぐには表示が変わらないことがあります。
修正後は、次のキャッシュを削除します。
- Chromeのキャッシュ
- Cocoonのキャッシュ
- キャッシュ系プラグイン
- サーバーのキャッシュ
- CDNを使用している場合はCDNのキャッシュ
Chromeでは、シークレットウィンドウでページを開いて確認する方法もあります。
再度デベロッパーツールを開き、HTTPのリクエストが消えていることを確認してください。
いきなりプラグインやデータベース置換を使わない
WordPressには、HTTPのURLをHTTPSへ置き換えるプラグインもあります。
しかし、一部ページだけに問題が出ている場合は、最初からサイト全体のURLを一括置換する必要はありません。
まずChromeで原因のURLを特定し、その画像や設定だけを修正する方が安全です。
データベースの一括置換や.htaccessの編集は、失敗するとサイトが表示されなくなる可能性があります。
大量の古いURLが残っていて個別修正が難しい場合は、必ずバックアップを取ってから作業してください。
2020年当時の原因はAMP用ロゴ画像だった
私が2020年に経験したケースでは、Cocoon設定に登録していたAMP用ロゴ画像のURLが、
http://
のままになっていました。
この画像URLをHTTPSに直すことで、「保護されていない通信」の表示は解消しました。
しかし、Cocoonは2024年2月に公開されたバージョン2.7.0で、AMP機能とPWA機能を廃止しています。
そのため、現在のCocoonには当時と同じAMP用ロゴの設定項目はありません。
古い記事に書かれている「Cocoon設定のAMP用ロゴを直す」という手順を探しても、現在の管理画面では見つからないので注意してください。
当時と設定画面は変わりましたが、Cocoon設定や記事本文に古いHTTPの画像URLが残り、Mixed Contentになる仕組みは同じです。
まとめ
Cocoonで一部ページだけ「保護されていない通信」と表示される場合は、ページ内でHTTPの画像や外部データを読み込んでいる可能性があります。
まずChromeのデベロッパーツールを開き、SecurityとNetworkから「http://」で読み込まれているURLを探します。
原因が分かったら、次の順番で確認してください。
- 記事本文の画像
- Cocoon設定に登録した画像
- ウィジェットやカスタムHTML
- 外部の埋め込みコード
- 追加CSSや子テーマ
- キャッシュ
原因を確認せずにプラグインを追加したり、データベースを一括置換したりするより、問題のURLを特定して個別に直す方が安全です。