WordPressサイトを常時SSL化すると、閲覧者とサーバーの間の通信が暗号化されます。しかし、「SSL証明書を有効にして、管理画面のURLをhttpからhttpsへ変えれば終わり」と考えて作業すると、管理画面に入れない、画像だけ表示されない、リダイレクトが繰り返されるといったトラブルにつながることがあります。
常時SSL化では、サーバー上の証明書、WordPressのURL設定、記事や画像に残った旧URL、httpからhttpsへの転送、外部サービスの登録情報を順番にそろえる必要があります。どれか一つだけを先に変えると、サイト内でhttpとhttpsが混在し、表示や計測、フォーム送信に影響が出る場合があります。
この記事では、WordPress初心者が常時SSL化を安全に進めるための確認事項を、作業前、切り替え中、切り替え後に分けて解説します。あわせて、自分で対応しやすいケースと、制作会社やサーバー管理者へ依頼した方が安全なケースも整理します。
- 常時SSL化はサイト全体の通信をHTTPSに統一すること
- 作業前にサイトの構成と管理範囲を把握する
- 変更前のバックアップと復旧手段を準備する
- 証明書を有効化してHTTPS接続を先に確認する
- WordPressの基準URLをHTTPSへそろえる
- 旧HTTPからHTTPSへのリダイレクトを一か所で管理する
- 混在コンテンツを見つけて修正する
- フォームや外部サービスの登録URLを確認する
- 切り替え後に行う表示と運用の確認
- 常時SSL化で起こりやすい失敗と戻し方
- 自分で進めるか専門家へ依頼するかの判断基準
- 費用を比較するときは証明書代より作業範囲を見る
- 常時SSL化の確認チェックリスト
- よくある質問
- 常時SSL化は順序と確認範囲が成功を左右する
- 参考にした公式情報
常時SSL化はサイト全体の通信をHTTPSに統一すること
SSLは現在ではTLSという仕組みで提供されていますが、一般には「SSL」「SSL化」という呼び方が広く使われています。常時SSL化とは、問い合わせフォームやログイン画面だけでなく、トップページ、記事、画像、管理画面など、サイト全体を原則としてhttpsで利用できる状態にすることです。
HTTPSでは、ブラウザとサーバーの間で送受信される内容が暗号化されます。WordPress公式の管理者向け資料でも、WordPressはサーバーにTLS／SSL証明書が用意されていればHTTPSに対応し、ログイン利用者と訪問者の安全性を保つためHTTPSの利用を強く推奨しています。
ただし、常時SSL化だけでWordPressの安全対策が完成するわけではありません。古いWordPress本体やプラグインを更新しない、弱いパスワードを使う、バックアップを取らないといった別のリスクは残ります。常時SSL化は、通信経路を守るための重要な土台と考えると分かりやすいでしょう。
SSL証明書とHTTPSは役割が異なる
SSL証明書は、サーバーがそのドメインでHTTPS通信を行うために必要な設定です。一方、WordPress側では、サイトの基準URLや内部リンク、画像URLなどをhttpsへそろえます。証明書の発行だけが完了していても、WordPressがhttpのURLを出力し続けていれば、常時SSL化は完成していません。
反対に、証明書が有効になる前にWordPressのURLをhttpsへ変更すると、ブラウザが安全な接続を確立できず、管理画面を含めてサイトへアクセスしにくくなることがあります。最初に証明書を有効化し、httpsでサイトに接続できることを確認してから、WordPress側を切り替えるのが基本です。
HTTPとHTTPSは検索エンジンや計測ツールから別URLとして扱われ得る
見た目が同じページでも、httpとhttpsは異なるURLです。切り替え後に両方へアクセスでき、転送や正規URLの指定が不十分だと、評価やアクセスデータが分散する可能性があります。そのため、旧http URLから対応するhttps URLへの転送、サイトマップや外部サービスの確認までを一つの作業として扱います。
作業前にサイトの構成と管理範囲を把握する
常時SSL化の難しさは、サイトごとに管理場所が違う点にあります。レンタルサーバーの管理画面だけで完了するサイトもあれば、CDN、リバースプロキシ、独自のサーバー設定、複数のWordPressが関係するサイトもあります。作業前に「どこを誰が管理しているか」を明確にすると、設定の重複や抜けを防げます。
ドメインとサーバーの契約状況を確認する
最初に、対象ドメインが現在どのサーバーへ向いているか、SSL証明書をどのサービスで発行するかを確認します。レンタルサーバーの無料SSLを使うのか、CDN側で証明書を管理するのか、別途取得した証明書をサーバーへ設置するのかで作業場所が変わります。
wwwありとwwwなしの両方を使っている場合は、必要なホスト名が証明書の対象になっているかも重要です。サブドメイン、開発環境、メール用ホスト名まで同じ証明書で扱えるとは限りません。公開サイトで実際に使うURLを一覧にしてから申請すると、切り替え後の証明書エラーを減らせます。
CDNやプロキシの有無を確認する
CDNやリバースプロキシを利用していると、訪問者からプロキシまではHTTPS、プロキシからWordPressまではHTTPという構成になることがあります。この状態をWordPressが正しく認識できないと、httpへ戻そうとする処理とhttpsへ転送する処理が衝突し、無限リダイレクトが起こることがあります。
WordPress公式資料でも、SSLを終端するリバースプロキシの背後でWordPressを動かす場合は、単純な設定変更によりリダイレクトループが起こり得ると注意されています。CDNやロードバランサーを使っている場合は、サービス側の推奨構成と、WordPressがHTTPSを判定するための転送ヘッダーを確認します。
WordPressが一つだけかを確認する
同じドメイン内に、公開サイト、ブログ、採用サイト、会員サイトなど複数のWordPressが置かれていることがあります。ルートの転送ルールを変更すると、別のシステムまで影響を受ける可能性があります。サブディレクトリやサブドメインごとに管理者が異なる場合は、対象範囲を先に合意しておきましょう。
WordPressマルチサイトは、通常の単一サイトとURLの保存場所や管理方法が異なります。単一サイト向けの手順をそのまま使わず、ネットワーク管理者や構築担当者へ確認する方が安全です。
変更前のバックアップと復旧手段を準備する
常時SSL化ではデータベース内のURLやサーバーの転送設定を変更することがあります。失敗しても戻せるように、ファイルとデータベースの両方をバックアップします。バックアップが「作成済み」と表示されるだけでなく、保存場所、作成日時、復元方法を確認することが大切です。
ファイルとデータベースを分けて考える
WordPressのテーマ、プラグイン、アップロード画像、設定ファイルはサーバー上のファイルにあります。記事本文、サイトURL、プラグイン設定の多くはデータベースにあります。どちらか一方だけでは、作業前の状態へ完全に戻せない場合があります。
最低限、WordPress一式とデータベースのバックアップを同じ時点で取得します。サーバー管理画面の自動バックアップを使う場合は、利用者が任意の時点へ戻せるのか、復元依頼が必要なのか、復元に時間がかかるのかも確認しておきます。
管理画面以外の復旧経路を確保する
URL設定を誤ると、WordPress管理画面にログインできなくなる可能性があります。そのため、サーバーのファイルマネージャー、SFTP、SSH、データベース管理画面など、管理画面に入れなくても設定を戻せる方法を一つは確保します。
WordPress公式の移行資料では、WordPress AddressとSite Addressを誤って変更した場合に、wp-config.phpやデータベースから修正する方法が示されています。ただし、値の意味を理解せず直接編集すると別の障害を起こすため、復旧方法に自信がなければ作業前にサーバー会社や制作者へ相談するのが安全です。
作業時間と影響範囲を決める
会社サイトやネットショップでは、切り替え中にフォーム、決済、会員ログイン、予約などが一時的に使えなくなると業務に影響します。アクセスが少ない時間帯を選び、担当者が表示確認とテスト送信を行える状態で作業します。
公開直前や広告配信の開始直前に常時SSL化を行うと、問題の原因を切り分けにくくなります。可能であれば、他の大きな更新やサーバー移行と同日に重ねず、常時SSL化だけを確認できる時間を確保します。
証明書を有効化してHTTPS接続を先に確認する
WordPressの設定を変える前に、サーバーまたはCDNでSSL証明書を有効化します。発行処理が完了したら、トップページだけでなく、存在する画像URLやログイン画面などへhttpsで直接アクセスし、証明書警告が出ないことを確認します。
証明書の対象ドメインを確認する
ブラウザで証明書エラーが表示される場合は、証明書の期限だけでなく、アクセスしているホスト名が証明書の対象に含まれているかを確認します。example.com用の証明書でwww.example.comが必ず使えるとは限りません。利用するURLと証明書の対象名を一致させます。
無料証明書でも有料証明書でも、HTTPS通信を成立させる基本的な役割は同じです。選択時は、費用だけでなく、自動更新の仕組み、再発行の手順、障害時のサポート、複数ドメインへの対応など、運用面を比較すると判断しやすくなります。
自動更新の有無を確認する
証明書には有効期限があります。レンタルサーバーやCDNが自動更新する場合でも、ドメインの向き先変更、DNS設定、契約状態などにより更新に失敗する可能性はあります。管理画面で自動更新の条件と、失敗時の通知方法を確認しておきます。
自前で証明書を管理する場合は、発行できたことよりも更新を継続できることが重要です。更新担当者、更新方法、確認日、失敗時の連絡先を決め、担当者が変わっても運用できる状態にします。
WordPressの基準URLをHTTPSへそろえる
証明書が使えることを確認したら、WordPressの基準URLをhttpsへ変更します。単一サイトでは、管理画面の「設定」から「一般」にある「WordPress アドレス（URL）」と「サイトアドレス（URL）」が主な確認場所です。
WordPress公式資料では、両方の設定にhttps://を含め、末尾にスラッシュを付けない形が示されています。二つの値は役割が異なり、WordPress本体が置かれている場所と、訪問者がサイトへアクセスする場所を表します。サブディレクトリにWordPressを置いている構成では同じ値にならないことがあるため、現在の構成を維持したまま通信方式だけを変更します。
値を保存する前に現在値を記録する
変更前の二つのURLをスクリーンショットやメモで残します。httpをhttpsへ変える以外に、wwwの有無、サブディレクトリ、末尾の文字を同時に変えないようにします。複数の要素を一度に変えると、問題が起きたときに原因を特定しにくくなります。
設定欄が編集できない場合は、wp-config.phpでWP_HOMEやWP_SITEURLが定義されている可能性があります。この場合は管理画面で無理に変更せず、設定を管理している担当者へ確認します。コード側と管理画面の値を別々に変更すると、意図しないURLが優先されることがあります。
ログインし直して管理画面を確認する
URLを保存すると、ログイン状態が切り替わり、再ログインを求められることがあります。httpsの管理画面へアクセスし、投稿一覧、メディア、設定画面が開けるかを確認します。ここでリダイレクトループや証明書エラーが出る場合は、後続の変更を増やさず、直前の設定とサーバー側のHTTPS判定を見直します。
管理画面だけをHTTPSへ強制するFORCE_SSL_ADMINという設定もありますが、サーバー側の証明書とHTTPS構成が先に整っていることが前提です。通常のレンタルサーバーでサイト全体を常時SSL化する場合は、提供事業者の手順を優先し、独自コードを必要以上に追加しない方が保守しやすくなります。
旧HTTPからHTTPSへのリダイレクトを一か所で管理する
WordPressのURLを変更しただけでは、旧http URLへのアクセスがすべて自動で適切に転送されるとは限りません。検索結果、ブックマーク、他サイトからのリンク、過去のメールなどには旧URLが残ります。訪問者を同じページのhttps URLへ案内する転送を設定します。
トップページだけに転送しない
旧記事のhttp URLへアクセスしたとき、すべてトップページへ送るのではなく、同じパスのhttps URLへ転送するのが基本です。たとえば、httpの特定記事はhttpsの同じ記事へ移します。これにより、訪問者が探していた内容へ到達しやすくなり、既存リンクも活かせます。
wwwあり・なしや別ドメインも同時に統一する場合は、転送経路が何段にもならないようにします。理想は、どの旧URLからでも一度の転送で正規のhttps URLへ到達する状態です。転送回数が多いと、表示が遅くなるだけでなく、設定ミスを見つけにくくなります。
サーバー、CDN、プラグインで重複設定しない
転送は、レンタルサーバー、CDN、Webサーバー設定、WordPressプラグインなど複数の場所で設定できます。複数箇所で同じ転送を入れると、条件が衝突し、無限リダイレクトや不要な往復が発生することがあります。
どこで転送を担当するかを一つ決め、他の設定は補助にとどめます。レンタルサーバーが常時SSL化用の転送機能を提供しているなら、その仕様を確認して利用するのが初心者には分かりやすい方法です。CDNを使う場合は、CDNとオリジンサーバーの暗号化方式も合わせて確認します。
リダイレクトの状態を複数URLで検証する
トップページだけでなく、記事、固定ページ、画像、カテゴリー、ログイン画面などでhttp URLを開き、対応するhttps URLへ移動するか確認します。wwwの有無を統一している場合は、その組み合わせも試します。
ブラウザ表示だけで判断せず、可能であればレスポンスの状態コードと転送先も確認します。意図しないページを経由していないか、何度も転送されていないかを見ます。検証方法が分からない場合は、サーバー会社や制作者へ「旧URLから新URLへの転送経路を確認してほしい」と具体的に依頼できます。
混在コンテンツを見つけて修正する
HTTPSのページ内で、画像、CSS、JavaScriptなどをhttp URLから読み込む状態を混在コンテンツと呼びます。ブラウザは一部の読み込みを拒否したり、安全ではない状態として扱ったりすることがあります。見た目では問題がないページでも、ブラウザの開発者ツールには警告が出ている場合があります。
記事本文とメディアの旧URLを確認する
古い記事本文に画像の絶対URLを直接貼っている場合、データベース内にhttp URLが残ります。トップページだけでなく、過去記事や固定ページをいくつか選び、画像がhttpsで読み込まれているか確認します。
URLを一括置換するときは、シリアライズされたデータやGUIDなど、単純に置換してはいけない値があります。WordPress公式資料でも、データベース全体を無差別に置換するとテーマやウィジェットの保存形式を壊す可能性があると注意されています。実行前にバックアップを取り、WordPressに対応した置換手段を使います。
テーマとプラグインの固定URLを確認する
テーマ設定、追加CSS、ヘッダーやフッターのコード、ウィジェット、広告タグ、古いプラグイン設定にhttp URLが書かれていることがあります。ロゴや背景画像だけ警告が出る場合は、テーマのカスタマイズ設定を確認します。
外部のJavaScriptやフォントがhttpでしか提供されていない場合は、https対応の配信元へ変更するか、その読み込みを停止します。URLの先頭からhttpを削るだけで解決するとは限りません。提供元がHTTPSに正式対応していることを確認します。
代表ページだけでなく機能ページも確認する
問い合わせ、検索結果、404ページ、会員ページ、購入画面などは、通常の記事と異なるテンプレートやプラグインを使うことがあります。トップページと記事が正常でも、機能ページにだけ旧URLが残る場合があります。
サイト内のすべてを目視するのが難しい場合は、アクセスの多いページ、問い合わせにつながるページ、個人情報を入力するページを優先します。その後、検査ツールやクロール結果を使って範囲を広げると効率的です。
フォームや外部サービスの登録URLを確認する
常時SSL化はWordPress内部だけで完了しません。アクセス解析、検索管理、広告、SNS、決済、予約、会員認証、API連携などでサイトURLを登録している場合、httpsへの変更や追加登録が必要になることがあります。
問い合わせフォームを実際に送信する
フォーム画面が表示されるだけでなく、入力、確認、送信、完了画面、通知メールまで一連の動作を試します。送信先URLやスパム対策サービスの許可ドメインにhttp URLが残っていると、送信が失敗する場合があります。
本番の宛先へテストメールが届くことを確認し、迷惑メールフォルダも見ます。常時SSL化とメール不達が直接関係しない場合もありますが、切り替え前後でテスト結果を残すと、どの変更で問題が生じたかを切り分けやすくなります。
決済やログイン連携のコールバックURLを確認する
決済サービス、SNSログイン、会員認証、外部APIは、処理後に戻るURLや通知先URLを登録していることがあります。http URLのままだと、認証や決済が完了してもWordPress側へ正しく戻れない可能性があります。
外部サービスの管理画面で、リダイレクトURI、コールバックURL、Webhook URL、許可オリジンなどの名称を探します。サービスごとに仕様が異なるため、推測で値を変えず、各サービスの公式手順を確認します。決済や個人情報に関係する場合は、保守担当者と一緒にテストする方が安全です。
検索・解析サービスを確認する
検索エンジン向けのサイトマップがhttps URLを出力しているか確認します。アクセス解析やタグ管理では、プロパティの設定、除外ルール、目標URL、参照元の扱いなどに旧URLが残っていないか見ます。
切り替え直後は、アクセス数や検索表示の変化を定期的に確認します。ただし、計測タグ自体が動いていないと、実際のアクセス減少と計測漏れを区別できません。まずリアルタイム計測やテストアクセスでタグの動作を確認してから、数値を評価します。
切り替え後に行う表示と運用の確認
常時SSL化は、設定を保存した時点ではなく、主要なページと機能が正常に動き、旧URLから正しく転送され、翌日以降も証明書を運用できる状態になって完了です。担当者が確認結果を残すと、後の保守にも役立ちます。
ブラウザで確認する項目
パソコンとスマートフォンで、トップページ、代表的な記事、固定ページ、問い合わせ、検索、404ページ、ログイン画面を開きます。アドレスがhttpsであること、証明書警告がないこと、画像や装飾が欠けていないこと、リンク先が意図したページであることを確認します。
管理者としてログインした状態だけでなく、ログアウト状態や別ブラウザでも確認します。キャッシュにより古い表示が残る場合があるため、キャッシュ削除後やプライベートブラウズでも試します。CDNやキャッシュプラグインを使っている場合は、切り替え後に旧httpのキャッシュを消します。
サイトの内部情報を確認する項目
WordPress AddressとSite Addressが意図したhttps URLになっているか、サイトマップやcanonical URLがhttpsになっているか、内部リンクや画像URLにhttpが残っていないかを確認します。ブラウザの開発者ツールで混在コンテンツや読み込みエラーが出ていないかも見ます。
サイトヘルスにHTTPS関連の問題が表示されていないか、REST APIや予約投稿など管理機能が正常かも確認します。外部からWordPressへ接続するアプリや連携ツールを使っている場合は、認証が継続しているかテストします。
しばらく監視する項目
切り替え直後に問題がなくても、証明書更新、キャッシュ更新、外部サービスの定期処理などで後から不具合が分かることがあります。エラーログ、フォーム受信、アクセス解析、検索管理、決済や予約の通知を数日間確認します。
証明書の自動更新が初めて行われる時期には、更新できたことを確認します。期限切れの直前だけに気づく運用ではなく、監視通知や管理画面のアラートを受け取れるようにしておきます。
常時SSL化で起こりやすい失敗と戻し方
管理画面に入れなくなった
証明書が使えない状態でWordPressのURLだけをhttpsへ変えた、WordPress AddressとSite Addressを誤った、wwwやサブディレクトリまで同時に変えた、といった原因が考えられます。変更を増やさず、まず証明書とURLの現在値を確認します。
管理画面に入れない場合は、事前に用意したファイル管理やデータベース管理の経路で元の値へ戻します。復旧操作に慣れていない場合は、バックアップの日時と変更内容を伝え、サーバー会社や制作者へ依頼します。
リダイレクトが繰り返される
サーバー、CDN、プラグインで転送が重複している、プロキシのHTTPS判定がWordPressへ正しく伝わっていない、wwwあり・なしの転送が循環している可能性があります。転送設定を追加して解決しようとせず、どの層がどのURLへ転送しているかを一つずつ確認します。
一時的にプラグインの転送を止める場合も、サイト全体への影響を理解して行います。CDNを利用しているなら、オリジンサーバーへ直接アクセスした場合とCDN経由の場合を分けて検証すると原因を絞りやすくなります。
画像やデザインが崩れた
画像、CSS、JavaScriptのURLにhttpが残り、ブラウザが読み込みを拒否している可能性があります。表示されない要素のURLを確認し、記事本文、テーマ設定、追加CSS、プラグイン設定、外部配信元のどこから出力されているかを特定します。
データベースの一括置換を何度も実行すると、元に戻しにくくなります。置換前のバックアップを保ち、対象と回数を記録します。原因が特定できない場合は、作業を続けるより、変更前へ戻してから計画を見直す方が被害を小さくできます。
アクセス数が急に減ったように見える
実際の流入が減った場合と、解析タグやプロパティ設定により計測できていない場合があります。サイトを自分で訪問し、リアルタイム計測へ反映されるか確認します。旧http URLがhttpsへ正しく転送されているか、サイトマップがhttpsを示しているかも見ます。
検索結果の変化は短時間の数値だけで判断せず、転送、正規URL、クロール状況、インデックス状況を順に確認します。常時SSL化以外の更新を同時に行った場合は、変更記録を使って影響を切り分けます。
自分で進めるか専門家へ依頼するかの判断基準
常時SSL化は、レンタルサーバーの機能と標準的なWordPress構成だけなら、初心者でも手順を確認しながら進められる場合があります。一方、事業に直結する機能や複雑なインフラがあると、停止時間やデータ損失のリスクが大きくなります。
自分で進めやすいケース
単一のWordPressサイトで、レンタルサーバーがSSL発行と転送の公式手順を提供しており、CDNや独自プロキシを使っていない場合は比較的進めやすいでしょう。ファイルとデータベースのバックアップがあり、管理画面以外の復旧手段を使えることも条件です。
問い合わせや決済など複雑な外部連携が少なく、問題が起きても一時的に停止できる個人ブログや小規模サイトなら、自分で作業する選択肢があります。ただし、手順を途中で推測せず、サーバー会社とWordPressの公式情報を確認しながら進めます。
依頼を検討したいケース
ネットショップ、会員サイト、予約サイト、広告運用中のサイト、問い合わせが売上に直結するサイトは、停止や計測漏れの影響が大きいため、専門家への依頼を検討します。マルチサイト、複数ドメイン、CDN、ロードバランサー、独自サーバー、古いテーマや独自開発機能がある場合も同様です。
バックアップから戻した経験がない、サーバーの転送設定を確認できない、データベース内のURL置換が必要、現在すでに表示エラーがある、といった場合は、先に原因調査を依頼する方が安全です。常時SSL化と既存障害を同時に解決しようとすると、問題が複雑になります。
依頼時に伝える情報
依頼先には、対象ドメイン、サーバー会社、WordPressの設置場所、wwwの利用有無、CDNやプロキシの有無、フォームや決済などの外部連携、希望作業時間を伝えます。現在のSSL証明書の状態と、バックアップの有無も共有します。
作業範囲として、証明書発行だけなのか、WordPress内URLの修正、リダイレクト、混在コンテンツ修正、外部サービス確認、切り替え後の監視まで含むのかを明確にします。見積もりを比較するときは金額だけでなく、確認範囲、復旧対応、作業後の保証や報告内容を比べることが大切です。
費用を比較するときは証明書代より作業範囲を見る
レンタルサーバーでは無料SSLが提供されることが多く、証明書の費用がかからない場合があります。しかし、既存サイトのURL整理、混在コンテンツ修正、外部連携テスト、障害対応には作業時間が必要です。証明書が無料だから常時SSL化全体も無料とは限りません。
有料証明書を選ぶ場合は、証明書の種類や事業者の審査、サポート内容を確認します。自社の要件として特定の証明書が必要なのか、一般的なドメイン認証証明書で足りるのかを先に整理します。要件が不明なまま高価な証明書を選んでも、WordPress内の混在コンテンツや転送設定が自動で解決するわけではありません。
制作会社へ依頼する場合は、サイトのページ数だけでなく、古い記事数、独自テーマ、外部サービス数、サーバー構成、テスト項目によって費用が変わります。固定価格だけを見ず、どこまで調査と修正を含むかを確認しましょう。
常時SSL化の確認チェックリスト
作業前には、対象ドメインとwwwの有無、サーバーとCDNの管理者、WordPressの数、外部連携、現在のURL、バックアップと復旧手段を確認します。作業日時と確認担当者も決めます。
切り替え時には、証明書が有効でhttps接続できることを先に確認し、その後にWordPress AddressとSite Addressを変更します。旧httpから同じページのhttpsへ転送し、転送設定が複数箇所で重複していないかを見ます。
切り替え後には、トップページ、記事、固定ページ、画像、問い合わせ、404ページ、ログイン画面を確認します。混在コンテンツ、内部リンク、サイトマップ、canonical URL、キャッシュ、アクセス解析、検索管理、フォーム通知、決済や認証の戻り先も確認します。
運用では、証明書の自動更新、更新失敗時の通知、定期的な表示確認、担当者と連絡先を決めます。作業内容と変更箇所を記録し、次回のサーバー移行や保守に引き継げるようにします。
よくある質問
SSL証明書を有効にするだけで常時SSL化できますか
証明書を有効にするだけでは、WordPressが出力するURL、旧httpからの転送、記事やテーマに残る旧URL、外部サービスの登録情報まではそろいません。証明書は最初の前提であり、その後のURL統一と動作確認が必要です。
SSL化プラグインを入れれば安全ですか
プラグインが設定を補助することはありますが、証明書の発行、CDNやサーバーの構成、外部サービスのURL、証明書更新まで自動で解決できるとは限りません。何を変更するプラグインかを理解し、サーバー側の公式機能と重複しないようにします。
HTTPのページを残しても問題ありませんか
常時SSL化では、公開ページを原則としてhttpsへ統一し、旧httpへのアクセスを対応するhttpsへ転送します。httpとhttpsの両方で同じ内容を表示し続けると、訪問者の安全性やURL評価、計測の一貫性を損なう可能性があります。
切り替え後すぐにHTTPを削除してよいですか
旧http URLからhttpsへの転送は、過去のリンクやブックマークを新URLへ案内するために必要です。httpで内容を直接表示する必要はありませんが、転送を継続し、意図したhttps URLへ到達する状態を保ちます。
HSTSはすぐ設定すべきですか
HSTSはブラウザにHTTPS利用を強制させる仕組みですが、設定後はhttpへ戻して復旧することが難しくなる場合があります。証明書、サブドメイン、転送、更新運用が安定していることを確認し、影響を理解してから導入します。初心者が常時SSL化と同時に推測で設定するのは避けましょう。
常時SSL化は順序と確認範囲が成功を左右する
WordPressサイトの常時SSL化は、証明書を有効化し、WordPressの基準URLをそろえ、旧httpから転送し、混在コンテンツと外部連携を確認する作業です。証明書だけ、URL変更だけ、プラグインだけで完了と考えず、サイト全体の流れとして確認します。
安全に進める要点は、変更前のバックアップ、管理画面以外の復旧経路、証明書を先に確認する順序、転送設定の一元化、切り替え後の機能テストです。複雑な構成や売上に直結する機能がある場合は、停止による損失も含めて依頼を判断します。
費用を比べるときは証明書の価格だけでなく、既存URLの調査、混在コンテンツの修正、外部サービスのテスト、障害時の復旧、運用引き継ぎまで含まれるかを確認しましょう。作業範囲が明確であれば、自分で進める場合も依頼する場合も、失敗の可能性を大きく減らせます。
参考にした公式情報
WordPress Developer Resources：HTTPS
WordPress Developer Resources：Changing The Site URL
