HTTPS化したあとに画像やCSSが読み込まれない場合、ページ内に古いhttp://の参照が残っていることがあります。HTTPSページからHTTPの画像やスクリプトを読み込もうとする状態が、Mixed Contentです。

直し方は、ブラウザーの開発者ツールで遮断されたURLを見つけ、その画像・CSS・設定の参照先をHTTPSへ変えることです。ただし、404や証明書エラーなど別の原因もあるため、最初にエラーの種類を確認します。Mixed Contentと表示されていなければ、URLの置換だけでは直らない場合があります。

証明書の警告とMixed Contentを分ける

Mixed Contentは、HTTPSで読み込んだ文書が、認証されていないHTTPの副資源を要求する状態です。W3CのMixed Content仕様では、スクリプトなど遮断される資源と、条件によってHTTPSへ自動的に昇格される画像などが定義されています。ブラウザーや資源の種類によって見え方が違うため、画面だけでは残存箇所を判断できません。

ページを開く前に全画面の証明書警告が出る場合は、Mixed Contentより先に調べることがあります。証明書の期限・ホスト名・認証経路の確認です。Mixed Contentでは、通常はHTTPSページそのものへ接続した後に、一部の資源が遮断されたり安全性表示が変わったりします。二つを分けることで、証明書を再発行しても画像が直らないという遠回りを防げます。

画像がブラウザーによって自動昇格され、見た目が正常でも放置しません。対象サーバーがHTTPSへ対応していなければ将来読み込めなくなり、別の資源ではすでに遮断されている可能性があります。修正の基準は「自分の画面に表示された」ではなく、ページが最初から安全なURLだけを要求していることです。

開発者ツールで遮断されたURLと発生元を見る

Chromeなら、対象ページを右クリックして「検証」を開き、Console（コンソール）を選んでページを再読み込みします。Mixed Contentのメッセージがあれば、そこに表示されたURLが手掛かりです。続いてNetwork（ネットワーク）で該当する通信を確認します。Mixed Contentのメッセージに出たHTTPのURL、資源の種類、読み込み元を記録します。Networkではリクエストの発生元を示すInitiatorも見ると、HTMLに直接書かれているのか、CSSやJavaScriptが後から生成したのかを追いやすくなります。

ページソースでhttp://を検索するだけでは十分ではありません。CSSのurl()や画像のsrcsetは、HTMLの外にある参照元です。

テーマ設定・ウィジェット・タグ管理にもURLが残ります。JavaScriptが取得するAPIや外部の埋め込みは、実行時に初めてリクエストを作ることがあります。トップページで見つからなくても、記事・検索結果・フォーム・ログイン後の画面で発生することがあります。

見つけたURLは、先にHTTPSで直接開けるか確かめます。自社管理の資源なら証明書と配信設定を整え、外部サービスなら公式のHTTPS用URLや新しい埋め込みコードを確認します。HTTPSへ対応していない外部資源を文字列だけ書き換えると、警告は消えても資源は取得できません。その場合は、代替サービスや自社で安全に配信できる素材へ置き換えます。

WordPressは保存場所ごとに参照元を直す

WordPressでは、一般設定のサイトURLをHTTPSへ変えただけで、過去の投稿本文やテーマ設定に保存されたURLまでは変わらないことがあります。メディア・投稿本文・カスタムフィールド・ウィジェットを分けて調べます。テーマやプラグイン独自の設定も、開発者ツールで特定した参照元から直します。

データベースを置換する場合は、作業直前のバックアップを用意し、変更件数を事前に確認します。WP-CLIのsearch-replaceはシリアライズされたデータを扱え、--dry-runで変更対象を試算できます。WordPress公式のHTTPS移行資料も、バックアップ後にデータベース内のURLを検索置換する流れを案内しています。

未確認のSQLでデータベース全体を一括置換すると、シリアライズされた値を壊したり、変更対象ではない外部URLまで書き換えたりすることがあります。ドメイン変更でもプロトコル変更でも、対象文字列とテーブルを確認します。試行結果を保存してから本番へ反映します。

CSSと外部タグは管理画面の外にも残る

CSSの背景画像やWebフォントは、投稿編集画面を直しても残ります。テーマや子テーマのファイルに加え、追加CSSとビルド済みCSSを調べます。

CDNに置いた古いファイルも対象です。ソース側を修正したのに同じ警告が出る場合は、複数層のキャッシュを調べます。ブラウザー・WordPress・サーバー・CDNが旧ファイルを返していないか確認します。

広告・アクセス解析・チャット・地図・動画の外部タグは、提供元の最新コードと利用条件を確認します。古いタグの一部だけをHTTPSへ変えるより、公式の埋め込みコードへ入れ替える方が、関連するスクリプトやAPIの参照漏れを減らせます。すでに使っていないタグなら、残す理由を確認したうえで削除します。

HTTP側でHTTPSへ転送される資源も、参照元から直接HTTPSを要求するよう直します。転送へ頼ると余計な通信が増え、遮断判定が転送より先に行われる資源では読み込めません。//example.jp/image.jpgのようなプロトコル相対URLへ逃げるのではなく、HTTPSで提供されることを確認して明示します。

修正後はページではなくサイトの型を確認する

キャッシュを必要な範囲だけ更新したら、開発者ツールを再度開き、Networkを記録した状態でページを読み直します。Consoleの警告が消えたか、HTTPリクエストが残っていないか、CSSやJavaScriptが正常なステータスで返るかを確認します。単に見た目が戻っただけでは、裏側のAPIや計測タグの失敗を見落とします。

確認対象は、トップページ一枚ではなくサイトの型で選びます。通常の記事と画像の多い記事を分けて見ます。一覧・検索・問い合わせフォーム・ログイン画面も異なるテンプレートです。スマートフォン向け表示に加え、ログイン中だけ表示される管理バーや会員ページも公開画面とは別に確認します。

たとえば記事の画像だけ直しても、共通CSSの背景画像に古いURLが残れば別ページで崩れます。逆に、共通ファイルの一か所を直すだけで全体が改善する場合もあります。エラーに出たURLから参照元をたどることが、無駄な一括変更を避ける近道です。