この記事は、WordPressのHTTPS切替で取りこぼしを防ぐ確認表です。サーバーごとの設定画面や転送設定の全文を一律に指定するものではありません。契約先のHTTPS手順と併用し、先に検証環境と復旧手段を用意してください。
SSL/TLS証明書を発行しただけでは、HTTPのURLがHTTPSへ統一されるとは限りません。変更順序を誤ると管理画面に入れなくなることがあります。
WORK EDITとしての結論
バックアップ→HTTPSの到達確認→WordPressのURL変更→サーバー転送→内部URLの検証の順で進めます。恒久移行では同じパスを保った301転送を基本にし、構成が分からない場合はホスティングの公式機能を優先します。
向く人
- 証明書を発行済みでHTTPアクセスをHTTPSへ統一したい人
- サーバー種別やホスティングの転送機能を確認できる人
向かない人
- まだ
https://でサイトを開けない人 - CDNやプロキシの構成が不明なまま設定例をコピーしようとしている人
公式情報：HTTPSとWordPressの2つのURL
WordPress公式は、TLS/SSL証明書がサーバーで利用可能ならHTTPSに対応し、利用を強く推奨しています。FORCE_SSL_ADMINは管理画面用で、公開サイト全体のサーバー転送そのものではありません。
「設定→一般」には次の2項目があります。
- WordPressアドレス（URL）：WordPressコアファイルがある場所
- サイトアドレス（URL）：訪問者がサイトへアクセスするアドレス
通常は両方に運用中サイトのHTTPS URLを設定しますが、サブディレクトリ構成では異なる場合があります。WP_HOMEやWP_SITEURLが定義済みなら管理画面から変更できません。
変更前に準備する
- DBとファイルをバックアップする。
- Apache、Nginx、管理型サービス、CDNのどこで転送するか確認する。
- 運用中サイトのHTTPS URLと管理画面を直接開き、証明書を確認する。
wwwあり・なしの正規URLを決める。
WordPress側のURLをHTTPSへ変更する
単一サイトの一般的な構成では「設定→一般」で2つのURLをHTTPSへ変更し、管理画面と公開画面を確認します。定数で管理している場合はwp-config.phpを変更します。旧HTTP URLをDB内で置換するときは、シリアライズを扱える移行手段を使います。
サーバー側でHTTPをHTTPSへ転送する
ApacheではHTTP用VirtualHostでRedirect permanentを使うと301を返せます。.htaccessしか編集できない場合はホスティング公式のrewrite例を使い、WordPress管理範囲の外へ置く必要があるか確認します。
NginxではHTTPを受けるserverブロックでreturn 301を使えます。どちらも正規ホスト名と元のリクエストURIを保つよう設定します。実際の記法と反映方法は、既存設定を確認したうえでサーバーまたはホスティングの公式手順に従ってください。
切替後に確認すること
代表的なHTTP URLをcurl -Iなどでも確認します。
- HTTPが同じパスのHTTPSへ転送され、最終応答が200
- トップ、投稿、画像、CSS、フォーム、管理画面がHTTPS
- canonical、サイトマップ、内部リンクがHTTPS
- 混在コンテンツ、転送ループ、長い転送連鎖がない
Google Search Centralは恒久移行にサーバー側の301または308を案内しています。HTTPからHTTPSへの移行ではChange of Addressツールは不要ですが、サイトマップやインデックス状況は監視します。
WORK EDITの分析：一括変更より段階判定
ここからは運用分析です。証明書、WordPress URL、転送、キャッシュを一度に変えず、段階ごとに確認すると原因を切り分けやすくなります。301はキャッシュされ得るため、転送先を確定してから配布します。
最大の注意点
HTTPSが直接開ける前に、WordPress URLと301転送を同時反映しないことです。CDNやプロキシ環境では転送を行う層を1つに決め、戻す経路も確保します。
未確認事項
特定ホスティング、CDN、証明書サービスの画面、料金、自動更新、プロキシヘッダーは未確認です。例の適用可否は既存設定やマルチサイト構成で変わるため、利用環境の公式手順を優先してください。
次に読む
変更前の復旧手段が未確認なら、先にWordPressのバックアップと復元確認を実施してください。本番反映前に移行を試すなら、WordPressのステージング環境を作る方法で分離方法を確認できます。
