wordpresshttpsを完全移行し混在ゼロと301最適化でSEOと速度向上

「httpのままで警告が出る」「リダイレクトが無限ループする」「画像だけ混在コンテンツになる」——そんな悩みを、最短ルートで解消します。Googleは2018年以降、HTTPページに“保護されていない通信”警告を表示し、HTTPSは検索評価にも影響します。Chromeのシェアは日本で50％超とも言われ、対応は待ったなしです。

本記事は、SSL証明書の前提確認からURL変更、.htaccessの301統一、プラグイン活用と手動設定の比較、外部リソースまでを工程順に解説。実運用で発生しやすい「ログイン不可」「無限リダイレクト」「httpに戻る」の復旧フローも網羅します。

さらに、お名前.com・エックスサーバー・ロリポップ・ConoHaの要点、Docker/ローカルの自己署名対応、CDN同期の順序まで具体的に示します。最終チェックリストで“やり残しゼロ”を担保し、今日から安全で速い常時SSLへ進めます。

wordpresshttpsをHTTPSにする前に確認すること（失敗防止の初期チェック）

サーバーのSSL証明書とドメイン設定の前提条件

WordPressをHTTPSに切り替える前に、サーバー側でSSL証明書が有効であること、対象の独自ドメインに正しいDNS設定が完了していることを必ず確認します。A/AAAAレコードが実サーバーを指し、www有無の両方へ証明書が適用されているかも点検します。SNI対応の有無、TLSバージョンや中間証明書の配置、OCSP Stapling設定の状態も重要です。2025/09/04時点で主要レンタルサーバーは無料SSLを提供しますが、有効化後の反映遅延やキャッシュによりブラウザで鍵マークが出ない場合があります。

• 独自ドメインで証明書の有効化・設置を完了してから着手

独自SSLと共有SSLの違いと選び方

独自SSLは自分のドメイン名で証明され、常時SSL運用や検索評価、ブランド信頼の観点で推奨されます。共有SSLはサーバー事業者のサブドメインを用いるため、URLが一致しません。WordPressは内部リンクやCookieスコープがドメインに依存するため、共有SSLでは混在コンテンツやセッション不整合が発生しやすく、決済や会員機能にも不向きです。常時SSLを前提に、独自SSLを基本選択とし、環境全体の整合性を確保してから移行します。

• 常時SSL運用に適した独自SSLを基本とし、要件により共有SSLは回避

無料SSLの自動更新可否と注意点

Let’s Encryptなどの無料SSLは有効期限が短く、自動更新が前提です。更新はHTTP-01やDNS-01認証を経るため、WAFやリダイレクト設定が認証パスを妨げると失敗します。CDNやリバースプロキシ配下では実サーバー到達性も確認が必要です。cronの定期実行、CertbotやACMEクライアントのログ監視、更新猶予期間中の再試行設計を行いましょう。2025/09/04時点ではゼロダウンタイムでの更新が一般的ですが、証明書と鍵のパーミッションにも注意が必要です。

• 自動更新の失敗要因（DNS/認証ファイル/cron）を事前確認

WordPressの動作環境とバックアップの準備

HTTPS化前にWordPress本体、テーマ、プラグインのバージョンを最新安定版へ更新し、PHPとデータベースの対応バージョンを確認します。ステージング環境で混在コンテンツの有無、http参照の外部スクリプト、画像CDN設定、.htaccessやNginx設定の競合を検証します。完全バックアップとして、データベースのダンプ、wp-content全体、wp-config.php、.htaccess/nginx.confを取得し、復元手順を事前にリハーサルします。移行後はキャッシュとCDNを順序立ててパージします。

• バックアップ取得とテーマ・プラグイン互換性の確認を実施

wordpresshttpsのURLをhttpsに変更する具体手順（管理画面とwp-configの両対応）

管理画面からのURL変更とログイン手順

• 一般設定でWordPressアドレスとサイトアドレスをhttpsへ変更し、httpsで再ログイン

WordPressのHTTPS化は、まずサーバー側でSSL証明書が有効であることを確認し、管理画面の設定でURLをhttpsへ変更します。管理画面にログイン後、設定→一般で「WordPressアドレス(URL)」「サイトアドレス(URL)」をhttpsへ統一します。保存後は自動的にログアウトやクッキー再発行が起きるため、ブラウザでhttps版のドメインにアクセスし直して再ログインします。キャッシュ系プラグインを利用中は事前にキャッシュを削除し、CDNを利用している場合はオリジンのプロトコル設定も合わせて見直します。混在コンテンツがあると鍵マークが出ないため、固定ページやウィジェット内の画像・スクリプトURLを確認し、httpをhttpsへ置換します。管理画面のURL変更後は、.htaccessやサーバー設定でhttp→httpsの恒久的リダイレクトも必ず適用します。

• 主な確認項目

  • SSL証明書の有効化状態
  • 一般設定のURL2項目の一致
  • リダイレクトの有無とループ
  • Mixed Contentの解消
  • キャッシュとCDNの更新

• 役立つチェック

  • ブラウザの鍵アイコン表示
  • 開発者ツールのコンソール警告
  • 画像・CSS・JSの参照プロトコル

変更後に管理画面に入れない時の復旧

• DBやfunctions.phpでURLを一時固定してアクセス復旧

URL変更後に「httpsでログインできない」「リダイレクトが繰り返される」などの不具合が起きた場合は、データベースかテーマのfunctions.phpで一時的にURLを固定して復旧します。phpMyAdmin等でwp_optionsを開き、siteurlとhomeをhttpsの正しいドメインへ更新します。誤ったサブディレクトリや余計なスラッシュが原因のことが多いです。DB操作が難しい場合は、一時的にfunctions.phpへフィルターを追加してhomeとsiteurlを上書きします。復旧後は不要なコードを必ず削除します。プラグインが原因のケースもあるため、FTPやホスティングのファイルマネージャーでpluginsディレクトリ名を一時変更し、全無効化でログイン可否を確認します。キャッシュの残留で管理画面がhttpへ戻る場合は、サーバー側キャッシュとオブジェクトキャッシュも同時に削除します。2025/09/04時点でも、http→httpsの多重リダイレクトは.htaccessとプラグイン併用が主因です。

• 代表的な復旧手段

  • phpMyAdminでsiteurl/home修正
  • functions.phpで一時上書き
  • プラグイン全停止で競合切り分け
  • .htaccess初期化でループ解消
  • ブラウザ/サーバーキャッシュ削除

• 復旧後の再発予防

  • URLを1箇所に集約管理
  • リダイレクト設定の重複排除
  • 固定リンク再保存でルール再生成

wp-config.phpでの強制設定と注意点

• 定数でURLを固定し、誤設定時のループや混在を防止

wp-config.phpでURLを明示的に固定すると、管理画面の誤操作やプラグインによる書き換えを防げます。運用例として、WP_HOMEとWP_SITEURL定数をhttpsで定義し、管理画面の一般設定をグレーアウト化します。併せてFORCE_SSL_ADMINをtrueにして管理画面の通信を強制的にHTTPSへ統一します。ロードバランサーやCDN経由で終端している環境では、HTTPS検出にX-Forwarded-Protoヘッダーが必要な場合があり、サーバーやアプリ側の信頼プロキシ設定も確認します。Apacheは.htaccess、Nginxはserverブロックで80番ポートからhttpsへ301転送を実施し、重複設定によるループを避けます。混在コンテンツはデータベース内のhttpリソースを一括置換し、テーマ/プラグインのハードコードURLを修正します。変更前には必ずファイルとデータベースのバックアップを取得し、失敗時に即時ロールバックできる体制を用意します。

• 推奨定義例

  • define(‘WP_HOME’,’https://例の独自ドメイン‘);
  • define(‘WP_SITEURL’,’https://例の独自ドメイン‘);
  • define(‘FORCE_SSL_ADMIN’, true);

• 注意点

  • 定義とDB値の不一致は混乱の原因
  • リダイレクト設定の二重化を回避
  • 画像や外部スクリプトのhttp参照を排除
  • 変更前バックアップの徹底
  • モバイルでのキャッシュ同期確認

• 確認ステップ

  • https直URLでログイン可否
  • 鍵アイコンと証明書チェーン
  • 開発者ツールでネットワーク/コンソール
  • 固定リンクの再保存
  • サイトマップとrobotsのURL更新

.htaccessでのhttp→httpsリダイレクト設定（確実な常時SSL化）

正規表現を使った恒久リダイレクトの基本

• 301でhttpをhttpsへ統一し、重複URLを解消

常時SSL化では、Apacheのmod_rewriteを用いてhttpアクセスを301でhttpsへ恒久転送します。サーバー内の任意リソースを網羅するため、正規表現でリクエストURI全体を対象にするのが安全です。条件分岐はHTTPS環境変数やX-Forwarded-Protoを確認し、リバースプロキシ配下でも二重転送を避けます。2025/09/04時点での推奨は、明示的なR=301とLフラグの併用です。キャッシュが強く残るため、検証時は一時的に302を使い、確認後に301へ切り替えます。

• 手順

  • .htaccess冒頭でRewriteEngine On
  • HTTPS!=onの時のみリダイレクト
  • プロキシ使用時はX-Forwarded-Protoも確認
  • 既存のCMSリライトルールより上に配置
  • 正規表現でクエリとパスを保持して転送

• 推奨スニペット例

  • 下表を参考に目的別の条件を選択し、1つに統一してください。

サブディレクトリ／www有無の統一

• www有無と末尾スラッシュの整合性を揃える

wwwの有無や末尾スラッシュの不統一は重複URLを生みます。https統一と同時に、ホスト名とスラッシュ方針を決めて1本化します。WordPressなどのCMSは内部生成URLに依存するため、.htaccessでの正規化を最優先に行い、次にアプリ側設定を整えると安定します。ディレクトリインデックスの自動補完に任せず、末尾スラッシュの方針をURL設計に合わせて固定化してください。混在はインデックス分散や計測誤差の原因になります。

• www統一例

  • wwwありに統一: Hostがexample.comならwww.example.comへ301
  • wwwなしに統一: Hostがwww.example.comならexample.comへ301

• 末尾スラッシュ方針

  • ディレクトリ型は/で統一、ファイル型は拡張子で終端
  • 内部リンクとサイトマップも同一ポリシーに更新

• 適用順序

  • 1. ホスト統一
  • 2. スラッシュ統一
  • 3. https統一
  • ループ回避のため転送先条件を必ず除外

リダイレクトさせないパスの例外設定

• ACME認証、API、Webhookなどは除外ルールで保護

常時SSL化でも、特定のパスはリダイレクトを抑制する必要があります。ACME認証(.well-known/acme-challenge/)はhttp経由での到達性が要件となる場合があり、無条件転送は失敗の原因です。外部連携のWebhookや監視ヘルスチェック、社内IP限定のAPIなども、転送により署名検証やタイムアウトが発生します。例外指定は最上位で評価されるよう、RewriteRuleの順序を厳密に管理し、否定先読みや条件除外で安定動作を確保します。

• 主な除外対象

  • /.well-known/acme-challenge/
  • /api/や/version/などの機械向けエンドポイント
  • /healthz,/statusなどの監視用URL
  • 特定のIPレンジからの社内用パス

• 実装ポイント

  • 例外RewriteRuleはLフラグで即時終了
  • パス前方一致で範囲を明確化
  • ログによりヒット確認後に本番適用

プラグインで簡単にhttps化する方法と落とし穴

Really Simple SSLの設定手順と推奨オプション

2025/09/04時点で、WordPressを迅速にhttps化するならReally Simple SSLが有効です。前提としてサーバー側でSSL証明書を有効化し、ドメインでhttps接続が成功していることを確認します。プラグインをインストール後に有効化し、ダッシュボードの検出結果に従って設定を進めます。推奨は自動検出、301リダイレクト、Mixed Content修正の最小構成です。HSTSは有効化前に全ページが完全にhttpsで配信されているかを確認します。CDNやキャッシュ併用時は順序を「証明書→プラグイン→キャッシュ削除→CDN反映」とし、リダイレクトループを防ぎます。

• 自動検出・301化・HSTSなど必要最小限を有効化

【推奨オプション比較】

プラグイン無効化でログインできない時の対処

プラグイン設定の不整合でログイン不可になった場合は、SFTPやホスティングのファイルマネージャーで応急処置を行います。wp-content/plugins配下のreally-simple-sslフォルダ名を一時変更して無効化します。次にwp-config.phpのdefine(‘FORCE_SSL_ADMIN’, true);を一時的に外し、管理画面へアクセスします。入れない場合はデータベースのwp_optionsでsiteurlとhomeをhttpsからhttpに戻し、.htaccessやサーバー側のリダイレクトを一旦停止します。復旧後はMixed Contentを整理し、段階的にhttpsへ再移行します。

• プラグインディレクトリ名変更やSFTPで一時停止しURLを修正

【復旧チェックリスト】

• ブラウザキャッシュとサーバーキャッシュを削除

• .htaccessやサーバー転送設定の二重化を解消

• wp_optionsのsiteurl/home整合性を確認

• 管理画面へhttp/https両方で疎通確認

• 必要なプラグインのみ再有効化し動作確認

プラグインに頼らない手動設定との比較

手動設定は軽量で制御性が高く、不要なフックや管理画面オーバーヘッドを避けられます。具体的には、サーバーでSSL証明書を導入し、.htaccessやNginxでhttp→httpsを301転送、WordPress一般設定でURLをhttpsへ変更、データベースの絶対URLを置換、Mixed Contentを検出・修正します。プラグインは導入の容易さと自動修正が強みですが、環境差でリダイレクトが重複したり、更新時に挙動が変わる可能性があります。運用リソースが限られる場合はプラグイン、長期の安定性と速度重視なら手動が有利です。

• 軽量性と制御性は手動、有効化の容易さはプラグインが有利

【方式比較】

画像や外部リソースのMixed Contentをゼロにする

データベース一括置換とテーマ内URLの書き換え

WordPressのMixed Contentは、本文・ウィジェット・メタ情報・ショートコード・シリアライズ済みオプション内のhttp参照が原因です。シリアライズ対応の置換ツールを使い、http://ドメインからhttps://ドメインへ安全に一括置換します。置換前に必ずフルバックアップを取得し、ステージングで検証します。テーマや子テーマ内の直書きURL、functions.php内の外部スクリプト、CSS内のbackground-image、JS内の絶対URLも検索し、httpsへ統一します。CDNや画像最適化プラグインを利用している場合は、プラグイン設定の配信URLもhttpsへ揃えます。2025/09/04時点ではHTTP/2やHTTP/3対応CDNはhttps前提のため、設定の取りこぼしが混在を招きます。

• シリアライズ対応の置換ツールでhttpリンクをhttpsへ統一

https i1 wp com等の外部CDNリンクの扱い

WordPress.comの画像プロキシ(i0.wp.com/i1.wp.com/i2.wp.com)や最適化サービスは、元画像URLがhttpのままだとMixed Contentを引き起こします。元サイトのメディアURLをhttpsに統一し、CDN側もhttpsスキームで呼び出します。ページビルダーやブロック追加CSSが生成する外部フォント・アイコン・スクリプトのリンクも対象です。OGP画像や構造化データ内のimage、RSSエンクロージャ、AMPテンプレートの参照も見落としやすい箇所です。外部ドメイン配信の計測タグやA/Bテストスクリプトは、提供元のhttpsエンドポイントへ更新します。混在が続く場合は、該当ウィジェットやモジュールを一時的に無効化して原因を特定します。

• 外部プロキシ画像やビルダー生成URLのhttp混在を点検

ブラウザ開発者ツールでの混在コンテンツ検出

ChromeやFirefoxの開発者ツールで、SecurityパネルとConsoleを開き、Mixed Contentエラーとブロック済み(autoupgraded含む)リソースを確認します。ネットワークタブで「blocked:mixed-content」やステータスの差分を絞り込み、呼び出し元のスタックトレースからテンプレートやプラグインを特定します。CoverageやSourcesでhttpスキーム参照を検索し、theme/plugin内の該当箇所を修正します。修正後はシークレットウィンドウとモバイルエミュレーションで再検証し、キャッシュ・OPcache・CDNエッジを順序良くパージします。最終確認としてトップ、カテゴリ、投稿、固定、検索、404、AMP、管理画面を横断チェックします。

• コンソールのMixed Contentエラーから原因リソースを修正

対処対象の洗い出し早見表

よくあるエラーと復旧フロー（ログイン不可・無限リダイレクト・httpに戻る）

無限リダイレクトの原因切り分け

無限リダイレクトはHTTPS判定とURL設定の不整合が主因です。まずwp-config.phpでFORCE_SSL_ADMINやWP_HOME/WP_SITEURLの上書き有無を確認し、不要な定数は一時コメントアウトします。次に.htaccessやnginx設定でhttp→httpsの常時リダイレクトが二重適用されていないか、正規表現の範囲やRewriteCondの条件を精査します。最後にCDN/ロードバランサ/リバースプロキシでX-Forwarded-Protoが正しく渡り、サーバー側がHTTPSとして認識しているか確認します。2025/09/04時点でも手順は有効です。

• wp-config、.htaccess、プロキシヘッダーの順で検証

• 代表的な確認ポイント

  • 同一階層での二重リダイレクト
  • ループを誘発するトレーリングスラッシュ差異
  • wwwあり/なしの不一致とhttps化の順序

逆プロキシ環境の_server https on wordpress設定

リバースプロキシ配下では、バックエンドPHPがHTTPSを誤判定し無限リダイレクトが発生しやすいです。プロキシでX-Forwarded-Proto:httpsを付与し、Webサーバー側でHTTPS=onにマップします。ApacheはRequestHeader set X-Forwarded-Proto “https”とSetEnvIfでHTTPS=onを設定、nginxはproxy_set_header X-Forwarded-Proto https;を使用します。WordPress側ではwp-config.phpで$_SERVER[‘HTTPS’]=’on’を条件付きで補正し、admin/ログインだけ強制SSLを有効化します。ヘッダー改ざん防止のため、信頼できるプロキシからの接続元IP範囲でのみ受理する設定を併用します。

• HTTPS判定ヘッダー（X-Forwarded-Proto等）の受け渡し確認

• チェック項目

  • プロキシ→オリジンのヘッダー継承
  • HSTS適用の有無と適切なmax-age
  • HTTP/2またはHTTP/3利用時の判定差異回避

• 参考コマンド例

  • curl -I -H “X-Forwarded-Proto: https” https://ドメイン
  • サーバーログで$http_x_forwarded_proto出力の確認

URLを誤変更した際の緊急ロールバック

管理画面に入れない場合は即時ロールバックで復旧します。データベースのwp_optionsを編集し、option_nameがsiteurlとhomeの値を正しいhttpsまたはhttpに戻します。作業前にDBバックアップを取得し、変更後はキャッシュとOPcacheをクリアします。SSHが使える場合はWP-CLIでwp option update home “URL”とwp option update siteurl “URL”を実行します。さらにシリアライズ対応の置換ツールでhttp→httpsの一括変換を行い、混在コンテンツを解消します。最後にリダイレクト設定とプラグイン自動リダイレクト機能の二重適用を解除し、再発を防ぎます。

• DB直修正やWP-CLIでURLを戻して再設定

対応フロー一覧

サーバー別のSSL設定ポイント（お名前.com・エックスサーバー・ロリポップ・ConoHa）

証明書発行と反映にかかる時間と確認方法

SSL証明書の発行と反映は、サーバーの自動プロビジョニングとDNS伝播、ブラウザキャッシュの影響を受けます。一般的にLet’s Encryptの発行は数分で完了しますが、2025/09/04時点でも反映確認には最大1〜2時間を見込むと安全です。確認はhttpsでのアクセス、鍵アイコンの表示、証明書の有効期限とCN/SANを閲覧し検証します。DNS切替直後は8.8.8.8など異なるリゾルバで名前解決を比較し、モバイルでは機内モードで回線キャッシュをリセットします。

• 反映待ちとブラウザ・DNSのキャッシュ影響を考慮

• ブラウザはシークレットモードで確認

• curl -I https://ドメイン でレスポンス確認

• http→httpsの301とHSTS設定の有無を確認

• 証明書チェーンの中間証明書を検証

• CDN利用時はオリジンとエッジ両方を確認

お名前.com、エックスサーバー、ロリポップ、ConoHaの自動更新は通常90日サイクルで失効前自動更新です。更新失敗に備え、失効14日前の手動更新チェックと監視を併用すると安全です。

ドメインとサブドメインの常時SSL運用

常時SSLはhttpアクセスをhttpsへ恒久転送し、混在コンテンツを排除して安定運用します。ルートドメインとwwwの両方で証明書のSANが一致しているか確認し、サブドメインは用途ごとに証明書適用を選びます。ワイルドカード(*.example.com)は複数のサブドメインを一括保護できますが、ルートドメインは別SANが必要です。HSTSはpreload前にwww統合やサブドメイン方針を固め、慎重にmax-ageを段階的に延ばします。

• ワイルドカードやサブドメインごとの証明書適用を整理

• ワイルドカードは発行手順やACME認証方式の要件を確認

• 管理画面だけhttpsが必要な場合は限定適用を検討

• httpを残す要件がある場合は特定パスで例外化

• マルチサイトはドメインマッピングとSAN整合を確認

• コンテンツ内のhttp固定リンクを一括置換

お名前.com、エックスサーバー、ロリポップ、ConoHaはいずれもwwwとnon-wwwの常時SSL転送設定を提供しています。リダイレクトは1回で終端するように設定し、https→httpsの二重転送を排除します。DockerやCDN経由ではX-Forwarded-Protoを尊重する設定とアプリ側のHTTPS判定を有効化します。

Docker・ローカル環境でのhttps対応（開発から本番まで一貫運用）

ローカルで自己署名証明書を使う手順

開発段階でWordPressをhttpsで動かすには、Docker上でリバースプロキシ(NginxやTraefik)を立て、自己署名証明書を発行し、OSの信頼ストアに登録します。2025/09/04時点では、mkcertなどのツールでローカルCAを作成し、ブラウザとOSに信頼登録する方法が安全で再現性が高いです。証明書と鍵はボリュームでプロキシへマウントし、http→httpsのリダイレクトも有効化します。

• 開発環境で信頼済み自己署名を導入して挙動を検証

以下は構成の要点です。プロキシでTLS終端し、WordPress(PHP-FPM)とDBは内部ネットワークに限定します。wp-config.phpでHOMEとSITEURLをhttps指定し、Mixed Contentを避けるためにテーマ内のリソースURLをプロトコル相対ではなくhttps固定で確認します。ブラウザのDevToolsで「保護された通信」ステータスと証明書チェーンを点検します。

• 証明書発行

• OS/ブラウザ信頼登録

• プロキシに配置・再読込

• リダイレクト確認

• Mixed Content修正

• Docker Composeのポイント

• プロキシ公開ポート:443

• WordPressサービスは内部のみ

• ボリュームにcert/key

• HEALTHCHECKで稼働監視

本番移行時のURL置換とキャッシュ・CDN同期

本番移行ではhttpで作成したデータをhttpsへ統一するため、DB内のURLをシリアライズ対応の置換ツールで安全に置換します。置換範囲はsiteurl、home、投稿本文、メタ、ウィジェット、オプション、GUID(通常は置換しない)を明確化します。置換後に.htaccessやリバースプロキシで恒久リダイレクトを有効化し、HSTSは段階導入で誤設定リスクを抑えます。実施日時は2025/09/04のようにメモし、巻き戻し手順を準備します。

• 置換後にキャッシュ削除とCDN反映順序を厳守

順序を誤ると古いhttp資産が配信され警告が残ります。推奨順序は「URL置換→アプリキャッシュ/OPcache削除→サーバーキャッシュ削除→CDNパージ→クライアントキャッシュ更新告知」です。さらに画像最適化系プラグインのキャッシュも削除します。検証はクリーンブラウザとモバイル回線で実施し、httpアクセスが完全にhttpsへ301転送されること、Mixed Contentがないことを必ず確認します。

• 推奨手順

• 事前バックアップ取得

• メンテナンスモード

• URL置換の実行

• リダイレクト設定

• キャッシュ全消去

• CDNパージ

• 監視とログ確認

まとめと次にやること（チェックリスト付き）

導入から確認までの最終チェックリスト

WordPressのHTTPS化は「証明書の準備→WordPress設定→サーバー転送設定→動作確認」の順で進めると安全です。まずレンタルサーバーやクラウドで無料または有料のSSL証明書を発行し、ドメインへインストールします。次に管理画面の一般設定でWordPressアドレスとサイトアドレスをhttpsへ変更します。続いて.htaccessやサーバー設定でhttp→httpsの301リダイレクトを有効化します。最後にMixed Contentを検出し、画像やスクリプトのhttp参照を修正し鍵マーク表示を確認します。

• SSL発行→URL変更→リダイレクト→Mixed Content確認の順で点検

• 推奨確認日時:2025/09/04

• 対象:フロント、管理画面、画像、JS、CSS、外部CDN

• 失敗時はリダイレクト設定とプラグイン競合を点検

• 変更前にバックアップ取得

運用時の更新・証明書期限・監視ポイント

運用では、有効期限と自動更新の状態を定期点検し、更新失敗でhttpsが無効化されないよう注意します。証明書更新後は中間証明書の連鎖やリダイレクトの維持、HSTS設定の影響も確認します。テーマやプラグイン更新でhttp参照が再発することがあるため、デプロイ後は主要ページでMixed Contentの再チェックを行います。2025/09/04時点では無料証明書の自動更新が主流ですが、更新ログの監視と通知設定を組み込みましょう。

• 有効期限と自動更新の状態監視を定期運用に組み込む

• 監視対象:有効期限、HTTP→HTTPS転送、鍵マーク、証明書チェーン

• 更新後チェック:トップ/LP/フォーム/決済/管理画面

• 障害時手順:一時的にリダイレクト解除→原因切り分け→再適用

• 週次:混在コンテンツ/コンソール警告/速度の簡易点検