WordPressサイトの常時SSL化を完了させる手順

常時SSL化（サイト全体のHTTPS化）は、セキュリティとSEOの双方に効く基礎施策でございます。本記事では、WordPressサイトを安全に常時SSL化するための具体的な手順を、つまずきやすい論点も含めて整理いたします。

この記事でわかること

• 常時SSL化の効果と、未対応のリスク
• SSL証明書の取得方法（無料・有料の選び方）
• WordPress側で必要な3つの設定変更
• 混在コンテンツ（Mixed Content）の解消手順
• 常時SSL化完了の判定基準

目次

1. 常時SSL化とは何か
2. SSL証明書の取得
3. WordPressの設定変更
4. サイト全体のリダイレクト設定
5. 混在コンテンツの解消
6. 常時SSL化完了の判定
7. 関連事例としての学び
8. まとめ

常時SSL化とは何か

常時SSL化とは、ウェブサイトの全ページをhttps://で配信する状態にすることでございます。SSL（正確にはTLS）による通信の暗号化により、閲覧者とサーバー間の通信が第三者に傍受されにくくなります。

2020年以降、主要ブラウザはhttp://で接続されたページに対し「保護されていない通信」という警告を表示するようになっており、未対応のサイトは閲覧者の信頼を損ねるリスクが大きくなっております。また、Googleは検索ランキング要因としてもHTTPSを評価しているため、SEO上も常時SSL化は基本要件でございます。

SSL証明書の取得

常時SSL化の最初の関門が、SSL証明書の取得です。証明書には複数の種類がございますが、コーポレートサイトやお役立ち情報サイトであれば、無料のドメイン認証型で十分です。

主要レンタルサーバーの自動証明書

日本国内の主要レンタルサーバー（エックスサーバー、ConoHa WING、さくらインターネット、ロリポップ、mixhost等）には、Let’s Encryptまたは独自の無料SSL機能が標準搭載されております。サーバー管理画面から数クリックで取得・有効化が可能で、有効期限の自動更新まで標準対応しているため、追加費用なしで導入できます。

有料証明書を検討すべきケース

個人情報を扱う、または法人としての信頼性を強く打ち出したい場合は、企業認証型（OV）や拡張認証型（EV）の有料証明書を検討する余地がございます。ただし表示上の差は近年ほぼ消えており、一般的なコーポレートサイト・ブログでは無料証明書で十分でございます。

WordPressの設定変更

SSL証明書がサーバー側で有効化された後、WordPress側で次の設定変更を行います。

① 一般設定でURLを変更

管理画面の「設定 → 一般」を開き、次の2つの値をhttpからhttpsに変更します。

• WordPress アドレス (URL)
• サイトアドレス (URL)

変更を保存すると、いったんログアウト状態となります。再度ログインし、URLがhttps://になっていることを確認してください。

② wp-config.php に強制https記述（任意）

管理画面の値を直接データベースから書き換えるのではなく、wp-config.phpで定数として定義する方法もございます。サーバー移転やトラブル時に確実に動作する点で安全度が高い手法です。

define('WP_HOME', 'https://example.com');
define('WP_SITEURL', 'https://example.com');

// 管理画面のSSL強制
define('FORCE_SSL_ADMIN', true);

③ 投稿コンテンツ内のhttp URLを置換

過去の投稿に含まれる絶対URL（画像・リンク等）は、データベース上でhttp://example.comのまま残っております。これを一括でhttps://に置換する必要がございます。

WP-CLIをご利用の場合、次のコマンドが最も簡単で確実です。

wp search-replace 'http://example.com' 'https://example.com' --all-tables --skip-columns=guid

--skip-columns=guidを必ず指定する点が重要でございます。投稿のGUIDは識別子であり、書き換えるとRSSフィード購読者に重複配信されるなどの副作用があります。

WP-CLIが使えない環境では、「Better Search Replace」などのプラグインを利用して同様の置換を実施できます。実施前には必ずデータベースのバックアップを取得してください。

サイト全体のリダイレクト設定

WordPressのURL設定だけでは、まだhttp://example.comへ直接アクセスされた場合に旧URLのままで動作してしまいます。サーバー側で「httpへのアクセスをhttpsへ恒久的にリダイレクト」する設定を追加します。

.htaccess に追記

サイトのドキュメントルートにある.htaccessに、次の記述をWordPressブロックよりも前に追加します。

# http → https へ恒久リダイレクト
<IfModule mod_rewrite.c>
RewriteEngine On
RewriteCond %{HTTPS} off
RewriteRule ^(.*)$ https://%{HTTP_HOST}/$1 [R=301,L]
</IfModule>

# BEGIN WordPress
...
# END WordPress

サーバー管理画面に「常時SSL設定」「http→https自動リダイレクト」といった項目がある場合は、そちらを有効化するだけで同等の効果が得られます。

Really Simple SSL プラグインを使う方法

サーバー側に直接触りたくない場合、「Really Simple SSL」というプラグインで上記処理をまとめて代行することも可能です。WordPress内部のURL書き換えと、リダイレクト設定の両方を一括対応してくれるため、初心者の方には扱いやすい選択肢でございます。

ただし、プラグイン依存度が高くなる点と、サーバー側で同様の設定をしている場合に二重リダイレクトとなる可能性がある点はご注意ください。

混在コンテンツの解消

常時SSL化を進めると、しばしば「混在コンテンツ（Mixed Content）」の警告が表示されます。これは、httpsで配信されているページの中に、httpで読み込まれる画像・スクリプト・スタイルシートなどが含まれている状態です。

混在コンテンツの検出

ChromeのF12開発者ツールを開き、「Console」タブを表示した状態でページを再読み込みすると、混在コンテンツの警告が次のように表示されます。

Mixed Content: The page at 'https://example.com/' was loaded over HTTPS, but requested an insecure image 'http://example.com/image.jpg'.

これらをひとつずつ確認し、httpになっている部分をhttpsに書き換える必要がございます。

解消の手順

1. 投稿本文中のhttp参照 → wp search-replaceで一括置換（上記参照）
2. テーマ・プラグインのソースコード中のhttp参照 → 該当ファイルを編集
3. 外部CDNからの読み込み → CDNがhttpsに対応していることを確認、対応していなければ提供元を変更
4. ウィジェットやカスタムHTMLブロック内のリンク → 管理画面で個別に修正

混在コンテンツが残っていると、ブラウザがアドレスバーに「保護されていない通信」と表示するため、せっかく常時SSL化しても効果が半減いたします。

常時SSL化完了の判定

すべての設定が正しく完了したかどうかは、次の3点でご確認ください。

① ブラウザのアドレスバーに鍵マーク

主要ページ（トップ・記事詳細・カテゴリページ・固定ページ・お問い合わせフォーム）にアクセスし、アドレスバーの左に鍵マークが表示されることを確認します。「保護されていない通信」「!」マークが出る場合は、混在コンテンツが残っている可能性が高いです。

② SSL Server Test での評価

Qualys SSL Labsの「SSL Server Test」（https://www.ssllabs.com/ssltest/）にサイトのURLを入力すると、SSL設定の総合評価が確認できます。A以上の評価が出れば、現代的なブラウザでは問題なく動作する水準でございます。

③ Search Console での認識

Google Search Consoleでは、httpsとhttpを別サイトとして扱います。常時SSL化後は、httpsプロパティを新規に登録し、サイトマップを送信し直す必要がございます。インデックスがhttps版に切り替わるまでには数週間かかる場合がありますが、これも完了の指標の1つです。

関連事例としての学び

弊社が支援しているクライアントサイトで、常時SSL化を実施したのに「保護されていない通信」が消えないというご相談を受けたことがございました。調査の結果、原因は次の2点でした。

1. 過去にコピーペーストで貼り付けられたYouTube動画の埋め込みコードに、httpのURLが残っていた
2. 外部のフォントサービスをhttp://から読み込むウィジェットが、サイドバーに設置されていた

WP-CLIによる一括置換だけでは検出できない、ウィジェット内のカスタムHTMLや、外部サービスの埋め込みコードが原因となっていたわけです。最終的に、ブラウザのF12開発者ツールで混在コンテンツを一つひとつ特定し、該当箇所を修正することで完全解消いたしました。

本事例の教訓は、「wp search-replaceは強力だが、すべてを置換できるわけではない」という点です。常時SSL化後は、必ずブラウザの開発者ツールでConsoleを開き、混在コンテンツ警告がゼロであることを確認することが大切でございます。

まとめ

WordPressサイトの常時SSL化の手順を整理しますと、次の流れになります。

1. サーバー側でSSL証明書を取得・有効化（Let’s Encrypt推奨）
2. WordPress管理画面でサイトURLをhttpsに変更
3. WP-CLIで投稿コンテンツのhttp URLを一括置換
4. .htaccess で http→https リダイレクトを設定
5. 混在コンテンツを開発者ツールで確認・解消
6. Search Console にhttpsプロパティを登録

これらの手順は、半日〜1日程度の作業で完了するケースが多いですが、古いサイトでは混在コンテンツの修正に予想以上の時間がかかることもございます。本番反映前に検証環境で一通り試し、問題がないことを確認してから本番に適用することをおすすめいたします。

SSL化作業に不安がある場合や、リダイレクトループといったトラブルが発生した場合は、無理に対処せず、サイトのバックアップを取得した状態でご相談ください。