SSL（HTTPS化）とは？必要性と導入手順をわかりやすく解説

SSL（HTTPS化）とは、Webサイトと閲覧者のブラウザの間の通信を暗号化し、第三者による盗み見や改ざんを防ぐ仕組みです。URLが「https://」で始まるサイトは、この仕組みで守られています。

結論から言うと、現在はお問い合わせフォームの有無にかかわらず、サイト全体をHTTPSにする「常時SSL化」が前提です。主要ブラウザはHTTPのページに警告を出しており、Googleも安全な接続をページエクスペリエンスの要素の一つとして挙げています。

この記事では、SSLの仕組みと必要性、証明書の種類（無料SSLと有料SSLの違い）、常時SSL化の手順、つまずきやすい混在コンテンツ、301リダイレクトなどSEO面の注意点までを順に解説します。

SSL（HTTPS）とは？通信を暗号化する仕組み

SSLは、ブラウザとWebサーバーの間でやり取りされるデータを暗号化し、通信相手が本物であることを証明書で確認する仕組みです。 HTTPにこの仕組みを組み合わせたものがHTTPSです。

SSLとTLSの関係

現在実際に使われている技術は、SSLの後継規格である「TLS」です。ただし慣習的に「SSL」「SSL証明書」という呼び方が今も広く使われているため、この記事でも「SSL」と表記します。

どのTLSのバージョンや暗号方式を使うべきかについては、IPA（情報処理推進機構）とCRYPTRECが「TLS暗号設定ガイドライン」を公開しています。サーバーを自社で管理している場合は、このガイドラインに沿った設定になっているか確認しましょう（出典：IPA「TLS暗号設定ガイドライン」。最新版の版数は公式ページで要確認）。

HTTPSで守れるもの・守れないもの

HTTPSが守るのは「通信経路」です。次の表のように、サイトそのものの安全性までを保証するものではありません。

サイト全体の守り方は「Webサイトのセキュリティ対策ガイド」で整理しています。

HTTPS化が必要な3つの理由

HTTPS化が必要な理由は、「閲覧者の情報を守る」「ブラウザの警告を避ける」「検索エンジンの評価で不利にならない」の3点です。

1. 入力情報と表示内容を守るため

HTTPの通信は暗号化されていないため、同じネットワーク上の第三者が内容を読んだり書き換えたりできる余地があります。お問い合わせフォームや資料請求フォームで個人情報を受け取るサイトでは、とくに重要です。フォーム側の対策は「お問い合わせフォームのセキュリティ対策」で詳しく解説しています。

2. ブラウザに「保護されていない通信」と表示されるため

Googleは2018年7月24日、Chrome 68からHTTPのページに「保護されていない（not secure）」という表示を出すと発表しました（出典：Google「A milestone for Chrome security: marking HTTP as “not secure”」2018年7月24日）。

さらにGoogleは2025年10月28日、2026年10月リリース予定のChrome 154で「常に安全な接続を使用する」設定を既定で有効にし、HTTPSに対応していない公開サイトへ最初にアクセスする前にユーザーの許可を求める方針を発表しています（出典：Google「HTTPS by default」2025年10月28日）。※公開時点での実際の提供状況は要確認。

問い合わせを検討している人がアドレスバーの警告を見れば、それだけで離脱につながりかねません。

3. SEOで不利にならないため

Googleは2014年8月7日に、HTTPSをランキングシグナルとして使い始めたと発表しました。ただし当時の説明では「全世界のクエリの1%未満に影響する、ごく軽いシグナル」で、良質なコンテンツなど他のシグナルより重みは小さいとされています（出典：Google検索セントラル ブログ「HTTPS as a ranking signal」2014年8月7日）。

現在のGoogleのページエクスペリエンスに関するドキュメントでは、「単一のシグナルはない」としたうえで、ページが安全に配信されているかを自己評価の観点の一つに挙げています（出典：Google検索セントラル「Understanding page experience in Google Search results」最終更新2026年9月22日）。

つまり「HTTPS化すれば順位が上がる」のではなく、**「HTTPのままでは利用者にも検索エンジンにも不安要素を残す」**と理解するのが実態に近いでしょう。SEO全体の考え方は「SEO対策とは？」をご覧ください。

SSL証明書の種類と選び方

SSL証明書は、発行時に「何を確認したか」でDV・OV・EVの3種類に分かれます。 暗号化の仕組み自体は共通で、違いは運営者の実在確認の深さです。

（出典：DigiCert（DV・OV・EV証明書の違いの解説ページ）。DigiCertは認証局事業者であり、確認項目の数などは同社の基準によるものです）

無料SSLと有料SSLの違い

無料SSLの代表例は、非営利団体ISRGが運営する認証局「Let’s Encrypt」です。発行されるのはDV証明書で、有効期間は現在90日。2028年までに45日へ短縮する予定が公表されています（出典：Let’s Encrypt「Decreasing Certificate Lifetimes to 45 Days」2025年12月2日）。

多くのレンタルサーバーが無料SSLの設定機能と自動更新を用意しています（対応状況・仕様は各社公式で要確認）。暗号化の強さは無料・有料で変わらないため、組織の実在証明（OV/EV）や補償・サポートが必要かどうかで選ぶのが基本です。

証明書の有効期間は短くなっていく

証明書の発行ルールを定めるCA/Browser Forumは、証明書の最大有効期間を段階的に短縮すると決めています。2026年3月15日以降は200日、2027年3月15日以降は100日、2029年3月15日以降は47日です（出典：CA/Browser Forum「Baseline Requirements」1.2.2 Relevant Dates、Ballot SC-081v3（2025年4月11日採択））。

有料証明書を手作業で更新している場合、更新の頻度が上がります。「自動更新できるか」は、今後の証明書選びで重要な判断軸になります。

常時SSL化（HTTPS化）の手順

常時SSL化は「証明書の導入→サイト内URLの修正→リダイレクト設定→検索エンジンへの反映」の順に進めます。 順番を守ると、表示崩れや検索評価の取りこぼしを防ぎやすくなります。

［画像：ssl-https-5-steps.webp（常時SSL化の5ステップを示すフロー図）／alt案：常時SSL化の手順を5段階で示したフロー図］

ステップ1：現状を把握しバックアップを取る

作業前にサイトのファイルとデータベースをバックアップします。あわせて、現在のURL一覧（サイトマップ）、外部サービスに登録しているURL（広告、SNS、Googleビジネスプロフィールなど）を書き出しておくと、後の修正漏れを防げます。

ステップ2：SSL証明書を取得・設定する

レンタルサーバーの管理画面から無料SSLを有効化するか、有料証明書を申し込んでサーバーに設定します。設定後、「https://」でページが表示されること、ブラウザで証明書エラーが出ないことを確認します。

ステップ3：サイト内のURLをhttpsに書き換える

画像・CSS・JavaScriptの読み込み先や内部リンクに「http://」が残っていると、後述の混在コンテンツになります。WordPressの場合はサイトアドレスの設定変更とデータベース内URLの置換が必要です。具体的な設定は「SEOに強いWordPressの設定方法」も参考にしてください。

ステップ4：httpからhttpsへ301リダイレクトする

すべての「http://」のURLを、対応する「https://」のURLへサーバー側の恒久的なリダイレクト（301または308）で転送します。Googleは、リダイレクトはできるだけ長く、一般的には少なくとも1年は維持するよう案内しています（出典：Google検索セントラル「How to move a site（サイト移転）」最終更新2026年8月20日）。

ステップ5：Search Consoleとサイトマップを更新する

Search ConsoleでHTTPS版のプロパティを確認（登録）し、HTTPSのURLで作ったサイトマップを送信します。なお、HTTPからHTTPSへの移行では「アドレス変更ツール」は不要とされています（出典：同上）。

混在コンテンツ（Mixed Content）とは？原因と直し方

混在コンテンツとは、HTTPSのページの中にHTTPで読み込まれる画像やスクリプトが混ざっている状態です。 鍵マークが表示されない、レイアウトが崩れる、機能が動かないといった不具合の原因になります。

ブラウザの扱い

MDN Web Docsによると、ブラウザは混在コンテンツを2種類に分けて扱います（出典：MDN Web Docs「混在コンテンツ」）。

• アップグレード可能なもの（img・audio・video など）：ブラウザが自動でhttpsに書き換えて読み込む。https版が存在しなければ表示されない
• ブロック対象のもの（script・スタイルシート・iframe・Webフォントなど）：読み込み自体がブロックされる

スクリプトやCSSがブロックされると、フォームや地図、スライダーが動かなくなることがあります。

見つけ方と直し方

1. ブラウザの開発者ツール（コンソール）を開き、「Mixed Content」の警告が出ていないか確認する
2. 自サイト内のリソースは「https://」または相対パスに書き換える
3. 外部サービスの埋め込みタグは、https版の提供元URLに差し替える
4. 補助策として、レスポンスヘッダー Content-Security-Policy: upgrade-insecure-requests で読み込みをhttpsに引き上げる方法もある（ただし元のURLの修正の代わりにはならない）

HTTPS化でSEO評価を落とさないための注意点

SEO上の注意点は、「URLの正規化を揃える」「リダイレクトを1回で済ませる」「クロールを妨げない」の3つに集約されます。

これらはGoogleのサイト移転ガイドと、2014年のHTTPSに関する発表で示された推奨事項をもとに整理しています（出典：Google検索セントラル「How to move a site（サイト移転）」、「HTTPS as a ranking signal」）。

HSTSは慎重に

HSTS（Strict-Transport-Security）は、ブラウザに「このサイトは今後HTTPSでのみ接続する」と記憶させる仕組みです。ただし一度設定すると、ブラウザ側で記憶した期間（max-age）中は簡単に解除できません。preloadリストへの登録には、max-ageが1年以上で、全サブドメインがHTTPSに対応していることが条件になります（出典：MDN Web Docs「Strict-Transport-Security」）。サブドメインの対応状況を確認してから、短いmax-ageで段階的に導入するのが安全です。

SEOで避けたい設定全般は「SEOでやってはいけないこと」でも解説しています。

【実例】アイエムワークスが常時SSL化で確認していること

アイエムワークスがこれまでに常時SSL化を担当したサイトでの傾向と、作業後に必ず確認している項目を紹介します。

HTTPS化の前によくある状態

ご相談を受けるサイトでは、次の3つの状態をよく見かけます。

3つ目は見落とされがちです。https://で表示できるため対応済みに見えますが、http://のURLでも同じページが開ける状態が残っています。

混在コンテンツが残りやすい場所

当社の作業で混在コンテンツが見つかるのは、外部サービスの埋め込みよりも、**サイト自身のデータやテンプレートに残った「http://」**であることが多いです。

• 記事や固定ページの本文に貼った画像のURL
• テーマ・テンプレートに直接書かれたCSS・JavaScript・画像のURL
• データベースに保存されたURL（WordPressの設定値、ウィジェット、カスタムフィールドなど）

本文の画像は目で見て気づけることもありますが、テンプレートやデータベースに残ったURLは画面からは見えません。そのため、開発者ツールでの確認が欠かせません。

作業後に必ず確認している8項目

当社では、HTTPS化の作業後やサイトの公開前に、次の項目をすべて確認しています。

この手順と確認を守って進めた結果、これまで当社が担当したHTTPS化では、大きなトラブルは起きていません。常時SSL化は特別に難しい作業ではなく、手順を飛ばさず、最後の確認まで行うことが大切です。

この手順と確認を守って進めた結果、これまで当社が担当したHTTPS化では、大きなトラブルは起きていません。常時SSL化は特別に難しい作業ではなく、手順を飛ばさず、最後の確認まで行うことが大切です。

まとめ：常時SSL化は「手順どおり」に進めれば難しくない

• SSL（HTTPS化）は、サイトと閲覧者の間の通信を暗号化し、盗み見・改ざんを防ぐ仕組み
• Chromeの警告表示や検索エンジンの評価を考えると、サイト全体の常時SSL化が前提
• 証明書はDV・OV・EVの3種類。暗号化の強さは同じで、無料SSLでも暗号化の面では十分
• 手順は「バックアップ→証明書設定→URL書き換え→301リダイレクト→Search Console更新」
• 混在コンテンツ、canonical、リダイレクトの連鎖を確認すれば、SEO評価の取りこぼしを防げる

HTTPS化は通信経路を守る対策です。サーバーの設定や管理画面の守りもあわせて見直す場合は、「サーバーのセキュリティ対策」「不正アクセス対策の基本」もあわせてご覧ください。

参考資料・出典

• Google検索セントラル ブログ「HTTPS as a ranking signal」（2014年8月7日）https://developers.google.com/search/blog/2014/08/https-as-ranking-signal
• Google「A milestone for Chrome security: marking HTTP as “not secure”」（2018年7月24日）https://blog.google/products-and-platforms/products/chrome/milestone-chrome-security-marking-http-not-secure/
• Google「HTTPS by default」（2025年10月28日）https://blog.google/security/https-by-defau/
• Google検索セントラル「How to move a site（サイト移転）」（最終更新2026年8月20日）https://developers.google.com/search/docs/crawling-indexing/site-move-with-url-changes
• Google検索セントラル「Understanding page experience in Google Search results」（最終更新2026年9月22日）https://developers.google.com/search/docs/appearance/page-experience
• Let’s Encrypt「Decreasing Certificate Lifetimes to 45 Days」（2025年12月2日）https://letsencrypt.org/2025/12/02/from-90-to-45/
• CA/Browser Forum「Baseline Requirements」https://cabforum.org/working-groups/server/baseline-requirements/requirements/
• CA/Browser Forum「Ballot SC-081v3」（2025年4月11日）https://cabforum.org/2025/04/11/ballot-sc081v3-introduce-schedule-of-reducing-validity-and-data-reuse-periods/
• DigiCert（DV・OV・EV証明書の違いの解説ページ）https://www.digicert.com/jp/difference-between-dv-ov-and-ev-ssl-certificates
• MDN Web Docs「混在コンテンツ」https://developer.mozilla.org/ja/docs/Web/Security/Mixed_content
• MDN Web Docs「Strict-Transport-Security」https://developer.mozilla.org/ja/docs/Web/HTTP/Reference/Headers/Strict-Transport-Security
• IPA「TLS暗号設定ガイドライン」https://www.ipa.go.jp/security/crypto/guideline/ssl_crypt_config.html

※各出典の内容は2026年10月時点で確認しています。