「Mixed Content」警告の直し方｜httpsで画像が表示されない時の対処完全ガイド
生徒サイトをhttpsにしたのに、アドレスバーに鍵マークが付かなくて「保護されていない通信」って出ます…。画像も一部表示されません。どうしたら直りますか？
ペン博士それは『Mixed Content（混在コンテンツ）』っていう、常時SSL化でいちばんよく起きるトラブルだよ！httpsのページの中にhttpのファイルが混ざってると出るんだ。原因の見つけ方から直し方まで、順番にやれば必ず解決できるから、いっしょに直していこうね！
サイトをhttps化したのに、ブラウザのアドレスバーに鍵マークが表示されない、あるいは「保護されていない通信」「安全ではありません」と警告が出る。さらに一部の画像が表示されない――。これはWordPressや自作サイトを常時SSL化したときに、非常によく起こるトラブルです。原因のほとんどは「Mixed Content（混在コンテンツ）」と呼ばれる状態にあります。
この記事では、Mixed Contentとは何かという定義から、原因の特定方法、そして具体的な直し方までを、未経験の方でも順番に追えるように解説します。ブラウザの開発者ツール（DevTools）でhttpリソースを見つける手順、WordPress管理画面での設定変更、データベースの一括置換、テーマやコンテンツ内にハードコードされたhttpの修正、外部リソースへの対応、そして仕上げのCSPや.htaccessリダイレクトまで、常時SSL化を最後までやり切るための知識をひととおり網羅します。読み終えるころには、鍵マークをきちんと点灯させ、すべての画像が正しく表示される状態を、自分の手で作れるようになっているはずです。
目次
この記事の結論｜まず何をすればいいか
先に結論からお伝えします。Mixed Content警告を直すゴールは、httpsページの中に読み込まれているhttpのファイル（画像・CSS・JS・動画など）を、すべてhttpsに置き換えることです。やることは次の流れに集約されます。上から順に進めれば、多くのサイトはこれで解決します。
- DevTools（開発者ツール）で犯人のhttpリソースを特定する。コンソールとセキュリティタブに警告が出るので、まずそこで「何がhttpのままか」を見つけます。
- WordPressの一般設定でサイトアドレス・WordPressアドレスをhttpsにする。ここが古いと全ページに影響します。
- データベースの一括置換で本文中のhttpのURLをhttpsに変える。過去記事に埋め込まれた画像リンクはここで直します。バックアップ必須です。
- テーマ・CSS・カスタムHTMLにハードコードされたhttpを直す。手書きのコード内のURLはDBを置換しても残ります。
- 外部リソース（CDN・YouTube・Webフォント）のURLをhttpsに揃える。自サイト外の読み込みも警告対象です。
- 最後にCSPや.htaccessリダイレクトで再発を防ぐ。仕上げとして自動で強制化しておくと安心です。
この記事では、この6ステップを軸に、それぞれの具体的な手順を詳しく解説していきます。逆に言えば、原因の特定を飛ばして「とりあえずプラグインを片っ端から入れる」といった行動は、状況を分かりにくくするだけです。まずは自分のサイトのどこにhttpが残っているのかを確認しながら読み進めてください。それでは、そもそもMixed Contentとは何が起きている状態なのかから見ていきましょう。
なお、この記事はWordPressサイトを主な例にしていますが、考え方は静的HTMLサイトや他のCMSでも共通です。「httpsのページに残ったhttpリソースを、httpsに置き換える」という基本は変わりません。WordPress以外の環境の方は、データベース置換の工程を「ファイル内の一括置換」に読み替えて進めてください。それぞれの環境に応じた補足も、各章で触れていきます。
Mixed Content（混在コンテンツ）とは
Mixed Content（混在コンテンツ）とは、httpsで配信されているページの中に、httpで読み込まれるリソース（画像・CSS・JavaScript・動画など）が混ざっている状態を指します。日本語では「混在コンテンツ」と訳されます。ページ本体は暗号化されているのに、その中の一部が暗号化されていない通信で読み込まれているため、ブラウザが「このページは完全には安全ではない」と判断し、警告を出したり、リソースの読み込み自体をブロックしたりします。
なぜMixed Contentは問題なのか
httpsはページとブラウザの間の通信を暗号化し、途中で内容を盗み見たり書き換えたりされるのを防ぎます。ところが、そのページの中にhttpで読み込まれるファイルが1つでもあると、そのファイルの通信は暗号化されていません。つまり、ページの一部に「鍵のかかっていない扉」が残っている状態です。
攻撃者はこの暗号化されていない部分を狙い、通信の途中で画像やスクリプトを悪意のあるものにすり替える（中間者攻撃）ことができてしまいます。特にJavaScriptがhttpで読み込まれている場合、そのスクリプトが書き換えられればページ全体を乗っ取られる危険すらあります。だからこそブラウザは、Mixed Contentを検知すると警告やブロックで利用者を守ろうとするのです。
もう一つ実務的に大きいのが、鍵マークが付かないことによる信頼低下です。近年の利用者は、鍵マークが無いサイトや「保護されていない通信」と表示されるサイトに対して敏感になっています。フォームで個人情報を入力する場面では特に、鍵マークが無いだけで離脱されてしまうことも珍しくありません。セキュリティの実害だけでなく、こうした心理的な影響の面でも、混在コンテンツは早く解消しておく価値があります。
受動的コンテンツと能動的コンテンツの違い
Mixed Contentは、リソースの種類によって「受動的（Passive／表示系）」と「能動的（Active／実行系）」の2つに分けられます。この違いを理解すると、なぜ「画像は警告だけで表示されるのに、CSSやJSはブロックされて崩れる」といった差が出るのかが分かります。
| 区分 | 主なリソース | ブラウザの挙動 | 危険度 |
|---|---|---|---|
| 受動的（Passive） | 画像（img）・音声（audio）・動画（video） | 警告を出すが、多くの場合は表示される（鍵マークは付かない） | 比較的低い（ページ内容の改ざんリスクは限定的） |
| 能動的（Active） | スクリプト（script）・スタイルシート（CSS）・iframe・XMLHttpRequest／fetch・Webフォント | 原則としてブロックされ、読み込まれない（レイアウト崩れ・機能停止） | 高い（ページ全体を書き換えられる恐れ） |
受動的コンテンツは、ページの見た目に影響するだけで、それ自体がページの構造を操作することはありません。そのため多くのブラウザは、警告は出しつつも表示は許可します。ただし1つでもhttpの画像があれば鍵マークは付かなくなります。
一方能動的コンテンツは、ページの動作や見た目を根本から変える力を持ちます。もし攻撃者にすり替えられたら被害が大きいため、ブラウザは容赦なくブロックします。CSSがブロックされればデザインが崩れ、JavaScriptがブロックされればスライダーやフォームなどの機能が動かなくなります。「httpsにしたらデザインが崩れた」という相談の多くは、この能動的コンテンツのブロックが原因です。
ブラウザが警告・ブロックする理由
ブラウザがここまで厳しく振る舞うのは、「httpsのページは完全に安全である」という約束を守るためです。鍵マークは利用者に「このページの通信はすべて保護されています」と伝えるサインです。もし一部がhttpのままでも鍵マークを付けてしまうと、その約束が嘘になり、利用者を危険にさらすことになります。
そのため近年のChrome・Firefox・Safari・Edgeなどのブラウザは、能動的コンテンツを自動でブロックし、受動的コンテンツについても可能な限りhttpsへ自動アップグレードを試みるようになっています。それでも解決しないものが「Mixed Content」として警告に残る、という仕組みです。つまり警告が出ているということは、ブラウザの自動対応でも直せなかったhttpリソースが確実に存在するということ。次章では、その犯人を突き止める方法を見ていきます。
Mixed Contentが起きる典型的なきっかけ
Mixed Contentは、何もしていないのに突然発生するものではありません。ほとんどの場合、次のようなサイトに手を加えたタイミングで起こります。心当たりがあれば、そこが原因の起点です。
- http時代に運用していたサイトを後からhttps化した：過去記事の画像URLがhttpのまま残り、大量の混在コンテンツが発生する。もっとも多いパターンです。
- 別サイトからコンテンツを引っ越した・記事を貼り付けた：他サイトの画像URLや埋め込みコードにhttpが含まれていた。
- 古いテーマやプラグインを使っている：内部でhttpのURLを直書きしているものが、httpsサイトで混在コンテンツを起こす。
- 外部サービスのタグを貼った：解析タグ・広告タグ・SNS埋め込みなどにhttpが混じっていた。
- 開発環境（http）で作ったコードを本番（https）にそのまま持ち込んだ：ローカルで書いたhttpのURLが残っている。
いずれのケースも「もともとhttpで書かれたURLが、httpsのページに残っている」という点では共通しています。だからこそ、対処の基本は残っているhttpを見つけて、httpsに置き換えるという一点に集約されるのです。この視点を持って、次章の原因特定に進みましょう。
原因の特定｜DevToolsでhttpリソースを見つける
直し方に入る前に、まずはどのファイルがhttpのまま残っているのかを正確に突き止めることが最優先です。ここを飛ばして闇雲に修正すると、時間ばかりかかって解決しません。犯人を見つける最強の道具が、ブラウザに標準搭載されているDevTools（開発者ツール）です。ここではChromeを例に、コンソール・セキュリティ・ネットワークの3つのタブを使った特定方法を紹介します。
DevToolsの開き方
警告が出ているページをChromeで開き、次のいずれかの方法でDevToolsを開きます。
- キーボードの
F12キーを押す（WindowsもMacも共通で使えます）。 - または、ページ上で右クリック→「検証」を選ぶ。
- Windowsは
Ctrl＋Shift＋I、MacはCommand＋Option＋Iでも開けます。
画面の右側または下側にパネルが開けば成功です。上部にあるタブ（Console／Security／Network など）を切り替えながら原因を探していきます。
① コンソール（Console）タブで警告文を読む
最初に見るべきはコンソール（Console）タブです。Mixed Contentがあると、ここに警告メッセージが赤や黄色で表示されます。典型的なメッセージは次のような英文です。
Mixed Content: The page at 'https://example.com/' was loaded over HTTPS,
but requested an insecure image 'http://example.com/wp-content/uploads/2024/01/photo.jpg'.
This content should also be served over HTTPS.この英文は、そのまま宝の地図です。ポイントはシングルクォートで囲まれたhttpから始まるURL。上の例ならhttp://example.com/wp-content/uploads/2024/01/photo.jpgが、httpのまま読み込まれている画像です。imageと書かれているので受動的コンテンツ、つまり「警告は出るが表示はされる」タイプだと分かります。
メッセージの中の単語で、リソースの種類も判別できます。insecure image は画像、insecure script はJavaScript、insecure stylesheet はCSSです。scriptやstylesheetの場合はwas blocked（ブロックされました）と書かれることが多く、これが「デザインが崩れる」原因です。警告が複数出ているときは、1つずつURLを控えて、あとでまとめて直します。
なお、コンソールには混在コンテンツ以外のエラーや警告も表示されます。混在コンテンツを探すときは、メッセージの先頭が「Mixed Content:」で始まっているものだけに注目してください。それ以外の赤いエラー（JavaScriptのエラーなど）は、今回の混在コンテンツとは別の問題なので、まずは切り分けて考えます。コンソール右上のフィルター機能で「Mixed」などのキーワードで絞り込むと、目的の警告だけを効率的に確認できます。
② セキュリティ（Security）タブで全体像を見る
次にセキュリティ（Security）タブを開きます。DevToolsの上部タブに見当たらない場合は、タブ右端の「≫」やメニューから探してください。ここでは、そのページの証明書の状態と、混在コンテンツの有無が一目で分かります。
Mixed Contentがあると、このタブに「This page is not secure（Mixed Content）」や「Non-secure origins」といった表示が出ます。証明書自体は有効なのに安全と表示されない場合、ほぼ間違いなく混在コンテンツが原因です。表示された項目をクリックすると、問題のあるリソースへ案内してくれることもあります。
③ ネットワーク（Network）タブでhttp通信を洗い出す
コンソールで見落としがないか、ネットワーク（Network）タブで最終確認します。このタブを開いた状態でページを再読み込み（F5）すると、そのページが読み込んだすべてのファイルが一覧表示されます。
- Networkタブを開き、ページを再読み込みする。
- 上部のフィルター欄に
http://と入力するか、URLの列を見てhttp://で始まるものを探す。 - 見つかったら、その
NameやURLを控える。これが直すべきhttpリソースの一覧になります。
コンソール・セキュリティ・ネットワークの3つを突き合わせれば、直すべきhttpリソースの全リストが完成します。この一覧を手元にメモしてから、次の修正作業に進むと効率的です。原因の特定はここで9割終わったようなものです。
編集部おすすめ｜httpリソース特定チェックリスト
実際に何度も混在コンテンツを直してきた経験から、見落としやすいポイントをチェックリストにまとめました。DevToolsで犯人が見つからないときや、直したはずなのに鍵マークが付かないときに、上から順に確認してください。
- トップページだけでなく、投稿ページ・固定ページ・アーカイブも確認したか：ページによって使われている画像やパーツが違うため、混在コンテンツもページごとに違います。
- スマホ表示（レスポンシブ）専用の画像を確認したか：PC表示では出ないhttp画像が、スマホ用の画像で残っていることがあります。
- 記事本文だけでなく、ヘッダー・フッター・サイドバーを確認したか：共通パーツのhttpは全ページに影響します。
- ページを最後までスクロールしたか：遅延読み込み（Lazy Load）の画像は、スクロールして初めて読み込まれ、警告が出ることがあります。
- キャッシュを無視して再読み込みしたか：キャッシュプラグインやブラウザキャッシュで、古い状態が見えている場合があります。
- ログイン状態とログアウト状態の両方で見たか：ログイン中だけ表示される要素にhttpが残ることがあります。
このチェックリストをひととおり潰せば、まず見落としはありません。特に遅延読み込みの画像とキャッシュは初心者がハマりやすい落とし穴なので、覚えておいてください。
鍵マーク（アドレスバー）の見方
DevToolsを開かなくても、アドレスバーの表示である程度の状態は判断できます。ブラウザによって細部は違いますが、おおむね次のように見分けられます。
| アドレスバーの表示 | 意味 | 混在コンテンツの状態 |
|---|---|---|
| 閉じた鍵マーク（またはサイト情報アイコン） | 通信がすべて保護されている | 混在なし（理想の状態） |
| 鍵マークが無い／情報アイコンのみ | 一部がhttpのまま | 受動的な混在コンテンツあり（画像など） |
| 「保護されていない通信」「安全ではありません」 | 証明書が無い／期限切れ、または深刻な混在 | 証明書の問題、または能動的な混在の可能性 |
| 鍵に赤い斜線・警告三角 | 能動的コンテンツがブロックされている | CSSやJSがhttpで読み込まれブロック中 |
鍵マークをクリックすると、そのサイトの証明書情報や「この接続は保護されています／されていません」といった説明が表示されます。まずここで大まかな状態を掴み、詳しくはDevToolsで確定させる、という流れが効率的です。それでは、いよいよ具体的な直し方に入っていきましょう。
直し方①｜WordPress一般設定のアドレスをhttpsにする
WordPressサイトでMixed Contentが起きているとき、最初に確認すべきは「一般設定」のサイトアドレス・WordPressアドレスです。ここがhttp://のままだと、WordPressが生成する多くのURLがhttpで出力され、サイト全体に混在コンテンツが発生します。まずはこの土台を整えます。
設定の確認と変更手順
WordPress管理画面から、次の手順で変更します。作業は数分で終わりますが、間違えると管理画面にログインできなくなることもあるため、落ち着いて進めてください。
- 管理画面にログインし、左メニューの「設定」→「一般」を開く。
- 「WordPress アドレス (URL)」と「サイトアドレス (URL)」の2つを確認する。
- どちらかが
http://で始まっていたら、https://に書き換える（例：http://example.com→https://example.com）。 - ページ下部の「変更を保存」をクリックする。
保存すると自動的にログアウトされ、httpsのURLで再ログインを求められます。これは正常な挙動なので、慌てずにhttpsのアドレスでログインし直してください。
注意：SSL証明書が有効になっていることが前提
この変更をする前に、必ずSSL証明書がサーバーに設定され、httpsでサイトが開ける状態になっていることを確認してください。証明書が無いのにアドレスだけhttpsにすると、サイトにも管理画面にもアクセスできなくなります。「https://あなたのドメイン/」をブラウザで開いて、証明書エラーが出ずに表示されるかを先にチェックしましょう。証明書の準備については、後半の章で詳しく触れます。
設定を変えても管理画面に入れなくなった場合
万が一、アドレスを変えた直後に管理画面へ入れなくなったら、wp-config.phpに一時的な指定を追加して復旧できます。FTPやサーバーのファイルマネージャーでwp-config.phpを開き、/* 編集が必要なのはここまでです */の行より上に、次の2行を追加してください。
define('WP_HOME', 'https://example.com');
define('WP_SITEURL', 'https://example.com');この記述はデータベースの設定より優先されるため、管理画面の設定が正しくなくてもhttpsのURLで動くようになります。example.comは自分のドメインに置き換えてください。復旧できたら、データベース側の設定も正しく直してから、この2行は削除しても構いません（残しておいても問題はありません）。
この設定だけで直るケース・直らないケース
一般設定のアドレスをhttpsにすると、WordPress本体が自動生成する部分（テーマの読み込みURLや投稿のパーマリンクなど）は一気にhttpsになります。そのため、比較的新しく作ったサイトや、記事本数が少ないサイトでは、この設定だけで鍵マークが点灯することもあります。
一方で、過去記事の本文に埋め込んだ画像や、テーマに直書きしたURL、外部リソースのhttpは、この設定を変えても直りません。これらはWordPress本体が生成する部分ではなく、データベースやファイルの中に文字列として保存されているためです。「一般設定を直したのにまだ警告が出る」というのは、むしろ普通のこと。次のステップであるDB置換やハードコード修正へ進むサインだと考えてください。ここから先の作業が、混在コンテンツ解消の本丸です。
直し方②｜データベースを一括置換してhttpのURLを直す
一般設定を直しても、過去に投稿した記事の本文に埋め込まれた画像やリンクのURLは、http://のまま残っています。これはデータベースの中にhttp://example.com/wp-content/uploads/...という文字列として保存されているためです。1記事ずつ手で直すのは非現実的なので、専用プラグインで一括置換します。
作業前に必ずバックアップを取る
データベースの一括置換は、一度実行すると元に戻すのが難しい作業です。置換する文字列を間違えると、サイトが正しく表示されなくなることもあります。そのため、必ず作業前にデータベースのバックアップを取ってください。バックアッププラグイン（UpdraftPlusなど）や、レンタルサーバーの自動バックアップ機能、phpMyAdminからのエクスポートなど、どの方法でも構いません。バックアップ無しでの一括置換は絶対に避けましょう。
バックアップを取るときは、「いつ・どの状態で取ったか」をメモしておくと安心です。万が一置換で不具合が出たとき、どの時点に戻せばよいかがすぐ分かります。また、可能であればアクセスの少ない時間帯に作業するのもおすすめです。置換の最中や直後に不具合が出ても、影響を受ける利用者を最小限にできます。バックアップ・記録・時間帯の3点を押さえれば、DB置換は初心者でも十分安全に行えます。
Better Search Replace を使った置換手順
初心者に扱いやすいのがBetter Search Replaceというプラグインです。ドライラン（試し実行）機能があり、いきなり本番置換せずに影響範囲を確認できるのが安心です。
- 「プラグイン」→「新規追加」で
Better Search Replaceを検索し、インストール・有効化する。 - 「ツール」→「Better Search Replace」を開く。
- 「Search for（検索する文字列）」に
http://example.comを入力する（自分のドメインに置き換え）。 - 「Replace with（置換後の文字列）」に
https://example.comを入力する。 - 「Select tables（対象テーブル）」で、通常はすべてのテーブルを選択する（
CtrlやShiftで複数選択）。 - はじめは「Run as dry run?（ドライランとして実行）」にチェックを入れたまま「Run Search/Replace」を実行し、何件ヒットするかを確認する。
- 件数に問題がなければ、ドライランのチェックを外して本番実行する。
ポイントは検索文字列をドメインまで含めて指定することです。単にhttp://だけを置換すると、外部サイトへの正当なhttpリンクや、置換すべきでない箇所まで巻き込む恐れがあります。必ずhttp://自分のドメインという形で、自サイト内のURLだけを狙って置換してください。
Search Regex を使う方法
もう1つの選択肢がSearch Regexです。こちらは検索結果を1件ずつ目で確認しながら置換できるため、慎重に進めたい場合に向いています。正規表現も使えるので、複雑なパターンにも対応できます。
- 「プラグイン」→「新規追加」で
Search Regexをインストール・有効化する。 - 「ツール」→「Search Regex」を開く。
- 「Search pattern」に
http://example.com、「Replace pattern」にhttps://example.comを入力する。 - 「Search」で該当箇所を一覧表示し、内容を確認する。
- 問題なければ「Replace & Save」で置換を確定する。
Search Regexは1件ずつ確認できる反面、記事数が非常に多いサイトでは時間がかかります。大量の記事があるならBetter Search Replace、慎重に確認したいならSearch Regex、と使い分けると良いでしょう。置換後は必ずサイトを開いて、画像が正しく表示されるか、リンクが切れていないかを確認してください。
置換の対象になりやすい文字列パターン
記事の中には、単純なhttp://ドメイン以外にも、混在コンテンツを引き起こす文字列が潜んでいることがあります。次のようなパターンも、必要に応じて置換の対象に含めましょう。
| 置換前の例 | 置換後の例 | 備考 |
|---|---|---|
| http://example.com | https://example.com | 基本形。まずはこれを置換する |
| http:\/\/example.com | https:\/\/example.com | エスケープされた形。ブロックエディタやJSON内に潜むことがある |
| src="http://example.com | src="https://example.com | エンコードされた属性値。手動置換時に注意 |
| //example.com | そのまま可（httpsページなら追従） | プロトコル相対URL。無理に変えなくてよい |
特にバックスラッシュでエスケープされたhttp:\/\/は、ブロックエディタで作った記事やページビルダーのデータ内に保存されていることがあり、通常のhttp://置換では引っかかりません。DevToolsで犯人のURLは分かっているのに置換で減らない、というときは、このエスケープ形も疑ってみてください。
phpMyAdminで直接置換する上級者向けの方法
プラグインを増やしたくない場合は、phpMyAdminのSQLで直接置換することもできます。ただしデータベースを直接操作するため、初心者にはプラグインの利用を強くおすすめします。実行する場合は、必ずバックアップを取ってから、次のようなSQLを流します。
-- 投稿本文（wp_posts.post_content）のURLを置換する例
-- 実行前に必ずデータベースのバックアップを取ること
UPDATE wp_posts
SET post_content = REPLACE(post_content, 'http://example.com', 'https://example.com');REPLACE関数は「指定した文字列を別の文字列に置き換える」というものです。テーブル名の接頭辞（wp_）は環境によって異なることがあるので、自分のデータベースに合わせてください。シリアライズされたデータ（プラグイン設定など）はこの単純なSQLでは壊れる恐れがあるため、その点でもBetter Search Replaceのようにシリアライズ対応済みのプラグインのほうが安全です。
直し方③｜テーマ・CSS・コンテンツ内のハードコードhttpを直す
データベースを置換しても、テーマファイルやカスタムCSS、カスタムHTMLに直接書き込まれた（ハードコードされた）httpは残ります。これらはWordPressのデータベースではなく、ファイルやウィジェットの中に手書きで書かれているため、DB置換の対象外だからです。ここを見落とすと、いつまでも鍵マークが付きません。
よくあるハードコードhttpの場所
次のような場所に、http://で始まるURLが直書きされていないかを確認しましょう。
- テーマの header.php・footer.php：ロゴ画像やファビコン、外部スクリプトの読み込みURL。
- style.css やカスタムCSS：
background-image: url(http://...)の形で背景画像を指定している箇所。 - ウィジェットのカスタムHTML：バナー画像やアフィリエイトタグに含まれるhttpのURL。
- 投稿・固定ページのカスタムHTMLブロック：埋め込みコードや外部サービスのタグ。
- テーマオプション・カスタマイザーの設定：ロゴやヘッダー画像のURL指定。
CSS内の背景画像URLの直し方
CSSで背景画像を指定している場合、次のようにhttpをhttpsに書き換えます。DevToolsのコンソールでinsecure stylesheetや背景画像の警告が出ていたら、ここが原因の可能性が高いです。
/* 修正前：httpで読み込まれてブロックされる */
.hero {
background-image: url(http://example.com/wp-content/uploads/bg.jpg);
}
/* 修正後：httpsに書き換える */
.hero {
background-image: url(https://example.com/wp-content/uploads/bg.jpg);
}CSSを直したら、ブラウザのキャッシュが残っていて古い状態が見えることがあります。スーパーリロード（Windowsは Ctrl＋F5、Macは Command＋Shift＋R）でキャッシュを無視して再読み込みし、変化を確認してください。
テーマを直接編集するときの注意
テーマファイルを編集する場合は、必ず子テーマで作業するか、編集前のファイルをバックアップしてください。親テーマを直接編集すると、テーマ更新時に変更が上書きされて消えてしまいます。また、編集ミスでサイトが真っ白になることもあるため、FTPで元に戻せる状態を確保してから作業しましょう。
ハードコードhttpを効率的に探すコツ
どのファイルにhttpが直書きされているか分からないときは、ファイル全体を対象に「http://」で文字列検索するのが確実です。ローカルにテーマファイルをダウンロードし、VS Codeなどのエディタでフォルダを開いて、フォルダ内全体をhttp://で検索すれば、直書きされた箇所が一覧で出てきます。
検索でヒットしたもののうち、自サイトのドメインを含むhttpは基本的にすべて修正対象です。外部サイトへのリンク（<a href>）は、必ずしもhttpsにできるとは限りませんが、リンク先がhttpsに対応していれば揃えておくのが望ましいです。なお、コメント行や説明文の中のhttp（例：作者情報のURLなど）は、実際に読み込まれるリソースでなければ混在コンテンツの原因にはなりません。「読み込まれるsrcやurl()のhttp」を優先して直しましょう。
画像のsrc属性がhttpになっている例と修正
投稿本文やカスタムHTMLで、画像のsrcがhttpになっている典型例です。DevToolsで表示されない画像を特定したら、次のように直します。
<!-- 修正前：画像がhttpで読み込まれ、鍵マークが付かない -->
<img src="http://example.com/wp-content/uploads/banner.png" alt="バナー">
<!-- 修正後：httpsに書き換える -->
<img src="https://example.com/wp-content/uploads/banner.png" alt="バナー">同じ考え方は、<link>のCSS読み込み、<script>のsrc、<iframe>のsrcなど、URLを指定するすべての属性に当てはまります。「読み込む系の属性のhttpをhttpsに」と覚えておけば迷いません。
直し方④｜プロトコル相対URLと絶対httpsの使い分け
URLの書き方には、プロトコル相対URL（//で始まる書き方）と、絶対https URL（https://で始まる書き方）の2種類があります。どちらもMixed Content対策として使えますが、それぞれ特徴があるので、使い分けを理解しておくと便利です。
プロトコル相対URLとは
プロトコル相対URLとは、http:やhttps:の部分を省略し、//から書き始めるURLの書き方です。ブラウザは、そのページのプロトコルに自動で合わせてリソースを読み込みます。
<!-- 絶対https URL：明示的にhttpsを指定 -->
<img src="https://example.com/wp-content/uploads/photo.jpg" alt="">
<!-- プロトコル相対URL：ページのプロトコルに自動追従 -->
<img src="//example.com/wp-content/uploads/photo.jpg" alt="">プロトコル相対URLの利点は、httpのページでもhttpsのページでも、そのページに合わせて自動で読み込まれることです。サイト全体をhttps化した後は、ページ本体がhttpsなので、リソースもhttpsで読み込まれ、混在コンテンツになりません。
今どちらを使うべきか
かつてはhttpとhttpsが混在する過渡期に、プロトコル相対URLが重宝されました。しかし常時SSL化が当たり前になった現在は、絶対https URLで明示的に書くのが推奨です。プロトコル相対URLは、うっかりhttpのページで表示した場合にhttpで読み込まれてしまう余地が残ります。一般に、これから書くコードはhttps://から始まる絶対URLで統一しておくと、意図が明確で安全です。既存のプロトコル相対URLは、そのまま残しても問題ありませんが、書き換える機会があれば絶対httpsに揃えていくと良いでしょう。
3つのURL書き方の比較
混乱しやすいので、代表的な3つのURLの書き方を整理しておきます。それぞれの特徴を理解して、状況に応じて選べるようにしておきましょう。
| 書き方 | 例 | 特徴 | 常時SSL後の推奨度 |
|---|---|---|---|
| 絶対https URL | https://example.com/a.jpg | プロトコルもドメインも明示。もっとも確実で意図が明確 | ◎ 最推奨 |
| プロトコル相対URL | //example.com/a.jpg | ページのプロトコルに追従。httpsページでは混在しない | ○ 残っていても可 |
| ルート相対URL | /wp-content/a.jpg | ドメイン以下だけ指定。同一ドメイン内で完結し混在しない | ◎ 内部リンクに便利 |
| 絶対http URL | http://example.com/a.jpg | httpを明示。混在コンテンツの直接原因 | × 必ず修正 |
実は、自サイト内のリソースならルート相対URL（/で始まる書き方）も便利です。ドメインを含まないため、httpかhttpsかを一切気にせず、同じドメイン内で読み込まれます。ただし、これは同一ドメイン内でのみ使える書き方で、外部サービスのリソースには使えません。外部はhttpsの絶対URL、内部はルート相対URLか絶対https、と覚えておくと整理しやすいでしょう。
直し方⑤｜外部リソース（CDN・YouTube・Webフォント）への対応
ここまでで自サイト内のhttpは直せますが、外部サービスから読み込んでいるリソースがhttpのままだと、やはりMixed Contentになります。CDN、YouTubeの埋め込み、Webフォント、アクセス解析タグ、広告タグなどが該当します。外部リソースは自分のサーバーにファイルが無いぶん、URLの書き方だけで対処します。
CDNや外部スクリプトのURLをhttpsにする
jQueryやアイコンフォント、各種ライブラリをCDNから読み込んでいる場合、そのURLがhttpになっていないか確認します。ほとんどの主要CDNはhttpsに対応しているので、単純にhttps://へ書き換えれば解決します。
<!-- 修正前：CDNをhttpで読み込んでいる（ブロックされる） -->
<script src="http://code.jquery.com/jquery-3.7.1.min.js"></script>
<!-- 修正後：httpsに書き換える -->
<script src="https://code.jquery.com/jquery-3.7.1.min.js"></script>YouTube・地図などの埋め込みコード
YouTube動画やGoogleマップの埋め込みコード（iframe）に、古いhttp://のURLが含まれていることがあります。iframeは能動的コンテンツなので、httpのままだとブロックされて表示されません。埋め込みコードのsrc属性を確認し、httpならhttpsに直します。新しく取得し直した埋め込みコードは、たいていhttpsになっています。
Webフォントの読み込み
Google FontsなどのWebフォントをhttpで読み込んでいると、フォントが適用されず、意図しない代替フォントで表示されてしまいます。フォント読み込みのURL（linkタグや@import）を確認し、httpsに揃えてください。Google Fontsの公式が発行する最新のコードはhttpsなので、埋め込みタグを取り直すのが確実です。
外部サービスがhttpsに対応していない場合
ごくまれに、外部サービス自体がhttpsに対応しておらず、httpでしか提供されていないことがあります。この場合、そのリソースをhttpsで読み込む方法はありません。対処としては、（1）httpsに対応した代替サービスに乗り換える、（2）そのリソースを自分のサーバーにダウンロードして、自サイトのhttpsから配信する、のいずれかになります。古い解析タグや広告タグが原因になりやすいので、不要なものは思い切って外すのも一つの手です。
外部リソースでよくある失敗例と回避策
編集部がよく見かける、外部リソースまわりの失敗例と、その回避策をまとめます。自分のサイトに当てはまっていないか確認してみてください。
- 失敗例：古い記事の中に貼ったYouTube埋め込みがhttpのまま→ 回避策：DevToolsでブロックされているiframeを特定し、埋め込みコードを最新のもの（https）に貼り直す。
- 失敗例：アフィリエイトのバナー画像がhttpで配信されている→ 回避策：ASPの管理画面で新しいhttps版のタグを取得し直す。https版が無ければ、そのバナーの掲載を見送る。
- 失敗例：昔設置したアクセス解析タグがhttp→ 回避策：解析サービスの最新タグ（https）に差し替える。すでに使っていない解析なら削除する。
- 失敗例：Webフォントの@importがhttp→ 回避策：フォント提供元の最新の埋め込みコード（https）を取得して置き換える。
- 失敗例：他人のブログの画像を直リンクで表示していて、それがhttp→ 回避策：そもそも他サイトの画像を直リンクするのは避け、自分のサーバーに保存して配信する。
外部リソースは、自分でファイルを直せないぶん「最新のhttps版タグに取り直す」か「使うのをやめる」かの二択になりがちです。常時SSL化を機に、使っていない古いタグを棚卸しして整理すると、混在コンテンツが減るだけでなく、ページの表示速度も改善することが多いです。トラブル対応をきっかけに、サイトの外部依存を見直してみましょう。
直し方⑥｜functions.phpやプラグインで一括対応する
個別に直すのが大変な場合や、原因のURLが多すぎて追い切れない場合は、出力時にhttpをhttpsへ自動変換する方法があります。プラグインを使う方法と、テーマのfunctions.phpで対応する方法の2通りを紹介します。
プラグインで自動変換する（初心者向け）
もっとも手軽なのがSSL Insecure Content Fixerというプラグインです。ページ出力時にhttpのリソースを検出し、可能な範囲でhttpsに書き換えてくれます。設定画面で修正レベル（Simple／Content／Widgets／Capture など）を選べるので、まずはSimpleから試し、直らなければ段階的に強い設定にしていきます。
ただし、こうしたプラグインはあくまで「出力時に補正する」対処であり、根本的にDBやファイルを直しているわけではありません。プラグインを止めると再発する可能性があるため、時間があるときにDB置換やハードコード修正で根本対応しておくのが理想です。とはいえ、原因が特定しづらい場合の応急処置としては非常に有効です。
functions.phpでupgrade-insecure-requestsを付与する
テーマを編集できるなら、functions.phpでヘッダーにContent-Security-Policyを出力し、httpリソースをhttpsに自動アップグレードさせる方法もあります。子テーマのfunctions.phpに次のコードを追加します。
<?php
// httpリソースの読み込みをhttpsへ自動アップグレードするCSPヘッダーを送出
add_action('send_headers', function () {
header("Content-Security-Policy: upgrade-insecure-requests");
});この記述により、ブラウザはページ内のhttpリソースを自動的にhttpsへ読み替えて取得を試みます。受動的・能動的の両方に効くため、混在コンテンツの多くを一気に解消できます。ただし、そのリソースがhttpsで存在しない場合は読み込みに失敗するため、根本のURL修正と併用するのが安全です。次章では、このCSPをHTMLのmetaタグで指定する方法も紹介します。
一括対応と個別対応、どちらを選ぶべきか
ここまで「個別にURLを直す方法」と「プラグインやCSPで一括対応する方法」の両方を紹介してきました。どちらを選ぶべきか迷ったら、次の基準で判断してください。
| 状況 | おすすめの方法 | 理由 |
|---|---|---|
| 記事数が少なく、原因も特定できている | 個別にURLを直す | 根本解決でき、プラグインを増やさずに済む |
| 記事数が多く、httpのURLが大量にある | DB一括置換＋個別修正 | 手作業では追い切れない量を一気に処理できる |
| 原因が特定しづらい／急いで警告を消したい | CSPまたはプラグインで一括対応 | 出力時に自動補正し、応急処置として即効性がある |
| 恒久的に安定させたい | 根本修正＋仕上げのCSP | URLを直しつつ、再発防止のCSPで二重に守る |
理想は根本修正（DB置換・ファイル修正）でhttpを消し、その上で仕上げのCSPで再発を防ぐという二段構えです。一括対応プラグインだけに頼ると、プラグインを止めた瞬間に再発したり、サイト移行時に問題が再燃したりします。応急処置と根本対応を上手に組み合わせ、最終的には根本対応でhttpを一掃しておくのが、長く安定して運用するコツです。
仕上げ｜CSP・.htaccessリダイレクト・HSTS
個別のhttpリソースを直したら、最後に「二度と混在コンテンツを起こさない・httpでアクセスさせない」ための仕上げを行います。CSPによる自動アップグレード、.htaccessでのhttpリダイレクト、そしてHSTSの3つを押さえておけば、常時SSL化として万全です。
ここまでの直し方（①〜⑥）が「今あるhttpを消す作業」だとすれば、この仕上げは「今後もhttpを発生させない・httpでアクセスさせない仕組みづくり」です。個別修正だけだと、新しいコンテンツを追加したときにまた混在コンテンツが出る可能性がありますが、仕上げの設定を入れておけば、うっかりhttpのURLを書いても自動でhttpsに補正してくれます。手間を減らしつつ安全性を高める、いわば保険のような設定だと考えてください。
metaタグでupgrade-insecure-requestsを指定する
functions.phpを触りたくない場合や、静的HTMLサイトの場合は、HTMLの内にmetaタグを1行入れるだけでも同じ効果が得られます。次のタグをすべてのページの<head>内に追加してください。
<meta http-equiv="Content-Security-Policy" content="upgrade-insecure-requests">この1行で、ブラウザはページ内のhttpリソースをhttpsに読み替えて取得しようとします。受動的コンテンツの警告や、能動的コンテンツのブロックの多くをまとめて解消できる、費用対効果の高い仕上げです。WordPressなら、テーマのheader.phpの<head>内、または「HTMLヘッダーを追加できるプラグイン」経由で挿入できます。
ただし、このupgrade-insecure-requestsはあくまで「httpsに読み替えて取得を試みる」機能であって、httpsで存在しないリソースを魔法のように表示してくれるわけではありません。もとのリソースがhttpsで配信されている必要があります。つまり、これは「本来httpsで取れるのにhttpと書かれてしまっているリソース」を救済するもの。根本的にURLを直す作業と併用してこそ、真価を発揮します。仕上げの一手として入れておきつつ、時間があるときに個別のURLも直しておく、という二段構えが理想です。
.htaccessでhttpをhttpsにリダイレクトする
次に、そもそもhttpでアクセスしてきた利用者を、強制的にhttpsへ転送する設定を入れます。Apacheサーバー（多くのレンタルサーバー）では、サイトルートの.htaccessファイルに次の記述を追加します。
<IfModule mod_rewrite.c>
RewriteEngine On
RewriteCond %{HTTPS} off
RewriteRule ^(.*)$ https://%{HTTP_HOST}%{REQUEST_URI} [R=301,L]
</IfModule>この記述は「httpsでない（HTTPS off）アクセスは、同じURLのhttpsへ301リダイレクトする」という意味です。301は「恒久的な移転」を表すリダイレクトで、SEO上の評価も新しいhttpsのURLへ引き継がれます。WordPressの.htaccessを編集する場合は、# BEGIN WordPressの行より前に追記してください。編集前にファイルのバックアップを忘れずに。
.htaccessは記述を1文字間違えるだけでサイト全体が500エラーになることもある繊細なファイルです。編集する前に必ず元のファイルをダウンロードして手元に保存し、もし不具合が出たらすぐ元に戻せるようにしておきましょう。また、リダイレクトの記述は同じ内容を二重に書かないよう注意してください。サーバー側の常時SSL設定とこの記述が重複すると、リダイレクトが無限ループになることがあります。サーバー側に常時SSL機能があるなら、まずそちらを使い、.htaccessへの手動記述は行わない、という判断が安全です。
なお、レンタルサーバーによっては管理画面のボタン一つで「常時SSL化（httpからhttpsへの自動リダイレクト）」を有効にできることもあります。エックスサーバー・ロリポップ・さくらのレンタルサーバーなどは、この機能を備えています。手動で.htaccessを書くより安全なので、まずは利用中のサーバーに同様の設定がないか確認するのがおすすめです。
HSTSで常にhttpsを使わせる（発展）
さらに一歩進んだ対策がHSTS（HTTP Strict Transport Security）です。これは、サーバーが「今後このサイトには必ずhttpsで接続してください」とブラウザに宣言する仕組みです。一度HSTSを受け取ったブラウザは、次回以降httpでアクセスしようとしても、サーバーに問い合わせる前に自動でhttpsへ切り替えます。
HSTSはStrict-Transport-SecurityというHTTPヘッダーで指定します。強力な半面、一度有効にすると指定期間中はhttpに戻せなくなるため、httpsが完全に安定してから導入するのが鉄則です。設定に不安がある場合は無理に導入せず、まずはリダイレクトとCSPで十分な効果が得られます。HSTSは「常時SSL化を完全に固めきったサイトの最後のひと押し」と考えておくと良いでしょう。
仕上げ後の最終チェック手順
すべての設定を終えたら、本当に混在コンテンツがゼロになったかを最後にきちんと確認します。次の手順で、抜け漏れなくチェックしてください。
- ブラウザのキャッシュをクリアするか、シークレット（プライベート）ウィンドウで自分のサイトを開く。
- トップ・投稿・固定ページ・アーカイブなど、複数のページを開いて、それぞれで鍵マークが点灯しているか確認する。
- 各ページで
F12を押してDevToolsを開き、コンソールにMixed Contentの警告が出ていないか確認する。 - http://あなたのドメイン/にアクセスして、自動でhttpsへリダイレクトされるか確認する。
- スマホの実機やスマホ表示でも、鍵マークと画像表示を確認する。
- 問題がなければ、Google Search Consoleにhttpsのサイトを登録し、sitemap.xmlのURLもhttpsに更新する。
ここまで確認できれば、混在コンテンツの対応は完了です。特にシークレットウィンドウでの確認は、キャッシュに惑わされず「素の状態」を見られるので、最終チェックには最適です。念のため、数日後にもう一度アクセスして、証明書やリダイレクトが安定して機能しているかを見ておくと万全です。
前提知識｜SSL証明書と常時SSL化の全体像
ここまでMixed Contentの直し方を見てきましたが、そもそもhttpsで通信するにはSSL/TLS証明書がサーバーに設定されている必要があります。証明書が無ければ、いくらURLをhttpsにしても接続できません。ここでは前提となる証明書と、常時SSL化の全体像を整理します。
SSL証明書とは
SSL/TLS証明書とは、「このドメインは本物であり、通信は暗号化されています」ということを証明する電子的な証明書です。ブラウザはこの証明書を検証し、問題なければhttpsの鍵マークを表示します。証明書はドメインの所有者に対して、認証局（CA）が発行します。
Let’s Encryptとレンタルサーバーの無料SSL
かつて証明書は有料が中心でしたが、現在はLet’s Encryptという無料の認証局が広く使われています。多くのレンタルサーバーは、このLet’s Encryptを使った無料SSLをボタン一つで設定できるようにしています。
- エックスサーバー・ロリポップ・さくら・ConoHa WING など：管理画面から無料独自SSLを数クリックで設定可能。
- 設定後、反映まで数分〜1時間程度かかることがあるので、すぐhttpsで開けなくても少し待つ。
- 証明書は自動更新されることが多いが、更新が止まっていないかは時々確認しておくと安心。
証明書が有効になり、https://あなたのドメイン/で証明書エラーが出ずに開けることを確認してから、この記事の直し方に取り組むのが正しい順番です。
常時SSL化の全体像
常時SSL化とは、サイトのすべてのページをhttpsで配信し、httpでのアクセスをhttpsへ統一することを指します。全体像を手順で示すと、次のようになります。
- SSL証明書をサーバーに設定する（Let’s Encryptなど）。
- WordPressの一般設定でアドレスをhttpsにする（直し方①）。
- DB置換で本文中のURLをhttpsにする（直し方②）。
- ハードコードや外部リソースのhttpを直す（直し方③〜⑤）。
- .htaccessやサーバー設定でhttpをhttpsへリダイレクトする（仕上げ）。
- 最後にDevToolsで混在コンテンツがゼロになったことを確認する。
この流れをひととおり終えれば、Mixed Content警告は解消され、鍵マークが点灯するはずです。
SEO・表示速度への影響
常時SSL化は、セキュリティだけでなくSEOや表示速度の面でもメリットがあります。Googleはhttpsをランキングのシグナルのひとつとしていることを公表しており、一般に、同条件ならhttpsのほうが評価面で有利とされています。また、httpsの通信では高速な通信プロトコル（HTTP/2など）が使えることが多く、表示速度の向上にもつながります。逆にMixed Contentを放置すると、鍵マークが付かず利用者に不安を与え、離脱の原因にもなります。常時SSL化をやり切ることは、信頼性・SEO・速度のすべてにプラスに働く、と考えておくと良いでしょう。
https移行後にやっておきたい設定
混在コンテンツを解消してhttps化が安定したら、外部ツールやサイト設定もhttpsに合わせて更新しておきましょう。ここを忘れると、アクセス解析が正しく取れなかったり、検索順位の引き継ぎがうまくいかなかったりします。
- Google Search Console：httpsのURLを新しいプロパティとして登録し、サイトマップも再送信する。httpとhttpsは別サイト扱いになる点に注意。
- Google Analytics：プロパティの「デフォルトのURL」をhttpsに変更する。
- サイトマップ（sitemap.xml）：中のURLがhttpsになっているか確認する。SEOプラグインを使っていれば自動更新されることが多い。
- 内部リンク・外部から貼られた被リンク：内部リンクはDB置換で対応済みのはず。外部の被リンクは301リダイレクトで評価を引き継ぐ。
- SNSのシェアボタン・OGP設定：シェア数のカウントはhttpとhttpsで分かれることがあるため、必要に応じて設定を見直す。
これらは混在コンテンツの直接の対処ではありませんが、常時SSL化を「サイト全体の引っ越し」として完成させるために欠かせない仕上げです。特にSearch Consoleの再登録は、検索流入を維持するうえで重要なので、忘れずに行ってください。
常時SSL化でよくある誤解
最後に、常時SSL化について初心者が抱きやすい誤解を解いておきます。正しく理解しておくと、無用な不安なく作業を進められます。
- 誤解：SSL証明書を入れれば自動でhttpsになる→ 実際は、証明書はあくまで「httpsで通信できる準備」。サイト側のURLをhttpsに揃える作業（この記事の内容）が別途必要です。
- 誤解：httpsにすると必ずサイトが速くなる→ 高速なプロトコルが使えるようになることは多いですが、画像の重さやサーバー性能など他の要因のほうが速度に効きます。https化だけで劇的に速くなるわけではありません。
- 誤解：無料SSLは有料より安全性が低い→ 暗号化の強度自体に差はありません。無料のLet’s Encryptでも通信は十分に保護されます。
- 誤解：一度https化すれば二度と混在コンテンツは起きない→ 新しく貼った外部タグや、移行してきた記事で再発することがあります。新規コンテンツを追加したら、時々DevToolsで確認する習慣をつけましょう。
常時SSL化は一度きりの作業ではなく、サイトを運営し続ける限り、ときどき見直すメンテナンスの一部だと捉えておくと、トラブルに落ち着いて対応できます。
よくある質問
最後に、混在コンテンツの対応でつまずきやすいポイントを、Q&A形式でまとめます。作業中に「これはどうすればいいんだろう」と迷ったときの参考にしてください。どれも編集部が実際によく受ける質問ばかりです。
Q. すべて直したのに鍵マークにならないのはなぜ？
A. まだどこかにhttpリソースが1つでも残っている可能性が高いです。DevToolsのコンソールとネットワークタブをもう一度確認し、http://で始まるものが無いか洗い直してください。特に見落としやすいのは、CSS内の背景画像URL、ウィジェットのカスタムHTML、外部の解析タグや広告タグです。また、ブラウザのキャッシュで古い状態が見えていることもあるので、スーパーリロードやシークレットウィンドウで確認するのも有効です。
Q. 一部の画像だけ表示されないのですが？
A. その画像だけhttpで読み込まれている（受動的コンテンツ）状態が疑われます。表示されない画像を右クリック→「検証」でHTMLを確認し、srcがhttpになっていないかを見てください。本文中の画像ならDB置換で、テーマやCSS内の画像ならファイルを直接直します。ブラウザによっては受動的コンテンツのhttp画像を完全にブロックするため、「警告だけで表示される場合」と「表示されない場合」の両方が起こり得ます。
Q. 管理画面は正常なのに、サイト表示だけ崩れます
A. これは典型的な能動的コンテンツ（CSS・JS）のブロックです。テーマやプラグインが読み込むCSS・JavaScriptがhttpのままだとブロックされ、デザインや機能だけが崩れます。DevToolsのコンソールでwas blockedと書かれたstylesheetやscriptを探し、そのURLをhttpsに直してください。原因が多い場合は、CSPのupgrade-insecure-requestsやSSL Insecure Content Fixerでまとめて対応するのが早道です。
Q. データベースを置換して本当に大丈夫ですか？
A. 必ず事前にバックアップを取り、検索文字列をドメインまで含めて指定すれば、多くの場合は安全です。http://自分のドメインという形で自サイト内のURLだけを狙い、Better Search Replaceのドライラン機能で影響件数を確認してから本番実行してください。http://だけの置換は、外部サイトへの正当なリンクまで巻き込む恐れがあるので避けましょう。心配なら、まず1つのテーブルだけで試すのも手です。
Q. httpに戻したくなったらどうすればいいですか？
A. 基本的には常時SSL化を維持することを強くおすすめしますが、戻す場合は設定した内容を逆の順番で解除します。.htaccessのリダイレクト記述を削除し、WordPressの一般設定をhttpに戻し、CSPのmetaタグやfunctions.phpの記述を外します。ただし、HSTSを有効にしている場合は、期間中はブラウザ側が強制的にhttpsへ切り替えるため、簡単には戻せません。HSTS導入前によく検討することが大切です。現在の環境ではhttpに戻すメリットはほとんど無いため、原則としてhttpsを維持しましょう。
Q. WordPressではなく静的HTMLサイトでも同じ対処でいいですか？
A. 考え方は同じです。DevToolsでhttpリソースを特定し、HTMLやCSSに直書きされたhttpのURLをhttpsに書き換えます。データベースは無いのでDB置換の工程は不要で、代わりに各HTMLファイル内のURLをエディタの一括置換で直すのが効率的です。仕上げのupgrade-insecure-requestsのmetaタグや、.htaccessのリダイレクトはそのまま使えます。
Q. プラグインで直すのと、URLを手で直すのはどちらが良いですか？
A. 根本的にはURLを直す（DB置換・ファイル修正）ほうが確実です。プラグインによる補正は出力時の応急処置であり、プラグインを止めると再発する可能性があります。ただし、原因のURLが特定しづらい場合や、急いで警告を消したい場合には、プラグインやCSPで一括対応してから、時間をかけて根本修正していく、という順番でも問題ありません。
Q. httpsにしたらアクセス数が減った気がします
A. リダイレクト設定を301（恒久的な移転）で正しく行っていれば、SEO評価はhttpsのURLへ引き継がれます。もし302（一時的）で設定していると、評価が引き継がれにくくなります。また、Google Search ConsoleにhttpsのURLを別プロパティとして登録し直す必要がある場合もあります。移行直後は一時的に変動することもありますが、正しくリダイレクトできていれば通常は回復します。まずは.htaccessのリダイレクトが301になっているかを確認してください。
Q. 「保護されていない通信」と「安全ではありません」は同じ意味ですか？
A. ブラウザによる表現の違いはありますが、いずれもこの接続やページに何らかのセキュリティ上の問題があるというサインです。証明書が無い・期限切れ・ドメインと一致しない、あるいは深刻な混在コンテンツがある、といった場合に表示されます。まずはhttps://あなたのドメイン/で証明書エラーが出ずに開けるかを確認し、証明書に問題がなければ混在コンテンツを疑ってDevToolsで原因を探してください。証明書と混在コンテンツのどちらが原因かを切り分けることが、解決への第一歩です。
Q. 画像は表示されるのに鍵マークだけ付きません
A. これは受動的コンテンツ（http画像など）が残っている典型的な状態です。ブラウザによっては受動的なhttp画像を表示しつつ、鍵マークだけ外すことがあります。DevToolsのコンソールでinsecure imageやinsecure mediaの警告を探し、そのURLをhttpsに直せば鍵マークが点灯します。「表示されているから大丈夫」ではなく、警告が1つでも残っていれば鍵マークは付かない、と考えて全部潰しましょう。
Q. サブドメインや別ページにも同じ対処が必要ですか？
A. はい。混在コンテンツはページ単位・ドメイン単位で発生します。サブドメイン（例：blog.example.com）を運用している場合は、それぞれに証明書が必要ですし、それぞれのページで混在コンテンツを確認する必要があります。1つのページを直しても、別のページに固有のhttp画像が残っていれば、そのページの鍵マークは付きません。主要なページを一通りチェックして、抜けが無いようにしましょう。
まとめ
Mixed Content（混在コンテンツ）警告は、常時SSL化の過程でほぼ必ず出会うトラブルですが、その正体はhttpsのページの中にhttpのリソースが混ざっているだけです。仕組みさえ理解すれば、原因の特定も修正も、順番に進めれば必ず解決できます。
この記事で解説したように、まずはDevToolsのコンソール・セキュリティ・ネットワークタブで犯人のhttpリソースを突き止め、WordPressの一般設定・DB一括置換・ハードコード修正・外部リソース対応で1つずつhttpsに置き換えていきます。仕上げにCSPのupgrade-insecure-requestsや.htaccessのリダイレクトを入れれば、再発も防げます。
大切なのは、闇雲に手を動かすのではなく、原因を特定してから直すこと、そしてDB置換の前には必ずバックアップを取ることです。この2点さえ守れば、常時SSL化は初心者でも安全にやり切れます。鍵マークが点灯し、すべての画像が正しく表示されたときの安心感は格別です。ぜひ最後まで直し切って、安全で信頼されるサイトに仕上げてください。
もし途中で行き詰まっても、焦る必要はありません。混在コンテンツは必ずどこかにhttpのリソースが残っているという、原因のはっきりしたトラブルです。DevToolsをもう一度開き、コンソールの警告を1つずつ潰していけば、必ずゴールにたどり着けます。1回で完璧に直そうとせず、「1つ直して確認、また1つ直して確認」と、小さく進めるのが結局は一番の近道です。この記事を手元に置きながら、落ち着いて作業を進めてください。
・原因を特定してから直す：DevToolsのコンソール・セキュリティ・ネットワークで、httpのままのリソースを先に洗い出す。
・自サイト内は設定＋DB置換で、手書き部分は個別に：一般設定→DB一括置換→ハードコード・外部リソースの順で、httpをhttpsに揃える。
・仕上げで再発を防ぐ：upgrade-insecure-requestsのCSPと301リダイレクトで、httpアクセスとhttpリソースを自動で封じる。
Mixed Contentの解消は、Webサイトのセキュリティや常時SSL化を理解するうえで、とても良い実践練習になります。DevToolsの使い方やURLの仕組みを手を動かして学べば、他のトラブルにも応用が効くスキルが身につきます。もし「独学だと原因の切り分けに自信が持てない」「体系的にWeb制作やセキュリティの基礎を学びたい」と感じたら、正しい順序で学べる環境を活用するのが近道です。まずは無料で試せる初級コースから、確かな一歩を踏み出してみてください。
WithCodeを体験できる初級コース公開中！
初級コース(¥49,800)が完全無料に！
- 期間：1週間
- 学習内容：
ロードマップ/基礎知識/環境構築/HTML/CSS/LP・ポートフォリオ作成
→ 正しい学習方法で「確かな成長」を実感できるカリキュラム。
副業・フリーランスが主流になっている今こそ、自らのスキルで稼げる人材を目指してみませんか？
未経験でも心配することはありません。初級コースを受講される方の大多数はプログラミング未経験です。まずは無料カウンセリングで、悩みや不安をお聞かせください！
