HSTS：SEO担当者のためのHTTP Strict Transport Security

TL;DR — HSTSは、サーバーからブラウザへ「このサイトでは常にHTTPSを使い、平文HTTPは使わない」と伝える小さな指示です。通常のHTTP→HTTPSリダイレクトだけでは残る最初の通信の隙を塞ぎ、SEOを損ないません。ただし意図的に厳格です。有効化後に証明書が壊れると、訪問者は警告を回避できずサイトを開けません。HTTPS環境が本当に安定してから有効化してください。

HSTSとは

サイトは暗号化され、鍵アイコンが表示されるHTTPSにすべきです。通常は、誰かが http://yoursite.com と入力すると、サーバーが https://yoursite.com へ 301 リダイレクトします。ただし、リダイレクトが動く前の最初のリクエストだけは安全でないHTTPで送られます。同じWi-Fi上の攻撃者は、このわずかな隙を狙えます。

HSTS（HTTP Strict Transport Security）は、この隙を塞ぎます。サーバーが安全な接続で返すレスポンスに短い指示（ヘッダー）を追加し、そのブラウザに「以後このサイトではHTTPを試さず、最初からHTTPSを使う」と伝えます。平文HTTPで届いた同じヘッダーは、攻撃者による注入や削除を防ぐため無視されます。これはサーバーを変更する仕組みではなく、各ブラウザが個別に学習して保存するポリシーです。一度学習すると、端末から通信が出る前に http:// リンクを自動で https:// に書き換えます。 この主張の根拠 After receiving HSTS, a browser upgrades future HTTP attempts to HTTPS before sending the request. 対象範囲： MDN documents user-agent enforcement after the header has been learned; first-visit protection requires preload or a prior secure visit. 信頼度： 高 · 検証日： 2026-07-14 MDN: Strict-Transport-Security header

HSTSはSEOに有利か、不利か

直接的にはどちらでもありません。HSTSはセキュリティと信頼性の機能であり、順位を上げる施策ではありません。正しく導入すれば順位を上げもしませんが、損ないもしません。重要なのは、HSTSはリダイレクトの代わりではないことです。GoogleやBingが実際に確認して利用するのは、HTTPからHTTPSへのサーバー側 301 リダイレクトです。HSTSは人間の訪問者のブラウザ内で働き、クローラーは依存しません。両方を維持してください。

最大の注意点

HSTSは意図的に容赦のない設計です。ブラウザがサイトをHTTPS専用だと学習した後は、証明書が期限切れまたは設定不良になると、サイトの読み込みを完全に拒否し、「このまま続行」するボタンも表示しません。偽のHTTP版へ誘導する攻撃を防ぐための仕様ですが、証明書切れは「煩わしい警告」ではなく「以前訪れた人にはサイトが停止している」状態になります。

さらに、ドメインをブラウザ自体へ組み込むpreloadという強力な方式があります。優れた仕組みですが、後でpreloadリストから外れるには数か月かかり、簡単ではありません。preloadは一方通行の扉だと考え、確信がある場合だけ選んでください。 この主張の根拠 HSTS preload requires at least a one-year max-age, includeSubDomains, and preload; removal can take months to reach users. 対象範囲： The Chromium preload service documents submission and removal behavior; requirements can change and should be rechecked before submission. 信頼度： 高 · 検証日： 2026-07-17 Chromium: HSTS Preload List Submission

ヘッダー構文、クローラーには見えないブラウザ内リダイレクト、preload要件、実際のロックアウト例を知りたい場合は、Advancedタブへ切り替えてください。

TL;DR — HSTSは Strict-Transport-Security レスポンスヘッダーです。ブラウザが安全な接続で受信した場合のみ有効となり、そのホストの将来のポリシーとしてクライアントごとに保存されます。301だけでは残る「最初のリクエスト問題」、つまり新規訪問者の初回HTTP通信がリダイレクトまで安全でない隙を塞ぎます。ディレクティブは、必須で秒数を指定する max-age、includeSubDomains、preload の3つです。HSTS適用時、ブラウザはサーバーへ通信する前にURIを内部でHTTPSへ書き換えます。RFC 6797はこの書き換えの特定ステータスコードを規定しておらず、ツールが307と表示することはあっても、検索エンジンとリンク評価にはサーバー側301が引き続き必須です。hstspreload.org経由のpreloadには max-age 31536000以上、includeSubDomains、preload が必要で、解除がユーザーへ届くまで数か月かかります。証明書エラーは強制停止になるため、全サブドメインのHTTPS運用が堅牢になってから有効化してください。

HTTPSハブでは、HSTSを301の上に重ねるブラウザ層の保護として紹介しています。このページでは、正確なヘッダー構文、SEO担当者が混同しやすい内部リダイレクト、preloadリストのほぼ不可逆な性質、実際のロックアウト原因を詳しく説明します。

HSTSが実際に解決する問題：最初のリクエスト

HTTPS移行が正しく完了したサイトを想像してください。すべての http:// URLは対応する https:// URLへ301リダイレクトされ、証明書は有効で、canonicalもHTTPSを指しています。隙がないように見えますが、完全ではありません。

初めての訪問者がスキームなしで yoursite.com と入力するか、古い http://yoursite.com リンクをクリックすると、ブラウザの最初のリクエストは平文HTTPで送られます。サーバーが301を返した後は安全ですが、その最初の往復だけは暗号化されません。同じネットワーク上のSSLストリッピング攻撃者はHTTPリクエストを傍受し、利用者をHTTPに留めたままサーバーへHTTPSで中継して、内容を読んだり書き換えたりできます。

HSTSは、以前訪問した利用者についてこの隙をなくします。web.devは仕組みを次のように説明しています。“use Strict Transport Security to tell clients they should always connect to your server using HTTPS, even when following an http:// reference. This defeats attacks like SSL Stripping, and avoids the round-trip cost of the 301 redirect.” (翻訳) 「Strict Transport Securityを使い、http:// 参照をたどる場合でも常にHTTPSで接続するようクライアントへ伝えます。これによりSSLストリッピングのような攻撃を防ぎ、301リダイレクトの往復コストも回避できます。」 (web.dev) 。最後の点は性能にも関係し、再訪ブラウザはHTTP→HTTPSの往復を丸ごと省けます。 この主張の根拠 After receiving HSTS, a browser upgrades future HTTP attempts to HTTPS before sending the request. 対象範囲： MDN documents user-agent enforcement after the header has been learned; first-visit protection requires preload or a prior secure visit. 信頼度： 高 · 検証日： 2026-07-14 MDN: Strict-Transport-Security header

境界条件を2つ正確に押さえましょう。第一に、HSTSはクライアントごとに保存されるポリシーです。安全な接続で配信されたヘッダーから、そのブラウザがそのホストについて学習します。HTTPレスポンス上の同じヘッダーは、平文通信で攻撃者が注入や削除を行えるため完全に無視されます。新規インストール、別ブラウザ、クローラーなど、ヘッダーを受け取ったことがないクライアントには適用するポリシーがありません。第二に、書き換えはスキームとポートを考慮します。暗黙のポート80は暗黙の443になりますが、元のURIに標準外ポートが明示されていれば、ブラウザは同じポート番号のままHTTPSで接続します。

ヘッダー構文

HSTSは、最大3つのディレクティブを持つ1つのレスポンスヘッダーです。MDN では、次の形式が示されています。

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

• max-age=<seconds> — 必須です。“The time, in seconds, that the browser should remember that a host is only to be accessed using HTTPS” (翻訳) 「ブラウザが、そのホストへHTTPSでのみアクセスすると記憶する秒数」 (MDN)。31536000 は1年、63072000 は2年です。ヘッダーを含むレスポンスを受け取るたびに期限がリセットされるため、稼働中のサイトはポリシーを継続的に更新します。ヘッダーを単に削除しても、学習済みポリシーはすぐ消えません。保存された max-age が切れるまで適用されます。学習済みクライアントでHSTSを無効にするには、安全なレスポンスで max-age=0 を配信し、次回の安全な訪問時に忘れさせる必要があります。これは学習済みポリシーだけを消し、別管理のpreloadリストからは削除しません。
• includeSubDomains — 任意です。“If this directive is specified, the HSTS policy applies to all subdomains of the host’s domain as well” (翻訳) 「このディレクティブを指定すると、HSTSポリシーはホストのドメイン配下の全サブドメインにも適用されます」 (MDN)。強力ですが同じだけ危険でもあるため、後述のロックアウト例を確認してください。
• preload — 任意です。ブラウザのpreloadリストへ登録する意思を示すフラグで、単独では何も起こりません。hstspreload.orgへ申請するための前提です。 この主張の根拠 HSTS preload requires at least a one-year max-age, includeSubDomains, and preload; removal can take months to reach users. 対象範囲： The Chromium preload service documents submission and removal behavior; requirements can change and should be rechecked before submission. 信頼度： 高 · 検証日： 2026-07-17 Chromium: HSTS Preload List Submission

MDNは動作を次のように説明しています。“Before loading an http URL, the browser checks the domain name against its HSTS hosts list. If the domain name is a case insensitive match for an HSTS host or is a subdomain of one that specified includeSubDomains, then the browser replaces the URL scheme with https.” (翻訳) 「http URLを読み込む前に、ブラウザはドメイン名をHSTSホスト一覧と照合します。大文字小文字を区別せずHSTSホストに一致するか、includeSubDomains を指定したホストのサブドメインであれば、URLスキームを https に置き換えます。」

クローラーには見えない内部アップグレード（SEO上の核心）

HSTSで最も誤解されやすく、リダイレクトの代わりにできない理由となる点です。

ブラウザがHSTSに従って http:// リクエストをアップグレードすると、ネットワークリクエストを送る前にURIを内部でHTTPSへ書き換えます。RFC 6797 §8.3 はスキーム置換を要求しますが、特定のステータスコードは規定しません。そのためブラウザやクロールツールは内部処理を任意に表現でき、多くは内部307と表示しますが、これはクライアントまたはツール固有でありプロトコル保証ではありません。SEO上重要なのは、HTTP版についてサーバーへ接続しないため、クローラーには見えないことです。GooglebotやBingbotは再訪者のChromeのように学習済みHSTSポリシーを保持せず、サーバーへ新規にアクセスします。そこで必要なのは実際のサーバー側301です。 この主張の根拠 RFC 6797 requires the user agent to rewrite a known-HSTS-host HTTP URI to HTTPS internally, but does not mandate any specific redirect status code for that internal rewrite; how a given browser or crawling tool represents that step (e.g., as an internal 307) is a client/tool implementation detail, not a protocol requirement. 対象範囲： RFC 6797 Section 8.3 ("URI Loading and Port Mapping") specifies the UA MUST replace the URI scheme with https; it does not prescribe an HTTP status code for that internal substitution, since no HTTP exchange occurs for it. Section 7.2's suggestion of status code 301 addresses ordinary server-side redirect behavior, not this internal client-side rewrite. 信頼度： 高 · 検証日： 2026-07-17 RFC 6797 §8.3 — URI Loading and Port Mapping

結論は明確です。HSTSはサーバー側301の代わりにはなりません。 検索エンジンがプロトコル移行を理解し、シグナルを統合するために使うのは301です。Googleも、“301 and other permanent redirects don’t cause a loss in PageRank” (翻訳) 「301などの恒久的リダイレクトでPageRankが失われることはありません」（Googleの説明）と述べています。ブラウザ内アップグレードは、その上に重ねるユーザー体験とセキュリティの層です。役割の異なる両方が必要です。

• 301（サーバー側）： クローラー、インデックス、リンク評価のため。
• 内部307形式のアップグレード（HSTSによるブラウザ側）： 再訪する人とSSLストリッピング対策のため。正確なステータス表現はクライアントやツールによって異なります。

HSTSがリダイレクトを処理するから301を削除できる、と説明するガイドは誤りで、気づかないうちに損失を招きます。

HSTS preload：ほぼ恒久的な方式

max-age は再訪者を保護しますが、まだヘッダーを受け取っていない初回訪問者は最初のリクエストで保護されないという起動時の問題があります。Preloadは、ドメインをブラウザのソース自体へ組み込み、接続したことがなくてもHTTPS専用だと認識させて解決します。

hstspreload.org から申請します。要件は厳密です。

1. “Serve a valid certificate.” (翻訳) 「有効な証明書を配信する。」
2. “Redirect from HTTP to HTTPS on the same host, if you are listening on port 80.” (翻訳) 「ポート80で待ち受ける場合、同一ホストでHTTPからHTTPSへリダイレクトする。」
3. “Serve all subdomains over HTTPS” (翻訳) 「すべてのサブドメインをHTTPSで配信する。」DNSレコードが存在する場合は、特に www も含みます。
4. ベースドメインのHTTPSレスポンスで、“the max-age must be at least 31536000 seconds (1 year),” (翻訳) 「max-age は少なくとも 31536000 秒、つまり1年」、“the includeSubDomains directive must be specified,” (翻訳) 「includeSubDomains ディレクティブを指定」、“the preload directive must be specified.” (翻訳) 「preload ディレクティブを指定」というHSTSヘッダーを配信する。 (hstspreload.org)

このため、上の2年の例（max-age=63072000; includeSubDomains; preload）が一般的な申請形式です。これはhstspreload.orgが公開する正確な申請要件であり、恒久的な定数ではなく現在の基準として扱い、申請前に公開ページを再確認してください。

混同されがちな4つの状態を分けて考えると理解しやすくなります。

削除も同じ4状態を逆向きに、同じように時間をかけて進みます。ヘッダーから preload を外すと削除フォームを申請できる状態になり、申請後は保留中になります。そのドメインを含むブラウザビルドが使われなくなるまで、利用者への適用は続きます。

ここがpreloadを一方通行の扉にする点です。申請サイト自体が、“Be aware that inclusion in the preload list cannot easily be undone. Domains can be removed, but it takes months for a change to reach users with a Chrome update and we cannot make guarantees about other browsers.” (翻訳) 「preloadリストへの収録は簡単には元に戻せません。ドメインは削除できますが、変更がChromeの更新で利用者へ届くまで数か月かかり、他のブラウザについては保証できません。」 (hstspreload.org) と注意しています。さらに、“Don’t request inclusion unless you’re sure that you can support HTTPS for your entire site and all its subdomains in the long term.” (翻訳) 「サイト全体と全サブドメインで長期的にHTTPSを維持できる確信がない限り、収録を申請しないでください。」と助言しています。

実務的には、preloadは非常に優れたセキュリティ対策ですが、将来レガシーなサブドメイン、買収したブランド、社内ツールなどを平文HTTPで提供する必要が生じても、全利用者へブラウザ更新が行き渡るまで待たなければなりません。Kinstaも、it can be a difficult and time-consuming process to get your domain removed (翻訳) 「ドメインの削除は難しく時間のかかる作業になり得ます」と説明しています。preloadは恒久的なものとして扱ってください。

障害時に厳しくなるようHSTSが設計されている理由

HSTSの厳格さは不具合ではなく、セキュリティ保証そのものです。web.devはトレードオフを次のように示しています。“Clients that have listed your site as a known HSTS Host are likely to hard-fail if your site ever has an error in its TLS configuration, (such as an expired certificate). HSTS is explicitly designed this way to ensure that network attackers can’t trick clients into accessing the site without HTTPS.” (翻訳) 「サイトを既知のHSTSホストとして登録したクライアントは、証明書期限切れなどTLS設定にエラーがあると強制的に失敗する可能性があります。攻撃者がHTTPSなしでサイトへアクセスさせるようクライアントを欺けないよう、HSTSは意図的にこのように設計されています。」 (web.dev)

Googleが導く結論は、有効化を考える人に必ず伝えたい一文です。“Don’t enable HSTS until you’re certain your site operation is robust enough to avoid ever deploying HTTPS with certificate validation errors.” (翻訳) 「証明書検証エラーのあるHTTPSを決してデプロイしないほどサイト運用が堅牢だと確信するまで、HSTSを有効にしないでください。」 (web.dev)

「強制失敗」とは、「このまま続行」リンクも回避手段もないという意味です。通常のHTTPSページで証明書が切れると、決意した利用者なら回避できる警告画面が出ます。HSTSホストではブラウザが完全に拒否します。証明書更新漏れの影響は、「警告を恐れた人が離れてトラフィックが減る」から「すべての再訪者がサイトへ到達できない」へ変わります。

実際に起きるロックアウト

実務でHSTSが問題になる原因は、ほぼ常に includeSubDomains またはpreloadが実際のHTTPS対応範囲を追い越すことです。

• 忘れられたサブドメイン。 example.com で includeSubDomains を設定したものの、古いアプリ、ステータスページ、外部ツールである legacy.example.com がHTTP専用か、証明書の対象外になっています。ヘッダーを見たブラウザはそのサブドメインを拒否します。サーバー側は変わっていなくても、親のポリシーが届いて壊します。
• ワイルドカード証明書の深さ不足。 *.example.com は foo.example.com を覆いますが、DNSラベルが2階層深い foo.bar.example.com は覆いません。深いサブドメインがHTTPや不一致証明書に依存すると、includeSubDomains で締め出されます。
• HSTSホストの証明書切れ。 自動更新に失敗すると、回避可能な警告ではなく、ポリシーを覚えている全利用者にとってサイトが停止します。有効な証明書を戻し、再接続して新しい安全なレスポンスを受け取るまで、より速い解除手段はありません。
• Preload後の後悔。 preload後にHTTP専用サービスが必要になると、戻す作業は1つではなく独立した2つです。HTTPSで max-age=0 を配信して消せるのは、再接続したクライアントの学習済みポリシーだけです。preloadリストからの削除は別申請で、サーバーをどう変更してもブラウザのリリースサイクルを通じて数か月かかります。
• ローカル開発／ステージングとの衝突。 example.com を includeSubDomains 付きでpreloadすると、dev.example.com や同じapex配下の localhost 形式の社内ホストまでHTTPを拒否し、予想外に開発を妨げることがあります。

これらはHSTSを避ける理由ではなく、段階的に導入する理由です。まず短い max-age、全サブドメインを監査してから includeSubDomains、確信できた場合だけ preload へ進んでください。

HSTSは順位施策ではなく、canonicalも制御しない

SEOの観点を明確にすると、HSTSはランキングシグナルではありません。HTTPS自体も意図的にごく小さなシグナルで、Googleは全クエリの1%未満に影響する「very lightweight signal」と呼びました。HSTSはHTTPS上の層であり、別の順位入力ではありません。canonicalやインデックスを直接制御するものでもありません。ただしGoogleは、同等のHTTPページよりHTTPSをcanonicalとして優先する一方、証明書が無効、ページ依存物が安全でない、HTTPSページがHTTPへリダイレクトする、HTTPを指す rel="canonical" がある場合は例外としています（Google: consolidating duplicate URLs）。HSTSはこれらを修正も上書きもできません。 Googleのcanonical判断に影響しないブラウザ側ポリシーだからです。canonicalは301、証明書、rel="canonical"、内部リンクで決まります。HSTSはセキュリティ、利用者の信頼、SSLストリッピングの隙を塞ぐことのために導入し、301と証明書を堅牢に保ってください。

より広いHTTP→HTTPS移行では、HSTSは最初ではなく最後に有効化します。移行が安定してから、全体的なサイト移行手順の一部として導入してください。

AI要約

Advanced版の要点です。

• HSTSは Strict-Transport-Security レスポンスヘッダーです。 ブラウザにドメインで常にHTTPSを使わせ、301だけでは残る新規訪問者の最初の安全でないHTTPリクエスト、つまりSSLストリッピングの隙を塞ぎます。
• 3つのディレクティブ： 必須で秒数を指定し、レスポンスごとに期限が更新される max-age、全サブドメインへ適用する includeSubDomains、ブラウザのpreloadリストへ申請するフラグ preload です。ヘッダー削除だけでは学習済みポリシーは消えず、HTTPSで max-age=0 を配信します。トークンあり、申請可能、申請済み、実際に収録済みは別々の状態です。
• 内部アップグレードの核心： HSTS適用時、ブラウザはサーバーへ通信する前にURIを内部でHTTPSへ書き換えます。RFC 6797は特定のステータスコードを規定せず、ツールが307と表示しても、サーバーにもクローラーにも見えません。検索エンジンとリンク評価にはサーバー側301が引き続き必須です。
• Preloadはhstspreload.org を通じてドメインをブラウザへ組み込みます。max-age 31536000以上、includeSubDomains、preload が必要で、解除申請がブラウザごとの利用者へ届くまで数か月かかるため、ほぼ不可逆です。
• 強制失敗する設計： 証明書が壊れたHSTSホストは回避できず読み込みを拒否されます。Googleは、“Don’t enable HSTS until you’re certain your site operation is robust enough to avoid ever deploying HTTPS with certificate validation errors.” (翻訳) 「証明書検証エラーのあるHTTPSを決してデプロイしないほど運用が堅牢だと確信するまで、HSTSを有効にしないでください。」と述べています。
• ロックアウト原因は、忘れたHTTPサブドメイン、ワイルドカード証明書の深さ不足、証明書切れ、preload後の方針変更、ステージングとの衝突など、includeSubDomains やpreloadがHTTPS対応範囲を追い越すことに集中します。
• ランキングシグナルではなく、canonicalも上書きできません。 無効な証明書、安全でない依存物、HTTPS→HTTPリダイレクト、HTTPを指すcanonicalがあるとGoogleのHTTPS優先は崩れ、HSTSでは修正できません。301、証明書、canonicalタグでSEO上の役割を果たしてください。

公式ドキュメント

ブラウザ、標準化団体、検索エンジンによる一次資料です。

Google／web.dev

• サーバーでHTTPSを有効にする（web.dev） — HSTSヘッダー、SSLストリッピング、強制失敗の警告、有効化時期について。
• URL変更を伴うサイト移転 — サーバー側301が引き続き必須で、リダイレクトによってPageRankが失われない理由。
• ページエクスペリエンスについて — Googleの考え方におけるHTTPSと、その延長上のHSTSの位置付け。

標準仕様とブラウザ資料

• MDN — Strict-Transport-Security — 完全なヘッダー構文、3つのディレクティブ、ブラウザによるスキーム変更。
• RFC 6797 — HTTP Strict Transport Security (HSTS) — 原仕様。
• HSTS Preload Listへの申請（hstspreload.org） — Chromiumプロジェクトが管理する正確なpreload要件と削除時の注意。

出典からの引用

Google／web.devとChromium preloadサービスによる公式発言です。各リンクは、元ページの引用箇所へ移動するか、その箇所を示します。

web.dev（Google）— HSTSの動作と警告

• “Use HTTP Strict Transport Security (HSTS) to avoid the cost of the 301 redirect.” (翻訳) 「HTTP Strict Transport Security（HSTS）を使って、301リダイレクトのコストを回避します。」 引用箇所へ
• “First, use Strict Transport Security to tell clients they should always connect to your server using HTTPS, even when following an http:// reference. This defeats attacks like SSL Stripping, and avoids the round-trip cost of the 301 redirect.” (翻訳) 「まずStrict Transport Securityを使い、http:// 参照をたどる場合でも常にHTTPSでサーバーへ接続するようクライアントに伝えます。これによりSSLストリッピングのような攻撃を防ぎ、301リダイレクトの往復コストも回避できます。」 引用箇所へ
• “Clients that have listed your site as a known HSTS Host are likely to hard-fail if your site ever has an error in its TLS configuration, (such as an expired certificate). HSTS is explicitly designed this way to ensure that network attackers can’t trick clients into accessing the site without HTTPS.” (翻訳) 「サイトを既知のHSTSホストとして登録したクライアントは、証明書切れなどTLS設定にエラーがあると強制的に失敗する可能性があります。攻撃者がHTTPSなしでアクセスさせるようクライアントを欺けないよう、HSTSは意図的にこのように設計されています。」 引用箇所へ
• “Don’t enable HSTS until you’re certain your site operation is robust enough to avoid ever deploying HTTPS with certificate validation errors.” (翻訳) 「証明書検証エラーのあるHTTPSを決してデプロイしないほどサイト運用が堅牢だと確信するまで、HSTSを有効にしないでください。」 引用箇所へ

Chromium preloadサービス — hstspreload.org

• “Be aware that inclusion in the preload list cannot easily be undone. Domains can be removed, but it takes months for a change to reach users with a Chrome update and we cannot make guarantees about other browsers.” (翻訳) 「preloadリストへの収録は簡単には元に戻せません。ドメインは削除できますが、変更がChromeの更新で利用者へ届くまで数か月かかり、他のブラウザについては保証できません。」 出典
• “Don’t request inclusion unless you’re sure that you can support HTTPS for your entire site and all its subdomains in the long term.” (翻訳) 「サイト全体とすべてのサブドメインで長期的にHTTPSを維持できる確信がない限り、収録を申請しないでください。」 出典

MDN — ヘッダーの動作

• “Before loading an http URL, the browser checks the domain name against its HSTS hosts list. If the domain name is a case insensitive match for an HSTS host or is a subdomain of one that specified includeSubDomains, then the browser replaces the URL scheme with https.” (翻訳) 「http URLを読み込む前に、ブラウザはドメイン名をHSTSホスト一覧と照合します。大文字小文字を区別せずHSTSホストに一致するか、includeSubDomains を指定したホストのサブドメインであれば、URLスキームを https に置き換えます。」 出典

HSTSを有効にすべきか、どこまで進めるべきか

上から順に進めてください。それぞれの「いいえ」は保留ではなく停止を意味します。以下の正確な max-age 値、つまり試験用の数分や安定運用時の1年はPatrickによる段階導入の推奨であり、プロトコル要件ではありません。唯一の必須数値は、その手順で明示するhstspreload.orgの最低値（max-age 31536000以上）です。試験期間は自社のリスク許容度とデプロイ周期に合わせて調整してください。

1. サイト全体が有効な証明書でHTTPS化され、移行が安定していますか？

• いいえ → まだHSTSに触れないでください。まずHTTPS移行を完了し、全URLを301にし、混在コンテンツを修正し、Search Consoleで確認します。HSTSは最初ではなく最後のスイッチです。
• はい → 次へ進みます。

2. 証明書更新は自動化され、期限切れを監視していますか？

• いいえ → 先に修正してください。HSTSホストの証明書切れは警告ではなく完全な停止です。自動更新と期限アラートを整えてから進みます。
• はい → includeSubDomains をまだ付けず、数分から1日程度の短い max-age で有効化し、障害がないことを確認します。

3. www、レガシーアプリ、ステータスページ、外部ホストを含むすべてのサブドメインを監査し、有効なHTTPSを確認しましたか？

• いいえ → includeSubDomains を無効のままにします。追加すると、HTTP専用または証明書不一致のサブドメインを壊します。
• はい → max-age を1年へ延ばし、includeSubDomains を追加します。多くのサイトで安全かつ強力な安定状態です。

4. 初回訪問の隙も塞ぎ、このドメイン配下で今後一切平文HTTPを使わないと確信できますか？

• いいえ／不明 → ここで止めます。 preloadなしの max-age=31536000; includeSubDomains は十分優れた状態です。不確かな場合、preloadのわずかな上積みは不可逆性に見合いません。
• はい、確実 → preload フラグを追加し、hstspreload.org で申請します。削除が利用者へ届くまで数か月かかるため、恒久的なものとして扱います。

常に成り立つ別の分岐：HSTSを有効にすれば301を削除できますか？

• できません。 クローラーにはHSTSのブラウザ内アップグレードが見えません。どこまで導入してもサーバー側301を維持してください。

HSTS導入チェックリスト

上から順に進め、各段階を次の段階の条件にしてください。ここでの期間は運用上の推奨で、プロトコル要件ではありません。唯一の必須数値は、ステージ3にあるpreloadの最低値 max-age 31536000です。

有効化する前

• apex、www、全サブドメインを含むサイト全体が有効な証明書でHTTPSを配信している。
• HTTP→HTTPSのサーバー側301が1対1で設定されている。
• 証明書の自動更新と期限監視／アラートがある。
• HTTP→HTTPS移行が安定し、Search Consoleに問題や順位急落がない。

ステージ1 — 安全性を証明する

• 短い max-age（数分から1日）で Strict-Transport-Security を追加する。
• includeSubDomains も preload もまだ追加しない。
• 複数ブラウザで通常どおり読み込め、障害がないことを確認する。

ステージ2 — 長期運用へ進む

• max-age を少なくとも 31536000（1年）へ延ばす。
• www、レガシー、ステータス、外部サービスを含む全サブドメインの有効なHTTPSを監査する。
• 監査合格後にだけ includeSubDomains を追加する。
• 各サブドメインをHTTPSで再テストする。

ステージ3 — preload（任意、ほぼ恒久的）

• 今後このドメイン配下でHTTPが不要だと確信している。
• ヘッダーが max-age=31536000 以上の ; includeSubDomains; preload になっている。
• ポート80のHTTPが同じホストのHTTPSへリダイレクトする。
• hstspreload.org で申請し、状態を確認する。

常に必要 — 省略しない

• サーバー側301を維持する。クローラーにはブラウザ内アップグレードが見えません。
• ロールバック計画を文書化する。HTTPSで max-age=0 を配信すると、再接続したクライアントの学習済み非preloadポリシーを消せます。preloadドメインには別の遅い削除申請が必要です。

理解に役立つ考え方

1. HSTSは置き換えではなく追加の層。 サーバー側301はクローラーとリンク評価のため、HSTSによるブラウザ側内部アップグレード（RFCが特定コードを要求しないものの307と表示されることがあります）は再訪者とSSLストリッピング対策のためです。対象も役割も異なり、常に両方が必要です。

2. HSTSは301だけでは塞げない隙を閉じる。 301が保護するのは2回目以降で、リダイレクト前の最初の通信はHTTPです。再訪者向けのHSTSと初回訪問者向けのpreloadだけが、この特定の隙を塞ぎます。

3. 一気に進めず、段階的に強める。 max-age は短期から長期へ。単純なヘッダーから、サブドメイン監査後の includeSubDomains、確信できた場合だけ preload へ進みます。最後以外は元に戻せるため、時間短縮のために段階を飛ばさないでください。

4. 厳格さこそが機能であり、その厳格さは運営者にも跳ね返る。 攻撃者を阻む強制的な接続失敗は、証明書に問題が起きれば運営者自身のサイトも止めます。つまり、前提として問うべきなのは「セキュリティを望むか」ではありません。誰もが望むものです。問うべきは「証明書運用が決して破綻しないほど堅牢か」です。

5. Preloadは一方通行の扉。 非preloadのHSTSは、安全なリクエストで max-age=0 を受け取ったクライアントに限り緩和できます。Preloadはさらに進み、削除が別申請で、ブラウザのリリースごとに利用者へ届くまで数か月かかります。簡単に戻せない意思決定として扱ってください。

6. HSTSは順位とは別軸で、悪いcanonicalシグナルも救えない。 ランキングシグナルではなく、canonicalやインデックスも直接制御しません。SEO効果ではなくセキュリティと信頼で判断します。一方で、証明書不良、安全でない依存物、HTTPS→HTTPリダイレクト、HTTP canonicalがあるとGoogleのHTTPS優先は崩れ、HSTSには上書きする力がありません。

HSTS早見表

ヘッダーディレクティブ

一般的なヘッダー値（以下の段階導入値は運用上の提案で、プロトコル要件ではありません。必須最低値はpreload行です）

リダイレクト：種類、発生元、見える相手

要点

• Preloadには max-age 31536000以上、includeSubDomains、preload が必要です。hstspreload.orgの現行公開要件で確認済みです。
• Preload削除は別申請で、ブラウザごとに利用者へ届くまで数か月かかります。恒久的なものとして扱ってください。
• HSTSホストで証明書が壊れると、回避できない強制失敗になります。
• HSTSはランキングシグナルではなく、301の代わりにもなりません。

HSTSヘッダーを設定する

ヘッダーはHTTPSサーバーブロックにだけ追加し、障害がないことを確認するまでは短い max-age から始めます。; preload は、ほぼ不可逆なhstspreload.org への申請を本当に行う場合だけ追加してください。

Apache（.htaccess）

<IfModule mod_headers.c>
  # Start short (300s) to prove it's safe; raise to 31536000 once confident.
  Header always set Strict-Transport-Security "max-age=300"
  # Full posture once every subdomain is verified HTTPS:
  # Header always set Strict-Transport-Security "max-age=31536000; includeSubDomains"
  # Only add ; preload when submitting to hstspreload.org:
  # Header always set Strict-Transport-Security "max-age=63072000; includeSubDomains; preload"
</IfModule>

Nginx

# On the HTTPS (listen 443) server block:
add_header Strict-Transport-Security "max-age=300" always;
# Full posture once subdomains are verified:
# add_header Strict-Transport-Security "max-age=31536000; includeSubDomains" always;
# Preload shape (near-irreversible):
# add_header Strict-Transport-Security "max-age=63072000; includeSubDomains; preload" always;

HSTSが設定されているか確認する

macOS／Linux

# Print only the Strict-Transport-Security response header
curl -sI https://example.com/ | grep -i strict-transport-security
# → strict-transport-security: max-age=31536000; includeSubDomains

Windows（PowerShell）

# Same check in PowerShell
(Invoke-WebRequest -Uri "https://example.com/" -Method Head).Headers["Strict-Transport-Security"]

ChromeでHSTS登録を確認・削除する（DevTools／net-internals）

テスト中、ブラウザが学習したHSTSポリシーを消す必要がある場合は、次の手順を使います。

1. Open a new tab and visit:  chrome://net-internals/#hsts
2. Under "Query HSTS/PKP domain", enter your host to see the stored policy.
3. Under "Delete domain security policies", enter the host and Delete.
   (This clears the *learned* policy — it does NOT remove a *preloaded* domain,
   which lives in the browser binary and can't be cleared this way.)

この手順は、ヘッダーが実際に保存されたことの確認やテストホストのリセットに使います。本番障害の修正手段ではありません。本番ではHTTPSで**max-age=0 を明示的に配信**します。ヘッダーを削除するだけでは学習済みポリシーは消えず、クライアントが再接続して max-age=0 を受け取った時点で初めて反映されます。

問題を招くHSTSの誤り

1. 「HSTSが処理する」から恒久リダイレクトを削除する。 典型的な誤りです。HSTSのリダイレクトはクローラーに見えないブラウザ内アップグレードです。サーバー側の恒久リダイレクトを削除すると、検索エンジンは移行を統合するシグナルを失います。常に両方を維持してください。

2. サブドメイン監査前に includeSubDomains を有効にする。 サブドメインを停止させる最も一般的な原因です。レガシーアプリ、ステータスページ、外部ホスト、www 自体のどれかが有効なHTTPSでなければ、ポリシーが届いて、ヘッダーを見た全ブラウザで壊れます。

3. 初日から1年の max-age またはpreloadへ進む。 安全網がありません。短い max-age=300 から始め、障害がないことを確認してから延ばします。設定不良サイトで長い max-age を送ると、ブラウザに1年間残る自己誘発障害になります。

4. HTTPS運用が完全になる前にpreloadする。 Preloadはほぼ不可逆で、削除には数か月かかります。Google自身も、“don’t enable HSTS until you’re certain your site operation is robust enough” (翻訳) 「サイト運用が十分に堅牢だと確信するまでHSTSを有効にしない」（Googleの説明 ）と述べています。Preloadはそのリスクをさらに大きくします。

5. 証明書切れを軽微な問題として扱う。 非HSTSサイトの期限切れ証明書は回避可能な警告ですが、HSTSホストでは回避できない完全停止です。HSTSを有効にするなら、証明書自動更新と期限アラートは必須です。

6. HTTPレスポンスにヘッダーを設定する。 攻撃者が注入や削除を行えるため、ブラウザは設計上HTTPで届くHSTSを無視します。HTTPSレスポンスで送らなければ有効になりません。

7. ワイルドカード証明書の深さ制限を忘れる。 *.example.com は foo.bar.example.com を覆いません。includeSubDomains を有効にすると、その証明書に依存する深いサブドメインが締め出されます。

HSTSホストがロックアウトされたときの対応手順

1. クリーンなネットワークと複数ブラウザで障害を確認する。 影響ホスト名と正確な証明書エラーを記録します。保存済みHSTSポリシーにより、再訪者と初回訪問者で症状が異なることがあります。
2. 最初に有効なHTTPSを復旧する。 証明書の期限切れ、不一致、中間証明書不足なら、更新または置換して完全なチェーンを配備します。HSTSブラウザには安全なHTTP回避策がありません。
3. ポリシー範囲を把握する。 公開中の Strict-Transport-Security ヘッダーを調べ、includeSubDomains またはpreloadが送信元ホスト名を超えて障害を広げているか確認します。
4. 影響する全サブドメインを棚卸しする。 忘れられたHTTP専用ホストには、有効な証明書とHTTPSエンドポイントを用意してから、維持、移行、リダイレクトを判断します。
5. アクセス復旧後にだけポリシーを修正する。 範囲が安全でなければ、HTTPSレスポンス上のヘッダーを短縮または削除します。ブラウザに保存済みのポリシーは即座には消えず、preload削除は別の遅い手続きです。
6. 復旧を検証する。 apex、www、影響サブドメインごとに、有効なチェーン、正しいホスト名、1段のHTTP→HTTPSリダイレクト、意図したHSTSヘッダーをテストします。同じ棚卸しに証明書期限監視を設定します。

HTTPリダイレクトを削除したり、利用者へ警告の回避を案内したりしないでください。永続的な修正は、有効なHSTSポリシーが届く全範囲に有効なHTTPSエンドポイントを用意することです。

公開中のHSTSポリシーを監査する

Act as a security-minded technical SEO. Review this Strict-Transport-Security
header, the HTTP redirect response, and the supplied subdomain inventory.

For the header, parse max-age, includeSubDomains, and preload. Explain the effective
scope, identify subdomains whose HTTPS or certificate coverage is unproven, and
separate browser-side HSTS behavior from the server-side 301 search engines need. Use
GET requests (HEAD can behave differently on some servers/clients), and record which
client or tool produced each observation and its version, since internal-redirect
representation is client/tool-specific rather than a fixed protocol value.

Recommend the next rollout stage: keep a short max-age canary, lengthen max-age,
add includeSubDomains, or consider preload. Do not recommend preload unless the
evidence shows a valid certificate, same-host HTTP→HTTPS redirects, HTTPS on every
subdomain, max-age of at least 31536000, includeSubDomains, and the preload token.

Return: observed configuration, risks, blocking evidence, next action, rollback
constraint, and exact validation checks.

HSTSロックアウトを切り分ける

Given the affected hostnames, browser error, certificate details, DNS/CDN layout,
and live response headers, identify whether this is an expired certificate, hostname
mismatch, incomplete chain, includeSubDomains spillover, or preload issue. Prioritize
restoring valid HTTPS. Explain why removing a header does not immediately erase a
cached browser policy, then provide recovery and verification steps.

HSTS確認ツール

• HTTP Header Checker — 公開中の Strict-Transport-Security ヘッダーを調べ、HTTPSレスポンスに含まれることを確認します。
• curl -I — ブラウザに保存されたHSTS状態に依存せず、HTTPリダイレクトとHTTPSヘッダーを比較します。
• ブラウザDevTools — 実際のクライアントが見る最終レスポンスヘッダーと証明書エラーを確認します。
• HSTS preload status — 申請要件と、ドメインがpreload処理に登録されているかを確認します。

少なくとも2つの視点で確認します。コマンドライン出力はサーバーレスポンスを示し、ブラウザはクライアント側の適用と証明書の強制失敗も示します。サーバーやクライアントによってHEADとGETの扱いが異なるため、ツール比較ではGETを優先し、各測定のクライアント／ツール／バージョンを記録してください。

HSTSを段階導入するテスト

テスト0：状態マトリクス（変更前に実施）

HSTSの状態は1つの事実ではなく、食い違う可能性のある複数の独立状態です。ホスト名ごとに分けて追跡します。

すべての観測でクライアント、ツール、バージョンを記録してください。内部リダイレクトの表現とHSTS適用の詳細はブラウザ、クローラー、コマンドラインツールで異なり、1クライアントの古い測定が、実際にはない矛盾に見えることがあります。

テスト1：短い max-age の試験運用

• 目的： クライアントを長期ポリシーへ固定する前に、正常なHTTPSレスポンスだけがヘッダーを返すことを証明する。
• 方法： 代表テンプレートとホストをHTTP Header Checkerと curl -I で調べ、配備値を承認済み試験設定と比較する。
• 期待結果： HTTPSレスポンスが意図した短い max-age を返し、HTTPは引き続きHTTPSへのサーバー側恒久リダイレクトを返す。
• 失敗条件： ヘッダー欠落や重複、想定外の長期間、証明書エラー、リダイレクトループ。
• 次の対応： ヘッダーまたはHTTPSエンドポイントを修正し、試験段階を維持する。

テスト2：includeSubDomains の準備確認

• 目的： 親ポリシーが忘れられたホスト名を締め出すことを防ぐ。
• 方法： 管理中のサブドメイン一覧にある全DNSホスト名について、有効なHTTPSレスポンス、正しい証明書名、完全なチェーンをテストする。
• 期待結果： レガシー、外部、開発、深い階層を含む範囲内の全サブドメインがHTTPSで動作する。
• 失敗条件： HTTP専用サービス、期限切れまたは不一致の証明書、一覧にないホスト名。
• 次の対応： includeSubDomains を追加する前にホストを修正または移設する。

テスト3：preloadの準備確認

• 目的： ほぼ恒久的なポリシーが公開済み申請要件を満たすか確認する。
• 方法： 有効な証明書、同一ホストのHTTP→HTTPSリダイレクト、全サブドメインのHTTPS、apexで max-age が少なくとも 31536000、includeSubDomains、preload を含むヘッダーを確認する。
• 期待結果： 全要件に合格し、組織が遅い削除経路を受け入れている。
• 失敗条件： 技術要件の失敗、またはHTTP専用サブドメインが必要か未解決。
• 次の対応： 申請せず、元に戻せる段階ポリシーを維持する。

参考資料

講演資料

• “Better Safe Than Sorry with HTTPS — SMX East 2016” (翻訳) 「HTTPSでは用心するに越したことはない — SMX East 2016」（SlideShare）— TLS、一般的なHTTPS実装不良、HSTSが塞ぐ一方で影響を拡大し得る移行上の注意点を詳しく説明しています。内容は私の理解に基づき、採用統計は2016年時点です。

関連する執筆記事

• The Beginner’s Guide to Technical SEO — 技術SEO全体におけるHTTPSとHSTSの位置付け。

業界資料

• サーバーでHTTPSを有効にする（web.dev） — HSTSヘッダー、SSLストリッピング、強制失敗に関するGoogleの説明。
• MDN — Strict-Transport-Security — 構文、ディレクティブ、スキーム変更動作の権威あるリファレンス。
• HSTS Preload Listへの申請（hstspreload.org） — Chromiumプロジェクトのpreload要件と、ほぼ不可逆であることの注意。
• RFC 6797 — HTTP Strict Transport Security — ディレクティブの正確な文言が必要な場合の原仕様。
• HSTS — What It Is and How to Use It （Kinsta）— ブラウザ内リダイレクト、preloadリスト、固定化リスクを扱う実装ガイド。
• SSL Labs Server Test （Qualys）— TLS設定を評価し、HSTSが正しく配信されることを確認します。

引用に使える統計と確定事項

• Preloadには max-age 31536000以上（1年）、includeSubDomains、preload が必要です。 ブラウザへ組み込まれるリストの厳密な申請条件です。 出典
• Preload削除が利用者へ届くまで数か月かかります。 申請サービスは、“inclusion in the preload list cannot easily be undone… it takes months for a change to reach users with a Chrome update.” (翻訳) 「preloadリストへの収録は簡単には元に戻せず、変更がChrome更新で利用者へ届くまで数か月かかります」と説明しています。これがpreloadを一方通行の扉にする数値です。 出典
• HSTSホストはTLSエラーで強制失敗します。 web.devによれば、サイトをHSTSホストとして認識するクライアントは、“are likely to hard-fail if your site ever has an error in its TLS configuration.” (翻訳) 「TLS設定にエラーがあると強制的に失敗する可能性があります」。回避できず、証明書切れは停止になります。 出典
• HTTPS自体は “a very lightweight signal—affecting fewer than 1% of global queries.” (翻訳) 「全世界のクエリの1%未満に影響する非常に軽量なシグナル」というGoogleの位置付けです。HSTSはHTTPS上の層であり、別のランキング入力ではないため、SEO上の重みは実質ゼロです。 出典

理解度テスト：HSTS

HSTSについて5問です。それぞれ答えを選び、結果を確認してください。

変更履歴