geo-technical

GEO テクニカル SEO 監査

目的

テクニカル SEO は、従来の検索での可視性と AI 検索での引用の両方の基盤となります。技術的な問題があるサイトは、どのプラットフォームからもクロール、インデックス登録、引用されません。このスキルでは、GEO の要件に特に注意を払いながら、テクニカル SEO の健全性に関する 8 つのカテゴリを監査します。なかでも重要なのは、サーバーサイドレンダリング（AI クローラーは JavaScript を実行しません）と、AI クローラーのアクセス（多くのサイトで、robots.txt により意図せず AI クローラーがブロックされています）です。

このスキルの使い方

1. 対象 URL を収集します（ホームページと主要な下層ページ 2～3 件）
2. curl/WebFetch を使って各ページを取得し、生の HTML と HTTP ヘッダーを確認します
3. 以下の 8 つの監査カテゴリを順に確認します
4. 評価基準に基づいて各カテゴリを採点します
5. 結果をまとめた GEO-TECHNICAL-AUDIT.md を生成します

---

カテゴリ 1：クロール可能性（15 点）

1.1 robots.txt の有効性

• https://[domain]/robots.txt を取得します
• 構文が有効か確認します。User-agent、Allow、Disallow の各ディレクティブが適切に記述されている必要があります
• よくあるエラーを確認します。User-agent の欠落、重要なパスをブロックするワイルドカード、サイト全体をブロックする Disallow: / などです
• XML サイトマップが参照されているか確認します：Sitemap: https://[domain]/sitemap.xml

1.2 AI クローラーのアクセス（GEO で重要）

robots.txt で、以下の AI クローラーを対象とするディレクティブを確認します。

クローラー	ユーザーエージェント	プラットフォーム
GPTBot	GPTBot	ChatGPT / OpenAI
Google-Extended	Google-Extended	Gemini / Google AI トレーニング
Googlebot	Googlebot	Google 検索 + AI Overviews
Bingbot	bingbot	Bing Copilot + ChatGPT（Bing 経由）
PerplexityBot	PerplexityBot	Perplexity AI
ClaudeBot	ClaudeBot	Anthropic Claude
Amazonbot	Amazonbot	Alexa / Amazon AI
CCBot	CCBot	Common Crawl（多くの AI モデルで使用）
FacebookBot	FacebookExternalHit	Meta AI
Bytespider	Bytespider	TikTok / ByteDance AI
Applebot-Extended	Applebot-Extended	Apple Intelligence

AI クローラーのアクセスに関する採点：

• 主要な AI クローラーをすべて許可：5 点
• 一部はブロックされているが、Googlebot と Bingbot は許可：3 点
• GPTBot または PerplexityBot がブロックされている：1 点（GEO に大きな影響）
• Googlebot がブロックされている：0 点（致命的）

重要な補足：Google-Extended をブロックしても Googlebot はブロックされません。Google-Extended が制御するのは AI トレーニングデータの使用のみであり、検索インデックス登録ではありません。ただし、Google-Extended をブロックすると、AI Overviews での表示が減る可能性があります。特別なデータライセンス上の懸念がない限り、Google-Extended を許可することを推奨します。

1.3 XML サイトマップ

• サイトマップを取得します（場所は robots.txt で確認するか、/sitemap.xml または /sitemap_index.xml を試します）
• XML の構文を検証します
• <lastmod> の日付を確認します（日付が設定され、正確である必要があります）
• URL の数を数え、インデックス登録可能なページの想定数と比較します
• 大規模なサイトではサイトマップインデックスがあるか確認します（サイトマップ 1 件あたりの URL 数の上限は 50,000 件です）
• サイトマップ内の URL がすべて 200 ステータスコードを返すことを確認します（サンプルチェック）

1.4 クロール深度

• ホームページを深度 0 とします。重要なページすべてに 3 クリック以内（深度 3）で到達できるか確認します
• 深度 4 以上のページはクロールバジェットが大幅に少なくなり、AI に引用される可能性も低くなります
• 内部リンクを確認します。重要なコンテンツページはホームページまたはメインナビゲーションからリンクされていますか？

1.5 noindex の管理

• インデックス登録すべきページに <meta name="robots" content="noindex"> が設定されていないか確認します
• HTTP ヘッダーに X-Robots-Tag: noindex が設定されていないか確認します
• よくある誤り：ページネーションページ、カテゴリページ、重要なランディングページに noindex を設定すること

カテゴリの採点：

確認項目	点数
robots.txt が有効で完全	3
AI クローラーが許可されている	5
XML サイトマップがあり、有効	3
クロール深度が 3 クリック以内	2
誤った noindex ディレクティブがない	2

---

カテゴリ 2：インデックス登録可能性（12 点）

2.1 正規タグ

• インデックス可能なすべてのページに、<link rel="canonical" href="..."> タグが必要です
• 正規タグは、権威あるバージョンとしてページ自身を指す必要があります（自己参照）
• 競合する正規タグがないか確認します（HTML 内の正規タグと HTTP ヘッダー）
• 正規タグの連鎖がないか確認します（A の正規タグが B を指し、B の正規タグが C を指す場合、A から C を直接指す必要があります）

2.2 重複コンテンツ

• www と www なしを確認します（どちらもアクセス可能にし、一方からもう一方へリダイレクトする必要があります）
• HTTP と HTTPS を確認します（HTTP は HTTPS にリダイレクトする必要があります）
• 末尾のスラッシュが一貫しているか確認します（一方のパターンを選び、もう一方からリダイレクトします）
• パラメーターによる重複を確認します（?sort=price によって重複ページが作成されていないか）

2.3 ページネーション

• ページ分割されたコンテンツがある場合は、rel="next" / rel="prev" を確認します（注：Google は 2019 年以降これらを無視しますが、Bing は引き続き使用します）
• 推奨：ページ分割されたページで rel="canonical" を使用し、すべて表示するページまたは最初のページを指すようにします
• 固有のコンテンツを含むページ分割ページが noindex になっていないことを確認します

2.4 Hreflang（国際的なサイト）

• <link rel="alternate" hreflang="xx"> タグを確認します
• 相互 hreflang を検証します（ページ A がページ B を指す場合、B から A も指す必要があります）
• x-default フォールバックがあることを検証します
• 言語／地域コードが有効か確認します（ISO 639-1 / ISO 3166-1）

2.5 インデックスの肥大化

• インデックスされたページ数を推定します（サイトマップの件数を確認し、site:domain.com で推定します）
• インデックスされたページ数と、実際に価値のあるコンテンツページ数を比較します
• インデックスされたページ数がコンテンツページ数を大幅に上回る場合は、指摘します（内容の薄いページ、重複ページ、パラメータ付きページによるインデックスの肥大化）

カテゴリの採点：

チェック項目	点数
すべてのページで正規タグが正しく設定されている	3
重複コンテンツの問題がない	3
ページネーションが適切に処理されている	2
Hreflang が正しい（該当する場合）	2
インデックスの肥大化がない	2

---

カテゴリ 3：セキュリティ（10 点）

3.1 HTTPS の強制

• サイトが HTTPS で読み込まれる必要があります
• HTTP は HTTPS にリダイレクトする必要があります（301 リダイレクト）
• 混在コンテンツの警告がないこと（HTTPS ページ上の HTTP リソース）
• SSL/TLS 証明書が有効で、期限切れになっていないこと

3.2 セキュリティヘッダー

HTTP レスポンスヘッダーを確認します：

ヘッダー	必須値	目的
Strict-Transport-Security	max-age=31536000; includeSubDomains	HTTPS を強制します
Content-Security-Policy	適切なポリシー	XSS を防止します
X-Content-Type-Options	nosniff	MIME スニッフィングを防止します
X-Frame-Options	DENY または SAMEORIGIN	クリックジャッキングを防止します
Referrer-Policy	strict-origin-when-cross-origin またはそれ以上に厳格な設定	リファラーデータを制御します
Permissions-Policy	適切な制限	ブラウザー機能を制御します

カテゴリの採点：

チェック項目	点数
有効な証明書で HTTPS が強制されている	4
HSTS ヘッダーが設定されている	2
X-Content-Type-Options	1
X-Frame-Options	1
Referrer-Policy	1
Content-Security-Policy	1

---

カテゴリ 4：URL 構造（8 点）

4.1 わかりやすい URL

• URL は人間が読みやすい形式にします：/blog/seo-guide を使用し、/blog?id=12345 は避けます
• URL にセッション ID を含めません
• 小文字のみを使用します（大文字と小文字を混在させません）
• 単語の区切りにはハイフンを使用します（アンダースコアは使用しません）
• 特殊文字やエンコードされた空白を含めません

4.2 論理的な階層

• URL パスにサイトの構造を反映します：/category/subcategory/page
• 適切な場合は階層を浅くし、不必要に深い階層を避けます
• サイト全体で一貫したパターンを使用します

4.3 リダイレクトチェーン

• リダイレクトチェーンがないか確認します（A から B、B から C へリダイレクトする状態）
• リダイレクトは最大 1 回の推移が推奨されます（A から C へ直接リダイレクトします）
• リダイレクトループがないか確認します
• 一時的なリダイレクトを意図している場合を除き、すべてのリダイレクトを 302（一時的）ではなく 301（恒久的）にします

4.4 パラメーターの処理

• URL パラメーターによって、インデックス可能な重複ページが作成されないようにしてください
• パラメーターのバリエーションには、canonical タグまたは robots.txt の Disallow を使用してください
• Google Search Console と Bing Webmaster Tools でパラメーターの処理を設定してください

カテゴリの採点：

チェック項目	点数
シンプルで読みやすい URL	2
論理的な階層構造	2
リダイレクトチェーンなし（最大 1 ホップ）	2
パラメーター処理の設定	2

---

カテゴリ 5：モバイル最適化（10 点）

重要な背景

2024 年 7 月現在、Google はすべてのサイトをモバイル版 Googlebot でのみクロールします。デスクトップ版のクロールはありません。サイトがモバイルで動作しなければ、Google にとっても機能しません。例外はありません。

5.1 レスポンシブデザイン

• <meta name="viewport" content="width=device-width, initial-scale=1"> があることを確認してください
• モバイルでコンテンツを表示する際に、横スクロールが必要にならないようにしてください
• ビューポートより幅の広い固定幅レイアウトを使用しないでください

5.2 タップ対象

• ボタンやリンクなどのインタラクティブな要素は、少なくとも 48x48 CSS ピクセルにしてください
• タップ対象の間隔は最低 8px 確保してください
• モバイルでナビゲーションが使いやすいことを確認してください

5.3 フォントサイズ

• 基本フォントサイズは少なくとも 16px にしてください
• 読むために拡大が必要なテキストがないようにしてください
• 十分なコントラスト比を確保してください（WCAG AA：通常のテキストは 4.5:1、大きなテキストは 3:1）

5.4 モバイルコンテンツの同等性

• デスクトップで表示されるすべてのコンテンツを、モバイルでも表示してください
• Googlebot が展開できない「続きを読む」トグルの背後にコンテンツを隠さないでください（ただし、Google は 2025 年現在、こうしたコンテンツの展開機能を改善しています）
• モバイルでも画像やメディアを読み込めるようにしてください

カテゴリの採点：

チェック項目	点数
Viewport メタタグが正しい	3
レスポンシブレイアウト（横スクロールなし）	3
タップ対象が適切なサイズ	2
フォントサイズが読みやすい	2

---

カテゴリ 6：Core Web Vitals（15 点）

2026 年の指標としきい値

Core Web Vitals では、実ユーザーデータ（フィールドデータ）の75 パーセンタイルを基準とします。ラボデータはデバッグに役立ちますが、ランキングシグナルを決定するのはフィールドデータです。

指標	良好	改善が必要	不良	備考
LCP（Largest Contentful Paint）	< 2.5s	2.5s - 4.0s	> 4.0s	読み込みを測定します。最大の可視要素が描画されるまでの時間です
INP（Interaction to Next Paint）	< 200ms	200ms - 500ms	> 500ms	2024 年 3 月に FID に代わって導入されました。最初の操作だけでなく、すべての操作を測定します
CLS（Cumulative Layout Shift）	< 0.1	0.1 - 0.25	> 0.25	視覚的な安定性を測定します。予期しないレイアウトの移動が対象です

CrUX データを使わずに評価する方法

実ユーザーデータを利用できない場合は、ページの特性から推定してください：

• LCP：ファーストビューで最も大きな要素を確認します。画像の場合はサイズや形式を確認してください。テキストの場合は Web フォントの読み込みを確認してください。サーバー応答時間（TTFB）も確認してください。
• INP：ページ上の負荷の大きい JavaScript を確認します。長いタスク（>50ms）はインタラクティブ性を妨げます。サードパーティ製スクリプトも確認してください。
• CLS：幅や高さが明示されていない画像を確認します。ファーストビューの上部に動的に挿入されるコンテンツがないか確認します。Web フォントによるレイアウトシフト（FOUT/FOIT）も確認してください。

LCP の一般的な修正方法

1. ヒーロー画像を最適化します。WebP/AVIF 形式を使用し、適切なサイズにして、<link rel="preload"> でプリロードします
2. サーバー応答時間を短縮します（TTFB < 800ms）
3. レンダリングを妨げる CSS/JS を排除します
4. 重要なサードパーティのオリジンに事前接続します

INP の一般的な修正方法

1. requestIdleCallback または scheduler.yield() を使って、長いタスク（>50ms）を小さなチャンクに分割します
2. サードパーティ製 JavaScript を削減します
3. 画面外のコンテンツには content-visibility: auto を使用します
4. イベントハンドラーにデバウンスやスロットリングを適用します

CLS の一般的な修正方法

1. 画像と動画には必ず width 属性と height 属性を指定します
2. CSS の aspect-ratio または明示的な寸法を使って、広告や埋め込みコンテンツ用のスペースを確保します
3. サイズを調整したフォールバックフォントとともに font-display: swap を使用します
4. ページ読み込み後に、既存のコンテンツより上へコンテンツを挿入しないでください

カテゴリの採点：

チェック項目	点数
LCP < 2.5s	5
INP < 200ms	5
CLS < 0.1	5

---

カテゴリ 7：サーバーサイドレンダリング（15 点）— GEO にとって極めて重要

AI に認識されるために SSR が必須である理由

AI クローラー（GPTBot、PerplexityBot、ClaudeBot など）は JavaScript を実行しません。取得した生の HTML を解析します。React、Vue、Angular、その他の JavaScript フレームワークによってコンテンツがクライアント側でレンダリングされる場合、AI クローラーには空のページが表示されます。

JavaScript を実行する Googlebot でさえ、追加のクロールバジェットが必要になるため、JS でレンダリングされたコンテンツの優先度を下げます。Google は JS のレンダリングを独立した「レンダリングキュー」で処理するため、インデックス登録が数日から数週間遅れることがあります。

検出方法

1. curl でページを取得します（JavaScript は実行されません）：curl -s [URL]
2. 生の HTML とレンダリング後の DOM（ブラウザー経由）を比較します
3. 重要なコンテンツ（見出し、段落、製品情報、記事本文）が curl の出力に含まれていない場合、サイトはクライアント側レンダリングに依存しています

確認項目

• メインコンテンツのテキスト：記事本文／製品説明／ページコンテンツは生の HTML に含まれていますか？
• 見出し：H1、H2、H3 タグは生の HTML に含まれていますか？
• ナビゲーション：メインナビゲーションはサーバー側でレンダリングされていますか？
• 構造化データ：JSON-LD は生の HTML に含まれていますか、それとも JavaScript によって挿入されていますか？
• メタタグ：title、description、canonical、OG タグは生の HTML に含まれていますか？
• 内部リンク：ナビゲーションとコンテンツのリンクは生の HTML に含まれていますか？（クロール可能性にとって重要です）

推奨する SSR ソリューション

フレームワーク	SSR ソリューション
React	Next.js（SSR/SSG）、Remix、Gatsby（SSG）
Vue	Nuxt.js（SSR/SSG）
Angular	Angular Universal
Svelte	SvelteKit
汎用	Prerender.io（プリレンダリングサービス）、Rendertron

スコアの詳細

• 重要なコンテンツがすべてサーバー側でレンダリングされている：15 ポイント
• メインコンテンツはサーバー側でレンダリングされているが、一部の要素は JS のみ：10 ポイント
• 重要なコンテンツの表示に JS が必要（製品情報、記事本文）：5 ポイント
• ページ全体がクライアント側でレンダリングされている（生の HTML では本文が空）：0 ポイント

カテゴリ別スコア：

チェック項目	ポイント
生の HTML にメインコンテンツが含まれている	8
生の HTML にメタタグと構造化データが含まれている	4
生の HTML に内部リンクが含まれている	3

---

カテゴリ 8：ページ速度とサーバーパフォーマンス（15 ポイント）

8.1 Time to First Byte（TTFB）

• 目標：< 800ms（理想は < 200ms）
• curl で測定します：curl -o /dev/null -s -w 'TTFB: %{time_starttransfer}s\n' [URL]
• TTFB > 800ms の場合は、サーバーの設置場所、キャッシュ、データベースクエリ、CDN の使用状況を確認します

8.2 リソースの最適化

• ページ全体の容量の目標：< 2MB（重要なページは < 1MB）
• 圧縮されていないリソースがないか確認します（gzip/brotli 圧縮を有効にする必要があります）
• CSS と JavaScript が圧縮されていない状態でないか確認します
• 使用されていない CSS/JS がないか確認します（多くのサイトでダウンロードされるバイト数の 50% 以上を占めることがあります）

8.3 画像の最適化

• 画像形式を確認します：JPEG/PNG より WebP または AVIF が推奨されます
• サイズが大きすぎる画像（表示サイズを超える画像）がないか確認します
• 遅延読み込みを確認します：ファーストビューより下にある画像には loading="lazy" を指定します
• 寸法が明示されているか確認します（width/height 属性は CLS の防止に役立ちます）
• ファーストビューの画像は遅延読み込みにしないでください（LCP に悪影響を与えます）

8.4 コード分割と遅延読み込み

• 各ページで必要なものだけが読み込まれるよう、JavaScript をコード分割する必要があります
• 大きな JavaScript バンドルがないか確認します（圧縮後 > 200KB は警告、> 500KB は重大です）
• サードパーティスクリプトは非同期で読み込む必要があります（async または defer）
• <head> 内にレンダリングをブロックするリソースがないか確認します

8.5 キャッシュ

• 静的リソース（画像、CSS、JS）の Cache-Control ヘッダーを確認します
• 静的アセットには、コンテンツハッシュ付きのファイル名を使用し、長いキャッシュ期間を設定する必要があります：max-age=31536000（1 年）
• HTML ページはキャッシュ期間を短くするか、検証（ETag または Last-Modified）を伴う no-cache を設定する必要があります

8.6 CDN の使用状況

• 静的リソースが CDN から配信されているか確認します（ドメインが異なるか、CDN 固有のヘッダーがあるか）。
• グローバルなユーザーを対象とする場合、一貫したパフォーマンスを実現するうえで CDN は不可欠です。
• CDN 固有のヘッダーを確認します：CF-Ray（Cloudflare）、X-Cache（AWS CloudFront）、X-Served-By（Fastly）

カテゴリのスコアリング：

チェック項目	ポイント
TTFB < 800ms	3
ページの容量 < 2MB	2
画像が最適化されている（形式、サイズ、遅延読み込み）	3
JS バンドルが適切なサイズ（圧縮後 < 200KB）	2
圧縮が有効（gzip/brotli）	2
静的リソースにキャッシュヘッダーが設定されている	2
CDN が使用されている	1

---

カテゴリ 9：エージェント対応のシグナル（スコア対象外）

これらのチェックでは、AI エージェントとの互換性に関する新たなシグナルを確認します。数値スコアには加算されず、合格または推奨事項を提示します。基盤となる標準は IETF ドラフトまたは初期導入段階の機能であり、対応していないことを減点するのは適切ではありません。

9.1 RFC 8288 Link ヘッダー（サービス検出）

RFC 8288（Web Linking）では、HTTP の Link: レスポンスヘッダーが定義されています。サーバーはこのヘッダーを使用して、API カタログ、サービスドキュメント、MCP サーバーカードなどの関連リソースを、HTML の解析なしで機械可読な形式で提示できます。

確認方法： 標準のホームページ取得時に、すべての Link: レスポンスヘッダーを取得します（追加のリクエストは不要です）。

確認する項目：

• <url>; rel="relation-type" のペアを解析します。
• 特に有用な rel タイプ：api-catalog（RFC 9609）、describedby、service-doc、mcp-server-card。

推奨事項を提示する場合： API ファーストのサイト（ナビゲーションに API ドキュメントへのリンクがある、/api/ または /developers/ のパスがある、サイトマップに swagger/OpenAPI がある）のみを対象とします。一般的なビジネスサイトでは、このセクション全体を省略します。未対応であることは想定内であり、特筆すべき事項ではありません。

状態	対応
Link: ヘッダーがあり、既知の rel タイプがある	情報提供 — 検出内容を記録します
Link: ヘッダーがあり、未知の rel タイプがある	情報提供 — 記載して説明します
API ファーストのサイトで未設定	推奨 — 理由を説明し、実装を提案します
一般的なビジネスサイトで未設定	省略 — 提示しません

9.2 Markdown コンテンツネゴシエーション

Accept: text/markdown に対して、サーバーが Content-Type: text/markdown を返すかを確認します。Cloudflare の「Markdown for Agents」機能を利用すると、AI エージェントは HTML ではなく、整った Markdown を受け取れます。これにより、不要な要素を取り除く作業が不要になり、コンテンツ抽出の精度が向上します。

確認方法： Accept: text/markdown を指定して、ホームページに GET リクエストを送信します。監査ごとに追加される HTTP リクエストは 1 件です。

評価：

• レスポンスの Content-Type が text/markdown（または text/markdown; charset=utf-8）の場合：合格 — 先進的な機能として記録します。
• それ以外の場合：失敗ではなく、将来を見据えた推奨事項とします。
• リクエストがエラーになるか、200 以外が返された場合：スキップし、エラーを記録します。減点しません。

状態	対応
text/markdown が返された	ボーナス — 先進的な機能として記録します
標準の HTML が返された	将来を見据えた推奨事項
リクエストがエラー／200 以外	スキップし、エラーを記録します。減点しません

---

IndexNow プロトコル

概要

IndexNow は、コンテンツの作成、更新、削除時にウェブサイトから検索エンジンへ即時に通知できるオープンプロトコルです。Bing、Yandex、Seznam、Naver がサポートしています。Google は IndexNow をサポートしていませんが、このプロトコルを監視しています。

GEO における重要性

ChatGPT は Bing のインデックスを使用します。Bing Copilot も Bing のインデックスを使用します。Bing でのインデックス登録が速くなれば、主要な 2 つのプラットフォームで AI に見つけてもらえるようになるまでの時間も短縮されます。

実装状況の確認

1. IndexNow のキー ファイルを確認します：https://[domain]/.well-known/indexnow-key.txt または類似のパス
2. CMS に IndexNow プラグインがあるか確認します（WordPress：IndexNow プラグイン。最新の CMS プラットフォームの多くは標準でサポートしています）。
3. 実装されていない場合は、手順を示して追加を推奨します

---

総合スコア

カテゴリ	最大ポイント	重み
クロール可能性	15	基盤となる要素
インデックス登録可能性	12	基盤となる要素
セキュリティ	10	信頼性を示す要素
URL 構造	8	クロール効率
モバイル最適化	10	Google の要件
Core Web Vitals	15	ランキング要因
サーバーサイドレンダリング	15	GEO に不可欠
ページ速度とサーバー	15	パフォーマンス
合計	100

スコア対象外のチェック項目（カテゴリ 9）は、「エージェント対応状況」の下に出力され、この合計には影響しません。

スコアの解釈

• 90-100：優秀 — 従来型 SEO と GEO の両方において技術的に健全です
• 70-89：良好 — 対処すべき軽微な問題はありますが、基本的には堅実です
• 50-69：改善が必要 — 可視性に影響する重大な技術的負債があります
• 30-49：不良 — クロール、インデックス登録、または AI での可視性を妨げる重大な問題があります
• 0-29：危機的 — 直ちに対処が必要な根本的な技術上の問題があります

---

出力形式

以下を含む GEO-TECHNICAL-AUDIT.md を生成します：

# GEO Technical SEO Audit — [Domain]
Date: [Date]

## Technical Score: XX/100

## Score Breakdown
| Category | Score | Status |
|---|---|---|
| Crawlability | XX/15 | Pass/Warn/Fail |
| Indexability | XX/12 | Pass/Warn/Fail |
| Security | XX/10 | Pass/Warn/Fail |
| URL Structure | XX/8 | Pass/Warn/Fail |
| Mobile Optimization | XX/10 | Pass/Warn/Fail |
| Core Web Vitals | XX/15 | Pass/Warn/Fail |
| Server-Side Rendering | XX/15 | Pass/Warn/Fail |
| Page Speed & Server | XX/15 | Pass/Warn/Fail |

Status: Pass = 80%+ of category points, Warn = 50-79%, Fail = <50%

## AI Crawler Access
| Crawler | User-Agent | Status | Recommendation |
|---|---|---|---|
| GPTBot | GPTBot | Allowed/Blocked | [Action] |
| Googlebot | Googlebot | Allowed/Blocked | [Action] |
[Continue for all AI crawlers]

## Critical Issues (fix immediately)
[List with specific page URLs and what is wrong]

## Warnings (fix this month)
[List with details]

## Recommendations (optimize this quarter)
[List with details]

## Agent-Readiness Signals (non-scoring)

### RFC 8288 Link Headers (Service Discovery)

**Status:** Present / Absent / Not Applicable


| Relation Type | URL | Meaning |
|---|---|---|
| api-catalog | /.well-known/api-catalog | Machine-readable index of available APIs |
| mcp-server-card | /.well-known/mcp.json | MCP server capability declaration |

AI agents and API clients can discover your services without parsing HTML.


**Informational Recommendation:** This site has API/developer-oriented content but no `Link:` headers advertising discoverable services.

Example: `Link: </.well-known/api-catalog>; rel="api-catalog"`

Relevant for: sites with public APIs, OpenAPI docs, or MCP server integrations.
Reference: RFC 8288, RFC 9609.



### Markdown Content Negotiation

**Status:** Supported / Not Supported
**Test:** GET [url] with `Accept: text/markdown`
**Response Content-Type:** [value]


This site serves clean Markdown to AI agents on request. AI crawlers that support content negotiation receive formatted text without HTML boilerplate.


**Forward-Looking Recommendation:** Cloudflare Workers/Pages sites can enable Markdown content negotiation with a one-line configuration change. When an AI agent sends `Accept: text/markdown`, the server responds with clean Markdown instead of HTML.

- Currently Cloudflare-specific
- Relevant for: sites already on Cloudflare infrastructure
- Other CDNs and frameworks expected to adopt this pattern as AI agent traffic grows

## Detailed Findings
[Per-category breakdown with evidence]