SSL化しないとどうなるか｜無料で対応する手順と失敗回避

自社サイトのURLが「http://」のままで、ブラウザに警告が出ていないか気になっていませんか。

この記事は、自社サイトを自分たちで管理している中小企業の経営者・広報・Web担当者に向けたものです。SSL化しないとどうなるかという実害と、無料で対応する手順をまとめています。

読み終わる頃には、自社サイトの現状を確認し、レンタルサーバーの無料SSLでhttps化を進め、公開後に何をチェックすればいいかまで判断できる状態を目指します。コピペで使える設定コードとチェックリストも載せています。

なお、この記事ではドメインの取得方法やサーバーの引っ越しそのものは扱いません。サーバー移転とセットで考えている方はWordPressのサーバー引っ越し手順｜DB移行と無停止切替を先に読んでおくと、作業の順番を間違えずに済みます。

Contents / 目次

1. SSL化しないとどうなるか。起きる4つの実害
2. SSL化を無料でやるやり方。5ステップで進める
3. よくある失敗と回避法。現場で見かける4パターン
4. SSL化するとどう変わるか。効果の見立て方
5. 無料SSLで足りるのか。現場での判断軸と妥協点
6. SSL化についてよくある質問
7. まずは自社サイトをhttpsで開いてみてください

SSL化しないとどうなるか。起きる4つの実害

結論から言うと、httpのまま放置すると「警告表示による離脱」「情報漏えいのリスク」「検索評価の不利」「ブラウザ側の締め出し」の4つが同時に起こります。しかも、その入口はほぼ確実にお問い合わせフォームや資料請求フォームです。

とくに影響が大きいのは、フォームの直前で読者が止まってしまうことです。ブラウザは、暗号化されていないページで個人情報を入力させようとすると、安全でない旨の警告を表示する方向で仕様が強化されてきました。どんな文言でどのタイミングで出るかはブラウザとバージョンによって変わるので、実際の見え方は自社サイトを開いて自分の目で確かめてください。

読者からすると、名前とメールアドレスを打ち込もうとした瞬間に「危険」と言われるわけです。ここで手が止まるのは当たり前ですよね。せっかく広告や検索でたどり着いた人を、最後の1画面で失うことになります。

httpのまま起きること	実際の影響	いつ効いてくるか
ブラウザの警告表示	フォーム入力の直前で離脱する。営業先から「御社のサイト、警告出てますよ」と言われる	今すでに起きている
通信が暗号化されない	問い合わせ内容やログインID・パスワードが、途中の経路で第三者に読まれる可能性がある	今すでに起きている
検索評価で不利になる	httpsであること自体が順位を押し上げるわけではないが、暗号化されていないサイトは訪問者の信頼を落とす	じわじわ効く
ブラウザ側の締め出し	ブラウザのセキュリティ設定が強化されるほど、httpのページは警告が挟まりやすくなる	これから強まる

ブラウザ側のセキュリティ強化は年々進んでおり、httpのページは警告が出やすくなる方向です。設定名や適用時期はブラウザのバージョンによって変わるため、最新の挙動は使っているブラウザの公式アナウンスで確認してください。

SSL化とは。わかりやすく言うと通信を封筒に入れること

SSL化とは、サイトとブラウザの間でやり取りするデータを暗号化し、URLを「https://」で表示できるようにする設定のことです。正式にはSSL/TLSという仕組みを指します。

かんたんに言うと、はがきで送っていた手紙を封筒に入れて送るようなものです。はがき（http）は配達の途中で誰でも中身を読めますが、封筒（https）に入れれば中身は読めません。

もう少し詳しく言うと、SSL化には「暗号化」に加えて「なりすまし防止」の役割もあります。証明書を発行する認証局が「このドメインの持ち主は本人です」と保証してくれるので、偽サイトにすり替えられていないことを確認できます。

つまり、中身を隠すことと、相手が本物かを確かめること。この2つをまとめてやってくれるのがSSL化です。

今日やることは3つだけ

やることはシンプルです。次の3つを順番に進めれば、費用をかけずにhttps化できます。

• 現状を確認する：自社サイトのURLがhttpsで開けるか、開けた場合に警告が消えているかを、スマホとPCの両方で確認する
• 無料SSLを有効にする：契約中のレンタルサーバーの管理画面から、無料SSLを対象ドメインに設定する
• httpをhttpsに寄せる：サイト内のURLをhttpsに直し、httpでのアクセスをhttpsへ301リダイレクトする

3つ目のリダイレクト設定だけは、サーバーの設定ファイルを触るので少し緊張する作業です。設定ファイルの書き方をもっと詳しく知りたい方は、.htaccessでhttpをhttpsへ301リダイレクト｜コピペ設定と失敗回避で個別に解説しています。

SSL化を無料でやるやり方。5ステップで進める

SSL化は、レンタルサーバーを使っているなら費用ゼロでできる場合があります。無料SSL機能が付いているかどうか、対象プランや設定手順はサーバー会社によって違うので、まず契約中のサーバー会社の公式マニュアルで「無料SSL」「SSL設定」の項目を確認してください。

ここからは、WordPressサイトを前提に5つのステップで進めます。作業にかかる時間はサイトの規模や構成で大きく変わります。証明書の反映待ちも発生するので、当日は他の予定を詰め込まず、余裕をみて取りかかってください。

ステップ1。作業前のバックアップと現状確認

最初にやるのはバックアップです。SSL化の作業ではデータベースの中身を書き換えるので、戻せる状態を作ってから始めます。

確認しておくことは4つあります。作業中に「これどこで管理してたっけ」と止まるのを防ぐためです。

• サーバー管理画面のログイン情報：契約しているレンタルサーバーのコントロールパネルに入れるか
• ドメインの管理会社：サーバー会社と別の場合、ネームサーバーがどこを向いているか
• WordPress管理画面の権限：管理者権限のアカウントで入れるか
• バックアップの取得：ファイル一式とデータベースの両方。サーバーの自動バックアップ機能があればその復元手順も確認しておく

ポイント。ドメインを移管したばかり、あるいはネームサーバーを変更した直後は、DNSの設定が完全に反映されるまで証明書の発行が失敗します。ドメイン移管と同時にSSL化しようとして詰まるのは、現場でよくあるパターンです。1日待ってから進めてください。

ステップ2。サーバー管理画面で無料SSLを有効にする

次に、レンタルサーバーの管理画面から無料SSLを設定します。多くのサーバーでは、管理画面のメニューから設定できるようになっています。

操作の流れは次の3ステップです。

1. 対象ドメインを選ぶ
2. 無料SSLの設定を追加する
3. 発行完了を待つ

メニュー名やボタンの位置はサーバーごとに違ううえ、管理画面のリニューアルで変わることもあります。「無料SSL」「SSL設定」といった名称で探し、正確な手順は契約中のサーバー会社の公式マニュアルで確認してください。

設定後、証明書が反映されるまでの待ち時間もサーバーによって違います。すぐ反映される場合もあれば、しばらく待つ場合もあるので、目安時間は管理画面の案内や公式マニュアルを確認してください。反映されたら、ブラウザのアドレスバーに「https://自社ドメイン」と直接打ち込んで開けるかを確認します。この時点ではまだサイト内の画像が表示されなかったり、警告が出たりしますが、問題ありません。次のステップで直します。

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

httpsで開けるようになったら、サイトの中身に残っているhttpのURLを一斉に置き換えます。ここを飛ばすと、後述する混在コンテンツの警告が消えません。

WordPressの場合、まず管理画面の「設定」から「一般」を開き、WordPressアドレスとサイトアドレスの2つをhttpsに書き換えます。この2か所を直すと、いったんログアウトされて再ログインを求められます。

次に、記事本文や設定値の中に埋め込まれたhttpのURLを置き換えます。WP-CLIが使えるサーバーなら、次のコマンドが確実です。

# 前提。SSH接続できるレンタルサーバーで、WP-CLIが使える環境
# WordPressのインストールディレクトリで実行する

# 1. データベースのバックアップを取る（必ず先にやる）
wp db export backup-before-ssl.sql

# 2. まず試し打ち。--dry-run を付けると実際には書き換えず、件数だけ表示される
wp search-replace 'http://example.com' 'https://example.com' --dry-run
# ［example.com を自社ドメインに変更］

# 3. 表示された件数に違和感がなければ、--dry-run を外して本実行
wp search-replace 'http://example.com' 'https://example.com'

# 注意。オプションや挙動はWP-CLIのバージョンで変わるため、
# 実行前に公式ドキュメント（wp help search-replace）で確認する

SSH接続ができない環境では、データベースの文字列置換に対応したWordPressプラグインを使う方法もあります。その場合も、必ず「まず試し打ちして件数を見る」「バックアップを取ってから実行する」の2つは守ってください。

ステップ4。httpからhttpsへ301リダイレクトを設定する

URLを置き換えたら、httpでアクセスしてきた人を自動的にhttpsへ転送します。これをやらないと、古いブックマークや他社サイトからのリンクで来た人が、httpのページを見続けることになります。

Apacheが動いているレンタルサーバーなら、サイトの一番上の階層にある.htaccessファイルに次を追記します。

# 前提。Apache系のレンタルサーバー。設置場所はドキュメントルート直下の .htaccess
# WordPress の場合、「# BEGIN WordPress」より前の行に書くこと

<IfModule mod_rewrite.c>
RewriteEngine On
RewriteCond %{HTTPS} off
RewriteRule ^(.*)$ https://%{HTTP_HOST}%{REQUEST_URI} [R=301,L]
</IfModule>

# つまずきやすい点。
# 反映後に無限リダイレクトになる場合は、下の条件に差し替えて挙動を確認する。
# RewriteCond %{HTTP:X-Forwarded-Proto} !https

.htaccessを編集する前に、必ず元のファイルをダウンロードして手元に保存してください。書き間違えるとサイト全体が500エラーで真っ白になりますが、元のファイルを上書きで戻せば復旧できます。

設定後にページがぐるぐる回って開かなくなった場合は、リダイレクトの条件が二重になっているケースをよく見かけます。原因の切り分け方はリダイレクトループの原因切り分けと直し方｜htaccess対処にまとめています。

なお、サーバーの管理画面に「常時SSL化」「HTTPSへのリダイレクト」といった設定項目が用意されている場合は、そちらを使う方が安全です。.htaccessとサーバー設定の両方でリダイレクトをかけると、ループの原因になります。どちらか一方にしてください。

ステップ5。公開後のチェックリストで確認する

最後に、抜けがないかを確認します。ここを省くと「SSL化したつもりで警告が消えていない」状態が半年続く、ということが起こります。次の項目を順番に潰してください。

• トップページと下層3ページ：PCとスマホの両方でhttpsで開き、アドレスバーに警告が出ていないか
• http直打ちの転送：「http://自社ドメイン/会社概要のURL」を打ち込み、httpsの同じページへ飛ぶか（トップに飛ばされるのはNG）
• 混在コンテンツ：ブラウザの開発者ツールを開き、コンソールに「Mixed Content」の警告が出ていないか
• フォーム送信：問い合わせフォームからテスト送信し、自動返信メールが届くか
• Search Console：httpsのプロパティを新規登録し、サイトマップを再送信したか
• アクセス解析：GA4の計測が止まっていないか、リアルタイムレポートで確認したか
• 証明書の自動更新：サーバー管理画面で自動更新が有効になっているか

Search Consoleのプロパティは、登録の仕方によってhttpとhttpsの扱いが変わります。SSL化の前後でデータが分断されないよう、自社の登録状況を管理画面で確認しておいてください。登録がまだの方はSearch Console登録手順｜初心者も3ステップで所有権確認までを見ながら進めてください。

よくある失敗と回避法。現場で見かける4パターン

SSL化のトラブルは、原因のパターンがほぼ決まっています。設定そのものより、設定した後の確認漏れで起きるものが大半です。ここでは実際によく見かける4つを、起きる状況と防ぎ方をセットで挙げます。

失敗1。混在コンテンツで鍵マークが復活しない

一番多いのがこれです。SSL化したのに「保護されていない通信」の表示が消えない、という相談は、ほとんどが混在コンテンツによるものです。

混在コンテンツとは、httpsのページの中に、httpで読み込まれている画像・CSS・JavaScriptが混ざっている状態のことです。ページ本体は封筒に入っているのに、中の写真だけはがきで届いている、というイメージですね。ブラウザはこれを検知して警告を出します。

とくに残りやすいのは次の4つです。データベースの置換だけでは、テーマ設定ファイルやウィジェット内の記述が残ることがあります。

• 記事本文に直接貼った画像URL
• テーマのカスタマイザーで設定したロゴやファビコン
• 外部から読み込んでいるフォントやSNSのボタン
• 古い解析タグ

防ぎ方はシンプルです。ブラウザの開発者ツールでコンソールを開き、「Mixed Content」と出ている行のURLを1つずつ潰します。自社で管理している画像ならhttpsに書き換えるだけ、外部サービスの読み込みならhttps版の埋め込みコードに差し替えます。

失敗2。リダイレクトを二重にかけてループする

サーバー管理画面の常時SSL設定をオンにしたうえで、.htaccessにも同じリダイレクトを書いてしまうパターンです。転送が延々と繰り返され、ブラウザに「リダイレクトが多すぎます」と表示されてサイトが開かなくなります。

この状態が怖いのは、社内では気づきにくいことです。ブラウザのキャッシュが効いていると、設定した本人の画面ではしばらく普通に見えてしまいます。外から来たお客さまだけが開けない、という事故になります。

防ぎ方は、リダイレクトの設定場所を1か所に決めることです。サーバー機能を使うなら.htaccessには書かない。.htaccessに書くならサーバー機能はオフにする。設定を変えたら、シークレットウィンドウかスマホのモバイル回線で必ず確認してください。

失敗3。証明書の期限切れでサイトが止まる

無料SSLは、自動更新が効いていれば問題ありませんが、サーバーの設定変更やドメインの向き先変更をきっかけに、自動更新だけ止まっていることがあります。気づかないまま有効期間を過ぎると、サイトを開いた人に警告画面が出ます。

証明書の有効期間は認証局やサーバー会社によって違うので、契約中のサーバーの管理画面か認証局の公式情報で確認してください。いずれにせよ、手動更新を前提にした運用は現実的ではありません。

防ぎ方は2つあります。

• 自動更新の確認：サーバー管理画面で自動更新が有効になっていることを確認する
• 期限の一元管理：ドメインとSSLの期限を1枚の一覧で管理し、担当者を決めておく

管理の仕組み作りはドメイン・SSL期限切れでサイトが止まる前に｜更新管理の手順で詳しく解説しています。

失敗4。SSL化のついでに解析データが途切れる

SSL化そのものは成功しているのに、Search ConsoleやGA4の設定が追いついておらず、数か月後に「検索流入のデータが見られない」と気づくパターンです。

Search Consoleはプロパティの登録方法によって、SSL化の前後でデータが別々に記録されることがあります。過去データは後から作り直せないので、作業のタイミングで登録状況を確認しておくことが大事です。

防ぎ方は、SSL化の作業チケットに「Search Consoleのプロパティ確認・追加」「サイトマップ再送信」「GA4のリアルタイム確認」を最初から含めておくことです。作業の当日ではなく、翌日にもう一度データが入っているかを見るところまでをセットにしてください。

SSL化するとどう変わるか。効果の見立て方

SSL化は「やると売上が伸びる施策」ではなく、「やらないと機会を失い続ける前提条件」です。効果の測り方を間違えると、社内で費用対効果を説明できなくなるので、ここを整理しておきます。

もっとも分かりやすい変化は、フォーム周りの離脱です。警告表示が消えることで、入力途中で止まっていた人が最後まで進めるようになります。どのくらい改善するかは業種やサイト規模で大きく変わるため、事前に数字を控えておいて自社で比べるのが確実です。

次に、営業現場での信用です。名刺交換の後にサイトを見た相手が「保護されていない通信」の表示を見る、という場面をなくせます。BtoBの取引では、発注先のセキュリティ体制を確認する社内ルールを持つ企業もあります。httpのままだと、それだけで候補から外れることがあります。

検索評価については、正直に書きます。https化そのもので順位が上がることは期待しない方がいいでしょう。「順位を上げる施策」ではなく「訪問者に不信感を与える要素を1つ取り除く作業」と考えるのが実態に近いです。

費用対効果でいうと、レンタルサーバーの無料SSLを使う場合、証明書の費用はゼロです。かかるのは作業時間だけです。制作会社に依頼する場合も、作業単価に対する時間分で見積もられるのが一般的です。

一方、放置して問い合わせを取り逃す損失は毎月積み上がります。この非対称さが、SSL化を後回しにすべきでない理由です。

ポイント。SSL化の効果は「増えた数」より「止まった漏れ」で見るのが正しい測り方です。作業前に、フォーム到達数と送信完了数を控えておくと、後から比較できます。

無料SSLで足りるのか。現場での判断軸と妥協点

結論として、企業サイトの大半は無料SSLで十分です。暗号化の強度そのものに有料・無料の差はなく、通信が守られるレベルは同じだからです。ただし、無料で割り切れない場面もあるので、その線引きを率直に書きます。

無料SSLで問題ないケースと、有料を検討するケース

無料SSLの証明書は、ドメイン認証型（DV）と呼ばれる種類です。「このドメインの管理権限を持っている人が申請した」ことだけを証明します。運営会社が実在するかどうかまでは確認されません。

一方、有料の企業認証型（OV）やEV認証型（EV）は、認証局が会社の実在性を審査したうえで発行します。金融・医療・大規模ECのように、取引先や監査から「実在証明のある証明書」を求められる業種では、こちらが必要になることがあります。

• 無料SSLで十分：コーポレートサイト、LP、採用サイト、お問い合わせフォーム程度の一般的な企業サイト
• 有料を検討：取引先や業界のルールで実在証明が求められる、決済情報を自社サーバーで扱う、複数サブドメインを一括管理したい
• 迷ったら：まず無料SSLで警告を消す。有料への切り替えは後からでもできる

費用の考え方をもう少し詳しく比べたい方は、常時SSL化の費用｜無料と有料の違い・選び方と失敗しない移行手順で判断軸を整理しています。

SSL化のどこまでをAIに任せられるか

SSL化の作業は、AIに任せられる部分と、人がやるべき部分がはっきり分かれます。ここを混ぜると事故ります。

AIが得意なのは「調べる・翻訳する・下書きを作る」ところです。たとえば、開発者ツールに出た大量のMixed Content警告を貼り付けて、どのファイルを直せばいいかの一覧に整理してもらう。あるいは、.htaccessに書いてある既存の記述が何をしているのかを解説してもらう。この使い方は失敗しにくく、時間短縮の効果も大きいです。

渡す材料としては、警告メッセージの全文、現在の.htaccessの中身、使っているサーバー会社名とWordPressのバージョンあたりを添えると、精度が上がります。次のような短い出発点から始めて、あとは対話しながら自社の状況に合わせて詰めていくのがおすすめです。

あなたはWebサイト運用の担当者です。
以下は、SSL化したページで開発者ツールのコンソールに出た警告の全文です。
1) どのファイルがhttpで読み込まれているか一覧にする
2) それぞれ「本文中の記述」「テーマ設定」「外部サービス」のどれが原因か推測する
3) 修正の優先順位をつける

［ここに警告メッセージを貼り付け］
［使用サーバー・WordPressのバージョンも書き添える］

逆に、AIに任せてはいけないのは「本番サーバーへの反映そのもの」です。生成された.htaccessをそのまま貼り付けて上書きする、SQLの置換文をそのまま実行する、という進め方は絶対に避けてください。AIは現在のサーバー構成を見ていないので、既存の記述を消したり、リダイレクトを二重にかけたりします。反映前に必ず人がバックアップを取り、1つずつ確認してください。

外注するかどうかの判断軸

自社でやるか、制作会社に頼むかで迷ったら、次の3つで判断してください。

• サーバー情報が揃っているか：管理画面に入れないなら、まず情報の掘り起こしから。ここが一番時間を食う
• サイトの規模と歴史：ページ数が多い、10年以上運用している、複数の会社が触ってきたサイトほど、想定外の記述が残っている
• 止まったときに戻せるか：500エラーになったときに自力で復旧できないなら、営業日の午前中に、相談先を確保したうえで作業する

正直なところ、5〜10ページ程度のシンプルなサイトなら、この記事の手順で自社対応できます。逆に、ECや会員機能がある、外部システムと連携している、といったサイトは、影響範囲の洗い出しの方が本番作業より重くなります。この見極めだけは、作業を始める前にやってください。

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

まずは自社サイトをhttpsで開いてみてください

今日すぐできる最初の一歩は、スマホで自社サイトのURLを「https://」で直接打ち込んで開くことです。開くか、開いても警告が出るか、この1分の確認で今の状況が分かります。

httpsで開けたのに警告が消えない場合は混在コンテンツが残っています。開発者ツールのコンソールで「Mixed Content」と出ている行を1つずつ確認し、httpで読み込まれているファイルを潰していってください。

ここまで読んで、社内に触れる人がいない、あるいはサイトが古くて何が起きるか読めない、と感じた方もいると思います。コレットラボでは、AIを使ったサイト制作・運用の内製化支援を行っており、SSL化のような「一度やれば終わる作業」を自社でこなせる状態づくりから一緒に整理しています。まずは現状を見せていただくだけでも構いません。AI業務システム化の詳細はこちらからお気軽にご相談ください。