seo-technical-audit

テクニカル SEO 監査

---

クロール可能性

検索エンジンがページを検出し、アクセスできる必要があります。クロール可能性に問題があると、インデックス登録が完全に妨げられます。

Robots.txt

クローラーがアクセスできる URL を制御します。

# Allow all crawlers access to everything
User-agent: *
Allow: /

# Block specific paths
User-agent: *
Disallow: /admin/
Disallow: /api/
Disallow: /staging/
Disallow: /*?sort=
Disallow: /*?filter=

# Sitemap reference (always include)
Sitemap: https://example.com/sitemap.xml

重要なルール：

• CSS／JS ファイルをブロックしないでください（Google がページをレンダリングするために必要です）
• 重要なコンテンツのパスを誤ってブロックしないでください
• 変更をデプロイする前に analyze_robots_txt でテストしてください
• Crawl-delay は Google では無視されます（Bing／Yandex では有効です）

Meta Robots と X-Robots-Tag

ページ単位のクロールおよびインデックス登録の指示です。

指示	効果
index	インデックス登録を許可します（デフォルト）
noindex	インデックス登録を防ぎます — 検索結果から削除されます
follow	このページ上のリンクをたどります（デフォルト）
nofollow	このページ上のすべてのリンクをたどりません
noarchive	キャッシュ版を表示しません
nosnippet	検索結果にテキストのスニペットを表示しません
max-snippet:N	スニペットを N 文字に制限します
max-image-preview:large	大きな画像プレビューを許可します

<meta name="robots" content="noindex, follow">


X-Robots-Tag: noindex, nofollow

MCP ツール： analyze_page は meta robots と HTTP ヘッダーの両方の指示を抽出します。

---

インデックス登録

Canonical タグ

検索エンジンに優先する URL を伝える決定的な方法です。

ルール：

• インデックス登録可能なすべてのページに、自己参照 canonical を設定します
• 絶対 URL のみを使用します（/page ではなく https://example.com/page）
• 一貫性が必要です。canonical URL は 200 を返す必要があります（リダイレクトや 404 ではありません）
• 1 ページにつき canonical は 1 つです（複数ある場合、Google は最初のものを使用します）
• 両方が指定されている場合、HTTP ヘッダーの canonical が HTML の canonical より優先されます

Noindex と Canonical

シナリオ	使用するもの
ページを検索結果に表示させない	noindex
重複ページで、別のバージョンを優先する	優先するバージョンへの canonical
URL パラメーターのバリエーション	クリーンな URL への canonical
ページ分割されたコンテンツ	各ページに自己参照 canonical

サイトマップの送信

• Google Search Console から送信します
• インデックス登録可能なページはすべてサイトマップに含めます
• noindex ページはサイトマップに含めないでください
• サイトマップは 1 ファイルあたり 50,000 URL／50MB 未満にします（大規模サイトではサイトマップインデックスを使用します）

MCP ツール： analyze_sitemap は構造を検証し、gsc_sitemaps は送信状況を確認します。

---

Core Web Vitals

Google のページエクスペリエンスに関するシグナルです。実ユーザーデータ（CrUX）とラボデータ（Lighthouse）を使って測定します。

しきい値（2024 年以降）

指標	良好	改善が必要	不良
LCP（最大コンテンツの描画）	≤ 2.5s	≤ 4.0s	> 4.0s
INP（次の描画までのインタラクション）	≤ 200ms	≤ 500ms	> 500ms
CLS（累積レイアウトシフト）	≤ 0.1	≤ 0.25	> 0.25

LCP の最適化

最大コンテンツの描画は、最も大きな可視要素のレンダリングが完了するタイミングを測定します。

LCP が不良になる一般的な原因：

1. サーバー応答が遅い（TTFB > 800ms）→ サーバーを最適化し、CDN を使用します
2. レンダリングをブロックするリソース → 重要でない CSS／JS の読み込みを遅延させます
3. リソースの読み込みが遅い → LCP 画像を最適化／圧縮し、preload を使用します
4. クライアントサイドレンダリング → 重要なコンテンツをサーバーサイドでレンダリングします

すぐにできる改善：

• LCP 画像をプリロードします：<link rel="preload" href="hero.webp" as="image">
• 静的アセットに CDN を使用します
• サーバー応答を最適化します（キャッシュ、データベースクエリ）
• LCP 要素の遅延読み込みを避けます

INP の最適化

次の描画までのインタラクションは、ユーザー入力に対する応答性を測定します。

INP が不良になる一般的な原因：

1. メインスレッドをブロックする長時間の JavaScript タスク → 小さなタスクに分割します
2. 負荷の高いイベントハンドラー → デバウンスし、requestAnimationFrame を使用します
3. DOM サイズが大きい → DOM ノードを減らします（目標は 1,500 未満）
4. サードパーティスクリプト → 読み込みを遅延させるか、遅延読み込みします

CLS の最適化

累積レイアウトシフトは、視覚的な安定性を測定します。

CLS が低くなる主な原因：

1. サイズ指定のない画像 → 常に width と height を設定します
2. 表示領域を確保していない広告や埋め込みコンテンツ → aspect-ratio または min-height を使用します
3. Web フォントによる FOIT/FOUT → font-display: swap とプリロードを使用します
4. 動的に挿入されるコンテンツ → 挿入前に表示領域を確保します

MCP ツール： check_core_web_vitals は、すべての指標と具体的な最適化の提案を返します。

---

ページ速度の最適化

Core Web Vitals 以外にも、ページ全体の速度はユーザー体験とクロールバジェットに影響します。

クリティカルレンダリングパス

1. レンダリングを妨げるリソースを最小限に抑えます（重要な CSS はインライン化し、JS は遅延します）
2. 圧縮を有効にします（Brotli を推奨、最低限 gzip を使用）
3. キャッシュヘッダーを設定します（静的アセットには Cache-Control: max-age=31536000 を使用）
4. HTTP/2 または HTTP/3 を使用します
5. メインスレッドの処理を最小限に抑えます（JS の実行時間を短縮します）

画像の最適化

• 最新の形式（WebP/AVIF）を使用します
• レスポンシブ画像（srcset）を配信します
• ファーストビューより下の画像は遅延読み込みします
• 積極的に圧縮します（品質 80～85％）

リソースヒント

<link rel="preconnect" href="https://fonts.googleapis.com">
<link rel="preload" href="/critical.css" as="style">
<link rel="prefetch" href="/next-page.html">
<link rel="dns-prefetch" href="https://analytics.example.com">

---

モバイルフレンドリー

Google はモバイルファーストインデックスを採用しているため、インデックス登録されるのはサイトのモバイル版です。

要件

• Viewport メタタグ：<meta name="viewport" content="width=device-width, initial-scale=1">
• レスポンシブデザイン（コンテンツが画面サイズに合わせて調整されること）
• 横方向にスクロールしないこと
• タップ領域：最小 48x48px、間隔は 8px
• フォントサイズ：本文は最小 16px
• 邪魔なインタースティシャルがないこと（コンテンツを覆うポップアップなど）
• コンテンツの同等性：モバイル版にデスクトップ版と同じコンテンツがあること

MCP ツール： check_mobile_friendly は、モバイルのユーザビリティに関するすべての要素を評価します。

---

HTTPS とセキュリティ

HTTPS の要件

• すべてのページを HTTPS で配信すること（インデックスに HTTP ページがないこと）
• 有効な SSL 証明書を使用すること（期限切れではなく、ドメインが正しいこと）
• 混在コンテンツがないこと（HTTPS ページが HTTP リソースを読み込まないこと）
• HSTS ヘッダーを推奨します：Strict-Transport-Security: max-age=31536000; includeSubDomains
• HTTP ページは HTTPS に 301 リダイレクトします

HTTPS でよくある問題

問題	影響	修正方法
混在コンテンツ	中	すべてのリソース URL を HTTPS に更新します
証明書の期限切れ	重大	直ちに SSL 証明書を更新します
HTTP ページがインデックス登録されている	高	HTTP から HTTPS に 301 リダイレクトし、canonical も更新します
HSTS がない	低	HSTS ヘッダーを追加します

---

リダイレクト

リダイレクトの種類

コード	種類	使用するケース	SEO への影響
301	恒久的	URL が恒久的に変更された場合、コンテンツが移動した場合	リンクエクイティの約 95％を引き継ぎます
302	一時的	一時的な移動（A/B テスト、メンテナンス）	リンクエクイティを引き継ぎません
307	一時的（厳密）	302 と同じですが、HTTP メソッドを保持します	リンクエクイティを引き継ぎません
308	恒久的（厳密）	301 と同じですが、HTTP メソッドを保持します	リンクエクイティを引き継ぎます

リダイレクトの問題

• リダイレクトチェーン： A → B → C → D。推奨される最大ホップ数は 2 です。A から D に直接つなぐよう修正します。
• リダイレクトループ： A → B → A。重大なエラーで、ページにアクセスできなくなります。
• ソフト 404： ページが 200 を返すものの、「見つかりません」というコンテンツを表示します。実際の 404 を返す必要があります。
• 301 が必要な場面での 302： 恒久的な移動に一時的なリダイレクトを使用すると、リンクエクイティが無駄になります。

---

XML サイトマップ

要件

• /sitemap.xml に配置します（または robots.txt で参照します）
• 有効な XML 形式であること
• インデックス登録可能なページのみを含めます（noindex、404、リダイレクトは含めません）
• 正確な日付（ISO 8601）を <lastmod> に含めます
• サイトマップファイルあたりの URL は最大 50,000 件です
• ファイルあたりの非圧縮サイズは最大 50MB です
• 大規模なサイトではサイトマップインデックスを使用します

検証

<?xml version="1.0" encoding="UTF-8"?>
<urlset xmlns="http://www.sitemaps.org/schemas/sitemap/0.9">
  <url>
    <loc>https://example.com/page</loc>
    <lastmod>2026-01-15</lastmod>
    <changefreq>weekly</changefreq>
    <priority>0.8</priority>
  </url>
</urlset>

MCP ツール： analyze_sitemap は、サイトマップを解析、検証し、問題を報告します。

---

Hreflang（国際 SEO）

多言語または複数地域向けのサイトで使用します。Google に表示する言語・地域別のバージョンを伝えます。

構文

<link rel="alternate" hreflang="en-us" href="https://example.com/page">
<link rel="alternate" hreflang="en-gb" href="https://example.co.uk/page">
<link rel="alternate" hreflang="es" href="https://example.com/es/page">
<link rel="alternate" hreflang="x-default" href="https://example.com/page">

ルール

• 双方向性： ページ A がページ B を参照する場合、ページ B もページ A を参照する必要があります
• 自己参照： 各ページには、自身を指す hreflang を含める必要があります
• x-default： フォールバック／言語選択ページに含めます
• 戻りタグ： 参照される各 URL は、同じ hreflang セットを返す必要があります
• ISO 639-1 の言語コードを使用し、必要に応じて ISO 3166-1 の地域コードを追加します

---

HTTP ステータスコード（SEO への影響）

コード	意味	SEO 対応
200	OK	インデックス登録可能なすべてのページで期待されるステータスです
301	恒久的に移動	リンク評価を引き継ぎます。URL を恒久的に変更する場合に使用します
302	発見（一時的）	リンク評価を引き継ぎません。一時的な移動にのみ使用します
304	未変更	良好 — 効率的なキャッシュです
404	見つかりません	サイトマップから削除し、ここを指す内部リンクを修正します
410	消失	恒久的に削除されています。インデックスから削除するシグナルとして、404 より強力です
500	サーバーエラー	直ちに修正します — クロールとインデックス登録が阻害されます
503	サービス利用不可	一時的です。Google は再試行します。計画メンテナンスに使用します

---

技術監査のワークフロー

技術監査を完全に実施する場合の推奨順序：

1. クロール可能性： analyze_robots_txt → クロールをブロックする問題がないか確認します
2. サイトマップ： analyze_sitemap → 構造と URL を検証します
3. ページ単位： analyze_page → meta robots、canonical、リダイレクト、ステータスを確認します
4. パフォーマンス： check_core_web_vitals → LCP、INP、CLS のスコアを確認します
5. モバイル： check_mobile_friendly → ビューポート、タップ対象、フォントを確認します
6. スキーマ： extract_schema → 構造化データを検証します
7. GSC データ： gsc_index_coverage → Google による実際のインデックス登録状況を確認します

完全な問題カタログについては、ERROR_CATALOG.md を参照してください。 詳細な監査方法については、AUDIT_WORKFLOW.md を参照してください。 ステータスコードの完全なリファレンスについては、HTTP_STATUS_REFERENCE.md を参照してください。