Mixed Content（混在コンテンツ）とは、HTTPSで表示しているWebページの中に、HTTPで読み込む画像・CSS・JavaScript・iframeなどが残っている状態です。
SSL証明書を設定してページ自体がHTTPSになっていても、ページ内の一部がHTTPのままだと、ブラウザがその通信を安全ではないと判断し、自動的にHTTPSへ変更したり、読み込みをブロックしたりします。
30秒でわかる結論
30秒でわかる結論
- Mixed Contentは「HTTPSページの中にHTTPリソースが残っている状態」
- 画像・動画・音声など一部はブラウザがHTTPSへ自動アップグレードする場合がある
- JavaScript・CSS・iframe・Webフォントなどはブロックされることがある
- 直す基本は、HTTPで読み込んでいるURLをHTTPSへ変更すること
- WordPressでは過去記事・テーマ設定・CSS・ウィジェット・プラグイン設定にhttp://が残りやすい
- ブラウザの開発者ツールでMixed Content警告と対象URLを確認すると原因を絞りやすい
- 「SSLを再設定する」より先に、どのリソースがHTTPで読み込まれているか確認する
Mixed Contentとは？
Mixed Contentは、日本語では「混在コンテンツ」と呼ばれます。 ページ本体をHTTPSで安全に読み込んでいるのに、そのページが一部のファイルをHTTPで取得しようとする状態です。
HTTPSページ ＋ HTTPリソース ＝ Mixed Content
例
ページ：https://example.com/
画像：http://example.com/photo.jpg
HTTPSは通信内容の盗み見や改ざんを防ぐための仕組みですが、ページ内にHTTP通信が残ると、その部分にはHTTPSの保護がありません。 そのためブラウザは、安全でないリソースをそのまま読み込ませない方向で処理します。
Mixed Contentが危険な理由
「画像1枚がHTTPなだけなら問題ない」と考えるのは適切ではありません。 HTTP通信は暗号化されないため、通信途中で内容を見られたり、改ざんされたりする可能性があります。
特にJavaScriptが改ざんされると、ページの表示や動作そのものを変更される可能性があります。 画像でも、見た目や案内内容を書き換えられれば、利用者を誤解させる原因になります。
HTTPSはページ本体だけでは不十分
HTMLだけをHTTPSで配信するのではなく、画像・CSS・JavaScript・フォント・iframeなど、ページが読み込むリソース全体をHTTPSにそろえることが重要です。
ブラウザはMixed Contentをどう処理する？
現在のブラウザでは、Mixed Contentを大きく「自動アップグレード可能なもの」と「ブロックされるもの」に分けて扱います。
| 種類 | 代表例 | 主な処理 |
|---|---|---|
| アップグレード可能 | 一部の画像・音声・動画 | HTTPをHTTPSへ自動変更して取得を試みる |
| ブロック対象 | JavaScript・CSS・iframe・Webフォントなど | HTTPのままなら読み込みを止める |
たとえば、画像が「http://example.com/photo.jpg」で指定されていても、ブラウザが「https://example.com/photo.jpg」へ変更して取得できれば表示される場合があります。
一方、JavaScriptやCSSなどはページ全体の挙動に大きく影響するため、安全でないHTTP読み込みはブロックされます。
自動で表示できても放置しない
ブラウザがHTTP画像をHTTPSへ自動アップグレードして表示できていても、元のHTMLやデータベースにhttp://が残っている状態は修正対象です。 ブラウザの補正に依存せず、サイト側でHTTPS URLへ統一してください。
Mixed Contentが起きる主な原因
| 原因 | よくある場所 |
|---|---|
| 古い画像URL | 過去記事・固定ページ |
| テーマ設定 | ロゴ・背景画像・独自CSS |
| プラグイン設定 | バナー・フォーム・外部スクリプト |
| 外部サービス | iframe・広告・地図・計測タグ |
| CSS内URL | background-image・Webフォント |
| HTML直書き | ウィジェット・カスタムHTML |
原因1．HTTPS化前に登録した画像URLが残っている
WordPressをHTTPで運営した後にHTTPS化すると、過去記事や固定ページのHTMLに「http://」から始まる画像URLが残る場合があります。
修正前と修正後
修正前：http://example.com/wp-content/uploads/photo.jpg
修正後：https://example.com/wp-content/uploads/photo.jpg
原因2．テーマ設定にHTTP URLが残っている
記事本文だけでなく、ロゴ画像、ヘッダー画像、背景画像、フッター、独自CSSなどに古いURLが保存されている場合があります。
原因3．外部サービスがHTTPにしか対応していない
昔のバナー、アクセス解析タグ、iframe、外部JavaScriptなどがHTTP URLを指定している場合があります。 外部サービス自体がHTTPSに対応していなければ、単純に「http」を「https」に書き換えても表示できません。
外部サービスの場合
まず同じサービスにHTTPS版URLがあるか確認します。HTTPS非対応なら、そのサービスの利用停止・別サービスへの変更を検討します。
原因4．CSS内にHTTP URLがある
HTML本文にhttp://が見つからなくても、CSSの背景画像やWebフォントにHTTP URLが書かれていることがあります。
CSSの例
background-image: url(“http://example.com/bg.jpg”);
この場合、記事本文だけ検索しても原因が見つかりません。 テーマのCSS、追加CSS、ページビルダーの設定なども確認します。
Mixed Contentの確認方法
原因を探すときは、闇雲にSSL設定をやり直すのではなく、ブラウザの開発者ツールで対象URLを確認するのが効率的です。
URLがhttps://になっていることを確認
ConsoleやNetworkを確認
http://で読み込もうとしているURLを特定
記事・テーマ・CSS・プラグイン・外部埋め込みを確認
Consoleで確認する
ChromeやFirefoxなどの開発者ツールでは、Mixed Contentが発生しているとConsoleに警告やエラーが表示されます。 そこにHTTPで読み込もうとしたURLが表示されるため、原因特定の手掛かりになります。
Networkで確認する
Networkでは、ページが読み込んでいる画像・CSS・JavaScriptなどを確認できます。 対象URLがHTTPになっていないか、HTTPSへの自動アップグレード後に失敗していないかを確認します。
確認対象
- 画像
- CSS
- JavaScript
- iframe
- Webフォント
- 動画・音声
- 外部API
- ダウンロードファイル
WordPressでMixed Contentを直す手順
WordPressでは、サーバー側・WordPress設定・データベース・テーマ・プラグインを分けて確認します。 「WordPressの問題」と一括りにしないことが重要です。
1．サーバー側でHTTPS表示できるか確認する
最初に、SSL証明書が有効で「https://example.com」に正常アクセスできるか確認します。 証明書自体が無効なら、Mixed Contentを直す前にSSL設定を修正する必要があります。
2．WordPressアドレスとサイトアドレスを確認する
WordPress管理画面の「設定」→「一般」では、WordPressアドレスとサイトアドレスを確認します。 HTTPS化済みなのにHTTPのままなら、サイト構成を確認したうえでHTTPSへ統一します。
URLだけ先に変更しない
サーバー側でHTTPSが利用できる状態になる前にWordPressのURLだけ変更すると、管理画面やサイトへアクセスできなくなる場合があります。 必ずSSL有効化を先に確認してください。
3．過去記事・固定ページ内のHTTP URLを確認する
HTTPS化前から運営しているサイトでは、本文中の画像やリンクに古いURLが残っている可能性があります。
少数なら手動で修正できますが、大規模サイトではデータベース内のURL置換が必要になる場合があります。
データベースの一括置換はバックアップ後に行う
WordPressのデータにはシリアライズされた値やプラグイン独自データが含まれることがあります。 単純なSQL置換や文字列置換で壊れる可能性があるため、対応ツールや移行機能を使い、必ずバックアップを取ってから実施してください。
4．テーマ・追加CSSを確認する
テーマカスタマイザー、追加CSS、子テーマ、ヘッダー・フッター設定などにHTTP URLが残っていないか確認します。
5．プラグイン設定を確認する
スライダー、広告、フォーム、アクセス解析、ページビルダーなどが独自にURLを保存している場合があります。 プラグインの設定画面も確認してください。
6．キャッシュを削除して再確認する
修正後も古いHTMLやCSSがキャッシュに残っていると、Mixed Contentが続いて見える場合があります。
- WordPressキャッシュ
- レンタルサーバーキャッシュ
- CDNキャッシュ
- ブラウザキャッシュ
利用中の範囲だけを確認し、必要なキャッシュを削除して再テストします。
「http://をhttps://へ置き換える」だけでよい？
同じURLがHTTPSでも正常に提供されているなら、http://をhttps://へ変更することで解決できます。 ただし、すべての外部URLがHTTPSに対応しているとは限りません。
| 状態 | 対処 |
|---|---|
| HTTPS版が正常にある | https://へ変更 |
| HTTPS版がない | 別サービス・別リソースへ変更 |
| 自サイトの古いURL | WordPress・DB・テーマ設定を修正 |
| 原因不明 | 開発者ツールで読み込み元を特定 |
文字列の一括置換だけで済ませない
サイト全体の「http://」を無条件に「https://」へ置き換えると、HTTPS非対応の外部URLや意図しない文字列まで変更する可能性があります。 対象URLを確認してから修正してください。
HTTPからHTTPSへのリダイレクトとの違い
HTTP→HTTPSリダイレクトとMixed Content対策は別の作業です。
| 項目 | 目的 |
|---|---|
| HTTP→HTTPSリダイレクト | ページURLへのアクセスをHTTPSへ統一する |
| Mixed Content対策 | ページ内で読み込むリソースもHTTPSへ統一する |
ページURLの統一 ＋ ページ内リソースのHTTPS化 ＝ 常時SSL化の基本
トップページへHTTPでアクセスしたときにHTTPSへ転送されても、内部のJavaScriptがHTTPならMixed Contentは残ります。
CSPのupgrade-insecure-requestsは使うべき？
Content Security Policy（CSP）には、HTTPリソースへのリクエストをHTTPSへアップグレードさせる「upgrade-insecure-requests」という指定があります。
大量の古いHTMLをすぐ直せない場合などに役立つことがありますが、根本的にはソース側のHTTP URLをHTTPSへ修正する方が分かりやすく、管理もしやすくなります。
初心者はCSPより原因URLの修正を優先
レンタルサーバーや通常のWordPress運営では、まず開発者ツールで原因URLを確認し、そのURLをHTTPSへ直す方法を優先してください。 CSPはサイト全体の読み込み制御に関わるため、意味を理解せず設定すると別の表示不具合を起こす可能性があります。
Mixed ContentとSEOの関係
Mixed Contentを直したから検索順位が直接上がる、と断定することはできません。
ただし、CSSやJavaScriptがブロックされればページ表示や操作に問題が起こり、利用者が正常に閲覧できなくなる可能性があります。 また、安全なHTTPSサイトとして正しく運用するうえでも、HTTPリソースを残さないことは重要です。
SEO目的だけで直すのではなく、「ページを正常・安全に表示するための技術上の修正」と考えてください。
どんな場合に確認が必要？
新規WordPressサイト
確認：公開前
最初からHTTPSで制作していれば起きにくいですが、外部埋め込みや古いテンプレートのURLを確認します。
HTTPからHTTPSへ移行したサイト
確認：必須
過去記事、画像、CSS、テーマ設定などにHTTP URLが残りやすいため、主要ページだけでなく複数ページを確認します。
会社・店舗サイト
確認：必須
問い合わせフォーム、予約、地図、外部バナー、計測タグなども含めて確認します。表示不具合が業務に影響するためです。
CDN利用サイト
確認：構成別
元サーバーだけでなくCDN側のURL変換やキャッシュも確認します。古いHTTP版CSSがCDNに残るケースもあります。
直しても警告が消えないときの確認順
キャッシュを使わず再確認
残っているHTTP URLを特定
本文以外のURLを探す
外部URLや埋め込みを確認
古いファイルが配信されていないか確認
SSL証明書エラーとMixed Contentを混同しない
証明書の期限切れ、ドメイン不一致、DNS設定ミスなどはMixed Contentとは別問題です。 ブラウザのエラー詳細を確認し、「証明書そのものの問題」なのか「HTTPSページ内のHTTP読み込み」なのかを分けてください。
教科書判定
HTTPS化後に警告や表示崩れが出たら、まずMixed Contentの対象URLを探す
初心者が最初にやるべきことは、SSL証明書を何度も入れ直すことではありません。 「HTTPSページの中で、どのファイルをHTTPで読み込もうとしているか」をブラウザの開発者ツールで確認してください。
WordPressでは、過去記事・画像・テーマ・追加CSS・プラグイン設定の順に確認すると原因を絞りやすくなります。 原因URLがHTTPSでも利用できるならHTTPSへ修正し、HTTPS非対応なら別のリソースへ変更するのが基本です。
FAQ
Q．Mixed ContentがあるとSSL証明書は無効ですか？
いいえ。SSL証明書自体が正常でも、ページ内にHTTPリソースが残っているとMixed Contentになります。証明書エラーとMixed Contentは分けて確認してください。
Q．画像が表示されているなら直さなくてもよいですか？
おすすめしません。現在のブラウザは一部のHTTP画像を自動的にHTTPSへ変更して表示することがありますが、元URLがHTTPのままという問題は残っています。サイト側でHTTPSへ修正してください。
Q．WordPressのURLをhttpsにすれば全部直りますか？
必ずしも直りません。過去記事、テーマ、CSS、プラグイン設定、外部埋め込みなどにHTTP URLが残っていることがあります。
Q．http://を全部https://へ一括置換してよいですか？
無条件の一括置換は避けた方が安全です。外部サービスがHTTPS非対応の場合や、WordPressのデータ構造を壊す可能性があるため、対象とバックアップを確認してから行ってください。
Q．Mixed Contentはどこで確認できますか？
ブラウザの開発者ツールにあるConsoleやNetworkで確認できます。警告に表示されるhttp://のURLを手掛かりに、記事・テーマ・CSS・プラグインなど保存場所を特定します。
まとめ
この記事の結論
- Mixed ContentはHTTPSページ内にHTTPリソースが残る状態
- 画像など一部は自動HTTPS化され、JavaScript・CSS・iframeなどはブロックされることがある
- 最初にブラウザの開発者ツールで原因URLを特定する
- WordPressでは過去記事、画像、テーマ、CSS、プラグイン設定を確認する
- HTTPS版があるリソースはHTTPSへ変更する
- HTTPS非対応の外部サービスは別サービスへの変更を検討する
- HTTP→HTTPSリダイレクトとMixed Content対策は別作業として確認する
- 修正後はキャッシュを削除し、複数ページで再確認する
Mixed Contentは「SSLを設定したのに安全にならない」というときの代表的な原因の一つです。 原因はSSL証明書そのものではなく、ページ内に残っているHTTP URLです。 警告に表示されたURLを1つずつ特定し、HTTPSへそろえてください。
「HTTPからHTTPSへリダイレクトする方法」「TLSとは？SSLとの違いを初心者向けに解説」「SSL証明書の有効期限と更新方法を解説」もあわせて確認してください。