2026年5月25日

WordPressのHTTPS強制とHSTSプリロードの設定手順とリスク

セキュリティ

WordPressをHTTPSに統一したあとにHSTSを設定すると、ブラウザが以降の接続を自動でHTTPSに切り替えるため、通信の盗み見や改ざんを狙う攻撃を防ぎやすくなります。ただしHSTSプリロードは「取り消しに数か月かかる」設定で、サブドメインの1つでもHTTPSに対応していないと、そのサービスが開けなくなります。この記事では、HTTPS強制からHSTS、プリロード申請までを安全な順番で進める手順と、事前に確認すべきリスクを説明します。

HSTSとプリロードの仕組み

HSTS（HTTP Strict Transport Security）は、サーバーが次のようなレスポンスヘッダーを返す仕組みです。

Strict-Transport-Security: max-age=31536000; includeSubDomains; preload

このヘッダーをHTTPSで一度受け取ったブラウザは、max-age で指定した秒数のあいだ、そのドメインへの接続をHTTPではなくHTTPSで行います。証明書エラーが出た場合も、利用者が警告を無視して先に進むことはできなくなります。includeSubDomains を付けると、サブドメインにも同じルールが適用されます。

弱点は「最初の1回」です。まだヘッダーを受け取っていないブラウザは、最初にHTTPで接続してしまう可能性があります。これを埋めるのが HSTSプリロード で、hstspreload.org から申請して認められたドメインは、Chrome・Firefox・Safari・Edgeなどのブラウザに組み込まれた一覧に載り、初回からHTTPSで接続されます。

申請前に確かめるリスク

プリロードは強力な反面、元に戻すのが難しい設定です。次の点を一つずつ確認してから進めてください。

すべてのサブドメインがHTTPSで動くか。 社内向けの管理画面、メールのWebインターフェース、検証用の dev. や staging.、ルーターや複合機の管理画面など、HTTPのみのサービスが一つでもあると開けなくなります。DNSのレコード一覧を見て、存在するサブドメインを洗い出します。
証明書の期限切れが「即停止」になる。 HSTS下では警告を無視して閲覧できないため、更新漏れがそのままサイト停止になります。自動更新と期限の監視を先に整えます。
取り消しが遅い。 一覧からの削除は申請できますが、ブラウザの新しいバージョンに反映されるまで時間がかかり、古いバージョンを使い続ける利用者には残ります。数か月から年単位で影響が続くと考えてください。
申請できるのは登録ドメイン単位。 blog.example.com だけを登録することはできず、example.com 全体が対象になります。

多くのWordPressサイトでは、プリロードまでしなくても通常のHSTSで十分な効果があります。プリロードは「HTTPSのみで運用し続ける」と組織として決められる場合の選択肢です。

手順1：WordPressをHTTPSに統一する

作業前にファイルとデータベースのバックアップを取り、可能ならステージング環境で先に試します。

SSL証明書を導入し、https:// で表示できることを確認します。
管理画面の「設定」→「一般」で、WordPressアドレスとサイトアドレスを https:// に変更します。
本文や設定に残る http:// のURLを置き換えます。WP-CLIなら、まず --dry-run で件数を確認してから実行します。

wp search-replace 'http://example.com' 'https://example.com' --skip-columns=guid --dry-run
wp search-replace 'http://example.com' 'https://example.com' --skip-columns=guid

ブラウザの開発者ツールで、画像やスクリプトが http:// で読み込まれる「混在コンテンツ」の警告がないか確認します。

wp-config.php に define( 'FORCE_SSL_ADMIN', true ); を加えると、管理画面とログインがHTTPSに限定されます。ロードバランサーやCDNの背後でHTTPSを終端している構成では、WordPressがHTTPSを認識できずにリダイレクトが繰り返されることがあります。その場合は、信頼できるプロキシからのヘッダーであることを確認したうえで、wp-config.php で次のように判定させます。

// 信頼できるリバースプロキシの背後にある場合だけ使う
if ( isset( $_SERVER['HTTP_X_FORWARDED_PROTO'] ) && 'https' === $_SERVER['HTTP_X_FORWARDED_PROTO'] ) {
	$_SERVER['HTTPS'] = 'on';
}

手順2：HTTPからHTTPSへ301リダイレクトする

リダイレクトはWordPressより手前のWebサーバーで行うのが適していて、画像などの静的ファイルにも効きます。Apacheでは .htaccess のWordPressのブロックより上に書きます。

RewriteEngine On
RewriteCond %{HTTPS} off
RewriteRule ^ https://%{HTTP_HOST}%{REQUEST_URI} [L,R=301]

server {
    listen 80;
    server_name example.com www.example.com;
    return 301 https://$host$request_uri;
}

プリロードの条件として、http://example.com はまず 同じホストの https://example.com へリダイレクトする必要があります。http://example.com から https://www.example.com へ一気に飛ばす設定は条件を満たさないため、http://example.com → https://example.com → https://www.example.com の順にします。

手順3：短いmax-ageでHSTSを試す

いきなり1年を設定せず、5分程度から始めて段階的に延ばします。問題が起きても、短い値なら影響はすぐに切れます。

# Apache（mod_headers が必要）
Header always set Strict-Transport-Security "max-age=300"

# Nginx（server ブロックの HTTPS 側に書く）
add_header Strict-Transport-Security "max-age=300" always;

Nginxでは、location ブロックの中に別の add_header があると、server ブロックの add_header が引き継がれません。ヘッダーが出ないページがないか、トップページ以外でも確認します。

curl -sI https://example.com/ | grep -i strict-transport-security
curl -sI https://example.com/wp-content/uploads/sample.jpg | grep -i strict-transport-security

max-age は300（5分）→86400（1日）→604800（1週間）→2592000（30日）のように延ばし、各段階で数日から数週間様子を見ます。サブドメインの確認が済んだら includeSubDomains を加えます。Chromeでは chrome://net-internals/#hsts で、自分のブラウザに記録されたHSTSの状態を確認・削除できます（プリロード一覧に載ったものは削除できません）。

PHPの send_headers フックで header() を送る方法もありますが、WordPressを通らない静的ファイルには付かないため、Webサーバー側での設定をおすすめします。CloudflareなどのCDNを使っている場合は、CDNの管理画面にもHSTSの設定があることが多く、サーバーと二重に設定しないよう、どちらで出すかを決めておきます。

手順4：条件を満たしてからプリロードを申請する

hstspreload.org が示している主な条件は次のとおりです（2026年10月現在。最新の条件は申請ページで確認してください）。

有効な証明書を使っている
ポート80で待ち受けている場合、同じホストのHTTPSへリダイレクトしている
すべてのサブドメインをHTTPSで提供している
登録ドメインのHTTPSレスポンスに、max-age が31536000（1年）以上、includeSubDomains、preload を含むHSTSヘッダーを付けている
HTTPSからさらにリダイレクトする場合も、そのリダイレクトのレスポンスにHSTSヘッダーを付けている

add_header Strict-Transport-Security "max-age=31536000; includeSubDomains; preload" always;

申請ページでドメインを入力すると、条件を満たしていない項目が表示されます。すべて解消してから申請してください。

まとめ

順番は「HTTPS統一→301リダイレクト→短いmax-ageでHSTS→段階的に延長→includeSubDomains→プリロード申請」。
プリロードは取り消しに長い時間がかかるため、全サブドメインのHTTPS対応と証明書の自動更新を先に整える。
ヘッダーはWebサーバーで付け、静的ファイルやリダイレクトのレスポンスにも出ているか curl で確認する。
多くのサイトは通常のHSTSで十分。プリロードはHTTPSだけで運用し続けると決めた場合に検討する。