「保護されていない通信」と出る主な原因は2つ。HTTPSなのに消えないときの混在コンテンツの見つけ方と直し方

「保護されていない通信」は、ブログがHTTPSで表示されていないとき、またはHTTPSのページにhttp://の画像やスクリプトが混ざっているときに出ます。どちらなのかは、アドレスバーのURLとページのソースを見れば切り分けられます。

自分のブログを開いたら、アドレスバーに「保護されていない通信」と出ていた。ブログサービスの設定でHTTPSにしたはずなのに消えない。HTTPSにしてから、古い記事の画像だけ表示されなくなった。検索順位に響くのかも気になる。そんな方に向けて書いています。

読み終えたときには、自分のブログが2つの原因のどちらに当たるかと、混在コンテンツを見つけて直す手順が分かるはずです。Chromeのヘルプ、web.dev、Googleの文書、Search Consoleのヘルプは、2026年10月9日に日本語版と英語版の原文で確かめました。HTTPSにすれば順位が上がる、とはこの記事では書きません。順位がどれだけ動くかを書いた公式の文書が見つからなかったからです。

結論:主な原因は2つ。まずアドレスバーのURLが http:// か https:// かを見る

切り分けの最初の一歩は、表示が出ているページのURLを見ることです。アドレスバーをクリックすると、URLの先頭まで表示されます。

Chromeのヘルプは、アドレスバーのアイコンを「情報、または保護されていない通信」と「保護されていない通信、または危険」に分けていて、この記事が扱うのは前者です。証明書が無効なときなど、HTTPS自体に問題がある場合も別の話です(Search ConsoleのHTTPSレポートのヘルプにも「HTTPS の証明書が無効である」というエラーがあります)。ページ全体に赤い警告画面が出たり、「この接続ではプライバシーが保護されません」というエラーが出たりする場合は、この2つとは別の問題です。Chromeのヘルプは、赤い警告画面はGoogle セーフ ブラウジングが安全でないと判断したサイト、「この接続ではプライバシーが保護されません」はサイト・ネットワーク・デバイスのいずれかの問題、と説明しています。この記事では扱いません。

原因1:ページ自体が http:// のまま

Chromeのヘルプ「サイトの接続が安全かどうかを確認する」(パソコン版)は、「情報、または保護されていない通信」のアイコンの意味を、こう説明しています。

サイトはプライベート接続を使用していません。このサイトとの間で送受信される情報は、何者かに見られる、または変更される可能性があります。
この問題を解決するには、サイト所有者が HTTPS を使用してサイトとお客様のデータを保護する必要があります。
— Google Chrome ヘルプ「サイトの接続が安全かどうかを確認する」(パソコン版。最終更新日の表示なし)

英語版も "The site doesn't use a private connection." "To resolve this issue, the site owner must secure the site and your data with HTTPS." で、日本語版と同じ内容です。直すのは読者ではなく、ブログの持ち主です。

直し方:HTTPSを有効にして、http:// から https:// へ転送する

やることは2つです。1つはブログをHTTPSで配信できるようにすること(ブログサービスでは「SSL」「HTTPS配信」などの名前の設定になっていることが多いです)。もう1つは、http://のURLで来た読者を https://のURLへ転送することです。HTTPSを有効にしても、http://のURLのリンクやブックマークから開かれると、そのページはhttp://のまま表示されることがあります。

転送のしかたについて、web.devの「サーバーで HTTPS を有効にする」(Googleのページ エクスペリエンスの文書が「HTTPS でサイトを保護する方法」としてリンクしている先です)は、「301 (Moved Permanently) を使用して、HTTPS バージョンが正規であることを検索エンジンとブラウザに示し、HTTP から HTTPS バージョンのサイトにユーザーをリダイレクトします。」と書いています(英語版は "Use 301 (Moved Permanently) to indicate to search engines and browsers that the HTTPS version is canonical")。ただしこのページの最終更新は2015年3月27日で、サーバーを自分で設定する人向けの内容です。

ブログサービスを使っているなら、設定画面の場所はサービスごとに違います。FC2ブログとSeesaaブログでの設定の場所はFC2ブログはSEOに弱い？「保護されていない通信」の直し方と、サーチコンソールで確かめることとSeesaaブログはSEOに弱い？検索に出ないとき確かめる3つとサーチコンソールの登録に、それぞれのヘルプで確かめた範囲でまとめています。転送できているかは、http://で始まるURLをアドレスバーに打ち込んで開き、https://に変わるかで確かめられます。

原因2:https:// なのに出るのは、混在コンテンツ

HTTPSにしたのに表示が消えないときにまず疑うのが、こちらです。ページ自体はhttps://で開かれているのに、ページの中で読み込む画像やスクリプトの一部がhttp://のURLのままになっている状態を、混在コンテンツ(英語では mixed content)と呼びます。web.devの「混合コンテンツとは」の日本語版は「混合コンテンツ」と訳しているので、以下、原文を引くところはその字のままにします。指しているものは同じです。

web.devは、混合コンテンツを2種類に分けています。

混合コンテンツには、アクティブとパッシブの 2 種類があります。
— web.dev「混合コンテンツとは」(日本語版・英語版とも最終更新2019年9月7日)

パッシブは画像・動画・音声のように、ページのほかの部分とやり取りしないもの、アクティブはスクリプト・スタイルシート・iframeのように、ページ全体とやり取りするものです。ブログで「保護されていない通信」が消えない理由として、web.devの次の1文が直接の答えになります。

パッシブな混合コンテンツが存在する場合、ページ自体が HTTPS で読み込まれていても、ほとんどのブラウザではアドレスバーにページが安全でないことが示されます。
— web.dev「混合コンテンツとは」

英語版は "If passive mixed content is present, most browsers indicate in the address bar that the page isn't secure, even when the page itself is loaded over HTTPS." です。つまり、http://の画像が1枚混ざっているだけでも、HTTPSにしたはずのページに表示が出ることがあります。

ただしこの文書は2019年9月7日の更新で、同じページは、Chromeがパッシブな混合コンテンツを自動でhttps://に切り替えることがある(「パッシブな混合コンテンツが自動的にアップグレードされることがあります。」)とも書いています。今のChromeでどの場合に表示が出るかは、私が読んだChromeのヘルプには書かれていません。

HTTPSにしたら画像が表示されなくなったのも、同じ原因のことがある

web.devは「現在、ほとんどのブラウザでは、セキュリティ上の理由から混合コンテンツがブロックされています。」とも書いています(英語版は "Most browsers now block mixed content for security reasons.")。Chromeは場合によって、http://で書かれた画像などをhttps://に切り替えて読み込みますが、「安全なバージョンがない場合、アセットは読み込まれません。」(英語版は "If there's no secure version, the asset doesn't load.")。https://で配信されていない画像は、表示されなくなるということです。HTTPSにしてから古い記事の画像だけ消えた、という場合は、その画像のURLがhttp://のままになっていないかを見てください。

ブログで混ざりやすい場所

web.devの「混合コンテンツの修正」は、CMS(ブログの管理画面のような仕組み)で公開しているサイトについて、画像が相対パスではなく完全なURLで入っていることがある、と書いています。個人ブログに当てはめると、混ざりやすいのは次のような場所です(ここは私の整理です)。

• HTTPSにする前に書いた記事の本文に、http://で始まる画像のURLが入っている
• サイドバーやフッターに貼った、古いブログパーツやアクセスカウンター、外部の画像
• テーマのHTMLやCSSに、http://で書かれた画像やスクリプトのURLがある
• 広告や外部サービスの貼り付けコードが、http://のURLを読み込んでいる

混在コンテンツの見つけ方と直し方

web.devの「混合コンテンツの修正」(日本語版・英語版とも最終更新2019年9月7日)に沿って、ブログでやる順に並べます。

1. 表示が出ているページのソースを開き、「http://」で検索する。web.devは「ソースで http:// を検索し、HTTP URL 属性を含むタグを探します。」と書いています(英語版は "Search for http:// in your source and look for tags that include HTTP URL attributes.")。見るのは、img の src のように、ページの中で読み込むもののURLです。ほかのページへ移動するだけのリンク(<a> の href)にhttp://が入っているのは、多くの場合、混合コンテンツの問題ではないとweb.devは書いています。ただし、一部の画像ギャラリーのスクリプトは <a> の href で指定されたhttp://の画像をページ内(ライトボックス表示)に読み込むので、混合コンテンツの問題になる、ともweb.devは書いています
2. Chromeのデベロッパーツールでも確かめる。web.devによると、ChromeでHTTPSのページを開くと、混合コンテンツがJavaScriptコンソールや[問題]タブにエラーや警告として出ます。ただし、出るのは今開いているページの分だけです。テンプレートが同じなら共通の部分はほかのページでも同じですが、記事本文の画像は記事ごとに違うので、表示が出ているページを1つずつ見ます
3. 見つけたURLを https:// に書き換えられるか試す。web.devは、ブラウザのURLバーでhttp://をhttps://に変えて開き、そのリソースが安全に取れるかを確かめる方法を挙げています。取れるなら、記事やテーマの中のURLをhttps://に書き換えます
4. https:// で取れないものは、3つのどれかにする。web.devが挙げる選択肢は、「別のホストのリソースがある場合は、そのリソースを含めます。」「法律で認められている場合は、コンテンツをダウンロードしてサイトで直接ホストします。」「サイトからリソースを完全に除外します。」の3つです。ブログでいえば、配布元がhttps://で配っている版に貼り替えるか、自分で権利を持つ画像ならブログに上げ直すか、古いブログパーツなら外す、ということになります
5. 直したら、最初に表示が出たページを開き直す。web.devも、修正したら元のページでエラーが出なくなったことを確かめるよう書いています。アドレスバーの表示が消えたかも、同じときに見ておきます

web.devの「混合コンテンツの修正」には、ヘッダーやmetaタグで「upgrade-insecure-requests」を指定して、ブラウザにhttp://の読み込みをhttps://へ切り替えさせる方法も載っています。ただ、https://で配信されていないリソースはその場合も読み込まれないとweb.devは書いているので、元のURLを直す手順の代わりにはなりません。

HTTPSにすると、検索ではどう扱われるか

検索順位に響くのかについて、Googleの文書に書かれている範囲をまとめます。ページ エクスペリエンスの文書(日本語版の最終更新2026年9月25日、英語版2026年9月22日)は、自己評価の質問の1つに「ページは安全な方法で配信されていますか。」(英語版は "Are your pages served in a secure fashion?")を挙げています。一方で、よくある質問ではこう書いています。

Core Web Vitals 以外のページ エクスペリエンスの要素が検索結果でのランキング上昇に直接貢献することはありません。
しかし、そういった要素はウェブサイトのユーザー満足度を向上させる可能性があり、それは通常、Google のランキング システムでも高く評価されます。
— Google 検索セントラル「ページ エクスペリエンスと Google 検索結果への影響」(日本語版の最終更新2026年9月25日)

英語版は "Beyond Core Web Vitals, other page experience aspects don't directly help your website rank higher in search results." です。また、上で引いたweb.devの「サーバーで HTTPS を有効にする」(2015年3月27日更新)には「Google は HTTPS を検索品質のプラス要因として使用しています。」(英語版は "Google uses HTTPS as a positive search quality indicator.")とあります。ただしこれは2015年の文書で、今の扱いを説明したものとしては読めません。2023年4月19日のGoogle 検索セントラル ブログは、HTTPSを「すでにコアランキング システムで使用されている」シグナルの例に挙げています(原文は「すでにコアランキング システムで使用されている HTTPS などのページ エクスペリエンス シグナルに加えて、新たに Core Web Vitals がシグナルとして導入されました。」)。どの文書にも、HTTPSにしたら順位がどれだけ動くかは書かれていません。この記事では、HTTPSと混在コンテンツは、読者のブラウザに警告を出さず、画像が消えないようにするために直すもの、として扱います。ページ エクスペリエンスの文書のほかの書き方や、2023年のGoogleのブログとの関係はページエクスペリエンスは順位に効く？公式がランキングで使うと名指ししている要素はCore Web Vitalsだけにまとめています。

Search ConsoleのHTTPSレポートで見られること、見られないこと

HTTPS レポートのヘルプは、このレポートについて「このレポートは、ドメイン プロパティと HTTPS URL プレフィックス プロパティでのみご利用いただけます。」とし、「HTTPS レポートでは、サイトでインデックス登録された URL のうち、HTTP の URL と HTTPS の URL がそれぞれどれだけあるかを確認できます。」と書き、「サイトのレポートに HTTP URL が含まれず、サイトの URL がすべて HTTPS URL であることが理想的です。」としています(英語版は "Ideally your site should have no HTTP URLs in the report, indicating that your site is using all HTTPS URLs.")。原因1(http://のまま、転送が漏れている)の確かめには使えます。

一方で、私が読んだこのヘルプ(日本語版・英語版)には、混合コンテンツ(mixed content)の語は出てきません。レポートが数えるのはインデックスされたURLがhttpかhttpsかなので、原因2の混在コンテンツは、上の手順でページのソースを見て確かめます。HTTPSにしたあと、Search Consoleの数字がどのプロパティに入るかはサーチコンソールのhttpとhttps、データが無いのはどちら？見分ける3つの確認で見分けられます。

よくある質問

「保護されていない通信」と出ていると、検索結果に出なくなりますか

私が読んだGoogleの文書には、そう書かれていません。Search ConsoleのHTTPSレポートのヘルプは、HTTPとHTTPSの両方のURLがあるページについて、Googleは優先的にHTTPSのほうをインデックス登録する、と書いています。http://のページが検索から外れるという書き方ではありません。ただ、読者のブラウザに警告が出ている状態は避けたいので、表示が出ているなら直しておくのが無難です。

混在コンテンツと混合コンテンツは、違うものですか

同じものです。英語の mixed content の訳で、web.devの日本語版は「混合コンテンツ」、ブログサービスのヘルプなどでは「混在コンテンツ」と書かれていることがあります。

自分のパソコンでは表示が出ないのに、読者に「安全ではない」と言われました

読者がhttp://のURL(古いリンクやブックマーク)から開いているのかもしれません。Chromeのヘルプには、「常に安全な接続を使用する」をオンにしている人がHTTPSに対応していないサイトを開くと、「このサイトへの接続は安全ではありません」という警告が出る、とも書かれています。http://のURLで開いてhttps://に転送されるかを、自分でも確かめてみてください。

一部の記事だけ表示が出るのはなぜですか

原因2の混在コンテンツは、ページごとに起きるからです。サイドバーやテーマに混ざっていれば全ページに出ますが、記事本文の画像に混ざっていれば、その記事だけに出ます。web.devも、混合コンテンツのエラーと警告は今開いているページの分しか出ないと書いているので、表示が出る記事と出ない記事を開き比べると、どこに混ざっているかの見当がつきます。

まとめ

• 「保護されていない通信」の主な原因は2つ。アドレスバーのURLが http:// ならページ自体がHTTPSでない、https:// なら混在コンテンツを疑う
• 原因1は、ChromeのヘルプのとおりサイトをHTTPSにする。あわせて http:// から https:// へ転送されるかを確かめる(サービス別の設定はFC2・Seesaaの記事へ)
• 原因2は、web.devによると、画像などのパッシブな混合コンテンツがあるだけで、ページがHTTPSでも多くのブラウザがアドレスバーで安全でないと示す
• 直し方は、ソースで http:// を探し、https:// で取れるなら書き換え、取れないなら別の配布元・自分でホスト・外すのどれかにする
• HTTPSについてGoogleの文書は、自己評価の質問に「安全な方法で配信されていますか」を挙げ、Core Web Vitals 以外の要素は順位に「直接貢献することはありません」と書く。一方、2023年4月19日のGoogleのブログはHTTPSを「すでにコアランキング システムで使用されている」シグナルの例に挙げている(2015年のweb.devの「検索品質のプラス要因」は今の扱いの説明としては読めない)。どれも、順位がどれだけ動くかは書いていない

表示が消えたあとに残るのは、検索結果に出ている記事のうち、どれがクリックされていないかの切り分けです。その切り分けのために私が作ったツールがあるので、ここから宣伝として書きます。

検索結果に表示されているのにクリックされていない記事を探して並べるツールを作りました。サーチコンソールのエクスポートをZIPのまま置くだけで、掲載順位が4.0〜20.5位のページを拾い、表示回数100回以上は通常判定、30〜99回は参考判定、30回未満は本文中心の監査に分けて、同じ区分の中ではCTR機会差の多い順に並べます。 判定と候補3記事のCTR機会差の確認、そのうち1記事分の診断カードまでは無料です。有料は2,980円(税込)の買い切りで、無料の1件を除いた3記事分の診断カードが対象です。3記事分が揃うとき(判定に出た候補が4件以上のとき)だけご案内します。生成の利用期限は購入から7日間で、月額課金や自動更新はありません。ログインも不要です。 CSVファイルそのものはブラウザの外に出ませんが、診断カードを出すときは選んだ1ページぶんの数値(URL・キーワード・順位・表示回数・CTR)を、タイトル取得を押したときは最大10件のURLを送ります。

⚠️ この記事の作業そのものには使えません。判定に使うのは、Google検索のページごとの平均掲載順位・表示回数・CTRです(診断カードでは選んだ1ページの本文を読みます)。ページがhttp://かhttps://か、混在コンテンツがあるか、転送が効いているかは調べません。診断カードは本文の画像のaltを見るために画像のURLも読み取りますが、それがhttp://かどうかを判定する処理はありません。CSVのURLは1行ずつそのまま扱うので、同じ記事のhttp://とhttps://の行が両方あると、別々のページとして並びます。表示回数が0の行は読み込み時に除きます。掲載順位4.0〜20.5位に入るページが無いブログでは、候補が0件になることがあります。並べ替えるだけで、順位やクリック数が上がることを約束するものではありません。