SEO監査が指摘するセキュリティヘッダー4つを、Cloudflareでコードなしに適用する

Sun, 30 Aug 2026 01:25:00 +0000

概要

SEO監査レポートで、4つのセキュリティヘッダーが指摘されることがあります。Strict-Transport-Security、Content-Security-Policy、X-Content-Type-Options、Referrer-Policyです。

最初はなぜこれがSEO項目なのかと思うはずです。結論から言うと、これらのヘッダーは検索順位を直接上げてくれるわけではありません。

この記事では、なぜSEO監査にセキュリティヘッダーが含まれるのか、各ヘッダーが何をするのか、そしてCloudflareを前段に置いた静的ブログで後から管理しやすい組み合わせで適用する方法を整理します。

なぜSEOレポートがセキュリティヘッダーを指摘するのか

Lighthouseスコアに含まれている

ほとんどのSEO監査ツールはGoogle Lighthouseをベースに技術SEOスコアを算出します。Lighthouseの4つのカテゴリのうち1つがBest Practicesで、ここにCSP、HSTS、X-Content-Type-Optionsのチェックが含まれています。

厳密にはセキュリティ衛生の点検なのですが、SEO監査フレームワークに組み込まれて一緒に報告されているのです。検索エンジンがこのヘッダーを読んで順位付けしているわけではありません。

本当のつながりはハッキングされた時の結果

実質的なつながりは次の経路です。

XSSやコンテンツインジェクションでスパムリンクや悪意のあるスクリプトが挿入される。
Google Safe Browsingが検索結果に警告を付けるか、インデックスから除外する。
トラフィックが一夜にして消える。

セキュリティヘッダーは1番が起こる確率を下げる予防措置です。監査レポートがこの項目を高優先度に分類するのは、発生確率が高いからではなく、起きた時のインパクトが大きいからです。

💡 まとめると「セキュリティヘッダー → 順位上昇」ではなく、「セキュリティヘッダー不在 → ハッキングリスク → (発生した場合)順位崩壊」という間接的で非対称な関係です。ユーザーアップロードもログインフォームもない静的ブログなら攻撃対象領域そのものが小さいため、優先度としては致命的というよりは、やっておくと安全な予防接種に近いものです。

各ヘッダーの役割

Strict-Transport-Security (HSTS)

ブラウザに対して、このドメインには今後必ずHTTPSでのみ接続するよう指示します。http://でリクエストが発生してもサーバーに確認せず、ブラウザが即座にhttps://に変換します。

すでに301でHTTPSリダイレクトをしていても、その最初のリクエストの瞬間は平文です。公共Wi-Fiのような環境で攻撃者が中間で傍受し、偽のページを表示するSSLストリッピングが可能な区間がまさにここです。HSTSはその区間をなくします。

Content-Security-Policy (CSP)

スクリプト、画像、スタイルをどの取得元から読み込めるかを定めるホワイトリストです。中核となる役割はXSS防御です。

外部依存(コメントウィジェット、アナリティクスなど)のいずれかがサプライチェーン攻撃を受けたり、コンテンツパイプラインのバグでエスケープされていないテキストがそのままHTMLに入り込む事故が起きても、許可されていない取得元からのスクリプト実行をブラウザが拒否します。

一次防御線が突破されても機能する二次防御線だと考えてください。

X-Content-Type-Options: nosniff

ブラウザがサーバーの示したContent-Typeを無視して、ファイルの内容を見て種類を自ら推測するMIMEスニッフィングを防ぎます。

この推測が悪用されると、実行されてはいけないファイルがスクリプトとして実行される迂回経路が生まれます。ユーザーアップロードのないブログならリスクは低いですが、副作用がないためそのまま有効にしておく項目です。

Referrer-Policy

訪問者が他のサイトへ移動したり外部リソースを読み込んだりする際、どのページから来たのかをどこまで渡すかを定めます。

最近のブラウザは何も指定しなくてもデフォルト値がすでにstrict-origin-when-cross-originになっています。以前のデフォルトだったno-referrer-when-downgradeは、プロトコルさえ同じであればパスまで含めた完全なURLを渡していましたが、2020年の仕様改定で基準が変わりました。

そのため、この項目は「今まさに情報が漏れている」というよりは、ブラウザのデフォルト値に依存せず、サイトが望むポリシーを明示しておくという意味合いが大きいです。SEOよりも訪問者のプライバシーの性格が強い項目です。

どこに何を置くか

ヘッダーを全部Cloudflareに集約することもできますし、全部HTMLに入れることもできます。実際に運用してみると、値が変わる頻度が基準になります。

ヘッダー	置き場所	理由
Strict-Transport-Security	Cloudflare	一度有効にすれば変わることがない
X-Content-Type-Options	Cloudflare	値が`nosniff`固定である
Referrer-Policy	Cloudflare	metaでもできるがヘッダーの方が確実
X-Frame-Options	Cloudflare	値が固定で、metaでは代替できない
Content-Security-Policy	HTML meta	外部サービスを追加するたびに値が変わる

CSPだけ性格が異なります。アナリティクスを乗り換えたりコメントウィジェットを追加するたびに許可元を修正する必要があり、これをCloudflareに置くと**サイトをいじるたびにダッシュボードに入らなければなりません。**サイトのリポジトリで一緒に管理する方がはるかに楽です。

Cloudflareに置くヘッダー

1. HSTSとnosniffは1画面で完結する

SSL/TLS → Edge Certificates → HTTP Strict Transport Security (HSTS) → Enable HSTS

Browser on plzhans blog