結論から言うと、wpX Speedで常時SSL化するときの主経路は、wpX管理パネルで対象WordPressの「独自SSL設定」を追加し、その後に同じ画面の「SSL化補助機能」を必要な項目だけ実行する方法です。通常作業としてWordPress管理画面の「WordPressアドレス」や「サイトアドレス」を先に直接書き換える必要はありません。先にバックアップと現状記録を取り、HTTPS単体、混在コンテンツ、HTTPからの転送を順に確認すると、障害時に戻す位置を特定できます。
最初に確認するwpX固有の制約
wpX Speedの無料独自SSLはLet’s Encryptを利用します。短期間に独自SSLの追加と削除を繰り返すと、Let’s Encrypt側の制限により約1週間そのドメインへ再追加できない場合があります。試験のたびに証明書を削除する運用は避け、証明書を有効にしたまま転送やコンテンツ側を切り分けます。
wpXが発行する独自SSLはWebサイトのHTTPS接続用です。他社証明書を持ち込む手順ではありません。外部サーバーから移転中の場合は、ドメイン追加後、ネームサーバーを切り替える前に、公式マニュアルのWeb認証またはDNS認証で事前設定します。移行データとSSLが準備できる前にDNSを切り替えると、表示停止の原因になります。
独自SSLの追加直後に「設定の反映待ちか、存在しないアドレスです」と出ても、直ちに設定を削除しません。wpX公式FAQでは最大15分程度待ち、ブラウザーキャッシュを消して再確認するよう案内しています。待機中にURL設定を重ねて変更すると、反映待ちと設定不良を区別できなくなります。
変更前に保存するもの
安全な確認は、変更前のサイトがHTTPで正常に表示され、WordPressへログインできることを確かめるところから始まります。障害が既にある状態でSSL化すると、新旧どちらの原因か判断できません。作業時間、対象ドメイン、wwwあり・なしの正規URL、現在のHTTPステータス、管理画面への入口を作業記録へ残します。
- wpX管理パネルの「データベースのエクスポート・インポート」からSQLまたはgzを取得し、ファイルが開けることと取得時刻を確認する。
- FTP等でwp-contentを退避し、使用中のテーマ、プラグイン、アップロード画像を同じ時点で保存する。
- 現在の.htaccess、リダイレクト系プラグイン、キャッシュ設定、CDNや外部DNSの転送設定を画面記録または設定ファイルで保存する。
- トップ、投稿、固定ページ、検索、問い合わせ、ログイン、REST API、外部決済など代表URLを検証表にする。
- 広告、解析、Webフォント、画像、JavaScript、CSSなど外部ホストから読む資源がHTTPSに対応するか確認する。
自動バックアップがある場合でも、それだけを直前バックアップの代わりにしないでください。取得時刻が作業直前とは限らず、データベースとファイルの世代がずれることがあります。自分で取得したSQLとwp-contentを同じ作業番号で管理し、戻す組み合わせを明確にします。
wpX管理パネルで独自SSLを追加する
- 管理パネルへログインし、「WordPress管理」から「インストール済みWordPress一覧」を開く。
- 対象WordPressの「設定」を選び、「セキュリティ設定」内の「独自SSL設定」で「設定する」を開く。
- コモンネームが対象ドメインと一致することを再確認し、「独自SSL設定の追加」から確認画面へ進む。
- 確定後は削除せず、最大15分程度の反映時間を考慮してHTTPS URLへ直接アクセスする。
この段階ではHTTPからHTTPSへの自動転送がまだ無くても異常とは限りません。まずHTTPSで証明書エラーが出ず、対象ホスト名でページが返ることを確認します。wwwあり・なしを利用する場合は両方を試し、最終的にどちらへ正規化するかも記録します。
SSL化補助機能は必要な項目だけ実行する
独自SSLが有効になった後、同じ「独自SSL設定」の「SSL化補助機能」タブを開きます。画面に表示された各機能の説明を読み、今回必要な項目だけチェックして「チェックを入れた機能を実行（確認）」へ進みます。全項目を一度に選ぶと、データベース内URL、表示資源、転送のどこで問題が起きたか分からなくなります。
WordPress AddressとSite Addressを手作業で先に変更する方法は、入力ミスで管理画面へ入れなくなるため通常手順にしません。wpXの補助機能が対象サイトで利用できない、または特殊なマルチサイト・リバースプロキシ構成なら、現行値を保存したうえでwpXサポートや構築担当者と個別設計します。一般サイトの説明を特殊構成へそのまま適用しないことが重要です。
混在コンテンツをブラウザーで特定する
HTTPSページに鍵マークが出ても、画像やスクリプトをHTTPで読んでいれば混在コンテンツです。ChromeやEdgeの開発者ツールを開き、ConsoleとNetworkを記録してからページを再読み込みします。ブロックされたURL、Initiator、対象ページを控え、テーマ、プラグイン、記事本文、外部サービスのどれがHTTP URLを生成しているかを直します。
単純な文字列置換を本番データベース全体へいきなり行うと、シリアライズされた設定や外部リンクを壊すことがあります。SSL化補助機能で直らない箇所だけを特定し、ステージングまたは限定ページで修正します。外部サービスがHTTPSを提供しない場合は、その資源を外すかHTTPS対応の提供元へ切り替え、HTTP読み込みを許可する例外にはしません。
リダイレクトは経路と回数を確認する
HTTP版の代表URLをシークレットウィンドウで開き、最終URLが意図したHTTPS URLになることを確認します。理想は不要な往復を挟まず一度で正規URLへ到達することです。http→https→www追加→別スラッグのような多段転送、httpとhttpsのループ、ログインだけHTTPへ戻る状態は修正対象です。
トップページだけで完了とせず、深い投稿URL、画像URL、管理画面、ログイン、フォーム送信、REST API、サイトマップを確認します。ブラウザー表示に加えて開発者ツールのNetworkでステータスとLocationを見れば、WordPress、.htaccess、プラグイン、外部CDNのどこが転送したか絞り込みやすくなります。
失敗時の戻し方
表示崩れや管理画面障害が出たら、新しい変更を重ねず作業を停止します。まず追加した強制転送を変更前へ戻し、HTTPSへ直接アクセスできる状態で原因を確認します。次に、SSL化補助機能で変更されたデータが原因なら、直前にエクスポートしたデータベースを同じサイトへインポートし、必要に応じて退避したwp-contentと.htaccessを同じ世代へ戻します。
復元後はキャッシュを消し、HTTPとHTTPSの両方、管理画面、投稿、フォームを再試験します。証明書自体の削除は最後の手段です。短期間の削除・再追加制限があるため、コンテンツや転送のロールバック目的で独自SSLを反復削除しないでください。原因、戻した項目、復旧時刻を残せば、次の試験で同じ範囲だけを安全に進められます。
公式情報・参考資料
以下は2026年7月17日時点で確認した公式一次資料です。画面名や仕様が変わる可能性があるため、実作業の直前にも対象ページを確認してください。
コメント