HTTPS化したら mixed content エラーが出る場合の原因と直し方（WordPress）

HTTPS化したあとに出る mixed content（混在コンテンツ）エラーは、HTTPSのページの中に http:// で読み込まれる画像・CSS・JavaScriptが残っていることが原因です。直し方は、ブラウザの開発者ツールで「どのURLが http のまま読み込まれているか」を特定し、その URL がどこから出力されているか（WordPressの設定、投稿本文、テーマ、プラグイン、外部サービス、プロキシ構成）を順に潰していくことです。この記事では、その調べ方と、原因ごとの直し方を可能性の高い順に説明します。

どんな症状が出るのか

mixed content には、ブラウザの扱いが異なる2種類があります。

• 画像・音声・動画など（受動的なコンテンツ）：ブラウザによっては自動で https に切り替えて読み込もうとし、https で取得できなければ表示されません。アドレスバーの鍵マークに警告が出ることもあります
• JavaScript・CSS・iframe など（能動的なコンテンツ）：ページ全体を改ざんできるため、ブラウザがブロックします。レイアウトが崩れる、ボタンが動かない、埋め込みが表示されないといった症状になります

ブラウザごとの細かな挙動はバージョンによって変わりますが（2026年10月現在）、「http の読み込みは表示されないか警告が出る」と考えて、すべて https にそろえるのが対処の基本です。

ステップ1：http のまま読み込まれているURLを特定する

まず、問題のページをブラウザで開き、開発者ツール（Windows は F12、Mac は Option + Command + I）のコンソールを確認します。Chrome では「Mixed Content: The page at 'https://…' was loaded over HTTPS, but requested an insecure …」のようなメッセージが出て、その後ろに http のURLが表示されます。このURLが調査の出発点です。

ページ数が多い場合や、コンソールを見落としそうな場合は、ページのHTMLから http のURLを抜き出すと全体像がつかめます。

# ページのHTMLに含まれる http:// のURLを一覧にする
curl -s https://example.com/ | grep -o 'http://[^"'"'"' )]*' | sort -u

ここで見つかったURLを、自サイトのドメインのものと外部ドメインのものに分けておくと、次の切り分けが速くなります。

ステップ2：原因を可能性の高い順に確認する

原因1：WordPress のサイトURLが http のまま

管理画面の「設定」→「一般」にある「WordPress アドレス (URL)」と「サイトアドレス (URL)」が http:// のままだと、WordPress が出力するほとんどのURL（CSS、JavaScript、画像、リンク）が http になります。両方を https:// に変更します。

入力欄がグレーで変更できない場合は、wp-config.php で WP_HOME と WP_SITEURL が定義されています。その値を https に書き換えてください。WP-CLI が使える環境では、次のように確認・変更できます。

wp option get home
wp option get siteurl
wp option update home 'https://example.com'
wp option update siteurl 'https://example.com'

原因2：投稿本文やカスタムフィールドに古い http のURLが残っている

HTTPS化する前に挿入した画像は、本文に http://example.com/wp-content/uploads/… という形でURLが保存されています。サイトURLを変えても、すでに保存されている本文のURLは変わりません。

これを直すには、データベース内の URL を一括置換します。作業の前にデータベースのバックアップを取り、できれば検証環境で先に試してください。WP-CLI の search-replace は、PHPのシリアライズ形式で保存されたデータも壊さずに置き換えられます。

# まずバックアップ
wp db export backup-before-https.sql

# 置き換え対象を確認するだけ（データは変更しない）
wp search-replace 'http://example.com' 'https://example.com' --skip-columns=guid --dry-run

# 問題なければ実行
wp search-replace 'http://example.com' 'https://example.com' --skip-columns=guid

guid 列は投稿の識別子として使われるもので、URLとして表示されるわけではないため、置換の対象から外すのが一般的です。phpMyAdmin などで SQL の REPLACE を直接実行する方法は、シリアライズされたデータの文字数がずれて設定が壊れることがあるため避けてください。WP-CLI が使えない場合は、Better Search Replace のような置換用プラグインを使う方法があります（画面や項目名はバージョンで変わることがあります）。

なお WordPress 5.7 以降には、サイトヘルスの画面からHTTPSへ切り替えた場合に、本文中の自サイトの http URL を表示時に https へ置き換える仕組みがあります。ただし、データベースの中身が変わるわけではなく、カスタムフィールドやテーマの出力には効かないこともあるため、根本的な直し方はデータの置換です。

原因3：テーマやプラグインの設定・ファイルに http が書かれている

本文を置換しても残る場合は、次の場所を確認します。

• カスタマイザーの「追加 CSS」に書いた背景画像などのURL
• テーマの設定画面で指定したロゴ・ファビコン・ヘッダー画像
• ウィジェットやブロックに直接書いたHTML
• 子テーマの functions.php やテンプレートファイルに直接書いたURL

テーマのファイルを調べるには、次のように検索するのが手早い方法です。

grep -rn "http://" wp-content/themes/your-child-theme/

テーマやプラグインのコードでURLを組み立てるときは、home_url() や get_stylesheet_directory_uri()、wp_get_attachment_url() のような関数を使えば、サイトの設定に合わせて https のURLが返ります。親テーマや配布プラグインのファイルを直接書き換えると更新で元に戻るため、修正は子テーマで行うか、提供元に報告します。

原因4：外部サービスのURLが http のまま

広告タグ、アクセス解析、地図や動画の埋め込み、外部の画像など、外部ドメインのURLが http で書かれている場合です。多くのサービスは https に対応しているので、URLを https:// に書き換えて表示されるか確認します。https で提供されていない古いサービスは、代替のサービスに置き換えるか、使用をやめることを検討してください。

原因5：リバースプロキシやCDNの裏で WordPress が HTTPS を認識していない

ロードバランサーやCDN、リバースプロキシでHTTPSを終端し、WordPress には http で通信が届く構成では、WordPress は「自分は http で動いている」と判断し、一部のURLを http で出力します。リダイレクトがループする症状と一緒に起こることもあります。

この場合は、プロキシが付けるヘッダーを見て HTTPS と判断させる設定を wp-config.php の「編集はここまで」の行より前に追加します。

if ( isset( $_SERVER['HTTP_X_FORWARDED_PROTO'] )
	&& false !== strpos( $_SERVER['HTTP_X_FORWARDED_PROTO'], 'https' ) ) {
	$_SERVER['HTTPS'] = 'on';
}

このヘッダーは誰でも付けて送れるため、信頼できるプロキシ経由でしか WordPress に届かない構成で使うことが前提です。ヘッダー名はプロキシやCDNによって異なることがあるので、利用しているサービスのドキュメントで確認してください。

原因6：キャッシュに古いHTMLが残っている

上の修正をしても変わらない場合は、キャッシュ系プラグイン、サーバーのページキャッシュ、CDNのキャッシュに、修正前のHTMLが残っている可能性があります。それぞれのキャッシュを削除してから、ブラウザのシークレットウィンドウで確認します。結合・圧縮したCSSのファイルの中に http のURLが残っていることもあるので、最適化系プラグインのキャッシュも削除対象です。

一時しのぎとしての upgrade-insecure-requests

すぐに全箇所を直せない場合は、Content-Security-Policy ヘッダーの upgrade-insecure-requests を使うと、ブラウザがページ内の http の読み込みを https に切り替えて取得します。

# Nginx の server ブロック内
add_header Content-Security-Policy "upgrade-insecure-requests" always;

ただし、https で取得できないリソースは結局表示されません。また、このヘッダーに対応していない環境やRSS、外部へのデータ提供には効かないため、あくまで修正が終わるまでのつなぎとして使い、URLそのものを https にそろえる作業は続けてください。

修正後の確認

修正が終わったら、トップページだけでなく、投稿ページ、固定ページ、カテゴリー一覧、お問い合わせフォームなど、構成の異なるページをいくつか開いてコンソールにエラーが出ないかを確認します。あわせて、http でアクセスしたときに https へ 301 リダイレクトされることも確かめておきます。HSTS の導入はその後、影響範囲を理解したうえで短い期間から試すのが安全です。

まとめ

• mixed content は、HTTPSのページに http で読み込まれるリソースが残っていることが原因です
• 開発者ツールのコンソールで http のURLを特定し、出力元を順に確認します
• 多い原因は、サイトURLの設定、本文に残った古いURL、テーマ・プラグインの設定、外部サービス、プロキシ構成、キャッシュの順です
• 本文の置換はバックアップを取ってから WP-CLI の search-replace などシリアライズ対応の方法で行います
• upgrade-insecure-requests は一時しのぎとして使い、URLを https にそろえる修正を続けます

• Really Simple SSL の設定方法
• CSPをレポートモードでテストする方法