Skip to main content
← ブログに戻る

SEOガイド ステップ7: セキュリティ — 2026年にGoogleが期待する基本

·5 分で読了·著者 LANGR SEO

SEOガイド ステップ7: セキュリティ

これは13ステップのSEOガイドのステップ7です。セキュリティはユーザーを保護するだけでなく、検索ランキングに直接影響を与えます。Googleは2014年からHTTPSをランキングシグナルとして利用しており、期待値は増す一方です。

ほとんどのサイトオーナーは「SSLを持っているから安全だ」とセキュリティを二元的に考えます。しかし実際には、Googleは数十ものセキュリティシグナルを評価しています。適切なセキュリティヘッダー、正当な証明書、混合コンテンツがないサイトは、基本的なSSL証明書だけを持つサイトよりもランクが上です — 全ての条件が同じであれば。

良いニュースは、ほとんどのセキュリティの修正は一度の設定で完了するということです。一度設定すれば、永久にランキングを保護します。

SSL構成

SSL（技術的にはTLS）は、サーバーと訪問者との間の接続を暗号化します。2014年以降、GoogleはHTTPSをランキングシグナルとして明示的に確認しています。2026年では、HTTPSを持っていないことは単なるランキング問題ではなくなり、ChromeはHTTPサイトをアドレスバーに「安全でない」と表示し、ユーザーの信頼を破壊します。

適切なSSLの要件：

要件理由チェック方法
有効な証明書期限切れ＝ブラウザ警告＝ユーザー離脱有効期限を確認
完全なチェーン不完全なチェーンは一部のデバイスで失敗SSL Labsテスト
TLS 1.2+古いバージョンには既知の脆弱性ありSSL Labsテスト
SHA-1なし廃止されたため、ブラウザが拒否証明書の詳細
SANカバレッジwwwおよび非wwwの両方をカバー証明書の詳細
自動更新期限切れの災害を防ぐLet's Encrypt / プロバイダー設定

SSLスコアリング：

100% = 有効な証明書 + 完全なチェーン + TLS 1.3 + 強力な暗号 + 自動更新
  0% = 期限切れまたは欠落した証明書

よくあるSSLの間違い：

  1. 証明書が通知なしに期限切れ — 期限切れの最低30日前にモニタリングを設定（ステップ6）
  2. 不完全な証明書チェーン — サーバーは中間証明書を送信する必要があります、リーフだけではない
  3. 混合コンテンツ — HTTPSページがHTTPリソース（画像、スクリプト、スタイルシート）を読み込む
  4. リダイレクトループ — 設定ミスのCDN/プロキシによって引き起こされるHTTP → HTTPS → HTTPサイクル
  5. 非wwwとwwwのミスマッチ — 証明書が一方をカバーしているが他方をカバーしていない

すぐにできる改善策: ドメインをSSL Labs (ssllabs.com/ssltest) で実行します。「A」未満の評価は対応が必要な問題があります。ほとんどのホスティングプロバイダーはワンクリックで修正できます。

セキュリティヘッダー

セキュリティヘッダーは、ブラウザがサイトを読み込む際にどのように行動すべきかを指示するHTTP応答ヘッダーです。これらは攻撃の全カテゴリを防ぎ、Googleのクローラーはこれをチェックします。

基本的なセキュリティヘッダー：

コンテンツセキュリティポリシー (CSP)

CSPは最も強力なセキュリティヘッダーです。ブラウザに、ページ上で読み込むことを許可するリソース（スクリプト、スタイル、画像、フォント）を正確に指示します。

Content-Security-Policy: default-src 'self'; script-src 'self' https://cdn.example.com; style-src 'self' 'unsafe-inline'; img-src 'self' data: https:; font-src 'self' https://fonts.gstatic.com; connect-src 'self' https://api.example.com; frame-ancestors 'none';

CSPが防ぐもの:

  • クロスサイトスクリプティング (XSS) 攻撃
  • データ注入攻撃
  • クリックジャッキング (frame-ancestorsによる)
  • 認可されていないスクリプト実行（クリプトマイナー、広告インジェクター）

CSP展開戦略:

  1. Content-Security-Policy-Report-Only で始める（違反をブロックせずにログ記録）
  2. 1-2週間レポートをモニタリング
  3. 正当なソースをホワイトリスト化
  4. 強制モードに切り替え
  5. 継続的な違反ログのために report-uri または report-to を追加

X-Frame-Options

あなたのサイトを他のドメインのiframeに埋め込むのを防ぎます（クリックジャッキング防止）。

X-Frame-Options: DENY

または同一オリジンのフレーミングを許可する場合：

X-Frame-Options: SAMEORIGIN

X-Content-Type-Options

ブラウザがMIMEタイプをスニッフィング（宣言されたタイプとは異なるタイプとしてファイルを解釈すること）するのを防ぎます。

X-Content-Type-Options: nosniff

この1行で、 .jpg ファイルが隠れたJavaScriptを含んでいて、ブラウザが実行するかもしれない攻撃を防ぎます。

Referrer-Policy

ユーザーがあなたのサイトからリンクをクリックしたときに送信されるリファラー情報の量を制御します。

Referrer-Policy: strict-origin-when-cross-origin

これにより、同一オリジンのリクエストに対しては完全なURLが送信されますが、クロスオリジンリクエストの場合はオリジン（ドメイン）のみが送信されます。分析ニーズとプライバシーのバランスを取ります。

Permissions-Policy

あなたのサイトで使用できるブラウザ機能（カメラ、マイク、位置情報など）を制御します。

Permissions-Policy: camera=(), microphone=(), geolocation=(), payment=()

使用していない機能を無効にすることで、サードパーティのスクリプトがそれらを悪用するのを防ぎます。

ヘッダー実装例 (Next.js):

// next.config.js
module.exports = {
  async headers() {
    return [{
      source: '/(.*)',
      headers: [
        { key: 'X-Content-Type-Options', value: 'nosniff' },
        { key: 'X-Frame-Options', value: 'SAMEORIGIN' },
        { key: 'Referrer-Policy', value: 'strict-origin-when-cross-origin' },
        { key: 'Permissions-Policy', value: 'camera=(), microphone=(), geolocation=()' },
        { key: 'Strict-Transport-Security', value: 'max-age=31536000; includeSubDomains; preload' },
      ]
    }]
  }
}

ヘッダー実装 (Apache .htaccess):

Header always set X-Content-Type-Options "nosniff"
Header always set X-Frame-Options "SAMEORIGIN"
Header always set Referrer-Policy "strict-origin-when-cross-origin"
Header always set Permissions-Policy "camera=(), microphone=(), geolocation=()"
Header always set Strict-Transport-Security "max-age=31536000; includeSubDomains; preload"

ヘッダー実装 (Nginx):

add_header X-Content-Type-Options "nosniff" always;
add_header X-Frame-Options "SAMEORIGIN" always;
add_header Referrer-Policy "strict-origin-when-cross-origin" always;
add_header Permissions-Policy "camera=(), microphone=(), geolocation=()" always;
add_header Strict-Transport-Security "max-age=31536000; includeSubDomains; preload" always;

すぐにできる改善策: 上記の5つのヘッダーをサーバー設定に追加します。これにより5分で完了し、スキャンツールでのセキュリティの姿勢がすぐに改善されます。

HSTSプリロード

HTTP Strict Transport Security (HSTS) は、ブラウザに対してあなたのドメインに対して常にHTTPSを使用するよう指示します — 最初のリクエストの前でさえも。HSTSがなければ、サイトへの最初の訪問はまだHTTPを使用する可能性があり（傍受の脆弱性あり）、その後HTTPSにリダイレクトされます。

HSTSヘッダー:

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

3つのディレクティブ:

ディレクティブ意味
max-age=315360001年間（秒単位）覚えておく
includeSubDomains全てのサブドメインにも適用
preloadブラウザのプリロードリストへの登録を要求

HSTSプリロードリスト:

究極のHSTS保護。ブラウザはHTTPSを常に使用すべきドメインのビルトインリストを持っています。あなたのドメインをhstspreload.orgに提出することは：

  • 初めての訪問者はすぐにHTTPSが得られる（HTTP → HTTPSのリダイレクトなし）
  • 攻撃者が接続をダウングレードすることは不可能
  • 永続的（提出後の削除は難しい）

HSTSプリロードの要件:

  1. 有効なHTTPS証明書
  2. 全てのHTTPをHTTPSにリダイレクト（サブドメインも含む）
  3. max-age >= 31536000のHSTSヘッダー
  4. HSTSヘッダーにincludeSubDomainsが含まれている
  5. HSTSヘッダーにpreloadが含まれている
  6. すべてのサブドメインがHTTPSをサポート

警告: すべてのサブドメインがHTTPSをサポートしている場合にのみプリロードに提出してください。includeSubDomainsディレクティブにより、HTTP専用のサブドメインはアクセスできなくなります。

すぐにできる改善策: すべてのサブドメインにHTTPSがすでにある場合、完全なHSTSヘッダーを追加してhstspreload.orgに提出してください。処理には数週間かかりますが、保護は永久的です。

脆弱性スキャン

自動脆弱性スキャンは、攻撃者が悪用する前にスタック内の既知のセキュリティ問題を特定します。

脆弱性スキャンがチェックするもの:

  • 古いソフトウェア: WordPress、プラグイン、既知のCVEを持つJavaScriptライブラリ
  • 公開されたファイル: .env、.git、wp-config.php、データベースダンプ
  • 情報漏洩: サーバーバージョンヘッダー、デバッグモード、スタックトレース
  • デフォルトの認証情報: 認証のない管理ページ、デフォルトパスワード
  • オープンポート/サービス: 不必要なサービスがインターネットに公開されている
  • インジェクションポイント: CSRF保護のないフォーム、検証されていない入力

プラットフォームごとの一般的な脆弱性：

プラットフォーム主な脆弱性修正方法
WordPress古いプラグイン自動更新 + WAF
Shopifyサードパーティアプリの権限四半期ごとにアプリリストを監査
Next.js公開されたAPIルート認証ミドルウェア + レート制限
静的サイトCDNの設定ミスキャッシュルールをレビュー
カスタムSQLインジェクションパラメータ化クエリ

スキャン頻度：

  • 毎日: 自動スキャン（SSL、ヘッダー、公開ファイル）
  • 毎週: 依存関係の脆弱性チェック（npm audit、WordPressプラグインスキャナー）
  • 毎月: 認証テストを伴う深いスキャン
  • デプロイ後: 回帰チェック

すぐにできる改善策: npm audit（Node.js）を実行するか、CMSプラグインリストをチェックして古いコンポーネントを修正します。クリティカルまたは高い重大度の問題は直ちに修正しましょう。

混合コンテンツ

混合コンテンツは、HTTPSページがHTTP経由でリソース（画像、スクリプト、スタイルシート、iframe）を読み込むときに発生します。これは暗号化を部分的に壊し、ブラウザ警告を引き起こします。

混合コンテンツの種類：

種類深刻度例ブラウザの挙動
アクティブ高HTTPスクリプト、iframe、CSSデフォルトでブロックされる
パッシブ中HTTP画像、動画、音声警告とともに読み込まれる

アクティブな混合コンテンツは最新のブラウザによってブロックされ、スクリプトとスタイルは読み込まれません。パッシブな混合コンテンツは読み込まれますが、セキュリティ警告が表示されます。

混合コンテンツの見つけ方：

  1. Chrome DevTools を開く → コンソール
  2. 「Mixed Content」警告を探す
  3. または、クローラー（Screaming Frog、LANGR）でスキャンする

一般的な混合コンテンツのソース：

  • コンテンツ内のハードコーディングされた http:// URL（ブログ投稿、商品説明）
  • HTTPリソースを読み込むサードパーティウィジェット
  • 埋め込まれたコンテンツ（古いYouTube埋め込み、ソーシャルメディアウィジェット）
  • HTTP URLを持つCSS background-image
  • HTTP経由で読み込まれるフォント

混合コンテンツの修正：

<!-- 悪い例 -->
<img src="http://example.com/image.jpg" />

<!-- 良い例 -->
<img src="https://example.com/image.jpg" />

<!-- 最良の例（プロトコル相対、ページプロトコルに適応） -->
<img src="//example.com/image.jpg" />

データベースでの修正 (WordPress)：

UPDATE wp_posts SET post_content = REPLACE(post_content, 'http://yourdomain.com', 'https://yourdomain.com');
UPDATE wp_postmeta SET meta_value = REPLACE(meta_value, 'http://yourdomain.com', 'https://yourdomain.com');

すぐにできる改善策: Chromeでホームページを開き、F12を押してコンソールタブで混合コンテンツの警告をチェックします。表示される警告を修正してください — これらはGoogleに見える形で直接表示されます。

サードパーティスクリプトのリスク

読み込む外部スクリプトは常に潜在的なセキュリティ（およびパフォーマンス）リスクです。サードパーティスクリプトは：

  • 妨害を受ける可能性がある（サプライチェーン攻撃）
  • 同意なしにユーザーを追跡する可能性がある（GDPR違反）
  • サイトを遅くする（レンダーブロッキング、ネットワーク遅延）
  • 機能を壊す（バージョン更新、障害）
  • 不要なコンテンツをインジェクトする（広告スクリプトの崩壊）

サードパーティスクリプトの監査：

スクリプト必要？リスクレベル代替
Google Analytics多くの場合必要低サーバー側トラッキング
チャットウィジェット場合による中自己ホスティングのソリューション
ソーシャルシェアボタンほとんど必要ない中静的シェアリンク
A/Bテスト時々必要高サーバー側テスト
リターゲティングピクセルビジネス判断高ファーストパーティデータ
フォントCDN便利低フォントを自己ホスト

必須のサードパーティスクリプトのリスク軽減策：

  1. サブリソース整合性 (SRI): ハッシュ検証により、改ざんされたスクリプトの読み込みを防ぐ
<script src="https://cdn.example.com/lib.js"
        integrity="sha384-oqVuAfXRKap7fdgcCY5uykM6+R9GqQ8K/uxAE+sO0..."
        crossorigin="anonymous"></script>
  1. CSP制限: 知られたドメインからのスクリプトのみを許可
  2. サンドボックス化されたiframe: サードパーティのウィジェットを隔離
  3. 定期的な監査: 四半期ごとの外部リソースのレビュー
  4. モニタリング: ページに新しい外部ドメインが出現した際にアラート

すぐにできる改善策: HTML内のすべての