混在コンテンツ

要点 — 混在コンテンツとは、安全な https:// ページが画像、スクリプト、スタイルシートなどを安全でない http:// 経由で読み込む状態です。HTTPSページに安全でない要素が混ざるため、HTTPSの保護が損なわれます。ブラウザーはスクリプト、スタイル、iframeなど危険性の高い種類をブロックし、画像やメディアなど比較的軽い種類には警告を出します。HTTPS移行直後にサイトが壊れる代表的な原因ですが、基本的な修正は単純です。すべてのリソースを https:// で読み込ませます。

混在コンテンツとは

サイトをHTTPSへ移行すると、ページ本体は安全に読み込まれます。しかしページはHTMLだけではありません。画像、スクリプト、スタイルシート、フォント、動画、場合によっては別の場所にある埋め込みフレームも読み込みます。そのどれかが平文の http:// でリクエストされていれば、混在コンテンツ、つまり安全なページが安全でない要素を運んでいる状態です。 Evidence for this claim Mixed content occurs when a secure page loads resources over insecure HTTP, and browsers upgrade or block mixed-content requests by resource type. Scope: MDN documents current browser categories and behavior; individual browser versions may differ at the margins. Confidence: high · Verified: 2026-07-14 MDN: Mixed content

Googleの解説では、“A page has mixed content when its initial HTML is loaded over a secure HTTPS connection, but other resources (such as images, videos, stylesheets, and scripts) are loaded over an insecure HTTP connection.” (翻訳) 「最初のHTMLは安全なHTTPS接続で読み込まれる一方、画像、動画、スタイルシート、スクリプトなど別のリソースが安全でないHTTP接続で読み込まれる場合、そのページには混在コンテンツがあります」と説明しています。

これが重要なのは、安全でない要素がHTTPSによって閉じた穴を再び開けるからです。訪問者とサーバーの間のネットワークにいる第三者は、その http:// リクエストを読み取ったり改ざんしたりできます。つまり、アドレスバーの南京錠が示す安全性と、ページの実際の安全性が一致しません。

2種類の混在コンテンツとブラウザーの対応

ブラウザーはすべての混在コンテンツを同じようには扱いません。安全でないリソースが及ぼせる被害の大きさに応じて分類します。

• アクティブ混在コンテンツ — スクリプト、スタイルシート、iframeです。ページ全体を制御できるため、改ざんされると内容を全面的に書き換えられます。ブラウザーはこれをブロックします。 移行後にレイアウト、操作機能、埋め込みウィジェット全体が壊れる原因です。
• パッシブ混在コンテンツ — 画像、音声、動画です。ページ全体を乗っ取れないため、従来のブラウザーは読み込みを許可する代わりに南京錠を外し、「完全には安全でない」という警告を表示していました。現在はこの扱いも変わり、最新ブラウザーでは自動アップグレードまたはブロックされる種類が増えています。

混在コンテンツに該当しない例は、HTTPページへの通常のリンク（<a href="http://…">）です。これは別のページへ移動するだけで、安全な現在のページ内に安全でない要素を読み込むものではありません。

修正方法

修正方法はほぼ共通です。安全でないリソースをHTTPSで読み込ませます。 参照の http:// を https:// に変更するか、プロトコルを固定しないパスを使います。多くの場合、リソース自体はすでにHTTPSで利用でき、テンプレート、プラグイン、データベースに古い http:// URLが残っているだけです。

見落としに備えるなら、設定を1行追加できます。upgrade-insecure-requests ヘッダーは、残っている http:// のリソースリクエストを送信前に https:// へ書き換えるようブラウザーへ指示します。有効な安全網ですが、元の参照を修正しなくてよい理由にはなりません。 Evidence for this claim The upgrade-insecure-requests CSP directive rewrites insecure URLs as secure URLs before requests are made. Scope: MDN documents the directive's rewriting behavior and limits; it does not guarantee that an HTTPS version of every resource exists. Confidence: high · Verified: 2026-07-14 MDN: CSP upgrade-insecure-requests

ブラウザーがブロックする正確なリソース一覧、DevToolsコンソールとCSPレポートを使った大規模検出、upgrade-insecure-requests と block-all-mixed-content、CMSが再発させる理由、HSTSとの関係まで確認するには、Advancedタブへ切り替えてください。

要点 — 混在コンテンツは、HTTPSページがHTTP経由でサブリソースを読み込む状態です。現在のブラウザーとW3Cは、HTTPSへ自動変更するアップグレード可能な種類と、拒否するブロック対象の種類に分類します。従来のアクティブ／パッシブ分類も影響範囲を把握するうえで有用ですが、例外があります。通常の img src はアップグレード可能でも、CORS付き画像、srcset／picture候補、IPアドレスをホストに使うリクエストはブロック対象です。スクリプト、スタイルシート、iframe、XMLHttpRequest／fetchなどのアクティブコンテンツはブロックされ、改ざんされたスクリプトはページを書き換えられるため、公開時に最優先で直します。画像、音声、動画などのパッシブコンテンツは従来、セキュリティ表示を下げて読み込まれていましたが、自動アップグレードまたはブロックされる傾向が強まっています。アンカーリンクなどのトップレベルHTTPナビゲーションは混在コンテンツではなく、安全でないダウンロードも関連する別の境界です。取得ソース、レンダリング後の実行状態、実ユーザーセッションの3層を、HTTPSクロール、Chrome DevTools、Content-Security-Policy-Report-Only違反で調べます。修正時はHTTPS版が実際に動くことを確認してから、すべてのサブリソースを https:// へ向けます。相対URLやプロトコル相対URLは所有権とbase URLの挙動を確認した場合に使えますが、万能な既定値ではありません。Content-Security-Policy: upgrade-insecure-requests は対象の http:// サブリソースを送信前、かつ混在コンテンツ/CSP判定前に https:// へ書き換えます。これは安全網であって元ソースの代替ではなく、失敗時にHTTPへ戻りません。また第三者オリジンへのトップレベル移動はアップグレードしないため、HSTSの代替にもなりません。このディレクティブ自体をreport-onlyに置いても機能しないので、監視には別のreport-onlyポリシーを使います。CMSデータベースではバックアップとdry-runを行い、直線的な文字列置換でシリアライズ済みデータを壊さないようにします。プラグイン、テーマ、Service Workerとキャッシュ、広告・解析タグも再発源になるため、ページ単位ではなく全体を監査します。

HTTPSハブでは、混在コンテンツをHTTPS移行公開時の2大障害の1つとして紹介しています（もう1つはリダイレクトです）。ここでは、リソース区分、検出手段、CSPディレクティブ、再発する運用上の理由を詳しく扱います。

混在コンテンツに該当するもの・しないもの

混在コンテンツの範囲は明確で、ページ内のリンクではなく、ページが読み込むサブリソースが対象です。Googleの定義は、“A page has mixed content when its initial HTML is loaded over a secure HTTPS connection, but other resources (such as images, videos, stylesheets, and scripts) are loaded over an insecure HTTP connection.” (翻訳) 「最初のHTMLは安全なHTTPS接続で読み込まれる一方、画像、動画、スタイルシート、スクリプトなど別のリソースが安全でないHTTP接続で読み込まれる場合、そのページには混在コンテンツがあります」です。 Evidence for this claim Mixed content occurs when a secure page loads resources over insecure HTTP, and browsers upgrade or block mixed-content requests by resource type. Scope: MDN documents current browser categories and behavior; individual browser versions may differ at the margins. Confidence: high · Verified: 2026-07-14 MDN: Mixed content

誤解を招きやすいのがアンカータグです。HTTPページへの <a href="http://…"> リンクは混在コンテンツではありません。新しい文書へ移動するだけで、現在の安全なページへ安全でないリソースを読み込まないためです。これはアンカーのクリックに限らず、HTTPページへのすべてのトップレベルナビゲーションに当てはまります。

それでも外部リンクはHTTPS宛てにする価値があります。現在のブラウザー既定の Referrer-Policy（strict-origin-when-cross-origin）では、HTTPSページからHTTP宛てに移動すると Referer ヘッダーが落ち、参照元分析が乱れることがあります。ただしこれはポリシーとブラウザーに依存し、普遍的な規則ではありません。ページや上流のプロキシ/CDNがより緩い Referrer-Policy を設定していれば、ダウングレード時にもreferrerを送る場合があります。参照データの損失を断定する前に、実際に有効な Referrer-Policy を確認してください。いずれにしても、これは混在コンテンツとは別の問題です。

アクティブとパッシブ：優先順位を決める違い

最新のブラウザーとW3C文書は、混在コンテンツを主にアップグレード可能とブロック対象に分類します。前者はブラウザーがHTTPSで静かに再試行する種類、後者は即座に拒否する種類です。従来のアクティブ／パッシブ分類は、リソースがページのどこまで侵害できるか、つまりブラウザーが線を引く理由を理解する略語として今も有用で、Googleの解説もこの枠組みを使っています。ただし、特定のリソース種別を判断するときは現在の公式分類として扱わず、後述の例外を確認してください。

ブラウザーは、安全でないリソースがページのどこまで侵害できるかで混在コンテンツを分類します。Googleは、“Active mixed content poses a greater threat than passive mixed content.” (翻訳) 「アクティブ混在コンテンツは、パッシブ混在コンテンツより大きな脅威になります」と説明しています。この一文を優先順位の基準にしてください。

アクティブ混在コンテンツはページ全体と連動し、乗っ取ることもできます。Googleは、“scripts, stylesheets, iframes, and any other code the browser can download and execute.” (翻訳) 「スクリプト、スタイルシート、iframe、その他ブラウザーがダウンロードして実行できるコード」と説明しています。実務上は次の種類です。

• <script src="http://…"> — 最悪のケースです。傍受されたスクリプトはDOM全体を書き換え、フォームデータを流出させ、コンテンツを注入できます。
• <link rel="stylesheet" href="http://…"> — CSSは任意の要素を隠す、移動する、覆うことができるため、アクティブ扱いです。
• <iframe src="http://…"> — 安全なページ内に安全でない文書を埋め込みます。
• http:// への XMLHttpRequest／fetch() — ページが処理に使うデータを安全でない経路で取得します。
• Webフォント、<object>／<embed>、実行可能またはレイアウトを制御する内容を読み込む <link> の各種形態です。

改ざんされたアクティブリソースはページを書き換えられるため、“Most browsers already block this type of content by default to protect users.” (翻訳) 「ほとんどのブラウザーは、ユーザーを保護するため、この種類のコンテンツを既定でブロックしています」。そのため移行後には、スタイルシートが止まってCSSが消える、スクリプトが止まって操作不能になる、iframeが止まって空白が残る、といった目に見える障害になります。アクティブを最初に修正してください。 単なるセキュリティ警告ではなく機能不良です。

パッシブ（表示）混在コンテンツは、Googleのいう “including images, video, and audio” (翻訳) 「画像、動画、音声など」で、“doesn’t interact with the rest of the page.” (翻訳) 「ページの残りの部分とは相互作用しません」。画像は差し替えられても文書全体を乗っ取れないため、従来のブラウザーは読み込みを許可し、セキュリティ表示だけを下げていました。Googleは、“Until recently, passive mixed content was loaded in all browsers … This is now beginning to change.” (翻訳) 「最近まで、パッシブ混在コンテンツはすべてのブラウザーで読み込まれていました……現在、この状況は変わり始めています」と説明しています。可能ならHTTPSへ自動アップグレードし、できなければブロックする方向に進んでいるため、「パッシブなら無害」とは考えられません。

アクティブ／パッシブ分類では捉えられない例外

アップグレード可能／ブロック対象の境界には、「画像はアップグレード、スクリプトはブロック」という一般則に従わない例外があります。実務で特に混乱しやすいのは次のケースです。

• CORS付き画像リクエストはアップグレードされず、強制的に失敗します。 通常の <img src="http://…"> はアップグレード可能ですが、crossorigin を指定した画像は混在コンテンツ処理が異なり、静かなアップグレードではなく失敗します。
• srcset と <picture> の候補はアップグレード対象ではなく、ブロック対象です。 同じ画像でも通常の src ではなくレスポンシブ画像機構から取得すると扱いが変わります。
• IPアドレスをホストに使うリクエストは、アップグレードではなくブロックされます。 http://203.0.113.5/logo.png は、ドメイン名を使う同等のリソースと同じ自動アップグレードを受けません。
• ネストしたコンテキストとworkerも対象です。 混在コンテンツの検査はトップ文書だけでなく、iframe、Service Worker、Shared Worker内にも適用されます。
• ローカルとloopback originには固有の扱いがあります。 localhost、loopbackアドレス、file:// コンテキストは、TLSがなくても仕様上「潜在的に信頼できるorigin」なので、開発環境ではHTTP対HTTPSだけで単純に判定できません。
• 安全でないダウンロードは関連しますが別の境界です。 安全なページから http:// で始めるダウンロードにも危険はありますが、この節のサブリソース混在コンテンツ規則ではなく、ダウンロード固有の安全処理に従います。
• トップレベルのHTTPナビゲーションは混在コンテンツではありません。 前述のアンカーリンクも含め、読み込まれるサブリソースではなくナビゲーションの性質によるものです。

混在コンテンツを検出する全体構成

単一のボタンですべてを確認することはできず、各層が答える問いも異なります。1層がcleanでも、ほかの層までcleanとは限りません。取得ソース（生HTMLが参照するもの）、レンダリング後／実行時の状態（解析とスクリプト実行後にブラウザーがリクエストするもの）、実ユーザーセッション（同意バナー、地域リダイレクト、ログイン、特定条件で発火する第三者タグの背後で起きること）を別々に診断します。1ページからサイト全体へ、次の順で重ねます。

1. Chrome DevToolsコンソール（レンダリング後／実行時）。HTTPSページを開いてコンソールを確認します。ブロックされたアクティブ混在コンテンツには、“Mixed Content: The page … was loaded over HTTPS, but requested an insecure … This request has been blocked; the content must be served over HTTPS.” (翻訳) 「このページはHTTPSで読み込まれましたが、安全でないリソースを要求したためブロックされました。コンテンツはHTTPSで配信する必要があります」といったメッセージが出ます。読み込まれたパッシブコンテンツはブロックではなく警告になります。SecurityパネルまたはIssuesタブでページ単位にまとめて確認できます。個別修正の確認には速い方法ですが、メッセージ文言、パネル配置、ブロック対象はブラウザーとバージョンに依存します。ここでの内容は2026年7月時点のChromeで確認したものなので、診断対象の実バージョンで再確認し、Firefox、Safari、Edgeとの差も見込んでください。

2. サイトクローラー（取得ソースを大規模に確認）。DevToolsはページ単位ですが、クロールはサイト全体を対象にします。Ahrefs Site AuditとScreaming Frogは、HTTPSサイトで http:// サブリソースを参照するページを検出でき、数千URLにまたがる混在コンテンツを探す現実的な方法です。ただしクロールが読むのは主にソースです。cleanな結果でも、レンダリング後や実セッションまでcleanとは証明できません。結果を報告するときは、使用したブラウザー／ツール／バージョンも記録します。

3. CSP違反レポート（実ユーザーセッション）。実際の訪問者のブラウザーから混在コンテンツを報告させれば、特定ページ、特定ユーザー、同意状態、制御できない第三者タグでのみ読み込まれるリソースも捕捉できます。web.devは、“You can use content security policy to collect reports of mixed content on your site. To enable this feature, set the Content-Security-Policy-Report-Only directive by adding it as a response header for your site.” (翻訳) 「Content Security Policyを使ってサイトの混在コンテンツのレポートを収集できます。有効にするには、Content-Security-Policy-Report-Only をレスポンスヘッダーとして追加します」と説明しています。Report-Onlyはポリシーを強制せずに違反を報告するため、ブロックを有効にする前に本番で規模を測れます。現在の仕組みは report-to と Reporting-Endpoints、旧方式は report-uri です。これは汎用のreport-onlyポリシーであり、upgrade-insecure-requests 自体をreport-onlyに置くこととは異なります。後者は機能しません。

3つすべてを使います。DevToolsでレンダリング済みページを確認し、クローラーで取得ソースを棚卸しし、CSPレポートで実セッションにだけ現れる長い尾を捕捉します。1回のクロールがcleanでも、それはソースについての証拠にすぎず、すべての同意状態、広告技術の変種、パーソナライズ分岐、workerまでcleanという保証ではありません。

発生元で修正する

実際の修正は参照を書き換える前に始まります。HTTPS版が存在し、有効な証明書を提示し、期待する内容を返すことを確認してください。 ドメインが解決するだけでschemeの置換が安全とは限りません。確認後、すべてのサブリソースをHTTPSで解決させます。次の選択肢はおおむね推奨順ですが、入力文字列だけでなく所有権と利用文脈で判断します。

• 絶対HTTPS URL — http://cdn.example.com/app.js を https://cdn.example.com/app.js に変更します。明示的で曖昧さがなく、後述の配信文脈に確信がない場合の安全な既定値です。
• ルート相対または相対パス — 同一サイトで所有するリソースなら、/assets/app.js はページのschemeを自動的に継承します。GoogleのHTTPSガイダンスは、“Make sure intrasite URLs and external URLs don’t depend on a specific protocol. Use relative paths or leave out the protocol as in //example.com/something.js.” (翻訳) 「サイト内URLと外部URLが特定のプロトコルに依存しないようにし、相対パスを使うか、//example.com/something.js のようにプロトコルを省略してください」と説明します。ただし万能な推奨ではありません。リソースを実際に所有していること、<base>タグ、プロキシパス、埋め込み／AMP環境を含め実際のbase URLが期待どおりに解決すること、window.locationからURLを組み立てるクライアントコードや保存済み絶対値が後で http:// を復元しないことを確認してください。
• プロトコル相対URL（//example.com/something.js）も動作しますが、常に最適な修正ではありません。所有権とbase URLを同じように確認します。全面HTTPSの環境では明示的な https:// のほうが分かりやすく、非HTTPコンテキストで開かれた場合の意外な挙動も避けられます。schemeを固定しない具体的な理由がある場合だけ使います。

大規模修正でテンプレートを1件ずつ手編集することはほぼありませんが、本番データベースに無防備な文字列置換をかけてもいけません。http://yourdomain から https://yourdomain への置換は平文フィールドなら安全なことが多い一方、CMSにはPHPのシリアライズ配列、JSON、ブロックエディターのデータなど構造化された内容があり、単純な部分文字列置換は修正ではなくレコード破損を招きます。形式を理解するアプリケーション対応ツールを使い、先にデータベースをバックアップし、dry-runで対象行を確認してから適用してください。その後、URLを生成するテンプレートや設定を修正し、クローラーとCSPレポートで残りを拾います。

upgrade-insecure-requests：安全網と制限

予防的な安全網はContent-Security-Policyディレクティブです。web.devは、“The upgrade-insecure-requests CSP directive instructs the browser to upgrade insecure URLs before making network requests.” (翻訳) 「upgrade-insecure-requests CSPディレクティブは、ネットワークリクエストの前に安全でないURLをアップグレードするようブラウザーへ指示します」と説明しています。次のヘッダーを設定します。

Content-Security-Policy: upgrade-insecure-requests

MDNによれば、これは “instructs user agents to treat all of a site’s insecure URLs (those served over HTTP) as though they have been replaced with secure URLs (those served over HTTPS).” (翻訳) 「サイト内の安全でないURL（HTTP配信）を、安全なURL（HTTPS配信）へ置き換えたものとして扱うようuser agentへ指示」します。具体的には、“requests to load resources (such as images, scripts, or fonts),” (翻訳) 「画像、スクリプト、フォントなどのリソース読込リクエスト」、“navigation requests (such as link targets) which are same-origin with the document,” (翻訳) 「文書とsame-originのリンク先などへのナビゲーション」、“navigation requests in nested browsing contexts, such as iframes,” (翻訳) 「iframeなどネストした閲覧コンテキストのナビゲーション」、および “form submissions.” (翻訳) 「フォーム送信」をアップグレードします。 Evidence for this claim The upgrade-insecure-requests CSP directive rewrites insecure URLs as secure URLs before requests are made. Scope: MDN documents the directive's rewriting behavior and limits; it does not guarantee that an HTTPS version of every resource exists. Confidence: high · Verified: 2026-07-14 MDN: CSP upgrade-insecure-requests

引用に加えて重要な運用上の点が2つあります。第一に、サブリソースのアップグレードはsame-originだけに限定されません。上の引用でsame-origin限定なのはナビゲーションです。通常のサブリソースはoriginをまたいで書き換えられるため、CDNのスクリプトや第三者フォントもアップグレードされます。第二に、書き換えはブラウザーが混在コンテンツとCSPを評価する前に行われます。そのため、本来なら混在コンテンツとしてブロックされるリソースも、先にHTTPSへアップグレードされれば読み込めます。

次の3つの制限を覆い隠してはいけません。

• 第三者originへのトップレベルナビゲーションはアップグレードしません。 MDNは、“However, top-level navigation requests whose target is a different origin will not be upgraded.” (翻訳) 「ただし、別originを対象とするトップレベルナビゲーションはアップグレードされません」と説明しています。そのためHSTSの代替ではありません。“The upgrade-insecure-requests directive will not ensure that users visiting your site via links on third-party sites will be upgraded to HTTPS for the top-level navigation and thus does not replace the Strict-Transport-Security (HSTS) header.” (翻訳) 「第三者サイトのリンクから訪れるユーザーのトップレベルナビゲーションをHTTPSへ確実にアップグレードできないため、Strict-Transport-Security（HSTS）ヘッダーの代替にはなりません」。
• 安全網であって修正ではなく、fallbackもありません。 リソースに実用可能なHTTPS版がなければ、アップグレードされたリクエストは失敗し、元の http:// へ戻りません。元ソースの修正は必要で、このディレクティブは見落としを補うだけです。
• Report-onlyではアップグレードされず、何も起きません。 Content-Security-Policy-Report-Only に upgrade-insecure-requests を入れてもブラウザーは無視し、書き換えもレポートも行いません。強制前に影響を把握するには、前述の default-src https: 方式など、安全でない宛先を報告する別の汎用report-onlyポリシーを使います。

block-all-mixed-content：ほぼ過去の仕組み

関連ディレクティブの block-all-mixed-content は、MDNによれば “prevents loading any assets over HTTP when the page uses HTTPS,” (翻訳) 「ページがHTTPSを使うとき、HTTP経由のすべてのアセット読込を防止」し、“both blockable and upgradable mixed content,” (翻訳) 「ブロック対象とアップグレード可能な混在コンテンツの両方」に適用され、iframeも対象です。しかし現在は置き換えられています。MDNはdeprecatedかつ “obsolete in the specification,” (翻訳) 「仕様上obsolete」とし、“Content that isn’t blocked is now always upgraded to a secure connection, so this directive is not needed.” (翻訳) 「ブロックされない内容は常に安全な接続へアップグレードされるため、このディレクティブは不要」と説明しています。新規導入では upgrade-insecure-requests を使い、block-all-mixed-content は継承する可能性があるlegacy設定として扱います。UIRをすでに送っている場合、書き換えが先に行われるため、block-allの判定時にはアップグレード済みか失敗済みであり、追加の役割はありません。

CMSが混在コンテンツを再導入する理由

混在コンテンツは一度きりの清掃では終わりません。次の複数の仕組みが、修正後にも http:// URLを静かに再注入するからです。

• コンテンツデータベース。 WordPress、Drupalなど多くのCMSでは、編集者が絶対 http:// URLの画像や埋め込みを本文へ貼り付けます。テンプレートではなくデータベースに保存されるため、コード修正では届かず、DBの検索・置換が必要です。
• テーマとプラグイン。 フォント、スクリプト、背景画像などの http:// URLをhard-codeしたテーマやプラグインは、レンダリングする全ページで問題を再発させ、更新時に戻すこともあります。
• 広告技術、解析、第三者タグ。 タグマネージャー、広告ネットワーク、チャット、解析snippetは独自のサブリソースを読み込みます。vendorタグが http:// を呼べば、自社コードだけでは直せません。CSPレポートはこの長い尾を捉えるためにあり、恒久策はvendorにHTTPS配信を求めるか、タグを外すことです。HTTPS endpointがない場合は、修正を依頼する、依存先を交換する、削除する、の3択で、安全にHTTP版を維持する第4の方法はありません。
• Service Workerとキャッシュ。 Service Workerが http:// を指すレスポンスやリクエストをcacheすると、ソース修正後も再訪時に古い参照を配信します。修正確認はincognitoまたはuncached sessionでも行い、URL変更を伴うdeployではService Worker／cache versionも上げて古いentryを破棄します。
• 再利用される**古いコンテンツやメール／印刷テンプレート内のhard-codeされた http://**も確認します。

運用上の結論は、検出を公開時に1回だけ行うチェックリストではなく、クローラーとCSPレポートを組み合わせた定期監査に組み込むことです。

混在コンテンツとHSTSの関係

混在コンテンツとHSTSは隣接する別々の問題を解決します。両者を混同するのはよくある誤りです。

• upgrade-insecure-requests は、安全な自ページが要求するサブリソースを修正し、ページが読み込む画像、スクリプト、iframeをアップグレードします。
• HSTS（Strict-Transport-Security）は、サイトへのトップレベルナビゲーションをHTTPSへ強制します。リダイレクト前の最初のリクエストにも適用され、SSL strippingを防ぎます。GoogleはHSTSを “avoid the cost of the 301 redirect” (翻訳) 「301リダイレクトのコストを避け」、“defeat attacks like SSL Stripping.” (翻訳) 「SSL Strippingのような攻撃を防ぐ」方法と説明しています。

両者は代替関係ではありません。MDNは、upgrade-insecure-requests が “will not ensure that users visiting your site via links on third-party sites will be upgraded to HTTPS for the top-level navigation and thus does not replace the Strict-Transport-Security (HSTS) header.” (翻訳) 「第三者サイトのリンクから訪れるユーザーのトップレベルナビゲーションをHTTPSへ確実にアップグレードできないため、Strict-Transport-Security（HSTS）ヘッダーの代替にはならない」と明記しています。十分に強化した構成では、upgrade-insecure-requests またはcleanなソースURLで安全でないサブリソースをなくし、同時にHSTSで最初からHTTP到達を防ぎます。ただしHSTSには通常の注意が必要です。Googleは、“Don’t enable HSTS until you’re certain your site operation is robust enough to avoid ever deploying HTTPS with certificate validation errors,” (翻訳) 「証明書検証エラーのあるHTTPSを決してdeployしないほど運用が堅牢だと確信するまで、HSTSを有効にしないでください」と警告しており、preloadはほぼ一方通行です。

混在コンテンツはSEOへ直接影響するか

まず自分で制御できる直接的な影響から考えます。混在コンテンツは第一にセキュリティと機能の問題です。ブロックされたアクティブ混在コンテンツはレンダリングや操作を壊します。スタイルシートやスクリプトの欠落は、検索エンジンの評価以前に明確な不具合なので、ランキングを考える前に修正すべきです。

SEOへの影響はありますが、直接的でも保証されたものでもなく、条件次第です。現在のGoogle公式ガイダンスは、混在コンテンツ修正による直接的な順位上昇を示していません。HTTPSのランキングシグナルはURLが https:// で始まるかというschemeに基づき、サブリソースのcleanlinessを直接判定するものではないため、安全でない画像が1つ残っただけで「HTTPSシグナル」を失うわけではありません。ただし、CSSやJSがブロックされた状態をGooglebotがレンダリングすれば、不完全なページがインデックスされる可能性があります。セキュリティ表示の低下は、順位が変わらなくても信頼、engagement、conversionを損ねます。またGoogleのHTTPS canonical優先も条件付きで、無効な証明書、安全でない依存、HTTPSからHTTPへのredirect、競合するcanonical signalによって選択は変わります。レンダリング、indexing、canonicalization、analyticsへの影響は自サイトで検証し、普遍的な結果として約束しないでください。まず安全性と機能のために修正します。

これは、移行手順、ランキングシグナルの重み、HSTSを扱うSEOのためのHTTPSの一部です。証明書自体のchain error、有効期限、DV／OV／EVを調査する場合は、関連する別の詳細記事を参照してください。

AI要約

Advanced版を短くまとめると次のとおりです。

• 混在コンテンツは、HTTPSページがHTTPでサブリソースを読み込む状態です。 ページが読み込むリソースが対象で、HTTPページへのアンカーなどトップレベルHTTPナビゲーションは対象外です。安全でないダウンロードも関連する別の境界です。
• 現在の分類はアップグレード可能／ブロック対象で、アクティブ／パッシブは旧来ながら影響範囲を把握するのに有用です。 スクリプト、スタイルシート、iframe、XMLHttpRequest／fetchなどのアクティブ種別はブロックされるため、最優先で直します。画像、音声、動画などのパッシブ種別は従来警告付きで読み込まれましたが、自動アップグレードまたはブロックが増えています。通常の img src とは異なり、CORS付き画像、srcset／<picture>、IP-address host、worker、local／loopback originには例外があります。
• 3層で検出します。 取得ソースはAhrefs Site AuditやScreaming Frog、レンダリング後／実行時はChrome DevTools、実ユーザーセッションは Content-Security-Policy-Report-Only 違反レポートで確認します。1層のclean結果だけでは残りを保証できません。
• HTTPS版が実際に動くことを確認し、元ソースを修正します。 サブリソースを https:// へ向け、相対／プロトコル相対パスは所有権とbase URLを確認した場合だけ使います。大規模置換はDBをバックアップしてdry-runし、構造化CMSデータを単純置換で壊さないようにします。Service Workerやcacheの古い http:// にも注意します。
• upgrade-insecure-requests は対象のcross-originを含む http:// サブリソースを送信・判定前に https:// へ書き換えます。失敗時にHTTPへ戻らず、第三者originへのトップレベル移動を変えないのでHSTSの代替ではありません。ディレクティブ自体をreport-onlyにしても機能しません。
• block-all-mixed-content はdeprecated／obsoleteで、upgrade-insecure-requests 導入後は冗長です。
• 再発します。 CMS DB、テーマ／プラグイン、Service Worker／cache、広告・解析タグを定期監査します。
• SEO影響は直接ではなく条件付きです。 修正による直接的な順位上昇は確立されていませんが、ブロックされたアクティブリソースはGooglebotのレンダリングを壊し、セキュリティ表示低下は信頼を損ねます。HTTPS canonical優先も証明書や競合signalなどの条件に左右されます。

公式ドキュメント

Googleおよびブラウザー／標準化チームによる一次資料です。

Google / web.dev

• 混在コンテンツとは — 定義、アクティブ／パッシブ分類、ブラウザーの挙動。
• 混在コンテンツを修正する — 検出、サブリソースURL修正、upgrade-insecure-requests、CSPレポート。
• サーバーでHTTPSを有効にする — 相対／プロトコル相対URL、HTTP <iframe>、HSTS。
• 混在コンテンツ防止を含むGoogleのHTTPS移行ガイダンス — 修正が属するサイト移行全体の手順。

MDN / 標準

• CSP: upgrade-insecure-requests — 対象、対象外、HSTSの代替にならない理由。
• CSP: block-all-mixed-content — deprecated／obsoleteなブロックディレクティブ。
• MDN — Mixed content — blockable／upgradableなリソースのブラウザー挙動。
• Content Security Policy (CSP) — レポートを含む各ディレクティブの親ヘッダー。

出典からの引用

Googleのweb.devとMDN標準文書に記録された定義です。対応する場合、各リンクは引用箇所へ直接移動します。

Google / web.dev — 混在コンテンツの定義

• “A page has mixed content when its initial HTML is loaded over a secure HTTPS connection, but other resources (such as images, videos, stylesheets, and scripts) are loaded over an insecure HTTP connection.” (翻訳) 「最初のHTMLは安全なHTTPS接続で読み込まれる一方、画像、動画、スタイルシート、スクリプトなど別のリソースが安全でないHTTP接続で読み込まれる場合、そのページには混在コンテンツがあります」 出典
• “Active mixed content poses a greater threat than passive mixed content.” (翻訳) 「アクティブ混在コンテンツはパッシブ混在コンテンツより大きな脅威になります」 出典
• アクティブ混在コンテンツは “includes scripts, stylesheets, iframes, and any other code the browser can download and execute,” (翻訳) 「スクリプト、スタイルシート、iframe、その他ブラウザーがダウンロードして実行できるコードを含み」、“Most browsers already block this type of content by default to protect users.” (翻訳) 「ほとんどのブラウザーはユーザー保護のため、この種類を既定でブロックしています」 出典
• パッシブ混在コンテンツは “including images, video, and audio,” (翻訳) 「画像、動画、音声など」で、“doesn’t interact with the rest of the page.” (翻訳) 「ページの残りとは相互作用しません」。さらに、“Until recently, passive mixed content was loaded in all browsers, because blocking it would have broken many websites. This is now beginning to change.” (翻訳) 「最近まで、ブロックすると多くのサイトが壊れるため全ブラウザーで読み込まれていましたが、現在変わり始めています」 出典

Google / web.dev — 検出と修正

• “You can use content security policy to collect reports of mixed content on your site. To enable this feature, set the Content-Security-Policy-Report-Only directive by adding it as a response header for your site.” (翻訳) 「Content Security Policyを使って混在コンテンツのレポートを収集できます。有効にするには、Content-Security-Policy-Report-Only をレスポンスヘッダーとして追加します」 出典
• “The upgrade-insecure-requests CSP directive instructs the browser to upgrade insecure URLs before making network requests.” (翻訳) 「upgrade-insecure-requests CSPディレクティブはネットワークリクエスト前に安全でないURLをアップグレードするようブラウザーへ指示します」 出典
• “Make sure intrasite URLs and external URLs don’t depend on a specific protocol. Use relative paths or leave out the protocol as in //example.com/something.js.” (翻訳) 「サイト内URLと外部URLが特定のプロトコルに依存しないようにし、相対パスを使うか //example.com/something.js のようにプロトコルを省略します」 出典

MDN — upgrade-insecure-requests と制限

• “The HTTP Content-Security-Policy (CSP) upgrade-insecure-requests directive instructs user agents to treat all of a site’s insecure URLs (those served over HTTP) as though they have been replaced with secure URLs (those served over HTTPS).” (翻訳) 「HTTP CSPの upgrade-insecure-requests は、サイト内の安全でないURLを安全なURLへ置換したものとして扱うようuser agentへ指示します」 出典
• “However, top-level navigation requests whose target is a different origin will not be upgraded.” (翻訳) 「ただし別originへのトップレベルナビゲーションはアップグレードされません」 出典
• “The upgrade-insecure-requests directive will not ensure that users visiting your site via links on third-party sites will be upgraded to HTTPS for the top-level navigation and thus does not replace the Strict-Transport-Security (HSTS) header.” (翻訳) 「第三者サイトのリンクから訪れるユーザーのトップレベルナビゲーションをHTTPSへ確実にアップグレードできないため、Strict-Transport-Security（HSTS）ヘッダーの代替にはなりません」 出典

MDN — block-all-mixed-content はlegacy

• “The HTTP Content-Security-Policy (CSP) block-all-mixed-content directive prevents loading any assets over HTTP when the page uses HTTPS.” (翻訳) 「ページがHTTPSを使用するとき、HTTP経由のすべてのアセット読込を防ぎます」。ただしdeprecatedかつ “obsolete in the specification,” (翻訳) 「仕様上obsolete」で、“Content that isn’t blocked is now always upgraded to a secure connection, so this directive is not needed.” (翻訳) 「ブロックされない内容は常に安全な接続へアップグレードされるため、このディレクティブは不要」です。 出典

混在コンテンツのチェックリスト

HTTPからHTTPSへの移行中と移行後に実行し、その後も定期的に繰り返します。

検出

• home、product、article、checkoutなど主要テンプレートをHTTPSで読み込み、Chrome DevToolsのコンソールを開いてすべての「Mixed Content」メッセージを記録した。
• Ahrefs Site AuditまたはScreaming Frogで全体をクロールし、http:// サブリソースを参照するページ一覧を取得した。
• reporting endpoint付きの Content-Security-Policy-Report-Only を設定し、ユーザー、ページ、第三者タグごとの本番の長い尾を捕捉した。

修正（アクティブを先に）

• <script>、<link rel="stylesheet">、<iframe>、fetch／XMLHttpRequest、fontなど、ブロックされてページを壊すアクティブ参照をすべて修正した。
• <img>、<audio>、<video> と <source>／poster URLなどのパッシブ参照をすべて修正した。
• 貼付コンテンツのCMS databaseで http://yourdomain → https://yourdomain を置換した。バックアップとdry-runを行い、構造化フィールドに生の文字列置換をかけていない。
• theme／pluginのhard-codeされた http:// asset URLを修正した。
• Service Worker／cacheをuncached sessionで再現し、versionを上げて古い参照の再生を防いだ。
• 広告、解析、chat、embedなどの第三者タグがHTTPSで読み込まれることを確認し、対応しないvendorには修正を求めるかタグを削除した。

安全網と検証

• HSTSの代替ではないと理解したうえで、Content-Security-Policy: upgrade-insecure-requests を安全網として設定した。
• 再クロールとコンソール再確認を行い、ブロックされたアクティブリソースが0で、対象ページのセキュリティ表示がcleanになった。
• plugin更新や新規コンテンツによる再発に備え、公開時だけでなく定期監査へ追加した。

この混在コンテンツにはどの修正が必要か

症状から順に判断します。

安全でない対象はページが読み込むリソースか、ページ内のリンクか？

• リンク（<a href="http://…">）→ 混在コンテンツではありません。 必要なら参照データのためHTTPSへ向け、ここで終了します。
• 読み込むリソース（script、style、iframe、image、font、media、fetch）→ 次へ進みます。

そのリソースはHTTPSで利用できるか？

• はい。証明書と返される内容も確認済み → 安全な既定値として参照を https:// へ変更します。相対／プロトコル相対パスは、所有権とbase URLの挙動を確認した場合だけ使います。これが本来の修正です。
• いいえ／不明 → first-partyかを確認します。
  • First-party → 自社サーバーでHTTPS配信し、参照を修正します。
  • Third-party → vendorにHTTPS endpointを求め、なければタグを交換または削除します。upgrade-insecure-requests はアップグレードを試みますが、HTTPS版がなければ失敗します。

アクティブかパッシブか？

• アクティブ（script／stylesheet／iframe／fetch／font）→ ブロックされ、ページが壊れるため最優先です。
• パッシブ（image／audio／video）→ こちらも修正しますが、セキュリティ表示低下や将来のブロックが主で、緊急度は次です。

見落としに安全網を設けるか？

• Content-Security-Policy: upgrade-insecure-requests を設定します。修正の代替ではなく、第三者originへのトップレベル移動を対象にしないため、HSTSの代替でもありません。

初回訪問や第三者referralでもトップレベルページをHTTPSへ強制する必要があるか？

• それは別の制御であるHSTSです。Strict-Transport-Security を追加しますが、証明書運用が確実になってからにしてください。特にpreloadはほぼ一方通行です。

判断に役立つ考え方

1. 対象はリソースであり、リンクではない。 混在コンテンツは安全なページが読み込むものの問題で、リンク先ではありません。現在のページを構築するためにブラウザーが取得するなら候補、別ページへ移動するだけなら対象外です。

2. 抽象的な深刻度ではなく、ブラウザーの挙動で優先順位を決める。 script、style、iframeなどのアクティブ種別はブロックされる機能不良なので先に修正します。画像やmediaなどのパッシブ種別は警告／アップグレードされるため次に修正します。

3. 検出は、確認→棚卸し→長い尾の捕捉というfunnel。 DevToolsコンソールは1ページを正確に、crawlerはサイト全体の大部分を、CSPレポートは本番の第三者・ユーザー別の長い尾を見ます。単独のツールでは3層すべてを確認できません。

4. 元ソースを直し、残りに安全網を張る。 DB、template、tag内の実URLをcleanにしてから、漏れに対するbackstopとして upgrade-insecure-requests を追加します。これは保険であり修理ではありません。

5. 「HTTPSを強制する」2つの仕事には別々の手段を使う。 upgrade-insecure-requests は安全なページが要求するサブリソースをアップグレードします。HSTSはサイトへのトップレベルナビゲーションをHTTPSへ強制します。一方が他方を置き換えることはなく、強化したサイトでは両方を使います。

6. 一度きりの作業ではなく定期監査。 CMS database、plugin／theme更新、第三者tagは http:// を再導入します。定期的に検出しなければ、問題は気づかないうちに戻ります。

混在コンテンツの失敗例

安全でないコンテンツを残す、または本質的な修正をせず覆い隠す失敗例です。

• upgrade-insecure-requests を修正そのものと考える。 HTTPS版がなければアップグレード後に失敗します。元URLをcleanにし、ディレクティブは残りへの安全網にします。
• コードdeployでdatabaseもcleanになったと思う。 CMSの http:// 画像やembedの多くはtemplateではなくcontent rowにあるため、DB検索・置換が必要です。
• アクティブ混在コンテンツを単なる警告として後回しにする。 実際にはブロックされ、stylesheetやscriptの停止は機能障害です。
• homeだけspot-checkして完了とする。 product、古いblog、特定ユーザーだけが通るpathにも潜むため、全体crawlとCSP reportingを使います。
• 第三者tagを無視する。 広告、解析、chat vendorが http:// を呼ぶ問題は自社repo内では直せません。vendorに対応を求めるかtagを外します。
• 新規buildで block-all-mixed-content を使う。 deprecated／obsoleteなので upgrade-insecure-requests を使います。
• upgrade-insecure-requests とHSTSを混同する。 前者はサブリソース、後者はトップレベルHTTPSとSSL stripping対策です。
• 定期監査から外す。 1回直して放置すれば、plugin更新や貼り付け画像で再発します。

混在コンテンツのチートシート

アクティブとパッシブ

検出手段

CSPディレクティブ

混同してはいけないもの

CMSの一行修正: DBで http://yourdomain → https://yourdomain を検索・置換し、template／pluginを修正してから upgrade-insecure-requests を設定します。

混在コンテンツを探すsnippet

1. コマンドラインで1ページをcrawlする

ページを取得し、HTMLに残る安全でない src／href サブリソースを検出します。

macOS / Linux

# Flag insecure script/img/link/iframe/source references on a single URL
curl -s https://example.com/ \
  | grep -Eo '(src|href)="http://[^"]+"' \
  | sort -u

Windows (PowerShell)

(Invoke-WebRequest -Uri "https://example.com/").Content `
  | Select-String -Pattern '(src|href)="http://[^"]+"' -AllMatches `
  | ForEach-Object { $_.Matches.Value } | Sort-Object -Unique

これは生HTMLだけを確認します。JavaScriptが注入するリソースは表示されないため、DevToolsと実際のcrawlerも併用します。

2. Chrome DevTools Console：レンダリング後の安全でないリソースを一覧化

JavaScriptが挿入した参照も捉えるため、HTTPSページのコンソールへ貼り付けます。

// Every element with an http:// resource attribute in the live DOM
[...document.querySelectorAll('[src],[href],[srcset],[data-src]')]
  .filter(el => /^http:\/\//.test(
    el.src || el.href || el.getAttribute('srcset') || el.getAttribute('data-src') || ''
  ))
  .map(el => ({ tag: el.tagName, url: el.src || el.href }));

ブラウザーはブロックしたアクティブ混在コンテンツを、「Mixed Content: … This request has been blocked; the content must be served over HTTPS.」 (翻訳) 「リクエストはブロックされました。コンテンツはHTTPSで配信する必要があります」と自動的に記録します。まずこれらを確認します。

3. Bookmarklet：1クリックでコンソールへ出力

bookmarkとして保存し、任意のHTTPSページでクリックして http:// 参照をコンソールへ出力します。

javascript:(()=>{const h=[...document.querySelectorAll('[src],[href]')].filter(e=>/^http:\/\//.test(e.src||e.href)).map(e=>e.src||e.href);console.log('%cMixed content candidates:','font-weight:bold',h.length);h.forEach(u=>console.log(u));})();

4. CSP reportingを有効にして本番で検出

report-onlyヘッダーを追加し、第三者tagやcrawlで見落としたページを含む違反を実訪問者のブラウザーから報告させます。

Content-Security-Policy-Report-Only: default-src https:; report-uri /csp-report-endpoint

Report-onlyは強制せずに報告するため、upgrade-insecure-requests や強制ポリシーを有効にする前に問題の規模を安全に測れます。現在の方式では Reporting-Endpoints ヘッダーと report-to を使います。

5. 元ソース修正後の安全網ヘッダー

Content-Security-Policy: upgrade-insecure-requests

第三者originへのトップレベルナビゲーションはアップグレードせず、HSTSの代替ではないことを忘れないでください。

定期的な混在コンテンツ監査SOP

HTTPS公開後、CMS／themeのrelease後、tag manager変更後に実行し、更新頻度の高いサイトでは定期的に繰り返します。

1. HTTPSページをraw modeとrendered modeでcrawlする。 src、srcset、stylesheet、iframe、media、fetch/XHRの安全でないURLをexportします。通常のHTTPアンカーは混在コンテンツではありません。
2. ブラウザーの証拠を集める。 代表的なtemplateをDevToolsで確認し、Content-Security-Policy-Report-Only で実訪問者や第三者tagによる違反を捕捉します。
3. 各findingを分類する。 active／passive、first-party／third-party、static／JavaScript-injectedを記録し、sourceを所有するtemplate、database field、plugin、tag、vendorを特定します。
4. source参照を修正する。 動作するHTTPSリソースまたは安全な相対URLへ向けます。http:// を https:// に変えるだけで十分とは考えず、宛先のTLS対応を確認します。
5. CSPを安全網に使う。 finding確認後に upgrade-insecure-requests を追加します。露出は減らせますが、CMS recordの修理やHSTSの代替にはなりません。
6. 再crawl・再renderする。 tested templateのactive mixed-content errorを0にし、passive resourceもfallbackなしでHTTPS解決させます。
7. 再発を防ぐ。 発生元templateまたはeditor workflowを直し、必要に応じてreport-only収集を維持し、新しい違反をsystem ownerへ割り当てます。

症状から原因と修正を特定する

混在コンテンツのrelease test

テスト1：レンダリング済みtemplateの確認

• 目的: 生HTMLだけでは見落とすactive／passive resourceを捕捉する。
• 方法: 各templateとinteraction stateの代表URLをrenderし、安全でないまたはblocked requestをConsoleとNetworkで確認する。
• 期待結果: HTTPで要求されるsub-resourceがなく、active contentもblockされない。
• 失敗条件: mixed-content warning、auto-upgrade失敗、blocked resourceによるlayout／function欠落。
• 次の行動: requestをtemplate、tag、plugin、stored fieldまで追跡し、sourceを直して再実行する。

テスト2：ソースとCSPの比較

• 目的: 実訪問者または第三者だけが導入する違反を検出する。
• 方法: crawler findingと Content-Security-Policy-Report-Only eventを比較し、blocked URL、page template、directive、owner別に集計する。
• 期待結果: 説明のないproduction-only違反がなく、既知noiseは文書化して狭く除外される。
• 失敗条件: crawlにない再現可能な違反、またはowner不明のthird-party source。
• 次の行動: visitor stateを再現し、注入するintegrationを修正または削除する。

テスト3：公開後の再発確認

• 目的: CMSが新しい安全でない参照を生成しないことを確認する。
• 方法: 通常のeditorial workflowでtest itemを公開し、本番と同じcheckでcrawl・renderする。
• 期待結果: 生成markupとloaded resourceが有効なHTTPS URLを使う。
• 失敗条件: 新規ページが、古いcontentから清掃したHTTP参照を再作成する。
• 次の行動: release前にeditor default、template、plugin、content transformを修正する。

時間を使う価値のあるリソース

講演

• HTTPSでは「転ばぬ先の杖」— SMX East 2016 (SlideShare) — TLS、一般的なHTTPS実装失敗、混在コンテンツを生む移行上の落とし穴を詳しく解説しています。これは私の理解に基づく内容で、掲載した普及統計は2016年のものです。

関連記事

• テクニカルSEO初心者ガイド — HTTPSと混在コンテンツをテクニカルSEO全体の中で位置づけます。

業界の資料

• 混在コンテンツとは（web.dev / Google） — 標準的な定義とactive／passive分類。
• 混在コンテンツを修正する（web.dev / Google） — 検出、sub-resource URL修正、upgrade-insecure-requests、CSP reportingの手順。
• MDN — upgrade-insecure-requests — アップグレード対象、対象外、HSTSの代替にならない理由。
• MDN — block-all-mixed-content — 継承時に知っておくべきdeprecatedなblock directive。
• MDN — Mixed content — blockable／upgradable resourceのbrowser behavior。
• サーバーでHTTPSを有効にする（web.dev / Google） — 相対／プロトコル相対URLとHTTPS設定全体。

引用に値する統計

• アクティブ混在コンテンツは既定でブロックされます。 Googleは、“Most browsers already block this type of content by default to protect users.” (翻訳) 「ほとんどのブラウザーはユーザー保護のため、この種類を既定でブロックしています」と説明します。警告ではなく機能障害になる理由です。 出典
• アクティブ混在コンテンツのほうが脅威は大きい。 Googleは、“Active mixed content poses a greater threat than passive mixed content.” (翻訳) 「アクティブ混在コンテンツはパッシブより大きな脅威になります」と分類しており、優先順位の根拠になります。 出典
• パッシブ混在コンテンツも安全に「許可」され続けるわけではない。 Googleは、“Until recently, passive mixed content was loaded in all browsers … This is now beginning to change.” (翻訳) 「最近まで全ブラウザーで読み込まれていましたが、現在変わり始めています」と説明します。 出典
• upgrade-insecure-requests はHSTSの代替ではありません。 MDNは、“does not replace the Strict-Transport-Security (HSTS) header.” (翻訳) 「Strict-Transport-Security（HSTS）ヘッダーの代替にはなりません」と明記します。 出典
• Webの約89%がHTTPS（W3Techs、2026年。現在値を要確認）だからこそ、安全なページに残る http:// サブリソースが現在の一般的な失敗になります。文脈はHTTPSハブを参照してください。

理解度チェック：混在コンテンツ

混在コンテンツに関する5問です。各問の答えを選び、結果を確認してください。

変更履歴