WordPressをSSL化したいのに、「サーバーで無料SSLを有効にすれば終わりなのか」「WordPressのURLはいつ変えるのか」「Search Consoleも設定し直すのか」と迷っていませんか。順番を間違えると、管理画面へ入れない、画像だけ警告が出る、転送が無限に繰り返されるといった問題が起きます。
安全なSSL化では、証明書を使える状態にする、WordPress内のURLをHTTPSへそろえる、HTTPを対応するHTTPSへ恒久転送するという3工程を分けて進めます。先にバックアップと設定記録を残し、HTTPSが正常に応答することを確認してからWordPressのURLを変えるのが基本です。
HTTPSでサイトを開けることを確認する前に、WordPressアドレスとサイトアドレスを変更しないでください。証明書やサーバー設定が未完了だと、公開画面だけでなく管理画面へ入れなくなるおそれがあります。
先に結論｜証明書→URL→転送→確認の順で進める
- 更新や投稿が少ない時間帯を選ぶ
- ファイルとデータベースをバックアップする
- 現在のURL、DNS、CDN、転送、計測設定を記録する
- サーバー側で対象ドメインのSSL証明書を有効にする
- HTTPSでトップ・下層ページ・管理画面が応答するか確認する
- WordPressアドレスとサイトアドレスをHTTPSへ変更する
- 本文・画像・テーマ設定などに残るHTTP URLを安全に更新する
- HTTPから対応するHTTPS URLへ恒久転送する
- canonical、サイトマップ、内部リンク、Search Consoleを確認する
- 表示、ログイン、フォーム、メール、計測を再テストする
途中で問題が出たときに戻せるよう、切り替え直前の状態を残しておきます。バックアップの作成はWordPressバックアップの取り方、実際に戻すときの判断はバックアップから復元する方法を先に確認してください。
SSL化は3つの設定をそろえる作業
| 工程 | 役割 | 未完了だと起きること |
|---|---|---|
| SSL証明書 | ブラウザーとサーバー間で暗号化通信を成立させる | 証明書警告、HTTPSで接続不能 |
| WordPress内のURL | ページ、画像、管理画面がHTTPSを正規URLとして使う | Mixed Content、画像欠落、管理画面の転送不具合 |
| HTTPからの恒久転送 | 古いHTTP URLへの訪問を対応するHTTPS URLへ送る | HTTPとHTTPSが併存し、利用者・計測・検索評価が分散 |
サーバーの「無料SSLを有効化」が完了しても、WordPress本文やウィジェットにHTTPの画像URLが残っていれば完全な移行ではありません。反対に、WordPressのURLだけをHTTPSへ変えても、対象ドメインに有効な証明書がなければ安全に接続できません。
GoogleはURL変更を伴うサイト移転の公式資料でHTTP→HTTPSも移転の一種として扱い、恒久転送、canonical、内部リンク、サイトマップを新しいHTTPS URLへそろえるよう案内しています。証明書の設定だけで終わらせず、サイト全体の正規URLを統一することが重要です。
切り替え前に9項目を保存する
- ファイルとデータベースの完全バックアップ
- 現在のWordPressアドレスとサイトアドレス
- 利用中のドメイン名とwww有無
- DNSレコードとネームサーバー
- サーバー側の転送・.htaccess・Nginx設定
- CloudflareなどCDNの暗号化モードと転送ルール
- Search Consoleのプロパティ種類
- GA4、広告、決済、フォーム、Webhookの登録URL
- 正常表示する主要URLとフォームのテスト結果
設定画面は変更前にスクリーンショットを残し、テキストで現在値も記録します。バックアップは同じサーバー内だけに置かず、少なくとも一つは別の保存先へ置きます。作業中は新しい投稿、商品更新、予約受付などを止めるか、差分が発生する範囲を把握してください。
WordPress本体やプラグインの大型更新、テーマ変更、サーバー移行を同じ日に重ねると、不具合の原因を切り分けにくくなります。必要な更新はWordPressを安全に更新する手順に分け、SSL化とは別の変更として実施しましょう。
手順1｜サーバー側でSSL証明書を有効にする
まず、利用中のレンタルサーバーやCDNの現行マニュアルに従い、実際に使うホスト名へ証明書を設定します。たとえば正規URLが「wwwなし」でも、www付きURLから転送するなら、転送元のホスト名でも証明書警告が出ない構成が必要です。
- 証明書の対象ドメインと有効期限を確認する
- HTTPSでトップページを開く
- 下層ページ、画像、ログイン画面をHTTPSで開く
- 証明書の対象名がアクセス中のホスト名と一致するか確認する
- この段階ではHTTPからの一括転送をまだ有効にせず、HTTPS単体の応答を確かめる
WordPress公式のHTTPS管理資料も、HTTPSを強制する前にサーバー側でSSLと安全な仮想ホストが構成されていることを前提にしています。証明書の発行待ちやDNS反映待ちの間にWordPress URLを変更せず、HTTPSで正常に応答してから次へ進んでください。
手順2｜WordPressの2つのURLをHTTPSへ変える
管理画面の「設定→一般」にある「WordPressアドレス（URL）」と「サイトアドレス（URL）」を確認します。通常は両方を同じHTTPS URLへそろえますが、WordPress本体をサブディレクトリへ置いている構成では異なる場合があります。現在の構成を理解せずに同じ値へ上書きしないでください。
- HTTPS URLをブラウザーからコピーし、入力ミスを避ける
- www有無と末尾のパスを現在の正規構成に合わせる
- 2項目を保存する
- ログインし直し、管理画面と公開画面を確認する
- パーマリンク設定は構造を変えず、そのまま保存して再生成する
入力欄が編集できない場合は、wp-config.phpのWP_HOMEやWP_SITEURLなどで固定されている可能性があります。ここを推測で削除せず、制作会社またはサーバー会社へ現在の定義を確認してください。
手順3｜内部のHTTP URLを安全に更新する
投稿本文、画像、ウィジェット、テーマ設定、CSS、メニュー、フォーム、構造化データに、http://の絶対URLが残ることがあります。最初にサイト内検索やブラウザーの開発者ツールで残存箇所を確認し、対象を限定して更新します。
| 場所 | 確認内容 | 安全な対応 |
|---|---|---|
| 投稿・固定ページ | 画像、ボタン、内部リンク | 対象URLを確認して更新 |
| テーマ・ウィジェット | ロゴ、背景、CSS、HTML | テーマ設定または子テーマで修正 |
| プラグイン設定 | フォーム送信先、Webhook、API | 各プラグインの設定画面で変更 |
| データベース | シリアライズされたURL | 対応ツールまたは移行機能で置換 |
| 外部配信 | 広告、CDN、外部画像 | 配信元がHTTPSへ対応しているか確認 |
データベースを単純なSQLやテキストエディターで一括置換しないでください。テーマやウィジェットの設定には文字数を含むシリアライズデータがあり、不適切な置換で設定を壊すことがあります。バックアップを取り、シリアライズデータに対応した移行機能や信頼できる置換手段を使います。
HTTPSページ内でHTTPの画像・CSS・JavaScriptを読み込むとMixed Contentになります。鍵マークだけで判断せず、ブラウザーのコンソールと複数ページで確認してください。残存箇所の詳しい切り分けはWordPressのMixed Contentを直す方法で確認できます。
手順4｜HTTPを対応するHTTPSへ恒久転送する
HTTPS側の表示と内部URLを確認したら、HTTPの各URLを同じパスのHTTPSへ恒久転送します。旧トップだけを新トップへ送るのではなく、http://example.com/page-a/ならhttps://example.com/page-a/へ送る形です。
- HTTPトップ→HTTPSトップ
- HTTP下層ページ→同じHTTPS下層ページ
- www有無の非正規URL→決めた正規URL
- 画像・PDFなど重要ファイル→対応するHTTPS URL
- 転送は一度で最終URLへ到達し、HTTPやwwwを何段も経由しない
転送はレンタルサーバーの常時SSL設定、Webサーバー設定、CDNの転送機能など、管理している場所の一つに寄せます。同じ目的の転送をサーバー、プラグイン、Cloudflareへ重ねると、ループや多段転送の原因になります。異常が出た場合はリダイレクトループの確認手順へ進んでください。
Cloudflare利用時は2つの接続を分けて確認する
Cloudflareを使うサイトでは、「訪問者→Cloudflare」と「Cloudflare→オリジンサーバー」という2つの接続があります。ブラウザー側がHTTPSでも、オリジン側がHTTPなら、サイト全体が同じ強度で保護されているとは限りません。
Cloudflareは暗号化モードの公式資料で、可能な場合にFullまたはFull（strict）を推奨しています。特にFull（strict）では、オリジン証明書の有効性も検証します。ただし、オリジンサーバーがHTTPSへ対応していない状態でモードだけを変えると接続エラーになります。先にオリジン証明書とHTTPS応答を確認してください。
FlexibleのままオリジンサーバーがHTTPをHTTPSへ強制すると、HTTPとHTTPSを往復するリダイレクトループが起こり得ます。Cloudflareのリダイレクトループの公式説明も確認し、Cloudflareとサーバーのどちらが転送し、Cloudflareがオリジンへどの方式で接続するかを一枚の設定記録にまとめます。
証明書検証で525・526が出る場合は、Cloudflare 525の確認手順とCloudflare 526の確認手順を使い、暗号化モードを無条件に下げる前にオリジン証明書を確認します。
手順5｜canonical・サイトマップ・Search Consoleをそろえる
- 主要ページのcanonicalがHTTPSの自分自身を指すか確認する
- XMLサイトマップにHTTPS URLだけが出るか確認する
- robots.txtやhreflangにHTTP URLが残っていないか確認する
- 内部リンクとメニューをHTTPSへ更新する
- Search ConsoleでHTTPS側の状態を確認する
- HTTPSサイトマップを送信する
- URL検査で主要ページの正規URLとインデックス状態を確認する
Search Consoleのプロパティの公式説明によると、URLプレフィックスプロパティはプロトコルを区別するため、HTTPプロパティしかない場合はHTTPSプロパティを追加します。ドメインプロパティはHTTP・HTTPSやサブドメインをまとめて含みますが、HTTPSだけを詳しく確認したいときはURLプレフィックスも役立ちます。
HTTP→HTTPSの移行では、Search Consoleの「アドレス変更」ツールは使いません。Googleは転送、canonical、サイトマップなどから変更を処理します。切り替え後の表示回数やインデックスは、Search Consoleで記事を改善する見方を参考に監視してください。
切り替え後は8領域を確認する
| 領域 | 確認例 | 異常時の見方 |
|---|---|---|
| 証明書 | 有効期限、対象名、証明書チェーン | ホスト名違い・発行待ちを確認 |
| 転送 | HTTP、www有無、下層URL | 最終URLまでの回数を確認 |
| 公開表示 | トップ、記事、画像、CSS、スマホ | Mixed Contentとキャッシュを確認 |
| 管理 | ログイン、編集、画像アップロード、更新 | CookieとWordPress URLを確認 |
| 送信 | 問い合わせ、会員登録、パスワード再設定 | 送信先URL・メール設定を確認 |
| 外部連携 | 決済、Webhook、API、SNSログイン | 登録済みコールバックURLを確認 |
| SEO | canonical、サイトマップ、Search Console | HTTP残存・noindexを確認 |
| 計測 | GA4リアルタイム、広告、タグ | データストリームと参照元を確認 |
トップページに鍵マークが出ただけでは完了ではありません。古い記事、画像の多い記事、フォーム、ログイン、404ページまで確認し、HTTPから直接開いた場合も最終的に正しいHTTPS URLへ一度で到達することを見ます。
よくある失敗と戻し方
| 症状 | 主な確認場所 | 最初の対応 |
|---|---|---|
| 管理画面へ入れない | WordPress URL、証明書、Cookie、定数 | 変更前の値とHTTPS応答を照合 |
| 画像・装飾が消える | Mixed Content、CSS、CDN、キャッシュ | 失敗URLを一つ保存して発生元を特定 |
| 転送が繰り返される | サーバー、プラグイン、Cloudflare | 転送を一か所ずつ確認 |
| 証明書警告が出る | 対象ホスト名、有効期限、中間証明書 | 証明書を直し、警告を無視して公開しない |
| 検索にHTTPが残る | 転送、canonical、サイトマップ、内部リンク | 信号をHTTPSへ統一して再クロールを待つ |
問題が出たら、変更を重ねてごまかさず、発生時刻、対象URL、転送経路、エラー文を保存します。復旧に必要な範囲だけを戻し、証明書、WordPress URL、転送のどこで失敗したかを切り分けます。
WordPressのSSL化に関するよくある質問
SSL化プラグインは必須ですか？
必須ではありません。レンタルサーバーとWordPressの標準機能で対応できる場合もあります。プラグインを使う場合も、証明書を発行するもの、内部URLを直すもの、転送するものの役割を分け、同じ設定を重複させないでください。
SSL化で検索順位は下がりますか？
URLがHTTPからHTTPSへ変わるため、Googleの再クロール中に表示が変動する可能性はあります。順位維持を保証はできませんが、一対一の恒久転送、HTTPS canonical、内部リンク、サイトマップをそろえることで、移行を正しく伝えられます。
Search Consoleのアドレス変更は必要ですか？
HTTP→HTTPSだけの変更では使いません。URLプレフィックスプロパティを使っている場合はHTTPS側を追加し、HTTPSサイトマップと主要URLを確認します。ドメイン名そのものを変える場合は、別の手順が必要です。
HSTSもすぐ有効にした方がよいですか？
SSL化直後の必須作業とは分けて考えます。HSTSはブラウザーへHTTPS利用を強く指示するため、証明書、サブドメイン、転送、更新体制が安定してから検討します。設定内容を理解せず長期間・全サブドメインへ適用しないでください。
まとめ｜HTTPSで開けることを確認してからURLを切り替える
WordPressのSSL化は、無料SSLのボタンを押すだけの作業ではありません。証明書、WordPress URL、HTTPからの恒久転送を順番にそろえ、内部URL、Mixed Content、canonical、サイトマップ、Search Console、フォーム、計測まで確認して完了です。
- 変更前のバックアップと設定記録を残す
- HTTPS単体の応答を確認してからWordPress URLを変える
- 内部URLを安全な方法で更新する
- HTTPを対応するHTTPSへ一対一で転送する
- Cloudflare利用時は2接続を分ける
- 公開表示だけでなく送信・計測・検索状態も確認する
まずは現在のWordPress URL、サーバーのSSL状態、Cloudflare利用有無を書き出してください。どこでHTTPSを終端しているか分からない場合は、URLを変更する前にサーバー会社へ構成を確認するのが最も安全です。