X（旧Twitter） 
Facebook 
LINE 
投稿日：2026.01.30 最終更新日：2026.01.30
WordPressのSSL化は必須｜5ステップ手順と見落としがちな注意点
ブラウザに「保護されていない通信」と表示されるWordPressサイトを見て、「設定を間違えてサイトが止まったら…」と不安に感じていませんか。
SSL化（HTTPS化）は、現代のWebサイト運営で避けて通れない基本対策です。
ただし、見落としてはいけない重要なポイントがあります。
SSL化しただけでは、WordPressサイトは完全に安全とは言えません。
この記事では、SSL化の具体的な手順から、よくあるトラブルの対処法、そして「SSL化だけでは不十分」という専門家の視点まで、WordPress SSL化の全体像を解説します。
この記事でわかること
- SSL/TLSとHTTPSの違い（基本知識）
- SSL化しない場合の3つのリスク
- 失敗しないSSL化の5ステップ手順
- Mixed Contentなどトラブルの対処法
- SSL化後に必要なセキュリティ対策
この記事を書いた人
みらいと
セキュリティサービス事業部 コンサルタント／プログラマーからシステム運用を経て情報セキュリティ全般の業務に従事。現在は培った情報セキュリティの経験を活かしお客様の課題に向き合った企画やマーケティングを担当。
目次
SSL/TLSとHTTPSって何が違う？基本を整理する
まず、用語を整理しておきましょう。
SSL化（HTTPS化）とは、「Webサイトの通信を暗号化して、URLをhttp://からhttps://に統一する作業」のことです。
SSL/TLSは暗号化技術、HTTPSは暗号化された通信
SSL/TLSとHTTPSは、よく混同されますが役割が違います。
SSL/TLSは、インターネット上でデータを暗号化して送受信するための技術です。
一般には「SSL」と呼ばれることが多いですが、正確にはSSLとその後継規格であるTLSの総称です。
一方、HTTPSは、そのSSL/TLSを使ってHTTP通信を安全に行うための仕組み。
つまり、SSL/TLSが通信の暗号化技術そのもので、HTTPSはその技術を使った「セキュア版HTTP」です。
HTTP通信は平文（暗号化なし）で流れるため、盗聴や改ざんのリスクがあります。
しかし、HTTPSでは違います。
SSL証明書に含まれる公開鍵でデータを暗号化し、対応する秘密鍵を持つサーバだけが復号できる仕組みになっています。
そのため、安全性が飛躍的に高まるわけです。
WebサイトがHTTPS対応になると、URLの先頭は「http://」から「https://」に変わり、主要ブラウザではアドレスバーに鍵アイコン（錠前マーク）が表示されます。
ユーザーから見ても、サイトの安全性が視覚的に分かるため、信頼感が高まります。
無料SSLで十分｜暗号化強度は有料と同じ
SSL証明書には「無料」と「有料」があります。
多くの場合、WordPressサイトでは無料SSL（Let’s Encrypt）で十分です。
なぜなら、暗号化強度は無料でも有料でも同じだからです。
無料SSL（Let’s Encryptなど）はドメイン認証（DV）で、「そのドメインの所有者であること」だけを確認します。
発行も即時～数分程度と手軽。
一方、有料SSLには企業認証（OV）や拡張認証（EV）があり、企業の実在性（社名・所在地など）を審査して発行されます。
そのため、ECサイトや金融機関サイトなど、信頼証明を強く打ち出したい場合に力を発揮します。
証明書の種類を表にまとめます。
| 証明書の種類 | 認証内容 | 発行時間 | 費用目安 | 用途 |
|---|---|---|---|---|
| ドメイン認証（DV） | ドメインの所有権のみ | 即時～数分 | 無料～安価 | 個人ブログ・小規模サイト |
| 企業認証（OV） | 企業の実在性確認 | 数日～数週間 | 数万円/年～ | 企業公式サイト |
| 拡張認証（EV） | 企業の厳格な審査 | 数日～数週間 | 10万円以上/年～ | 金融機関・EC |
SSL化にかかる時間と費用は？｜DVなら無料で1〜2時間が目安
エックスサーバー、さくらインターネット、ロリポップなど、主要レンタルサーバーが無料SSL（Let’s Encrypt）を標準提供しています。
無料の場合、SSL化にかかる時間は1〜2時間が目安。
証明書の発行自体は数十分以内で完了します。
WordPress側のURL変更やリダイレクト設定も、プラグイン利用で1〜2時間ほどで完了します。
証明書は90日ごとに自動更新されるため、維持費も手間もかかりません。
SSL化しないとどうなる？｜SEO・信頼・セキュリティの3つのリスク
SSL化は「やると得」というより、「やらないと困る」を避ける意味が大きい対策です。
代表的なリスクを3つに整理します。
Googleの検索順位で不利になる｜「上がる」より「下がらない」ために必須
Googleは2014年に「HTTPSを検索順位のシグナルに使用する」と公式発表し、現在もこの評価は継続しています。
影響は軽微とされていますが、HTTP版とHTTPS版が両方存在する場合、HTTPS版が優先的にインデックス登録される仕組みが実装されています。
つまり、「SSL化したから劇的に順位が上がる」のではありません。
「SSL化していないと相対的に不利になる」という位置づけです。
「保護されていない通信」の警告でユーザーが離脱する
現在、Chrome、Firefox、Edgeなど主要ブラウザは、HTTP接続のページに対して警告を表示します。
特にChromeは2017年以降段階的に警告を強化してきました。
現在ではあらゆるHTTPページで「保護されていない通信」という表示が出る仕様になっています。
ユーザーにとって、これは直感的に「このサイトは安全ではない」というメッセージ。
離脱の大きな要因です。
米国のユーザー調査では、ブラウザに「Not Secure」と表示された場合、約半数のユーザーが情報入力を避け、そのうちの約6割が即座にサイトを離脱するという結果が出ています。
その結果、お問い合わせや資料請求といったコンバージョン機会を逃すだけでなく、ブランド全体の信頼低下にもつながってしまうわけです。
フリーWi-Fiで通信内容が丸見えになる危険性
暗号化されていないHTTP通信は、同じネットワーク上の第三者に内容を傍受されるリスクがあります。
たとえばカフェや公共施設のフリーWi-Fiでは、多くの場合通信が暗号化されていません。
そのため、悪意ある攻撃者がスニッフィングツールで通信パケットを盗み見ることができてしまいます。
HTTPサイトでフォームに入力された情報（氏名・住所・パスワードなど)は、ネットワーク上で「丸見え」の状態となります。
これは、例えるなら、人混みの中でクレジットカード番号を大声で読み上げるようなもの。
また、HTTP通信ではCookie（ログインセッションIDなど）も盗聴される可能性があります。
攻撃者がユーザーになりすましてログインする（セッションハイジャック）恐れがあるわけです。
さらに、通信内容を改ざんして悪質なスクリプトを混入させる（中間者攻撃）こともできます。
SSL化は、今や必須です。
フォームやログインがあるサイトなら、なおさらです。
WordPressをSSL化する5つの手順
ここまでSSL化の重要性を解説しました。
ここからは、実際にWordPressサイトをSSL化する具体的な手順を順番に説明します。
【事前準備】バックアップを取らずに進めると取り返しがつかない
SSL化作業前には必ずWordPressサイトのバックアップを取得してください。
SSL化ではサイトURLの変更や設定ファイルの編集を行います。
ミスが起これば、サイト表示不具合やログイン不能といったトラブルが起こってしまいます。
「BackWPup」や「UpdraftPlus」といったプラグインを使えば、データベースやファイルの自動バックアップを簡単に設定できます。
エックスサーバーなど一部サーバーではサーバー側でバックアップを取っていますが、復元に手数料がかかる場合もあります。
自前でのバックアップ取得は必ずするようにしましょう。
①サーバーパネルから無料SSL証明書を有効化する
レンタルサーバーのコントロールパネルから無料SSL証明書を有効化します。
エックスサーバーの場合
サーバーパネルの「SSL設定」から対象ドメインを選択し、「独自SSL設定追加」タブで証明書を申請します。
証明書が有効になるまで5分～最大1時間程度待機します（通常は数十分以内）。
その後、「https://～」でアクセスし、錠前マークが付くか確認します。
他のサーバーでも流れは同じです。
管理画面から「無料SSL」や「独自SSL」といった項目を探して設定すれば、同様に証明書を取得できます。
Let’s Encryptなどの無料証明書は有効期限90日ですが、サーバー側で自動更新されます。
②WordPress管理画面で2箇所のURLを変更する
WordPress管理画面の「設定」→「一般」を開きます。
「WordPressアドレス (URL)」と「サイトアドレス (URL)」の両方を「http://～」から「https://～」に書き換えます。
先頭の「http」を「https」に変更するだけで、ドメイン名以下は変更しないでください。
保存すると自動的にログアウトされます。
新しいHTTPSのURLで再ログインし、両方のURL欄が「https://～」に更新されていることを確認します。
重要
2箇所が不一致だとリダイレクトループやコンテンツ表示エラーが発生します。
必ず2箇所とも同時にhttpsへ変更してください。
③httpアクセスを自動的にhttpsへ転送する
HTTP→HTTPSへの移行後は、古い「http://～」でアクセスされた場合も自動的に「https://～」に誘導する301リダイレクト設定が必要です。
これを設定しないと、ユーザーが旧URLで来た場合に非SSLページが表示されます。
コード編集に不慣れな場合は、プラグイン「Really Simple SSL」などをインストールして有効化すれば、自動的にHTTPからHTTPSへのリダイレクトが実装されます。
プラグインを使わない場合は、「.htaccess」ファイルに以下のコードを追加します。
RewriteEngine OnRewriteCond %{HTTPS} !onRewriteRule ^(.*)$ https://%{HTTP_HOST}%{REQUEST_URI} [R=301,L]
エックスサーバーではサーバーパネルの「.htaccess編集」から設定できます。
注意
エックスサーバーで「HTTPS転送ON」を有効にしている場合、.htaccessでの設定は不要です（二重設定は不具合の原因）。
設定後、httpでアクセスしてもhttpsに転送されるか全ページ確認してください。
④Mixed Content（混在コンテンツ）をなくす
Mixed Contentとは、ページ自体はHTTPSなのに、ページ内の一部リソース（画像やスクリプトなど）のURLがHTTPのまま混在している状態です。
この状態では、ブラウザのアドレスバーに鍵アイコンが表示されず、コンソールに「Mixed Content」警告が表示されます。
典型的には、記事内の画像や外部JS/CSSのURLが「http://」で始まっている場合です。
データベース内の既存URLは自動では書き換わらないため、残存リンクがMixed Contentを引き起こします。
Really Simple SSLプラグインの「混在コンテンツ修正」機能を有効にすると、サイト内のhttpリンクを自動的にhttpsへ変換してくれます。
まずはこのプラグインを有効にして動作を確認してください。
また、「Search Regex」や「Better Search Replace」を使えば、データベース上の全コンテンツから「http://あなたのドメイン」を「https://あなたのドメイン」に一括置換できます（事前にDBバックアップ推奨）。
手動で確認する場合は、ChromeのF12キー→「Console」タブで、どのリソースがhttpなのか特定できます。
Mixed Contentの警告が一つも出なくなるまで繰り返します。
⑤全ページで鍵アイコンが表示されるか確認する
SSL化作業の最後に、全体が正しく機能しているか確認します。
確認項目
- リダイレクト動作：
トップページだけでなく下層ページも「http://～」でアクセスし、確実に「https://～」に転送されるか確認 - ブラウザ表示：
アドレスバーに錠前マークが表示されているか確認（「保護されていない通信」が出る場合はMixed Contentが残っています） - コンテンツ・機能：
画像・スタイル・スクリプトが正しく読み込まれ、お問い合わせフォームなど動的機能も正常に動作するかテスト - Search Console登録：
Google Search ConsoleにHTTPS版サイトを新たに登録し、サイトマップを送信（SEO上非常に大事な手順）
一定期間後、GoogleがHTTP→HTTPSの301を検知し、検索インデックスをHTTPS優先に切り替えます。
SSL化でよくあるトラブルと対処法
代表的なトラブルを「症状→原因→対処法」で整理します。
Mixed Contentエラーで鍵アイコンが表示されない
SSL化後にアドレスバーの鍵アイコンが表示されず、ChromeのConsoleに「Mixed Content」警告が出る場合があります。
これは、サイト内の画像URL・スクリプトURLなどに「http://」が残っていることが原因です。
データベース内のコンテンツは自動では書き換わらないので、過去投稿のリンクがそのまま残っています。
対処方法
- ChromeのConsole（F12）で原因のURLを特定
- Really Simple SSLプラグインの「Mixed content fixer」を有効化
- または「Search Regex」プラグインで「http://あなたのドメイン」を「https://あなたのドメイン」に一括置換
- 警告が消えるまで全ページを確認
リダイレクトループで延々と読み込み中になる
「ERR_TOO_MANY_REDIRECTS」エラーが表示され、ページが表示されない場合があります。
これは、転送ルールの二重設定（サーバー側とプラグイン側で同じ転送設定）や、「サイトアドレス」と「WordPressアドレス」の不一致が原因です。
対処方法
- リダイレクト設定を一箇所だけにする（サーバー設定かプラグインかどちらかに統一）
- 「設定→一般」でサイトアドレスとWordPressアドレスがhttpsで一致しているか確認
- ログインできない場合は、「wp-config.php」に以下を追記define(‘WP_HOME’,’https://あなたのドメイン’);define(‘WP_SITEURL’,’https://あなたのドメイン’);
- ブラウザのCookieとキャッシュを削除して再アクセス
管理画面にログインできなくなった
正しいID/パスワードを入れてもログイン画面に戻ってしまう、または404エラーやリダイレクトループでダッシュボードに入れない場合があります。
これは、WordPress一般設定でサイトURLを誤って入力した、または「https://～」と「http://」が混在していることが原因です。
対処方法
- 「wp-config.php」にサイトURLを直接指定：
define(‘WP_HOME’,’https://あなたのドメイン‘);define(‘WP_SITEURL’,’https://あなたのドメイン‘); - FTPでアップロード後、「https://あなたのドメイン/wp-login.php」にアクセス
- ログインできたら一般設定で値を確認・修正し、「wp-config.php」に追加した行は削除
- それでもダメな場合は、phpMyAdminで「wp_options」テーブルの「siteurl」と「home」を直接書き換え
- ブラウザのCookieとキャッシュを削除して再ログイン
SSL化しただけではWordPressは安全ではない
SSL化は完了しても、WordPress運用では別の経路から攻撃を受ける可能性があります。
SSL化の役割は「通信の暗号化」のみ｜防げない3つのリスク
SSL/TLSによるHTTPS化は、ユーザー～サーバー間の通信経路を暗号化し、盗聴・改ざん・なりすましを防ぐという役割を果たします。
しかし、SSLが守るのは通信データだけです。
ウェブサイト自体やサーバ上のアプリケーションの脆弱性を防ぐものではありません。
SSLでは防げない主なリスク
- WordPress本体・プラグイン・テーマの脆弱性：
古いバージョンのまま放置すると、既知の脆弱性を突かれてサイト改ざんやデータ窃取のリスクがあります - 不正ログイン（ブルートフォース攻撃など）：
HTTPS通信でも、弱いパスワードや対策不足があれば、総当たり攻撃で突破される恐れがあります - 代表的なWeb攻撃（SQLインジェクション・XSSなど）：
SSLは攻撃コードも暗号化して運ぶだけなので、アプリケーションの論理的な脆弱性には無力です
関連記事
WordPressのセキュリティ対策、何から始める？まずやるべき5つの対策
WordPressのセキュリティ対策、何から始めればいいか分からない。 調べると「更新」「バックアップ」「プラグイン」「パスワード」といろいろ出てくるけれど、全部やるのは無理。 セキュリティ対策が進まないのは、「これだけはやっておくべき」という最低ラインが見えないからです。 まずは最優先のもの
関連記事
WordPress不正ログイン対策｜まず塞ぐべき7項目を優先度別に解説
WordPressのセキュリティ対策記事、読んだことありますか？ 「やることが多すぎて、結局どこから手をつければいいのか分からない」 そう感じた経験がある方も多いのではないでしょうか。 実は、不正ログイン対策には明確な優先順位があります。 すべてを一度にやる必要はありません。 この記事では
関連記事
WordPressの脆弱性を診断する3つの方法と専門家が教える対策
インターネットの普及に伴い、多くの企業や個人がウェブサイトを運営しています。 中でもWordPressは、世界中で広く利用されているコンテンツ管理システム（CMS）です。 しかし、その人気が裏目に出て、WordPressサイトは常にサイバー攻撃の標的となりやすいという問題があります。 しかし、
私たちIFTの診断実績でも、SSL化済みサイトで「プラグインの更新漏れ」や「管理画面への不正アクセス試行の痕跡」が多く見つかります。
SSL・WAF・診断ツールの違いを理解する
SSL化後のセキュリティ対策を考える際、SSL、WAF、診断ツールの違いを理解しておくことが大事です。
| 対策 | 役割 | 守る対象 |
|---|---|---|
| SSL/TLS | 通信経路を暗号化し盗聴・改ざんを防止 | ユーザーとサーバ間のデータ |
| WAF | 悪意あるリクエストを遮断し攻撃から防御 | Webサーバ/アプリへの攻撃トラフィック |
| 脆弱性診断ツール | サイト内の脆弱性を発見し事前に対処 | Webアプリ自体の弱点 |
重要なポイント
- SSLは通信内容の保護（暗号化）が役割で、サイト内部の脆弱性や攻撃ブロックは担当しない
- WAFはリアルタイムに攻撃トラフィックをブロックする役割
- 脆弱性診断ツールはサイトの弱点を洗い出す役割
SSL化だけでは不十分で、WAFや診断ツールなど多層的な対策が必要です。
WAFについてもっと詳しく知りたい方は、以下の記事で解説しています。
関連記事
WordPressにWAFは必要か？サイトのリスクレベルで決める判断基準と選び方
「WordPress WAF」で検索してこの記事にたどり着いたあなたは、WAFという言葉は知っていても、こんな疑問を抱いていませんか？ 「自分のサイトに本当に必要なのか」 「どの種類が良いのか」 「導入した後、運用で詰まらないか」 WAFは強力な防御手段です。しかし万能ではありません。 判
SSL化の次にやるべき6つのセキュリティ対策
SSL化の次に最低限やるべきことを整理します。
- WordPress本体・プラグイン・テーマの常時アップデート：
既知のセキュリティホールを修正し、攻撃リスクを下げる - 強力なパスワードとログイン保護：
推測困難なパスワード設定、ログイン試行制限プラグイン導入、二要素認証の実装 - 不要な機能・ファイルの削除：
使っていないプラグインやテーマを削除し、潜在的な脆弱性を減らす - WAFの導入：
外部からの攻撃トラフィックをリアルタイムに監視・遮断 - 定期的な脆弱性診断：
専門家による診断で自社では気付けない穴を発見・修正 - バックアップ＆緊急対応準備：
万一の事態に備えた復旧手順の確立
このように、セキュリティ対策では、SSL化以外にも多面的な対策が必要です。
もし自力で難しければ、専門家に相談することも検討してください。
IFTでは、WordPress本体・プラグイン・テーマの脆弱性チェック、設定ミスの検出、実際の攻撃シミュレーションを組み合わせた、トータルでの診断を提供しています。
診断後の修正支援や継続的な監視サービスもあり、SSL化後のさらなる安全対策をサポートします。
「設定が合っているか自信がない」「どこを見ればいいか分からない」という場合は、管理画面の設定を専門家がチェックするサービスもご用意しています。
＼＼管理画面の設定を専門家がチェック／／
まとめ：WordPressのSSL化はセキュリティ対策がセット
SSL化（HTTPS化）は、無料で1〜2時間で完了し、SEOでの不利や通信盗聴のリスクを避けられる基本対策です。
この記事のポイント
- 無料SSLで十分。費用0円で1〜2時間が目安
- SSL化は5ステップ（証明書→URL→転送→混在→確認）
- 混在コンテンツや転送ループは原因を切り分ける
- SSLは通信の暗号化だけ。弱点は別で塞ぐ
- 更新・ログイン対策・WAF・診断で守りを重ねる
この記事で解説した5つのステップに従えば、失敗せずにSSL化を完了できます。
ただし、SSL化は通信の暗号化に過ぎません。
WordPress本体・プラグイン・テーマの更新、強固なパスワード、ログイン制限、WAF、定期診断など、継続的な対策が必要です。
IFTでは、WordPress本体・プラグイン・テーマの脆弱性チェック、設定ミスの検出、実際の攻撃シミュレーションを組み合わせた、トータルでの診断を提供しています。
診断後の修正支援や継続的な監視サービスもあり、SSL化後のさらなる安全対策をサポートします。
もし「SSL化は完了したが、この先どう対策すればよいか分からない」とお困りであれば、ぜひご相談ください。
