SEOガイド ステップ7: セキュリティ — 2026年にGoogleが期待する基本
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の間違い:
- 証明書が通知なしに期限切れ — 期限切れの最低30日前にモニタリングを設定(ステップ6)
- 不完全な証明書チェーン — サーバーは中間証明書を送信する必要があります、リーフだけではない
- 混合コンテンツ — HTTPSページがHTTPリソース(画像、スクリプト、スタイルシート)を読み込む
- リダイレクトループ — 設定ミスのCDN/プロキシによって引き起こされるHTTP → HTTPS → HTTPサイクル
- 非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展開戦略:
Content-Security-Policy-Report-Onlyで始める(違反をブロックせずにログ記録)- 1-2週間レポートをモニタリング
- 正当なソースをホワイトリスト化
- 強制モードに切り替え
- 継続的な違反ログのために
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=31536000 | 1年間(秒単位)覚えておく | | includeSubDomains | 全てのサブドメインにも適用 | | preload | ブラウザのプリロードリストへの登録を要求 |
HSTSプリロードリスト:
究極のHSTS保護。ブラウザはHTTPSを常に使用すべきドメインのビルトインリストを持っています。あなたのドメインをhstspreload.orgに提出することは:
- 初めての訪問者はすぐにHTTPSが得られる(HTTP → HTTPSのリダイレクトなし)
- 攻撃者が接続をダウングレードすることは不可能
- 永続的(提出後の削除は難しい)
HSTSプリロードの要件:
- 有効なHTTPS証明書
- 全てのHTTPをHTTPSにリダイレクト(サブドメインも含む)
max-age>= 31536000のHSTSヘッダー- HSTSヘッダーに
includeSubDomainsが含まれている - HSTSヘッダーに
preloadが含まれている - すべてのサブドメインが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画像、動画、音声 | 警告とともに読み込まれる |
アクティブな混合コンテンツは最新のブラウザによってブロックされ、スクリプトとスタイルは読み込まれません。パッシブな混合コンテンツは読み込まれますが、セキュリティ警告が表示されます。
混合コンテンツの見つけ方:
- Chrome DevTools を開く → コンソール
- 「Mixed Content」警告を探す
- または、クローラー(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 | 便利 | 低 | フォントを自己ホスト |
必須のサードパーティスクリプトのリスク軽減策:
- サブリソース整合性 (SRI): ハッシュ検証により、改ざんされたスクリプトの読み込みを防ぐ
<script src="https://cdn.example.com/lib.js"
integrity="sha384-oqVuAfXRKap7fdgcCY5uykM6+R9GqQ8K/uxAE+sO0..."
crossorigin="anonymous"></script>
- CSP制限: 知られたドメインからのスクリプトのみを許可
- サンドボックス化されたiframe: サードパーティのウィジェットを隔離
- 定期的な監査: 四半期ごとの外部リソースのレビュー
- モニタリング: ページに新しい外部ドメインが出現した際にアラート
すぐにできる改善策: HTML内のすべての タグをリストアップし、外部ドメインから読み込まれているものを確認します。認識できないものや不要なものは削除します。各削除がセキュリティとページ速度を向上させます。
マルウェア検出とGoogle安全なブラウジング
Googleは、マルウェアを配布したりフィッシングコンテンツをホストしていることで知られるサイトの安全なブラウジングリストを維持しています。ここにリストされることはSEOにとって壊滅的です — Googleはユーザーがあなたのサイトを訪れる前に全画面の警告を表示します。
サイトがフラグされる方法:
- マルウェアを配布する侵害されたサイト(ハッキングされたWordPressなど)
- 悪意あるサイトへのリダイレクトを行うスクリプトが挿入される
- あなたのドメインにホストされたフィッシングページ
- マルウェアへのリンクを持つユーザー生成コンテンツ
- 危険としてフラグされたファイルのホスティング
安全なブラウジングステータスのチェック:
https://transparencyreport.google.com/safe-browsing/search?url=yourdomain.com
またはGoogle Search Console: セキュリティ問題セクションで。
予防策:
- すべてのソフトウェアを最新の状態に保つ(CMS、プラグイン、ライブラリ)
- 強力でユニークな管理者パスワード + 2FAを使用
- ファイルの整合性を監視(不正な変更を検出)
- ユーザーがアップロードしたコンテンツをスキャン
- 使用していないプラグイン/テーマを削除
- 管理者ユーザーを定期的にレビュー
フラグが立った場合:
- マルウェア/フィッシングコンテンツを特定し削除する
- すべてのソフトウェアを更新し、すべてのパスワードを変更する
- Google Search Consoleでレビューをリクエスト
- レビューは通常1-3日かかる
- 30日間注意深く監視する(再感染が一般的)
すぐにできる改善策: transparencyreport.google.comでサイトをチェックします。クリーンであれば、CMSとすべてのプラグインを最新の状態に保ちましょう。
セキュリティSEOチェックリスト
- [ ] 自動更新が設定された有効なSSL証明書
- [ ] すべてのページでHTTP → HTTPSのリダイレクト(301、302ではない)
- [ ]
max-age>= 31536000のHSTSヘッダー - [ ] コンテンツセキュリティポリシーヘッダーが構成されている
- [ ] X-Content-Type-Options: nosniff
- [ ] X-Frame-Options: DENYまたはSAMEORIGIN
- [ ] Referrer-Policy: strict-origin-when-cross-origin
- [ ] 使用されていない機能を無効にするPermissions-Policy
- [ ] 混合コンテンツがない(HTTPSページ上のHTTPリソース)
- [ ] 感度の高いファイルが公開されていない(.env、.git、設定ファイル)
- [ ] サーバーバージョンヘッダーが削除または一般的である
- [ ] すべてのソフトウェア/プラグインが最新である
- [ ] Google安全なブラウジングステータス: クリーン
- [ ] サードパーティスクリプトが監査され、最小限に抑えられている
- [ ] 重要な外部スクリプトにSRIハッシュがある
一般的なセキュリティの間違い(SEOの影響に基づくランキング)
- 期限切れのSSL証明書 — 直ちにランク落ち + ブラウザ警告
- 混合コンテンツ — 信頼信号を低下させ、部分的な暗号化が無効
- HSTSなし — 最初のリクエストが脆弱、弱いセキュリティ姿勢を示す
- CSPがない — 任意のスクリプトの実行を許可する(XSSベクトル)
- 感度の高いファイルが公開されている — APIキーを含む
.env、ソースコードを含む.git - 古いCMS/プラグイン — 既知の脆弱性、最終的な侵害
- セキュリティヘッダーがまったくない — セキュリティを考慮していないことを示す
- 過剰に許可されたサードパーティスクリプト — 制御できないセキュリティホール
次のステップは?
ステップ8: AIの可視性 — 2026年のSEOの最前線。Google AI概要、ChatGPTの引用、Perplexityの参照、Gemini — 最も競争相手が考慮していない急成長している発見チャネルを最適化する方法。
このガイドはLANGRの13ステップのSEOシリーズの一部です。無料監査を実行して、あなたのサイトが13の分野でどこに位置しているかを確認してください。