サイト制作者や会社のホームページ担当者であれば知っておくべきことの一つに「サイトSSL化」があります。
インターネットが普及し、様々なサービスが展開している中で、個人情報やクレジットカード情報など、インターネット上で個人を特定する情報をやりとりするケースが増えてきました。
ウェブサイトでは、情報を入力するページだけでなく、サイト全体でHTTPSによる暗号化通信を使うことが大切です。ただし、HTTPSに対応しただけでサイト全体の安全性や検索順位が保証されるわけではありません。
ここでは、サイトSSL化の重要性やサイトSSLのメリット、SSL化までの道のりについてご紹介しています。
サイトSSL化って何？
あなたはサイトSSLと言う言葉を聞いたことがありますか？
「サイトSSL化」は、ウェブサイトをHTTPSで提供する対応を指す呼び方です。現在のHTTPSでは主にTLSという仕組みを使い、ブラウザとサーバーの間の通信を暗号化します。SSLは以前の技術名ですが、証明書やサービスの名称として今も使われています。
ブラウザの表示は、製品や版によって異なります。現在のChromeでは、アドレスバーのサイト情報を開いて接続の状態を確認します。以前の鍵マークや緑色の表示が、そのまま出るとは限りません。
HTTPSは、買い物や個人情報の入力画面だけに使うものではありません。会社案内や商品紹介を含め、サイト全体の通信を保護する方針で整えます。
HTTPによる暗号化されていない接続や、証明書に問題がある接続では、ブラウザに警告が出ることがあります。接続の警告と、有害なサイトとしての警告は、同じ意味ではありません。
「保護されていません」と言う、おなじみの警告を見慣れたことがある人も多いかも知れませんね。
接続の状態を表示するのは、利用しているブラウザです。Chromeはその一つであり、表示の文言や位置は環境によって変わります。
運営者は、画面に警告がないことだけで安心せず、正しいHTTPS接続、証明書の期限、サイトや管理環境の保守をそれぞれ確認しましょう。
どのブラウザで警告されるのか？
Chromeでは、アドレスバーの表示やサイト情報から、保護されている接続かを確認できます。HTTPSを使っていても、接続先の名前が正しいかを確かめることが必要です。
Chromeは、HTTP接続に入力した情報が第三者に見られたり変更されたりするおそれを知らせます。これは通信の保護に関する案内で、運営会社や商品の信用を保証するものではありません。
どのように警告されるのか？
現在のChromeでは、接続の状態や設定によって、アドレスバーの注意表示や接続エラーの画面が出ます。「常に安全な接続を使用する」を有効にしている場合は、HTTPSに対応していないサイトへ進む前に確認画面が出ることもあります。警告を無視して個人情報を入力せず、サイト運営者へ確認してください。
サイトSSL警告の経緯は？
ここからは、2014～2018年当時の公式発表をもとに、HTTPS推進とChromeの表示変更の経緯を振り返ります。現在の操作手順や表示は、今のChromeの案内で確認してください。
Googleは「セキュリティは、最優先事項」と言うくらい、重要視しています。
Googleは、2014年の発表で、自社の検索、Gmail、Google DriveなどのHTTPS利用を紹介し、ほかのウェブサイトにもHTTPS対応を勧めています。
さらに2014年になると、検索結果でHTTPSサイトの優遇を始めました。
2017年にはChrome56ブラウザが登場し、HTTPサイトで、クレジットカード番号やパスワードの入力がある場合に、警告表示をはじめました。
2017年10月のChrome62では、HTTPページへの入力時と、シークレットモードでのHTTPページの閲覧時に、警告の対象を広げると発表されました。
当時は、パスワードやカード情報の入力画面から、より広いHTTP接続へと段階的に警告を拡大する方針でした。
2017年には、GoogleのChromeはセキュリティに関しては、グッと前進したと言わざるを得ません。
HTTPページの表示は、このように入力する情報や利用モードに応じて変わってきました。過去の画面表示を、現在のすべてのブラウザへ当てはめないようにします。
そして2018年、7月リリースのChrome68ブラウザにて、HTTPサイトと言うだけで、「保護されていません」と言う警告を表示すると言う公式アナウンスがされました。
これは2018年時点の表示変更です。今の導入判断では、当時の普及状況ではなく、自社サイトの接続と証明書、使っている環境の条件を確認します。
同じ2018年の公式発表では、10月のChrome70で、HTTPページに入力した際の「保護されていない」表示を赤くすると案内されています。これは当時の変更であり、現在の画面が必ず同じ色や文言になるという意味ではありません。
なぜ、警告が必要なのか？
セキュリティを最優先に掲げているGoogleですが、Googleの提供するウェブブラウザChromeを使うメリットは、特に商品購入ページや採用、資料請求など、個人情報を扱うページであった場合、SSLで保護されていないページだと、アラートが出て、一目で保護されていないページだとわかります。
それにより、ユーザーは入力を控えたり、そのページから離脱したりします。
これもひとえにGoogleのユーザー保護に他なりません。もし、SSL化されていないサイトで個人情報を入力してしまったら、運が悪いと情報を盗まれてしまったりすることになりかねません。
また、ユーザーによく分かるようにアラートを表示することで、ユーザー、そのサイトの持ち主両方への啓蒙行為となります。
対応では、必要な証明書を用意するだけでなく、サーバーへ正しく設定し、サイト全体をHTTPSで表示できるか確認します。証明書の期限や更新の管理も続けます。
警告が出た場合は、色だけで意味を決めず、接続の問題か、サイト自体の危険性に関する案内かを確認します。利用者に警告の回避を勧める対応は避けましょう。
常時SSLのメリットとは？
では常時SSLにすると、どのようなメリットがあるのでしょうか？
個人情報を守る事ができる
GoogleがサイトSSL化を推進している第1の目標はここにあります。
個人情報というと、クレジットカード情報や住所、氏名、年齢、電話番号などが思い浮かびますが、意外な盲点なのがcookieや閲覧履歴です。
これらのページは個人情報を入力するフォームなどが設置されているわけではありませんが、今までの閲覧履歴の中に、沢山の個人情報が含まれています。
具体的な例で言えば、スマホの公衆Wi-Fiです。
HTTPSは、公衆Wi-Fiを使う場合でも、ブラウザと接続先の間の通信を盗み見られたり、途中で変更されたりするリスクを抑えます。ただし、Wi-Fi自体や端末、接続先サイトの安全性まで保証するものではありません。
通信が保護されていても、偽のサイトへ情報を渡してしまえば守れません。HTTPSであることに加え、接続先のドメインや、情報を渡す相手も確かめることが大切です。
検索への影響を正しく理解する
元々はこの「常時SSL(HTTPS)をランキングシグナルに使用します」との発表をGoogleが行なったことにより、各サイトが常時SSL化に意識を向け始めました。
2014年の発表は、HTTPSを検索の評価要素に使い始めるというものです。当時の発表だけで、現在の評価の大きさや順位を決めつけないようにします。
現在は、Googleの検索向け資料でも、安全な配信やモバイル表示など、ページの利用体験を全体として確認することが勧められています。HTTPSはその土台の一つです。
HTTPSにしただけで検索順位が大幅に上がる、という保証はありません。内容の有用性やサイトの使いやすさも含めて改善を続けます。
サイトの安全性の強化
例えばワードプレスなどで作られたサイトを常時SSL化しようとします。
HTTPSは通信を保護しますが、WordPressやプラグインの弱点、管理者アカウントの不正利用などを、それだけですべて防ぐことはできません。更新、アクセス管理、バックアップを別に整えます。
静的なページを配信する構成などを採る場合も、HTTPSや公開先の設定を確認する必要があります。サーバーを一つ追加するだけで、WordPress側の確認が不要になるわけではありません。
配信方法を変えても、検索での最高評価が保証されることはありません。公開URL、正しいページへの転送、検索エンジンが内容を取得できるかを確認します。
構成を変える場合は、問い合わせや更新機能への影響も含めて、現在の制作・管理担当者と作業範囲を決めましょう。表示速度だけを理由に、一律の構成変更を勧めるものではありません。
アクセス解析で確認すること
アクセス解析で扱う参照元は、訪問者がどの案内元から来たかを考える材料です。ただし、自社サイトがHTTPであることだけで、すべての参照元が取得できなくなるわけではありません。
HTTPSのページからHTTPのページへ移動すると、ブラウザの方針によって参照元が渡されないことがあります。一方、現在のGA4の「(direct) / (none)」には、URLの直接入力、参照元の情報がないリンク、計測を妨げる要因など、複数の理由があります。
HTTPSにするだけで、参照元がすべて分かるわけではありません。リンクの案内方法や転送、計測設定も確認します。URLや計測用の情報に、氏名やメールアドレスなどを含めないようにしてください。
サイトSSL化までの道のり
では、具体的にサイトSSL化までには、どんなことをしなければいけないのでしょうか？
証明書の取得
まず、利用中のサーバーで使える証明書と、発行・設定・更新を誰が管理するかを確認します。証明書は通信先の確認に使うもので、サイトの商品や運営者を無条件に信用できると保証するものではありません。
証明書の取得方法は提供元によって異なります。サーバーの管理画面や自動発行の仕組みで取得できるものもあれば、組織の確認などの手続きが必要なものもあります。利用する証明書の条件に沿って進めます。
証明書の設置・サーバ設定
発行された証明書を、サーバーや配信に使うサービスへ設定し、正しいドメインでHTTPS接続できるか確認します。発行から設定までをサーバー側で自動管理する場合もあります。
証明書自体が無料のサービスもありますが、サーバー契約、設定代行、移行、更新の管理などの費用は別に確認します。ミラーサイトを設ければ、すべての費用が不要になるわけではありません。
既存ページの内部リンク変更
内部リンクは、同じサイト内の関連するページへ進むためのリンクです。HTTPSへ移行する際は、ページ内のリンクや画像などの参照先に、古いHTTPの指定が残っていないか確認します。
HTTPからHTTPSへ変わるURLを整理し、CMSの設定やページ内の指定を見直します。相対URLなど、そのまま使える指定もあるため、実際の構成を確認して進めます。
まとめて変更する作業も、事前のバックアップと確認環境での検証を行い、想定外の箇所を変えないようにします。公開後は、重要なページやフォームまで一通り確認しましょう。
リダイレクト設定の追加・修正
サイトSSL化により、URLが変更になると、リダイレクトという作業をして、古いサイトから新しいサイトへ、言わばサイトを「転送」させなくてはなりません。
HTTPからHTTPSへ恒久的に移す場合は、一般に301や308のリダイレクトを使います。対象URLごとの対応と、利用しているサーバーやCMSの手順を確認して設定します。
転送は、古いHTTPの各URLから、対応するHTTPSのURLへ行うのが基本です。すべてをトップページへ送らず、リンクやサイトマップなども更新します。「設定しないとサイトの年齢が0歳になる」という仕組みではありません。
https通信エラーページのチェック
サイトSSL化すると、HTTPSの通信エラーページのチェックも必要となります。
このHTTPS通信エラーページチェックは、正しくHTTPSページに対応できているかのチェックをする作業となります。
まず、テスト用の環境を用意しましょう。レンタルサーバなどでも、テスト用環境が提供されているケースが多いので、昔と比べたらずいぶんハードルが下がっています。
HTTPSのページで、画像やスクリプトなどをHTTPで読み込む指定があると、ブラウザがその読み込みを制限する場合があります。ページ本体だけでなく、関連するファイルの接続先も確認します。
以前のサイトでは、決済や入力画面だけHTTPSにしている構成もありました。移行時は、そのような古い指定が会社案内や商品ページなどに残っていないかも調べます。
でもいまやサイトの安全性を確保するためには全ページのSSL化が求められています。
Chromeサイトで見ると警告が表示されますので、速やかにHTTPの箇所を修正しましょう。
証明書の更新・設置
ここまででサイトSSL化に関する手続きや作業は一通り終了しました。
証明書には有効期限があります。公開用TLS証明書は、2026年3月15日から2027年3月15日より前に発行されるものでは、有効期間の上限が200日です。すべて2年間有効というわけではありません。実際の期限は、使っている証明書で確認してください。
期限が切れると、ブラウザに接続エラーが出て、利用者が正常に閲覧や入力を続けられなくなるおそれがあります。自動更新でも、更新とサーバーへの反映が完了したかを確認し、期限切れの前に対応します。
サイトSSLのまとめ
ここまで、サイト制作者や会社のホームページ担当者の方に向けて、サイトSSLとは何か、サイトSSLにするメリット、サイトSSLまでの道のりについてご紹介してきました。
サイト全体をHTTPSで提供するには、証明書、サーバー、ページ内の指定、転送、公開後の確認を整えます。必要な作業や費用は、現在の構成や契約によって異なります。
HTTPSは、安全に通信するための大切な土台です。ただし、導入すればサイト全体が安全になり、検索で上位に出るという保証ではありません。内容の改善や、システムの保守も続ける必要があります。
公衆Wi-Fiでの利用を考えるときも、HTTPSで守れるのは通信の区間であることを押さえましょう。端末やWi-Fi、接続する相手の確認も必要です。
自社サイトの対応が分からない場合は、現在の管理担当者と、HTTPSで表示できる範囲、証明書の期限、更新の担当、公開後の確認方法を整理してください。警告を無視して使い続ける対応は避けましょう。
参考資料（2026年10月29日確認。過去の発表は当時の経緯として紹介）：MDN：HTTPS／Google：Chromeの接続確認／Google：2014年のHTTPSに関する発表／Google：2016年のChrome警告の発表／Google：2017年のChrome警告の発表／Google：2018年のChrome警告の発表／Google：URL変更を伴うサイト移転／Google：ページエクスペリエンス／CA/Browser Forum：証明書の要件6.3.2／Let’s Encrypt：証明書と運用／DigiCert：証明書の認証方式／MDN：参照元の送信方針／Google：GA4のdirect/none／WordPress：更新と事前のバックアップ。
