SEO対策コース/カリキュラム/第2章: テクニカル SEO を自動チェック/2-3 モバイル SEO と HTTPS 対応チェック

2-3 モバイル SEO と HTTPS 対応チェック

無料

モバイルファーストインデックスとレスポンシブ対応、HTTPS / HSTS / CSP などセキュリティヘッダを Claude Code で一括点検。順位に直結する技術要件を 10 項目で診断します。

第2章: テクニカル SEO を自動チェック45分

このレッスンのゴール

前回の robots.txt とサイトマップで「ロボットに見てもらう導線」を整えたあとは、「見てもらった結果、ちゃんと評価されるか」という観点に進みます。今回のテーマはモバイル対応とセキュリティの 2 本柱です。

ポイント

このレッスンで持ち帰るもの

モバイルファーストインデックスの仕組みと、PC との表示差がなぜ順位低下に直結するのかを理解する
レスポンシブデザインの基本（viewport / メディアクエリ / 流動レイアウト）を頭の中で再構成できる
スマホ UX チェックリスト 10 項目を、自分のサイトに当てはめて点検できる
HTTPS / HSTS / CSP / X-Frame-Options など主要なセキュリティ要素をひと言で説明できる
Claude Code に ==/seo technical== を投げて、モバイルとセキュリティをまとめて棚卸しできる
失敗パターン 3 つ（モバイル非対応 / 混在コンテンツ / CSP が厳しすぎ）の見分け方を覚える

所要時間 — 約 45 分（手を動かしながらで 60 分くらい） 難易度 — ★★☆☆☆（前回 2-1, 2-2 を終えていれば OK）

1. なぜ「モバイル」と「セキュリティ」を 1 回でまとめるのか

どちらも「サイトを開いた瞬間に Google が品質判定に使う基礎レイヤー」だからです。レストランで言えば、料理の味より前に「店の入口がボロボロ」「ドアに鍵がかかっていない」と感じたら減点しますよね。Google も同じで、コンテンツの中身を読む前に「入口の安全さ・使いやすさ」を先に評価しています。

モバイル対応 = 入口の幅が広く、誰でも入れること
セキュリティ = 入口に鍵がかかっていて、客が安心して入れること

ここでつまずくと、いくらコンテンツを磨いてもスタートラインに立てません。だから 2-1（Core Web Vitals）/ 2-2（クロール導線）の直後にこのレッスンを置きました。

気づき

SEO の土台は「速さ・到達性・モバイル・安全」の 4 点セット。3 章以降のコンテンツ最適化は、この土台が出来ている前提でこそ効果が出ます。

2. モバイルファーストインデックスの仕組み

2.1 「PC 版」ではなく「スマホ版」を見ている

2018 年に Google はモバイルファーストインデックス（MFI）を導入し、2023 年 10 月までに全サイトの評価基準を完全にスマホ版へ切り替えました。Google のクローラーはスマホサイズで見たときのページを取りに行き、それをインデックスに登録します。PC 版がどれだけ綺麗でも、スマホ版が崩れていたら順位は下がるという冷たい現実です。

2.2 日本では検索の 7 割以上がスマホから

日本国内では検索クエリの 70〜80% がスマートフォン経由です。BtoB 系のキーワードでも半分以上はスマホからアクセスされます。スマホでまともに動かないサイトは、ユーザーの大多数を取りこぼしながら Google からも減点されるという二重損失です。

2.3 Google が見ているのは何か

Google のクローラー（Googlebot Smartphone）は、ビューポート幅約 412px（Pixel 7 相当）で JS も実行しつつ、CSS / 画像 / フォントを取得します。「スマホ版だけ画像を出さない」「重要コンテンツを隠す」のような実装をすると、「コンテンツがないページ」として扱われます。

Bad

よくある誤解 — 「スマホ版は情報量を減らしたほうがシンプルで親切」これは SEO 的には自殺行為です。スマホ版こそが評価対象なので、ここから情報を削ると評価対象そのものが薄くなります。情報量はそのまま、表示の仕方だけ最適化するのが正解です。

3. レスポンシブデザインの基本

モバイル対応にはレスポンシブ / 動的配信 / 別 URL の 3 方式がありますが、Google が公式に推奨するのはレスポンシブです。URL が 1 つに統一され、被リンクの分散も起きず、運用も 1 ファイルで済むからです。

3.1 viewport メタタグ — まずはこの 1 行

レスポンシブの第一歩は、<head> に viewport を入れることです。これが無いとスマホでも「PC 表示を縮小したもの」が出てしまい、文字が小さすぎて読めません。

<!DOCTYPE html>
<html lang="ja">
  <head>
    <meta charset="UTF-8">
    <meta name="viewport" content="width=device-width, initial-scale=1.0">
    <title>サンプル</title>
  </head>
  <body>...</body>
</html>

==width=device-width は「画面の物理幅をそのまま使え」、initial-scale=1.0 は「初期ズームを 100% にしろ」という意味です。この 1 行が無いだけで Google から「モバイル非対応」と判定されます== ので、最重要チェック項目の 1 つです。

3.2 メディアクエリと流動レイアウト

CSS のメディアクエリで「画面幅が ◯◯ px 以下のときだけこのスタイル」と切り替えます。最近はモバイルファーストの書き方が主流で、デフォルトをスマホ用、画面が広くなったら追加スタイルを当てる順序です。

/* デフォルト = スマホ */
.main { padding: 16px; }
h1 { font-size: 20px; }

/* タブレット以上 */
@media (min-width: 641px) {
  .main { padding: 24px; }
  h1 { font-size: 24px; }
}

/* PC */
@media (min-width: 1025px) {
  .sidebar { width: 280px; }
}

固定幅（width: 320px）は使わず、==width: 100% / max-width / flex / grid / clamp() などの相対指定にします。Grid と Flexbox== を覚えると、メディアクエリすら不要になることが多いです。

ポイント

container-type: inline-size と @container クエリを使うと、親コンテナの幅に応じてレイアウトを変えられます。デザインシステムを作るときに便利です。

4. モバイル UX チェックリスト 10 項目

スマホで自分のサイトを開きながら、上から順に確認していってください。

#	項目	合格基準
1	viewport タグ	`width=device-width, initial-scale=1`
2	文字サイズ	本文 16px 以上
3	タップ領域	48 × 48px 以上（指で押せる）
4	ボタン同士の間隔	8px 以上のすき間
5	横スクロール	出ない
6	画像の幅	`max-width: 100%; height: auto`
7	フォーム入力	`inputmode` で適切な IME
8	ポップアップ	侵入型インタースティシャル禁止
9	クリック遅延	viewport 設定で自動解消
10	フォントロード	`font-display: swap`

特に #8 のインタースティシャルは要注意。スマホで開いた瞬間に大きな広告やニュースレター登録モーダルが出ると、Google は「侵入型インタースティシャル」として明確に減点します。表示するならスクロール後や 2 ページ目以降に。

気づき

指で押せるかどうかがモバイル UX の本質。マウスポインタは 1 ピクセル単位で正確ですが、指は 8〜10mm の太さがあります。デザイン上ボタンが小さくても、padding を多めに取ってタップ判定領域だけ大きくすれば合格です。

5. HTTPS 必須化と SSL 証明書

5.1 HTTPS は順位要因

2014 年に Google は「HTTPS は順位要因」と公式発表。2018 年からは Chrome が HTTP サイトを「保護されていない通信」と警告するようになり、ユーザー離脱率も上がるダブルパンチ状態です。

5.2 鍵マークが意味するもの

ブラウザの鍵マーク🔒 は暗号化 / 完全性 / 認証の 3 つを保証しています。問い合わせフォーム・ログイン・決済を HTTP のまま運用していたら、入力した個人情報が誰でも盗み見できる状態で流れます。

5.3 証明書はもう無料で取れる

Let's Encrypt が完全無料で 90 日有効の証明書を発行しており、Cloudflare Pages / Vercel / Netlify / GitHub Pages / Cloud Run など主要なホスティングでは自動有効化されます。現代では HTTPS 化していない理由がほぼ存在しません。

ポイント

HTTPS 移行で気をつけること

301 リダイレクトで HTTP → HTTPS を恒久リダイレクト
canonical タグの URL も HTTPS 版に更新
サイトマップ・robots.txt の URL も HTTPS 化
混在コンテンツ（Mixed Content）をなくす（次節）
Search Console の URL プロパティを HTTPS 版で再登録

5.4 混在コンテンツ（Mixed Content）に注意

HTTPS ページ内に HTTP の画像・スクリプト・CSS が混ざると、ブラウザが警告を出して鍵マークが消えます。これを混在コンテンツと呼びます。古い CMS や外部の動画・地図埋め込みで発生しがち。Chrome DevTools の Console で「Mixed Content: ...」を 1 つずつ潰します。

6. セキュリティヘッダー — HSTS / CSP / X-Frame-Options

HTTPS だけでは防げない攻撃が、まだいくつかあります。それを補強するのがセキュリティヘッダーです。HTTP レスポンスに数行追加するだけで、サイト全体の安全性が一段階上がります。

6.1 HSTS（HTTP Strict Transport Security）

HSTS は「このサイトに来るときは絶対に HTTPS を使え」とブラウザに命令するヘッダーです。ユーザーが http://example.com と打っても自動で https:// に書き換わります。

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

==max-age=31536000 で 1 年間設定を記憶、includeSubDomains でサブドメインも含める、preload== でブラウザに最初から組み込ませます（HSTS Preload List 登録が必要）。

6.2 CSP（Content Security Policy）

CSP は「このページで実行していい JS / 読み込んでいい画像」をホワイトリスト形式で指定し、XSS（クロスサイトスクリプティング）攻撃を大幅に防ぎます。

Content-Security-Policy: default-src 'self'; script-src 'self' https://cdn.example.com; img-src 'self' data: https:;

CSP は強力な反面、設定が厳しすぎると正規の機能まで壊れます。最初は ==Content-Security-Policy-Report-Only== で観測モードで動かし、違反レポートを見ながら段階的に締めるのが安全です。

6.3 X-Frame-Options — クリックジャッキング対策

X-Frame-Options は「このページを iframe で他サイトに埋め込ませない」と宣言するヘッダー。これが無いと、悪意のあるサイトがあなたのページを透明な iframe で重ねて操作を盗むクリックジャッキングを仕掛けられます。

X-Frame-Options: SAMEORIGIN

最近は CSP の frame-ancestors で代替するのが主流ですが、古いブラウザ対応のため両方書くケースが多いです。

6.4 その他の重要ヘッダー

ヘッダー	役割	推奨値
`X-Content-Type-Options`	MIME 推測を無効化	`nosniff`
`Referrer-Policy`	リファラ漏れを制限	`strict-origin-when-cross-origin`
`Permissions-Policy`	カメラ・位置情報など API 利用制限	サービスに応じて

これらは securityheaders.com で URL を入れると、現状のスコア（A+ / A / B / ...）と不足分を一覧で見せてくれます。

ポイント

Cloudflare を前段に置いている場合は、ダッシュボードの「Security Headers」からチェックボックスでまとめて設定できます。コードに手を入れずに済むので、まず Cloudflare 経由で動かしてみるのも 1 つの手です。

7. Claude Code で一括チェックする手順

ここまでの内容を、Claude Code は 1 コマンドでまとめて検査できます。手で全部チェックするのは大変なので、まず機械に棚卸ししてもらい、そこから人間が判断する流れが速いです。

7.1 基本コマンド

# モバイル + セキュリティを一括診断
> /seo technical https://あなたのサイト.com

# 出力に含まれる主要項目
#  Mobile   : viewport / tap target / horizontal scroll / font-size
#  Security : HTTPS / HSTS / CSP / X-Frame-Options / Mixed Content

このレポートを見るだけで、どこに穴があるかが 30 秒で把握できます。

7.2 改善案を実装させる

問題が見つかったら、その場で Claude Code に修正を依頼します。

> 上のレポートで NG だった項目を全部直して。
> セキュリティヘッダーは Cloudflare Workers の設定ファイルに追記して。
> viewport タグは全 HTML ファイルに入っているか確認して、無いものに追加して。

Claude Code は ==Read/Edit/Bash を組み合わせて、設定ファイルと HTML を自動で書き換えます。差分は必ず (y/n)== で確認を求めてくるので、変更内容を見てから許可すれば安全です。

7.3 デプロイ前のチェックを自動化する

CI に組み込むと、デプロイ前に自動でチェックさせられます。GitHub Actions と組み合わせれば、PR を出した瞬間にスコアが PR コメントに貼られる運用も可能。慣れてきたら 5 章以降で扱う CLAUDE.md にワークフローを書き込んで、Claude に自動チェックさせるところまで持っていきます。

ポイント

手動チェックも併用する

Claude Code は自動チェックは得意ですが、「指で押した感触」「実機での読みやすさ」は判定できません。Chrome DevTools の Device Mode（F12 → 左上のスマホアイコン）で iPhone SE 表示を確認する手動チェックも、月に 1 回はやるようにしてください。

8. 失敗パターン — モバイル非対応 / 混在コンテンツ / CSP 厳しすぎ

ここからは、実際の現場でよく見る「やらかし」3 連発です。自分のサイトが当てはまっていないかチェックしながら読んでください。

8.1 失敗パターン A — viewport を入れ忘れている

Bad

症状 — PC では問題ないのに、スマホで開くと文字が小さすぎて読めない。横スクロールが必要。

原因 — <head> に viewport メタタグが入っていない。古いテンプレートをそのまま流用したケースが多い。

修正 — <head> に 1 行追加。

<meta name="viewport" content="width=device-width, initial-scale=1.0">

注意 — 過去に user-scalable=no や maximum-scale=1 を入れているサイトはアクセシビリティ違反として減点されます。これらは外してください。

8.2 失敗パターン B — 混在コンテンツで鍵マークが外れる

Bad

症状 — 鍵マークがグレーや黄色になり、Console に「Mixed Content」の警告が複数件。

原因 — HTTPS のページに HTTP の画像・スクリプト・iframe が混ざっている。CMS のテーマや外部埋め込みが古い URL を持っている。

修正 — 該当箇所を ==https://== またはプロトコル相対 // に書き換える。動画埋め込み iframe など、外部サイトの HTTPS 対応も確認する。

8.3 失敗パターン C — CSP が厳しすぎてサイトが壊れる

Bad

症状 — Content-Security-Policy を設定した途端、Google Fonts が読み込まれない、Google Analytics が動かない、ボタンを押しても反応しない。

原因 — script-src 'self' のように自サイトだけ許可し、外部 CDN を許可していない。'unsafe-inline' を拒否しているのにインライン JS が残っている。

修正の順番

まず ==Content-Security-Policy-Report-Only== で違反だけレポートさせる
report-uri で違反ログを 1 週間集める
ログに出てきた正規ドメインをホワイトリストに追加
違反がゼロになったら本番モードに切り替え

大事な原則 — 「最初から完璧な CSP を書こうとしない」。観測 → 段階導入 → 強化の順序を守る。

気づき

失敗パターンの共通項は、「最初から完璧を目指して、観測なしで一気に締めた」こと。モバイル対応もセキュリティヘッダーも、まず観測モード → 段階的に強化が鉄則です。

9. まとめ

Google はスマホ版を基準にサイトを評価する（モバイルファーストインデックス）
レスポンシブの第一歩は viewport メタタグ。これが無いと無条件でモバイル非対応判定
タップ領域 48px / 本文 16px / 横スクロールなしの 3 つは絶対死守
HTTPS は順位要因かつ必須機能。Let's Encrypt + モダンホスティングで無料自動化
セキュリティの基本三点セットは HSTS / CSP / X-Frame-Options。securityheaders.com でスコアを定期確認
CSP は観測モードから始める。いきなり本番投入すると正規機能が壊れる
==/seo technical== でモバイル + セキュリティをまとめて棚卸し。手動チェックと併用

章末演習

章末演習 — このレッスンの内容を、自分のサイトに当てはめて点検しましょう。所要時間 15〜20 分。

Chrome DevTools の Device Mode で iPhone SE 表示を開き、トップページのスクリーンショットを撮ってください。横スクロールが出ていないか・タップ領域は十分か、目視で 10 個チェックしてください
https://securityheaders.com/?q=あなたのサイト.com にアクセスし、現在のスコア（A+ / A / B など）を確認してください。F や D だった場合、不足しているヘッダーをメモしてください
Claude Code に ==/seo technical https://あなたのサイト.com を投げて、モバイル + セキュリティの全項目スコアを取得してください。レポートを保存し、NG が出た項目を 3 つ選んで== 改善案を Claude Code に書かせてみてください

次のステップ

3-1: E-E-A-T 対策の基本フレームワーク — 次章。技術 SEO の土台を整えたら、コンテンツ品質と E-E-A-T で順位を伸ばします
4-1: 構造化データ（JSON-LD）でリッチリザルトを狙う — モバイル対応と同じく検索 UI を整える施策。リッチリザルト獲得の手順に進めます
5-1: SEO 戦略の立て方｜優先順位の決め方 — テクニカル SEO の修正が一段落したら、戦略レイヤーで全体最適を学びます