seo-technical

テクニカル SEO 監査

カテゴリ

1. クロール可能性

• robots.txt：存在し、有効で、重要なリソースをブロックしていないこと
• XML サイトマップ："${CLAUDE_PLUGIN_ROOT}/scripts/claude-seo" run sitemap_discovery.py <url> --json を実行します。found に有効なエントリがあることを確認し、古い、または安全でない robots.txt の指定は、機能している代替の場所とは分けて報告します
• Noindex タグ：意図的なものか、誤って設定されたものか
• クロール深度：重要なページがホームページから 3 クリック以内にあること
• JavaScript のレンダリング：重要なコンテンツの表示に JS の実行が必要か確認します（方法はセクション 8）
• クロールバジェット：大規模サイト（>10k ページ）では、効率が重要です
• Googlebot の取得上限：Googlebot が取得するのは、HTML の最初の 2MB と PDF の最初の 64MB です（非圧縮時。広範なクローラーインフラストラクチャのデフォルトは 15MB）。これは長年変わっておらず、2026 年の変更ではありませんが、インライン base64 画像、容量の大きすぎるインライン CSS／JS、肥大化したナビゲーションにより、重要なコンテンツや JSON-LD が上限を超え、インデックスから外れる可能性があります。主要なコンテンツと構造化データは最初の 2MB 以内に収めてください。
• クロール頻度は自動調整されます（5xx エラーや応答の遅延があると頻度を下げます）。手動でクロール頻度を制御する方法はありません（旧 Search Console の設定は 2024 年 1 月に削除されました）。サイトマップ、サーバーの応答性、robots の制御を通じてクロールに影響を与えます。
• Google の正規のクロール／robots リファレンスは developers.google.com/crawling に移動しました（2025-11-20 に移行）。IP 範囲ファイルは /crawling/ipranges/ に移転し、googlebot.json は common-crawlers.json に名称変更されました。
• AMP に独立したランキング上の優位性はありません。2026-07-01 以降、Google 検索はユーザーをパブリッシャーがホストする AMP URL に直接誘導するため、AMP Cache、AMP Viewer、署名付き交換の保守は推奨しないでください。ほかのページと同じコンテンツ、操作の同等性、品質要件に照らして AMP を監査してください。

AI クローラーの管理

2025〜2026年現在、AI 企業はモデルのトレーニングや AI 検索の強化を目的として、積極的にウェブをクロールしています。robots.txt を使ってこれらのクローラーを管理することは、テクニカル SEO において重要な考慮事項です。

既知の AI クローラー（クローラーごとの robots.txt での動作を含む正式な表は seo-geo にあります）：

クローラー	会社	robots.txt のトークン	目的
GPTBot	OpenAI	GPTBot	モデルのトレーニング（ChatGPT Search ではありません）
OAI-SearchBot	OpenAI	OAI-SearchBot	ChatGPT Search での引用可能性
ChatGPT-User	OpenAI	ChatGPT-User	リアルタイムのブラウジング（ユーザーが開始）
ClaudeBot	Anthropic	ClaudeBot	モデルのトレーニング（Claude 検索での引用可能性には影響しません）
Claude-SearchBot	Anthropic	Claude-SearchBot	Claude の検索結果での引用可能性
PerplexityBot	Perplexity	PerplexityBot	Perplexity の検索インデックス（モデルのトレーニングではありません）
Bytespider	ByteDance	Bytespider	モデルのトレーニング
Google-Extended	Google	Google-Extended	Gemini のトレーニングとグラウンディング、および検索の生成 AI 機能を支えるモデルのトレーニング（検索への掲載やランキングには影響しません）
Applebot-Extended	Apple	Applebot-Extended	Apple Intelligence のトレーニングをオプトアウト（Siri／Spotlight／Safari には影響しません）
CCBot	Common Crawl	CCBot	オープンデータセット

重要な違い：

• Google-Extended をブロックすると、Gemini のトレーニングやグラウンディングでの利用（および検索の生成 AI 機能を支えるモデルのトレーニング）は防げますが、Google 検索のインデックス登録や AI Overviews には影響しません（これらは Googlebot を使用します）。
• GPTBot をブロックすると OpenAI によるトレーニングは防げますが、ChatGPT Search での引用可能性には影響しません。これは OAI-SearchBot が制御します。また、ユーザーが開始するブラウジング（ChatGPT-User）にも影響しません。引用可能性について主張する場合は OAI-SearchBot を確認してください。GPTBot の状態から分かるのは、トレーニングでの利用についてのみです。
• ClaudeBot をブロックすると Anthropic によるモデルのトレーニングは防げますが、Claude 独自の検索機能での引用可能性には影響しません。これは Anthropic のクローラーサポート記事によると、Claude-SearchBot が制御します。Claude の検索での引用可能性について主張する場合は Claude-SearchBot を確認してください。ClaudeBot の状態から分かるのは、トレーニングでの利用についてのみです。
• Applebot-Extended をブロックすると、Apple Intelligence／生成モデルのトレーニングでの利用をオプトアウトできますが、Siri、Spotlight、Safari を通じた発見可能性には影響しません。Apple のサポート記事によると、これらは Applebot に従います。また、Applebot-Extended 自体はクロールしません。

例：AI クローラーを選択的にブロックする場合

# Allow search indexing, block AI training crawlers
User-agent: GPTBot
Disallow: /

User-agent: Google-Extended
Disallow: /

User-agent: Bytespider
Disallow: /

# Allow all other crawlers (including Googlebot for search)
User-agent: *
Allow: /

推奨事項： ブロックする前に、AI における可視性の戦略を検討してください。AI 検索クローラーをブロックすると、その検索エンジンの回答からサイトが除外されます。許可すればトラフィックが増えると約束してはいけません。AI クローラー／フェッチャーの分類の全容については、seo-geo スキルを参照してください。

Google のユーザーが開始するフェッチャーは、通常 robots.txt のルールを無視します（他社の挙動は異なり、Anthropic の Claude-User はルールに従います）。Google は現在、Google-Agent（ユーザーが開始するエージェント型ブラウジング）、Google-GeminiNotebook（旧 Google-NotebookLM）、Google Messages を、robots.txt ではブロックできない ユーザーが開始する フェッチャーとして説明しています。代わりにサーバー側のアクセス制御を使用してください。一方、Google-Extended と Google-CloudVertexBot は robots.txt に従います。新たな動向として、Web Bot Auth（RFC 9421）では、Signature-Agent ヘッダーと agent.bot.goog のキーディレクトリを使って、ボットが暗号学的に認証できます（Google-Agent が使用）。従来の逆引き DNS 検証は引き続きフォールバックとして使用されます。

2. インデックス登録可能性

• カノニカルタグ：自己参照型で、noindex と競合しないこと
• 重複コンテンツ：類似した重複ページ、パラメーター付き URL、www と www なし
• カノニカル化の修正には時間がかかる場合があります。Google は再評価中、修正済みページを重複クラスターに最大 2 週間保持することがあります。修正直後にカノニカルが変わらなくても、修正に失敗した証拠だと判断しないでください。
• 薄いコンテンツ：種類ごとの最低語数を下回るページ
• ページネーション：各ページへのクロール可能な <a href> リンク（Google は rel=next/prev を使用しなくなりました。2019 年に発表済みです）。各ページに自己参照型のカノニカルを設定します。もっと読み込む機能や無限スクロールでは、その背後にページ分割された URL が必要です
• Hreflang：多言語・多地域のサイトで正しく設定されていること
• インデックスの肥大化：クロールバジェットを消費する不要なページ

3. セキュリティ

• HTTPS：強制され、有効な SSL 証明書を使用し、混在コンテンツがないこと
• セキュリティヘッダー：
  • Content-Security-Policy（CSP）
  • Strict-Transport-Security（HSTS）
  • X-Frame-Options
  • X-Content-Type-Options
  • Referrer-Policy
• HSTS プリロード：セキュリティ要件の厳しいサイトでは、プリロードリストへの登録を確認します
• 戻るボタンの乗っ取り（スパムポリシー違反、悪意のある行為）：history.pushState／replaceState を使って戻るボタンを機能しなくするページにフラグを付けます（サードパーティの広告／ライブラリプラットフォームが挿入したスクリプトも含みます）。Google のスパムポリシーに 2026-04-13 に追加され、2026-06-15 から取り締まりが開始されています（手動による対策＋自動降格）。Critical として扱います。
• サーバースタックの CVE への露出（読み取り専用、所有者の許可を得たサイトのみ）：既知の重大な CVE を抱えるサーバーサイドスタックをサイトが実行している場合に検出し、所有者がパッチを適用するか、サイトをオフラインにできるようにします。通常のレスポンス（X-Powered-By、Set-Cookie: PHPSESSID、WordPress の wp-json／generator シグナル、_next/static などの静的／Node マーカー）からスタックを読み取ります。ファジングやエクスプロイトペイロードの送信は決して行わず、オペレーターが管理していないサイトを調査しないでください。現在の PHP の重大な RCE アドバイザリ（CVE-2026-109618 / CVE-2026-109619、CVSS 9.2、PHP 8.5.12 / 8.4.27 / 8.3.36 / 8.2.35 で修正済み）、検出シグナル、レポート区分については references/stack-cve-exposure.md を参照してください。修正済みバージョンより古い PHP バージョンが確認された場合は Critical として扱います。このアドバイザリにおいて、PHP のシグナルがないマネージドホストまたは静的ホストは露出していません。

4. URL 構造

• クリーンな URL：内容を説明するハイフン区切りの URL を使用し、コンテンツにクエリパラメーターを使用しないこと
• 階層：サイトのアーキテクチャを反映した論理的なフォルダー構造
• リダイレクト：チェーンを作らない（最大 1 ホップ）。恒久的な移動には 301 を使用
• URL の長さ：100 文字を超える場合にフラグを付ける
• 末尾のスラッシュ：一貫して使用すること

5. モバイル最適化とページエクスペリエンス

• レスポンシブデザイン：viewport メタタグ、レスポンシブ CSS
• タッチターゲット：WCAG 2.2 AA では、CSS px で少なくとも 24x24 が必要です。間隔を設けた 48x48px が使いやすさの目安です（Google の要件ではありません）。
• フォントサイズ：拡大しなくても読めるテキスト（16px を基本とするのは一般的な慣行であり、Google のルールではありません）。
• 横スクロールがないこと
• モバイルファーストインデックス：Googlebot Smartphone が主要なクローラーです（2024 年に導入完了）。モバイル版は厳密には必須ではありません（Google は「非常に強く推奨」としています）。モバイルで動作しないサイトでもインデックス登録される可能性はありますが、実際のリスクは完全な除外ではなく、コンテンツや情報の同等性が失われることです。
• モバイル版とデスクトップ版のコンテンツの同等性（最も重要なモバイルチェック）：主要コンテンツが同等であること、robots メタタグが一致していること、タイトルと説明文が一致していること、構造化データが同等であること、リソースをクロールできることを確認します。ユーザー操作が必要な主要コンテンツの遅延読み込みは避けてください。
• 煩わしいインタースティシャル／広告密度：全画面インタースティシャル、単独の同意確認ページへのリダイレクト、表示し続けるブロッキングダイアログ、過剰または注意をそらす広告密度（ページエクスペリエンスの明示的な評価項目）にフラグを立てます。許容されるもの：小さなバナー、一般的な CMS／法務関連のダイアログ。
• 「続きを読む」へのディープリンク：重要なコンテンツはページ読み込み直後に表示してください（タブ／アコーディオンの背後に隠さない）。読み込み時にスクロール位置を強制変更せず、URL のハッシュフラグメントを保持してください。展開可能なセクションの背後に隠されたコンテンツは、対象として認められにくくなります。

ページエクスペリエンスは指針であり、単一のランキングシステムではありません。 ランキングに直接反映されるのは Core Web Vitals のみです。HTTPS は確認済みのシグナルですが、影響は小さいものです（Google は 2014 年の発表時に、非常に軽微なシグナルと説明しました）。ページエクスペリエンスが低くても関連性が高ければ評価されるため、セキュリティヘッダーを過度に重視しないでください。注：Search Console の独立した ページエクスペリエンスレポートは削除済みです（Core Web Vitals レポートと HTTPS レポートで確認してください）。

6. Core Web Vitals

• LCP（Largest Contentful Paint）：目標 <=2.5s
• INP（Interaction to Next Paint）：目標 <=200ms
  • INP は 2024 年 3 月 12 日に FID に置き換わりました。FID は 2024 年 9 月 9 日に Chrome のフィールドデータツール（CrUX API、PageSpeed Insights）から削除されました（Lighthouse はラボツールであり、FID を報告したことはありません）。FID にはどこにも言及しないでください。
• CLS（Cumulative Layout Shift）：目標 <=0.1
• 評価には実ユーザーデータの 75 パーセンタイルを使用します。
• MCP が利用可能な場合は、PageSpeed Insights API または CrUX データを使用します。

7. 構造化データ

• 検出対象：JSON-LD（推奨）、Microdata、RDFa
• Google がサポートするタイプに照らして検証します。
• 詳細な分析については seo-schema スキルを参照してください。

8. JavaScript レンダリング

• 方法："${CLAUDE_PLUGIN_ROOT}/scripts/claude-seo" run agentic_check.py <url> --json は、生の HTML に含まれる可視単語を報告します（server-rendered）。Chromium が利用可能な場合は、render_page.py <url> --mode always --json の結果と比較してください。Chromium が利用できない場合は、生の HTML の結果を報告し、レンダリング後のコンテンツとは比較していないことを明記してください。
• 初期 HTML でコンテンツが表示されるか、JS が必要かを確認します。
• クライアントサイドレンダリング（CSR）とサーバーサイドレンダリング（SSR）を特定します。
• インデックス登録の問題につながる可能性がある SPA フレームワーク（React、Vue、Angular）にフラグを立てます。
• 動的レンダリングが検出された場合は、有効な設定ではなく技術的負債としてフラグを立てます。 Google は、複雑さとリソースコストが増すため、「回避策であり、推奨される解決策ではない」と説明しています。 https://developers.google.com/search/docs/crawling-indexing/javascript/dynamic-rendering を参照してください。

推奨されるレンダリング戦略：

戦略	用途
SSR	公開 SEO コンテンツ、動的ページ
SSG	静的コンテンツ、ブログ、ドキュメント
CSR	認証が必要なコンテンツ／ログイン後のコンテンツのみ

推奨フレームワーク： Next.js、Astro、React Router v7 (Remix)、SvelteKit

JavaScript SEO：Canonical とインデックス登録のガイダンス（2025 年 12 月）

Google は 2025 年 12 月に JavaScript SEO のドキュメントを更新し、重要な点を明確にしました。

1. Canonical の競合： 生の HTML にある canonical タグと JavaScript によって挿入される canonical タグが異なる場合、Google はどちらか一方を使用することがあります。サーバーでレンダリングされた HTML と JS でレンダリングされた出力の canonical タグが同一になるようにしてください。
2. JavaScript と noindex： 生の HTML に <meta name="robots" content="noindex"> が含まれていて、JavaScript がこれを削除した場合でも、Google は生の HTML の noindex を尊重する可能性があります。初期 HTML レスポンスで正しい robots ディレクティブを配信してください。
3. 200 以外のステータスコード： Google は、200 以外の HTTP ステータスコードを返すページでは JavaScript をレンダリングしません。エラーページで JS によって挿入されたコンテンツや meta タグは、Googlebot から見えません。
4. JavaScript 内の構造化データ： JS によって挿入された Product、Article、その他の構造化データは、処理が遅れる可能性があります。時間的制約のある構造化データ（特に E コマースの Product マークアップ）は、初期のサーバーレンダリング済み HTML に含めてください。

ベストプラクティス： 重要な SEO 要素（canonical、meta robots、構造化データ、title、meta description）は、JavaScript による挿入に頼らず、初期のサーバーレンダリング済み HTML で配信してください。

9. IndexNow プロトコル

• サイトが Bing、Yandex、Naver 向けの IndexNow に対応しているか確認します
• Google 以外の検索エンジンがサポートしています
• Google 以外の検索エンジンでのインデックス登録を高速化するため、実装を推奨します

エージェント対応ページとエージェント型ブラウジング

エージェント対応には、独自のサブスキル /seo agentic <url>（seo-agentic）があります。 このサブスキルは、Lighthouse の エージェント型ブラウジング カテゴリ（0～100 のスコアではなく、N 項目中の X 項目という割合）、エージェント向けのアクセシビリティツリー、AI エージェントのアクセス方針、llms.txt、Markdown の配信、ai-catalog.json、/.well-known の検出ファイル、および WebMCP を担当します。技術監査では、次の 2 つのシグナルのみを記録し、それ以外については seo-agentic を参照してください。

• JS のレンダリング：生の HTML に主要コンテンツがない場合、JavaScript を実行しないエージェントにもそのコンテンツは表示されません。
• 5xx の robots.txt。準拠するクローラーはこれを「すべてを拒否」として扱います。

"${CLAUDE_PLUGIN_ROOT}/scripts/claude-seo" run agent_ux_check.py https://example.com --json

上記の Agent-UX 0～100 スコアは、ローカルのヒューリスティックです。Lighthouse の割合とは区別し、検出結果は失敗ではなく改善の機会として提示してください。Lighthouse の agent-accessibility-tree 監査での失敗は別扱いです。これは Google が独自に測定するチェックであるため、seo-agentic では P0 と評価します。

出力

技術スコア：XX/100

測定した項目のみを採点します。各カテゴリのスコアは、そのカテゴリのチェックのうち合格したものの割合を重大度に応じて調整したものです。測定できなかったカテゴリは数値を付けず、「未測定」と報告します。各スコアの根拠となるチェックを示してください。

カテゴリ別の内訳

カテゴリ	ステータス	スコア
クロール可能性	pass/warn/fail	XX/100
インデックス登録可能性	pass/warn/fail	XX/100
セキュリティ	pass/warn/fail	XX/100
URL 構造	pass/warn/fail	XX/100
モバイル	pass/warn/fail	XX/100
Core Web Vitals	pass/warn/fail	XX/100
構造化データ	pass/warn/fail	XX/100
JS レンダリング	pass/warn/fail	XX/100
IndexNow	pass/warn/fail	XX/100

重大な問題（直ちに修正）

優先度：高（1 週間以内に修正）

優先度：中（1 か月以内に修正）

優先度：低（バックログ）

DataForSEO 連携（任意）

DataForSEO MCP ツールが利用できる場合は、実際のページ分析（ステータスコード、ページのタイミング、リンク切れ、ページ内チェック）に on_page_instant_pages を、Lighthouse 監査（パフォーマンス、アクセシビリティ、SEO スコア）に on_page_lighthouse を、技術スタックの検出に domain_analytics_technologies_domain_technologies を使用します。

Google API との統合（任意）

Google API の認証情報が設定されている場合は、"${CLAUDE_PLUGIN_ROOT}/scripts/claude-seo" run pagespeed_check.py <url> --json を使用すると、実際の PSI と CrUX のフィールドデータを取得できます（ラボデータのみを使った CWV の推定値に置き換わります）。"${CLAUDE_PLUGIN_ROOT}/scripts/claude-seo" run crux_history.py <url> --form-factor PHONE --json を使用すると、25 週間の CWV の推移を確認できます（PHONE を使用してください。全デバイスの表示では、モバイルでの問題が隠れることがあります）。また、"${CLAUDE_PLUGIN_ROOT}/scripts/claude-seo" run gsc_inspect.py <url> --json を使用すると、URL ごとの実際のインデックス登録状況を確認できます。

ローカルホストまたはプライベートホストの監査

url_safety はデフォルトでループバックアドレスとプライベートアドレスを拒否するため、http://localhost:3000 や Tailscale 上のステージングホストは「Blocked hostname」または「Blocked IP literal」というエラーになります。このデフォルト設定は意図的なものです。これらのスクリプトは、クロールするページ上で見つかった URL にアクセスするためです。

デプロイ前のホストを監査するには、オペレーターが CLAUDE_SEO_LOCAL_TARGETS にホスト名を指定します。値は host または host:port のエントリーをカンマ区切りで並べたリストです。

CLAUDE_SEO_LOCAL_TARGETS="localhost:3000,127.0.0.1:8080,100.101.102.103" \
  "${CLAUDE_PLUGIN_ROOT}/scripts/claude-seo" run fetch_page.py http://localhost:3000/

対象となること、ならないことは次のとおりです。

動作	許可リストに登録されたホスト
最初のトップレベル URL への生の HTTP でのアクセス	許可
その URL から到達するリダイレクト先	拒否
レンダリングされたページが取得するサブリソース	拒否
Playwright によるレンダリング（--render、スクリーンショット）	拒否。生の HTTP の経路を使用してください
変数に指定されていないホスト	拒否
リストに含まれている場合でも、クラウドのメタデータエンドポイント	拒否

host:port はそのポートのみを対象とし、ポートを指定しない host はすべてのポートを対象とします。変数が設定されていない場合、ポリシーは変更されません。ユーザーが管理していないホストに対して、この変数を設定するよう提案しないでください。SECURITY.md を参照してください。

エラー処理

状況	対応
URL に到達できない	ステータスコードを含む接続エラーを報告します。URL の確認、DNS 解決の確認、サイトが一般公開されていることの確認を提案します。
robots.txt が見つからない	ルートドメインに robots.txt が検出されなかったことを伝えます。適切なディレクティブを含むファイルの作成を推奨します。残りのカテゴリの監査は続行します。
HTTPS が設定されていない	重大な問題として指摘します。HTTP がリダイレクトなしで提供されているか、混在コンテンツが存在するか、SSL 証明書がないか期限切れかを報告します。
Core Web Vitals のデータを利用できない	CrUX データを利用できないこと（トラフィックの少ないサイトではよくあります）を伝えます。代替として Lighthouse のラボデータを使用し、再テストの前にトラフィックを増やすことを推奨します。