SSL化とは｜LPをHTTPSにする理由と確認方法

｜広告運用ノウハウ公開中！

より詳しく知りたい方は資料をダウンロード！

LPのURLを開いたら、アドレスバーに「保護されていない通信」と出ていた。フォームに入力しようとしたら、ブラウザに警告が表示された。LPやフォームのURLが「http」のままになっていると、こうした表示がユーザーの目に入ります。

URLを「https」にして通信を暗号化することを、一般に「SSL化」や「HTTPS化」と呼びます。サイトのすべてのページをHTTPSにすることは「常時SSL化」とも呼ばれます。いまではChromeの表示や検索エンジンの扱いも、HTTPSを前提にしたものに変わってきています。

この記事では、MDN（Mozilla）やGoogleの公式情報（2026年10月28日時点の記載）をもとに、SSL化の意味、httpのままのLPやフォームで起きること、HTTPSにしたあとの混在コンテンツ、HTTPSへの移行手順と確認方法をまとめます。

1. SSL化とは｜通信を暗号化してURLをhttpsにすること

1-1. SSL化・HTTPS化・常時SSL化の意味

HTTPSは、HTTPプロトコルを暗号化したバージョンです。通常はTLSを使ってクライアント（ブラウザ）とサーバーの間のすべての通信を暗号化し、機密データを安全にやり取りできるようにします（出典：HTTPS｜MDN Web Docs）。

「SSL化」という言葉に残っているSSLは、古いセキュリティの標準技術で、現在はTLSに置き換えられています。TLSは、以前はSSLとして知られていたプロトコルです（出典：Secure Sockets Layer (SSL)｜MDN Web Docs、Transport Layer Security (TLS)｜MDN Web Docs）。そのため、「SSL化」「SSL証明書」と呼ばれていても、中身はTLSによるHTTPS化を指しているのが一般的です。この記事では、ページをHTTPSで配信することを「SSL化」、サイトのすべてのページをHTTPSで配信することを「常時SSL化」と呼びます。

1-2. SSL化で何を守るのか

IPA（情報処理推進機構）は、ウェブサイトの運用管理のチェックポイントの1つに「インターネットを介して送受信する通信内容の暗号化」を挙げています。ウェブアプリケーションと利用者の間の通信は、盗聴や改ざん、なりすましなどの被害を受ける恐れがあり、通信内容を暗号化（HTTPS化）すれば、盗聴などの被害を受けても重要情報が不正に取得されることを防止できる、と説明しています（出典：安全なウェブサイトの運用管理に向けての20ヶ条｜IPA 独立行政法人 情報処理推進機構）。

LPでは、フォームに入力される氏名やメールアドレス、電話番号などがこの「送受信する通信内容」にあたります。

1-3. SSL証明書の役割

ブラウザは、HTTPSで接続するときに、サーバーに有効なデジタル証明書の提示を求めて相手の身元を確認し、安全な接続を確立します（出典：Transport Layer Security (TLS)｜MDN Web Docs）。Chromeのヘルプでも、ウェブサイトの証明書を使ってHTTPS接続を認証・保護し、証明書によってサイトとブラウザの間のリンクが暗号化されると説明されています（出典：サイトの接続が安全かどうかを確認する｜Google Chrome ヘルプ）。

一般に「SSL証明書」と呼ばれるのはこの証明書のことです。SSL化の作業は、証明書を用意してサーバーに設定し、ページをhttpsのURLで表示できるようにすることから始まります。

2. LPやフォームがhttpのままだと起きること

2-1. Chromeのアドレスバーに「保護されていない通信」と表示される

ChromeでURLがHTTPSを使っていないサイトを読み込むと、アドレスバーに「保護されていない通信」という警告が表示されます（出典：Chrome の安全性とセキュリティを管理する｜Google Chrome ヘルプ）。このアイコンの意味について、Chromeのヘルプは「サイトはプライベート接続を使用していません。このサイトとの間で送受信される情報は、何者かに見られる、または変更される可能性があります」と説明し、解決にはサイト所有者がHTTPSを使う必要があるとしています（出典：サイトの接続が安全かどうかを確認する）。

この表示は段階的に強められてきました。Googleは、2018年7月のChrome 68からすべてのHTTPサイトを「not secure（保護されていない）」と表示すると発表しました（出典：A secure web is here to stay｜Chromium Blog）。さらに2018年10月のChrome 70からは、HTTPのページでユーザーがデータを入力すると、赤い「not secure」の警告を表示すると発表しています（出典：Evolving Chrome's security indicators｜Chromium Blog）。

2-2. 「常に安全な接続を使用する」がオンだと、開く前に警告が出る

Chromeには「常に安全な接続を使用する」という設定があります。オンにすると、URLがHTTPSにアップグレードされ、HTTPSに対応していないサイトにアクセスする前に警告が表示されます（出典：Chrome の安全性とセキュリティを管理する）。警告の文言は「このサイトへの接続は安全ではありません」です（出典：サイトの接続が安全かどうかを確認する）。

Googleは2025年10月28日のブログで、2026年10月のChrome 154のリリースで、この設定（公開サイトが対象の設定）を既定で有効にすると発表しました。HTTPSのない公開サイトに初めてアクセスする前に、ユーザーの許可を求める形です。それに先立ち、2026年4月のChrome 147で、セーフ ブラウジングの保護強化機能を有効にしているユーザーに対して有効にするとしています。よく訪れるサイトについては繰り返し警告せず、ユーザーは設定をオフにすれば警告を止められます（出典：HTTPS by default｜Google Online Security Blog）。

ブログでは、警告は新しいサイト（または最近訪れていないサイト）にアクセスしたときに表示されると説明されています。広告から初めてLPを訪れるユーザーにとって、LPは新しいサイトです。この設定が有効なブラウザでは、httpのLPは表示される前に警告をはさむことになります。

2-3. HTTPSのページでも、フォームの送信先がhttpだと警告が出る

ページ自体がHTTPSでも、フォームの送信先がhttpのままだと問題になります。Googleは2020年8月のブログで、HTTPSのページにありながらHTTPSで送信しないフォームを「mixed forms」と呼び、Chromeでの扱いを次のように変えると発表しました。当初Chrome 86で予定していた変更は、Chrome 87に延期されています（出典：Protecting Google Chrome users from insecure forms｜Chromium Blog）。

• mixed formsでは自動入力（オートフィル）を無効にする
• ユーザーが入力を始めると、フォームが安全でないことを知らせる警告テキストを表示する
• 送信しようとすると、ページ全体の警告を表示し、それでも送信するかを確認する

LPと外部のフォームツールを組み合わせている場合は、フォームの送信先（action）のURLまでhttpsになっているかを確認しておく必要があります。フォームの入力のしやすさを改善する方法やツールは「EFOツール比較15選｜CVR改善する選び方」で比較しています。

2-4. Google検索での扱い

Googleは2014年8月のブログで、HTTPSをランキングのシグナルとして使用することにしたと発表しました。当時は移行期間としてシグナルのウェイトを非常に小さく設定し、グローバル クエリの1%未満にしか影響せず、高品質のコンテンツなどほかのシグナルよりウェイトが小さいと説明しています（出典：ランキング シグナルとしての HTTPS｜Google Search Central Blog）。

一方、2026年9月に更新された現行のページ エクスペリエンスのドキュメントでは、「ページは安全な方法で配信されていますか」が自己評価の質問に挙がっているものの、ランキングシステムで使用されるのはCore Web Vitalsであり、Core Web Vitals以外のページ エクスペリエンスの要素が検索結果でのランキング上昇に直接貢献することはない、と書かれています。そのうえで、これらの要素はサイトの満足度を高める可能性があり、それは通常ランキングシステムでも高く評価される、としています（出典：ページ エクスペリエンスが Google 検索の検索結果に与える影響について｜Google 検索セントラル）。「SSL化すれば順位が上がる」と期待するより、ユーザーが安心して使えるページにするための前提と考えるのが、現在の公式の説明に沿った見方です。

インデックスの面では、同じ内容のHTTPとHTTPSのページがある場合、GoogleはHTTPSのページを優先して正規URLに選びます。ただし、SSL証明書が無効な場合や、HTTPSのページがHTTPのページにリダイレクトしている場合、HTTPのページを指す rel="canonical" がある場合などは例外です（出典：重複する URL を統合する｜Google 検索セントラル）。

2-5. Google広告の計測URLはHTTPSが必要

Google広告では、トラッキング テンプレートのURLと、すべてのリダイレクトURLはHTTPSである必要があり、リダイレクトもサーバー側で行う必要があります（出典：最終ページ URL とトラッキング テンプレートについて｜Google 広告 ヘルプ）。「ランディング ページのテスト」でも、トラッキング チェーンにHTTPのURLが含まれていると「トラッキング チェーンの HTTP リダイレクト」というメッセージが出ます（出典：ランディング ページをテストする｜Google 広告 ヘルプ）。

3. 混在コンテンツ｜HTTPSにしたLPで、タグや部品が読み込まれない

3-1. 混在コンテンツとは

混在コンテンツとは、HTTPSなどで安全に読み込まれたページが、HTTPなど保護されていないプロトコルで取得するリソースを使っている状態です。保護されていない方法で送られたリソースは、見られたり、攻撃者に変更されたりする可能性があります。ページのあらゆる部分を変更できるスクリプトは、特に危険だとされています（出典：混在コンテンツ｜MDN Web Docs）。

3-2. 画像はhttpsに切り替わり、スクリプトはブロックされる

ブラウザは、混在コンテンツのうち画像・動画・音声のリクエストを自動的にHTTPからHTTPSにアップグレードし、それ以外のリソースの保護されていないリクエストはブロックします（出典：混在コンテンツ）。

扱い	主なもの（MDNの記載）
自動でhttpsにアップグレード	<img>（src で指定した画像）、CSSの画像（background-image など）、<audio>、<video>、<source>
ブロック	<script>、<link>（スタイルシート）、<iframe>、fetch()、XMLHttpRequest、Navigator.sendBeacon、ウェブフォント、srcset や <picture> で指定した画像

出典：混在コンテンツ

アップグレードされた画像でも、アップグレード先のhttpsのURLにリソースがなければ表示されません。また、URLのホストがドメイン名ではなくIPアドレスの場合は、アップグレードされるはずのリクエストもブロックされます（出典：同上）。

3-3. 計測タグや埋め込みフォームのURLに注意

LPに貼る計測タグの多くは <script> で読み込みます。埋め込みのフォームや動画は <iframe> を使うことがあります。これらのURLが「http://」のまま残っていると、ページはHTTPSで表示されていても、タグやフォームが読み込まれずに動かないことがあります。

ブラウザの開発者コンソールには、混在コンテンツがアップグレードまたはブロックされたときに警告が表示されます。直し方としてMDNは、ドメイン内のすべてのコンテンツをHTTPSで提供する、自分のドメインのリソースへの参照を相対リンクかHTTPSのリンクに変える、ほかのサイトのリソースは可能ならHTTPS版を使う、の3つを挙げています（出典：混在コンテンツ）。

4. HTTPからHTTPSへ移行する手順

すでにhttpで公開しているページをHTTPSに移す場合は、Googleのサイト移転のドキュメントにある「HTTPからHTTPSへのURLの変更」の手順が参考になります。

4-1. 証明書を用意し、httpsで表示できるようにする

HTTPSに移行する場合は、必要なTLS証明書を入手してサーバーに設定します（出典：サイトを移転する方法｜Google 検索セントラル）。LPを作るツールやサーバーによっては、証明書の発行を自動で行うものもあります（Squad beyondの場合は7章）。

4-2. ページの中のhttpを直す

ページ内の画像やタグ、フォームのURLをhttpsにそろえ、3章の混在コンテンツを残さないようにします。Search ConsoleのHTTPSレポートでは、HTTPのページを正規URLとして示す rel="canonical" や、HTTPのURLを参照しているサイトマップがエラーとして報告されます（出典：HTTPS レポート｜Search Console ヘルプ）。canonicalとサイトマップのURLもhttpsに書き換えます。

4-3. httpからhttpsへ、サーバー側の永続的なリダイレクトを設定する

Googleは、技術的に可能な場合はサーバー側の永続的なリダイレクト（301や308など）を使うよう勧めています。リダイレクトのチェーンは避け、最終的な宛先へ直接リダイレクトするのが推奨で、直接できない場合はチェーン内のリダイレクトを5個未満（理想的には3個以下）に抑えるよう書かれています（出典：サイトを移転する方法）。

4-4. Search Consoleで確かめる

サイト移転のドキュメントでは、Search ConsoleでHTTPSとHTTPの両方のパターンのサイトを確認するよう書かれています。ドメインを変える場合に使うアドレス変更ツールは、HTTPからHTTPSへの移転には必要ありません。移転後は、HTTPSのサイトでrobots.txtを確認し、移転のためだけに入れたnoindexやrobots.txtのブロックが残っていないかも見ておきます（出典：サイトを移転する方法）。

4-5. リダイレクトを残し、リンクを新しいURLに更新する

リダイレクトはできるだけ長く、一般的には1年以上保持するよう勧められています。ユーザーの観点からは無期限の保持も検討し、リダイレクトはユーザーにとって低速なので、サイト内のリンクと、ほかのサイトからのアクセスが多いリンクはできるだけ新しいURLに更新します（出典：サイトを移転する方法）。広告の最終ページURLやメール、SNSに載せたLPのURLも、この「リンク」に含めて洗い出しておくと漏れを防げます。

5. SSL化できているか確認する方法

5-1. Chromeでアイコンと証明書を見る

Chromeでは、アドレスの左にあるアイコンで接続が安全かどうかを確認できます。アイコンを選ぶと、サイトの情報の概要が表示されます（出典：サイトの接続が安全かどうかを確認する）。Squad beyondのFAQでは、Chromeで対象のページを開き、URLの横の「サイト情報を表示」から「この接続は保護されています」>「証明書は有効です」と進むと、SSL証明書の内容が表示される手順が紹介されています（出典：独自ドメインのSSL証明書について｜Squad beyond FAQ）。

5-2. Search ConsoleのHTTPSレポートを見る

Search ConsoleのHTTPSレポートでは、インデックス登録されたURLのうちHTTPとHTTPSがそれぞれいくつあるかを確認できます。サイトにHTTPとHTTPSの両方のアドレスを持つページがある場合、Googleは優先的にHTTPSのバージョンをインデックスに登録します。レポートには、次のようなエラーが表示されます（出典：HTTPS レポート）。

• HTTPが正規化タグでマークされている
• HTTPSの証明書が無効である（通常はサイト全体に影響する）
• サイトマップがHTTPを参照している
• HTTPSにリダイレクトが設定されている（HTTPSのURLがHTTPのURLにリダイレクトしている）
• HTTPS URLへのアクセスがロボットによりブロックされました

ヘルプには、HTTPSのエラーが多いと、サイトのHTTPSページに対するクロールが停止される場合があると書かれています（出典：同上）。

5-3. 開発者コンソールで混在コンテンツの警告を見る

ページはhttpsで開けるのに一部が表示されない、タグが動かないといった場合は、ブラウザの開発者コンソールを開きます。混在コンテンツがアップグレードまたはブロックされると、ここに警告が表示されます（出典：混在コンテンツ）。

6. SSL化でよくある失敗例

6-1. 失敗例1：LPをhttpsにしたのに、計測タグをhttpで読み込んでCVが取れない

症状：LPのURLをhttpsに切り替えても、ページに貼った計測タグの読み込み先が「http://」のままだと、タグが読み込まれず、CVやアクセスが計測されなくなる。

原因：HTTPSのページから保護されていないHTTPのリソースを読み込むと混在コンテンツになり、ブラウザは <script> や fetch()、sendBeacon などのリクエストをブロックします。自動でhttpsにアップグレードされるのは画像・動画・音声に限られます（出典：混在コンテンツ）。

対策：開発者コンソールで混在コンテンツの警告が出ているURLを確認し、タグの読み込み先をhttpsのURLに書き換えます。タグの提供元がhttpsのURLを用意しているかも確かめます。

回避策：HTTPSへの切り替え作業の中に、ページ内の「http://」を検索して洗い出す手順を入れておきます。切り替えの前後でCV数やアクセス数を比べ、急に減っていないかを確認するところまでを作業の範囲にしておくと、計測漏れに早く気づけます。

6-2. 失敗例2：httpsのページを用意しても、検索結果にhttpのURLが残る

症状：httpsでも表示できるようにしたのに、httpからhttpsへのリダイレクトを入れず、canonicalもhttpのURLを指したままにすると、検索結果にhttpのURLが表示され続けることがある。

原因：GoogleはHTTPSのページを優先して正規URLに選びますが、HTTPSのページにHTTPのページを指す rel="canonical" がある場合や、HTTPSのページがHTTPにリダイレクトしている場合は例外になります。Search ConsoleのHTTPSレポートでも、「HTTPが正規化タグでマークされている」「サイトマップがHTTPを参照している」はエラーとして扱われます（出典：重複する URL を統合する、HTTPS レポート）。

対策：httpからhttpsへのサーバー側の永続的なリダイレクトを設定し、canonicalとサイトマップのURLをhttpsに書き換えます。そのあと、HTTPSレポートでエラーが減っているかを確認します。

回避策：HTTPSへの移行は、証明書の設定だけで終わりにせず、4章の5つの手順を1つの作業としてまとめて行います。移行後しばらくは、HTTPSレポートを定期的に確認する予定を入れておきます。

6-3. 失敗例3：証明書が無効になり、LPにたどり着けなくなる

症状：SSL証明書の有効期限切れなどで証明書が無効になると、Chromeのページ全体に「この接続ではプライバシーが保護されません」というエラーが表示され、広告から来たユーザーがLPの内容を見られなくなる。

原因：ChromeはウェブサイトのSSL証明書を使ってHTTPS接続を認証します。「この接続ではプライバシーが保護されません」がページ全体に表示されるのは、サイト・ネットワーク・デバイスのいずれかに問題がある場合です（出典：サイトの接続が安全かどうかを確認する）。Search ConsoleのHTTPSレポートでも、「HTTPSの証明書が無効である」は通常サイト全体に影響するエラーとされています（出典：HTTPS レポート）。

対策：証明書を更新し、Chromeで「証明書は有効です」と表示されることを確認します。Meta広告のLPが開かないときの確認項目は「Meta広告でLPが開かない？リンクエラーの原因と対策を解説」にもまとめています。

回避策：証明書の有効期限と更新の担当者を、LPのドメインごとに一覧で管理します。証明書の発行と更新を自動で行うサービスを使う場合も、どのドメインが対象になっているかを把握しておきます。

7. Squad beyondで作るLPのSSL化

7-1. 登録した独自ドメインはSSL証明書が自動で発行される

Squad beyondに登録した独自ドメインには、自動的にSSL証明書が発行されます（出典：独自ドメインのSSL証明書について｜Squad beyond FAQ）。発行された証明書は、5-1の手順でChromeから確認できます。

7-2. 配信用URLのドメインを設定する

Squad beyondでは、LPにドメインを設定することで配信用URLが作成されます。使えるドメインは、独自ドメイン（本ドメイン・サブドメイン）と、Squad beyondが提供するフリードメインです。独自ドメインを使う場合は、事前にDNSの設定が必要です。設定後は、URLにアクセスしてLPが表示されること、管理画面でドメインのステータスが「有効」になっていることを確認します（出典：1. 配信用URLを設定する｜Squad beyond FAQ）。フリードメインを使うかどうかの判断は「フリードメインLPのメリット・デメリット｜おすすめツール5選を紹介」で解説しています。

サブドメインを追加した場合は、最大1時間で承認が完了して利用できるようになります。クライアントのドメイン配下でLPを配信したい場合も、サブドメインで対応できます（出典：サブドメインで配信する｜Squad beyond FAQ）。代理店がクライアントのドメインで配信する運用の例は「代理店も広告主も嬉しい！Squad beyondだけでできるクライアントドメイン配信！」で紹介しています。

7-3. LPの中のURLもhttpsにそろえる

証明書が自動で発行されても、LPの中に貼ったタグや画像、外部フォームのURLが「http://」のままなら、3章の混在コンテンツになります。外部のツールから持ってきたタグを貼るときは、読み込み先のURLがhttpsになっているかを確認しておきましょう。

8. SSL化についてよくある質問

9. まとめ

• SSL化は、通信をTLSで暗号化し、URLをhttpsにすること。SSLは古い技術でTLSに置き換えられているが、呼び名として残っている
• httpのLPは、Chromeのアドレスバーに「保護されていない通信」と表示される。Googleは、2026年10月のChrome 154で「常に安全な接続を使用する」を既定で有効にすると発表している
• HTTPSのページでも、フォームの送信先がhttpならChromeは警告を出し、自動入力を止める
• HTTPSにしたLPでhttpのスクリプトやiframeを読み込むと、混在コンテンツとしてブロックされ、計測タグやフォームが動かないことがある
• HTTPSへの移行は、証明書・ページ内のURL・永続的なリダイレクト・Search Consoleでの確認・リンクの更新までを1つの作業として行う

LPのSSL化は、証明書の設定だけでなく、ページの中のURLまでそろえて完了します。Squad beyondでは、登録した独自ドメインにSSL証明書が自動で発行されるので、残る作業はLPに貼るタグやフォームのURLの確認です。

---

　

Squad beyondサービス紹介資料はこちらからダウンロード