...
ウェブホスティングのロゴ

WordPressのHTTPS化：安全かつ正確にHTTPからHTTPSに切り替える

ワードプレス HTTPS ログインデータ、コンタクトフォーム、クッキーを保護し、ランキングとコンバージョンを高めるのに役立ちます。このガイドでは、証明書、URL変換、301リダイレクト、混合コンテンツの修正、クリーンなSEO対策など、WordPressのHTTPからHTTPSへの完全な切り替えを紹介します。

中心点

  • エスエスエル 正しくアクティベートし、ドメインをカバーする
  • URL ワードプレスに変換
  • 301 強制転送
  • 混合コンテンツ 的を絞った修正
  • ＳＥＯ 増し締めと点検

WordPressでHTTPSが重要な理由

暗号化がなければ、攻撃者はセッションを乗っ取ったり、フォームを読んだりすることができる。 トランスミッション ブラウザとサーバー間をTLSで接続します。HTTPSは、ブラウザの警告メッセージを防ぎ、信頼を高め、検索エンジンが肯定的に評価するシグナルを強化します。多くのAPI、決済サービス、ブラウザの機能は、いずれにせよ安全な接続を必要とする。また、HTTP/2やHTTP/3は、TLSのもとでより速くロードされ、並列処理が可能になるというメリットもあります。HTTPSに切り替えると、重複コンテンツを防ぐことができる。 キャノン (カノニカル）。

バックアップとSSL証明書の準備

どの設定にも触れる前に、ファイルとデータベースを完全にバックアップし、いつでもアクセスできるようにしている。 バックアップ を返却することができます。Let's Encryptを使えば追加料金なしで十分なことが多いのですが、要件に応じてDV/OV/EV証明書を使うこともあります。多くのホスティング業者は、証明書を自動的に発行・更新するウィザードを提供しています。ステップバイステップのヘルプが必要な場合は、このチュートリアルの 無料SSLの設定.次に、証明書チェーンが完全かどうか、wwwとapexドメイン（wwwなし）の両方が証明書でカバーされているかどうかをチェックします。 妥当性 一目瞭然。

証明書の選択と鍵の管理

初期アクティベーションに加え、多くの説明書に欠落しているいくつかの詳細にも注意してください：多くのサブドメインにワイルドカード証明書（*.domain.tld）が必要なのか、それともいくつかの明確なホスト名を持つSAN証明書で十分なのか。パフォーマンスについては、可能な限り古典的なRSAキーの代わりにECDSA証明書（楕円曲線）に頼っています。秘密鍵は厳重に保護し（ファイルパーミッションは600、サーバーユーザーのみ）、TLSのハンドシェイクを高速化するために、ECDSA証明書（楕円曲線）を使用しています。 リニューアル-チェーン：上流にCDNやリバースプロキシが接続されていても、自動更新は本当に行われるのか？ACMEの課題については、リダイレクト、レート制限、メンテナンスページが検証を妨げていないかどうかをチェックしています。また、OCSPステープリングと最新のプロトコル（TLS 1.2/1.3）をウェブサーバーで直接有効にし、ブラウザが証明書のチェックをより迅速に処理できるようにしています。

WordPressのURLを変更する

ダッシュボードにログインして「設定」→「一般」を開き、「WordPressのアドレス（URL）」と「ウェブサイトのアドレス（URL）」を https://.保存した後、セッションが再起動したら再度ログインします。その後、ブラウザのキャッシュを削除し、キャッシュ・プラグインのキャッシュがあればそれも削除して、訪問者がすぐにセキュア・バージョンを受け取れるようにします。それから、ウィジェット、メニュー、ハードリンクを見てみる。記事中のメディアについては、個々のコンテンツを編集するか、またはクリーンアップを計画する。 検索 をデータベースに追加した（下記参照）。

安全なログインと管理

管理エリアでは、TLSを強制している。 wp-config.php.これを行うには、「/* 以上で編集は終了です！*/ファイルをアップロードする： 

define('FORCE_SSL_ADMIN', true)；

つまり、ログイン、クッキー、バックエンド全体がHTTPSで厳密に実行される。リバースプロキシやCDNレイヤーがアップストリームに接続されている場合、WordPressが "X-Forwarded-Proto: https "ヘッダーを正しく解釈するようにします。そうしないと、アプリケーションは誤って接続を安全でないものとして扱い、クッキーを設定せずに セキュア-フラグを立てる。

より安全なWordPress定数とプロキシ検出

バックエンドのURLに到達できない場合（プラグインをループするなど）、wp-config.phpに明示的な定数を一時的に設定することで、誤った設定を排除している：

define('WP_HOME', 'https://deinedomain.de')；
define('WP_SITEURL', 'https://deinedomain.de')；

また、プロキシの背後にある検出も追加している。 is_ssl() を正しく理解している：

if (isset($_SERVER['HTTP_X_FORWARDED_PROTO']) && $_SERVER['HTTP_X_FORWARDED_PROTO'] === 'https') { { $_SERVER['HTTPS'] = 'on; 'https'
    $_SERVER['HTTPS'] = 'on'；
}

これにより、バックエンドでの誤った混合コンテンツ生成を防ぎ、認証クッキーが一貫して セキュア-属性が配信される。

.htaccessで301リダイレクトを設定する

すべてのリクエストが恒久的にセキュアなバージョンに行くようにするために、私は 転送 をhttpからhttpsに変更した。古典的なApache環境では、WordPressのルートで.htaccessを開き、WordPressブロックの上にルールを追加します： 

RewriteEngine On
RewriteCond %{HTTPS} !=on
RewriteRule ^ https://%{HTTP_HOST}%{REQUEST_URI}。[L,R=301］

Nginxの場合、転送はサーバ・コンフィギュレーションで行われます（server { listen 80; return 301 https://$host$request_uri; }）。詳細、バリエーション、トラブルシューティングについては HTTPS転送.重要：私はリダイレクトチェーンを短く保つ。つまり、http→https、必要であればwww→non-www、またはその逆を1回のジャンプで済ませるようにし、リダイレクトチェーンに不要なホップがないようにする。 ローディング時間 増加した。

ループのないクリーンなリダイレクト戦略

基本的な転送に加えて、一貫性のルールを設定した：wwwかnon-wwwのどちらかである。アパッチでは、ホストチェックで一度に解決できる：

RewriteEngine On
RewriteCond %{HTTPS} !=on [OR] (日本語)
RewriteCond %{HTTP_HOST} !^deinedomain.de$ [NC].
RewriteRule ^ https://deinedomain.de%{REQUEST_URI}。[L,R=301］

クエリ文字列（UTMパラメータ）を自動的に受け取り、リダイレクトを1ホップに減らし、プラグインやCDNで競合するルールを有効化しないことでループを回避している。エッジプロキシが "Flexible SSL"（ブラウザ→CDN暗号化、CDN→オリジン非暗号化）を使用している場合、私は "Full (strict) "に切り替え、訪問者とオリジンの両方にTLSが適用されるようにする。

混合コンテンツの認識と排除

リダイレクトの後、私はブラウザのツールで "混合コンテンツ"、すなわち、まだアクセス可能なコンテンツがあるかどうかをチェックする。 http が読み込まれます。テーマ、ページビルダー、ウィジェット内の画像、フォント、スクリプト、スタイルシートが影響を受けることがよくあります。私は、エディタやカスタマイザー、プラグインの設定でhttpsに変更することで、ハードコードされたURLを修正します。Really Simple SSL」のようなツールは短期的には役立ちますが、ソースの恒久的なクリーンアップの方が良いでしょう。ブロックされたコンテンツはスタイリングエラーや隠し機能の原因となるので、私はブラウザがコンテンツをブロックしなくなるまですべてをクリーンアップする。 警告 はさらに表示されます。

ミックスコンテンツ・プロフェッショナル・チェックリスト

  • テストとしてCSPディレクティブを有効にする アップグレード・インセキュア・リクエスト ブラウザが自動的に https にアップグレードするものを確認するために、レポート専用モードで、ソースを永久にクリーンアップします。
  • フォントや外部スタイルは、多くの場合CORSヘッダーを必要とします。 アクセス制御-許可-オリジン ブロックされているように見える。
  • 開発者ツールで、httpリンクが絶対パスになっているCSS背景画像を認識し、相対パスまたはhttpsに置き換えています。
  • iframe（例：地図、動画）もhttpsでなければなりません。そうでなければ、ブラウザは非表示にします。
  • テーマでは、ハードコードされたパスを避け、次のような関数を使用します。 ホーム_url(), サイト_url(), plugins_url() そして content_url()WordPressが正しいベースURLを配信するように。

ステップごとの概要

次の表は、交代に関わるすべての作業をコンパクトにまとめたもので、次のような作業に役立つ。 シーケンス を遵守しなければならない。

ステップ 推奨／説明
バックアップの作成 各変更を完了する前に バックアップ ファイルとデータベースの
SSL証明書の設定 Let's Encryptまたは有料版をホスティング会社でアクティベートする。
URLのカスタマイズ バックエンドの「設定」→「一般」でhttpsに設定する。
リダイレクトの設定 .htaccessまたはNginxサーバーブロックを301からHTTPSに設定する
混合内容のチェック コンテンツ、テーマ、プラグイン内のハードhttpリンクを置き換える
データベースの置換 すべてのhttpをバックアップと信頼できるツールで置き換える。
Google/SEOのアップデート Search Consoleのプロパティ、サイトマップ、アナリティクス、カノニカルのカスタマイズ

データベースのURLをきれいに置き換える

ウィジェットやショートコード、ユーザー定義フィールドにhttpリンクが眠っていることがあります。 工具 Better Search Replace "のようなものだ。私は "http://deinedomain.de "を検索して "https://deinedomain.de "に置き換えています。最初はドライランで、次にバックアップを取りながら本番で行います。WP-CLIを使った連続リネームには、"wp search-replace "を使っている。シリアル化された配列とオブジェクトは正しく処理されなければならないので、これを適切に処理するツールに頼っている。交換後、私はフロントエンドでランダムなサンプルをチェックし、重要な レイアウト.

データベース：私がやみくもに交換しないもの

実際にドメインを変更するときだけ、wp_posts の GUID カラムを触ります。https への純粋なプロトコルの変更には、通常 なし GUIDは主に一意な識別子として機能するため、変更する。グローバルリプレイスの前に、私はプラグインがhttpで外部エンドポイント（ウェブフック、API）を参照しているかどうかもチェックする。大規模なプロジェクトでは、検索置換中に古いスキーマを持つ新しい投稿が作成されないように、短いコンテンツ凍結フェーズを計画します。私はスピードと再現性を確保するためにWP-CLIを使用しています：

wp search-replace 'http://deinedomain.de' 'https://deinedomain.de' ---tables-with-prefix --precise --dry-run
wp search-replace 'http://deinedomain.de' 'https://deinedomain.de' --all-tables-with-prefix --precise

交代後のSEOチェック

変更後、Search Consoleでhttpsの新しいプロパティを作成し、更新された サイトマップ について。内部リンク、canonicalタグ、hreflang参照、オープングラフタグのhttpsをチェックする。トラッキングスニペット（アナリティクス、タグマネージャー、ピクセル）もセキュアなアドレスを使用する必要があります。SEOプラグインでは、リダイレクトルールをチェックし、「ソフト404」がないことを確認する。ソーシャルシェアカウンターが重要な場合は、そのツールが新しい 住所 ハンドル

フィード、ロボット、カノニカルの微調整

RSS/Atomフィードがhttps経由でアクセスでき、有効なコンテンツを配信しているかどうかをチェックする。静的に管理されている robots.txt で、必要であればサイトマップのパスを https に合わせる。hreflang ペア（多言語サイト）は、プロトコルが異ならないようにする。

HTTPSでのキャッシュ、CDN、パフォーマンス

HTTPS は、HTTP/2/3 によって多重化とヘッダー圧縮が可能になるため、速度の面でも価値があります。 接続.TLSのセッション再開、OCSPのステープリング、最新の暗号スイートには注意を払っています。CDNは、静的アセットを訪問者の近くに配信するが、一貫してhttpsで実行する必要がある。キャッシュ・プラグインでは、利用可能であれば「HTTPS用キャッシュ」オプションを有効にし、古いアーティファクトをクリアする。そして、Lighthouseのようなツールで計測し、その結果を比較する。 タイムズ 変更前と変更後。

CDN/プロキシ機能

アップストリームのCDNでは、常にOriginに「Full (strict)」を設定し、そこに証明書をアップロードするか、Originの証明書を使用し、httpsのみの配信を許可しています。CDNがリダイレクトをキャッシュしているかどうかを確認し（そうしないと古い状態が表示される）、切り替え後にエッジキャッシュをクリアします。Brotli圧縮、HTTP/3/QUIC、0-RTTも役立ちますが、ページ全体のルールがhttpリソースを注入しないようにすることが重要です。最後に、正しい クライアントIP-ヘッダー（X-Forwarded-Forなど）を設定し、ログに実際の訪問者のIPが表示されるようにウェブサーバーを設定します。

HSTSとその他のセキュリティ・ヘッダ

サイトがすべてHTTPSで動作している場合は、HTTP Strict Transport Security（HSTS）を有効にして、ブラウザが HTTPS-バリアント。例えば、こんな風にヘッダーを設定する：Strict-Transport-Security: max-age=31536000; includeSubDomains; preload - ただし、すべてのサブドメインが本当に安全にアクセスできる場合に限る。ただし、すべてのサブドメインが本当に安全にアクセスできる場合に限る。 HSTSの有効化.さらに、X-Content-Type-Options、X-Frame-Optionsなどのセキュリティ・ヘッダを設定し、httpsのソースを許可する厳格なコンテンツ・セキュリティ・ポリシーを設定しています。これらのヘッダーは、コンテンツインジェクション、クリックジャッキング、そして マイム-嗅ぐ。

セキュリティ・ヘッダの微調整

HSTSに加えて、実用的なヘッダー設定を追加する： リファラー・ポリシー: strict-origin-when-cross-origin センシティブなパスの移動を制限する、 許可ポリシー ブラウザのAPI（カメラやマイクなど）を制限している。 default-src 'self' https： 不要な外来源を防ぐ。まずは レポートのみ私は違反を収集し、ガイドラインを厳格化する。こうして、セキュリティーヘッダが意図せずサイトを "壊す "ことを防いでいる。

テスト、モニタリング、トラブルシューティング

私は、プライベート・ウィンドウとモバイル・デバイスで切り替えをテストしています。 クッキー またはキャッシュがある。ブラウザのコンソールログには、混合コンテンツの警告とブロックされたリソースがすぐに表示される。私は、"curl -I http://deinedomain.de" を使って、httpsバージョンへの301が行われるかどうか、そして、他のチェーンが発生するかどうかをチェックする。その後、サーバー上のエラーログと、SEOプラグインまたはSearch Consoleの404レポートを監視する。個々のプラグインがロードされなくなった場合は、その外部プラグインをチェックする。 依存関係 そして最新バージョンにアップデートしてください。

稼動管理と継続的モニタリング

  • リダイレクトとキャッシュの一貫性を確立するため、切り替える前にオプションで短いメンテナンスモードを有効にする。
  • 私は証明書の有効期限（アラーム）を監視し、不意打ちがないようにしている。
  • 最初の数日間は、404率、ランキングカーブ、クロール統計、コアウェブバイタルなどを監視し、早期の対策を講じる。
  • キャンペーンについては、301リダイレクトによってUTMパラメータが完全に保持されているかどうかをチェックする。

マルチサイト、プロキシ、ステージングの特殊機能

マルチサイトの場合、ネットワークアドレスをhttpsに変更し、マッピングを調整することで、すべてのサイトが統一されます。 転送 を使用します。ロードバランサーやCDNの背後では、ウェブサーバーは "X-Forwarded-Proto "ヘッダーを観察しなければなりません。そうしないと、WordPressは接続が安全でないと思い、間違ったURLを設定してしまいます。ステージングシステムの場合、私は独自の証明書を使用するか、検索エンジンにインデックスされないようにBasic Authで保護する。本番環境の変更後は、キャッシュのスイッチを入れ直し、ウォームアップして負荷を監視する。独自のプロキシやファイアウォールがある環境では、すべての変更を文書化し、後のデプロイメントで 構成 引き継ぐ。

不足しがちなマルチサイトとコマースの詳細

マルチサイトのセットアップでは、サイトごとに サイトURL そして ホーム 特にドメインマッピングが関係している場合は。もし sunrise.php や特別なマッピング・プラグインを使用する場合は、https に対応しているかどうかを確認します。ショップ（例：WooCommerce）では、私は一貫して「チェックアウト」と「マイアカウント」をhttpsに設定し、決済のテストと、「マイアカウント」をhttpsに設定しています。 ウェブフック-リターンページとサンキューページ。支払いプロバイダーや配送APIは、コールバックURLの更新を要求することがよくあります。

よくある落とし穴と迅速な解決策

そのため、発行期間、チェーン、そしてすべてのドメインが証明書に含まれているかどうかをチェックする。 接続 を中断することなく実行する。301リダイレクトの欠落は重複コンテンツを生み出す。私はこれを明確で短いルールで規制し、複数のホップを避ける。混合コンテンツは、ハードコードされたテーマファイルに由来することが多い。httpスキームを置き換えるか、適切な場所にスキームレスURL（"//..."）を使用する。httpブロックリクエストをまだ参照している外部サービス。ここでは、ウェブフック、エンドポイント、キーを更新します。プラグインが切り替えに対応できない場合は、アップデートをテストするか、HTTPSを完全にサポートするソリューションに置き換えます。 サポート.

要約：HTTPSに安全に切り替えた

私は完全なバックアップから始め 証明書WordPressのURLをhttpsに切り替え、301リダイレクトを実施し、混在したコンテンツを一貫してクリーンアップします。その後、データベースに残っているhttpのエントリーを置き換え、SEO設定を更新し、パフォーマンスを測定します。HSTSとセキュリティヘッダーは、すべてのサブドメインがhttpsに適切に対応している限り、セキュリティをさらに高めます。ホスティングについては、webhoster.deのようなサポートが充実し、自動更新が可能で、TLSのプロビジョニングが速いプロバイダーを頼りにしています。これにより、サイトの安全性、高速性、視認性が保たれ、まさに私が持続可能なウェブサイトに期待していることが実現されている。 HTTPS-交代。

現在の記事