villetakanen/asdlc-io GEO監査

GEO監査 — Generative Engine Optimization監査

目的

asdlc.ioコードベースに対して、包括的なGenerative Engine Optimization（GEO）監査を実行します。GEOとは、AIシステム（ChatGPT、Claude、Perplexity、Geminiなど）がウェブコンテンツを発見、理解、引用、推奨できるように最適化する実践です。

ASDLC.ioはパブリッシャー/ナレッジベースサイトであり、Agentic SDLCパターンを文書化した静的Astroサイトです。この監査では、コンテンツ、スキーマ、技術インフラがAIによる引用と推奨をどの程度サポートしているかに焦点を当てます。

サイトタイプ: Netlify上にデプロイされた静的Astro 5.xサイト ドメイン: https://asdlc.io コンテンツモデル: 3つのコレクション（concepts、patterns、practices）とMCPサーバーによる公開

境界

• スコープ内: AI引用可能性、技術的GEOインフラ、E-E-A-T、スキーマ/構造化データ、MCP最適化の監査、および docs/reports/GEO-AUDIT-REPORT.md の生成。
• スコープ外: コードまたはコンテンツの変更（dev）、仕様の変更（spec）、公開またはプッシュ（ship）。

---

監査ワークフロー

フェーズ0: 公開サイト現状確認

ソースコードに深入りする前に、公開サイトを取得してAIクローラーが実際に何を見ているかを検証します。これにより、ソースコードは正しく見えてもレンダリング出力が壊れているビルドタイムのバグを発見できます。

ステップ1: 主要ページの取得

WebFetch/HTTP検索を使用して、以下のページのレンダリング済みHTMLを https://asdlc.io から取得します:

1. ホームページ（/）
2. 各コレクションから1記事（例: /concepts/agentic-sdlc、最初にリストされている /patterns/、最初にリストされている /practices/）
3. /robots.txt
4. /sitemap-index.xml（または /sitemap.xml）
5. /llms.txt

各取得には30秒のタイムアウトを適用します。公開サイトにアクセスできない場合は、失敗をログに記録し、コードベースのみの分析を続行します。

ステップ2: レンダリング出力検証

取得した各ページについて、以下の項目を抽出して記録します:

• 実際の <title> と <meta name="description"> — ソースコードの意図と一致しているか？
• JSON-LDブロック — すべての <script type="application/ld+json"> を解析し、スキーマタイプとフィールドがレンダリングされたHTMLに実際に存在するかを検証します。
• Open Graphタグ — og:title、og:description、og:image、og:url、og:type を抽出します。
• 正規URL — <link rel="canonical"> が正しく解決されているか？
• 見出し構造 — <h1> が1つだけ存在するか？見出しの階層は適切か？
• コンテンツのアクセシビリティ — メインコンテンツはセマンティックHTML（<article>、<main>、<section>）に含まれているか、それともJSでレンダリングされたdivに埋もれているか？
• レスポンスヘッダー — X-Robots-Tag、Cache-Control、およびAI関連のヘッダーを記録します。

ステップ3: ソースとレンダリングの差分

ソースコードで定義されている内容とレンダリング出力に含まれている内容の間の不一致を報告します:

• コンポーネントで定義されているがページにレンダリングされていないスキーママークアップ
• フロントマターのメタディスクリプションがレンダリングされた <head> に表示されない
• サイトマップにリストされているが404になるページ、またはリストされるべきだが欠落しているページ
• ヘッダー設定と一致しない robots.txt ディレクティブ

すべての不一致を記録し、最終レポートの「ソースとレンダリングの差分」専用セクションに含めます。

---

フェーズ1: コードベース詳細分析

レンダリング出力からは見えないすべての要素（コンテンツ品質、関連性密度、MCP内部構造、全ページにわたるスキーマの完全性）をソースコードから分析します。

ステップ1: コンテンツインベントリ

1. list_articles を使用して完全な記事マニフェストを取得します。
2. src/content/config.ts を読み込み、スキーマとフロントマターフィールドを理解します。
3. src/content/**/*.{md,mdx} をグロブして、総コンテンツファイル数をカウントします。
4. 各コレクション（concepts、patterns、practices）について以下を記録します:
   • 総記事数とステータス分布（Live、Experimental、Draft）
   • 単語数サンプリング（コレクションごとに3〜5記事を読む）
   • フロントマターの完全性（description、tags、relatedConceptsなど）

ステップ2: 技術インフラスキャン

1. public/robots.txt を読み込みます — AIクローラーディレクティブ（GPTBot、ClaudeBot、PerplexityBotなど）を確認します。
2. public/llms.txt または public/.well-known/llms.txt の存在を確認します。
3. astro.config.mjs を読み込みます — サイトマップ統合、サイトURL、出力設定を確認します。
4. src/layouts/BaseLayout.astro を読み込みます — メタタグ、構造化データ注入ポイントを確認します。
5. src/components/SEOMetadata.astro を読み込みます — Open Graph、Twitter Cards、正規URLを監査します。
6. Astro設定でのサイトマップ統合を確認します。
7. MCPサーバーのセットアップを確認します: netlify/edge-functions/mcp.ts または同等のものを読み込みます。

ステップ3: スキーマと構造化データスキャン

1. すべての .astro ファイルで application/ld+json をgrepし、すべてのJSON-LDブロックをカタログ化します。
2. schema.orgタイプ（Article、TechArticle、WebSite、Organization、BreadcrumbList、FAQPage、HowTo）をgrepします。
3. スキーマ生成コンポーネントまたはユーティリティを読み込みます。
4. 記事ページ、インデックスページ、ホームページにスキーマが存在するかを確認します。

---

フェーズ2: 並列分析

5つのコアカテゴリにわたって収集したデータを分析し、スコア（0-100）と所見を計算します:

1. AI引用可能性分析（重み: 30%） — パッセージの自己完結性、回答ブロック密度、定義の明確さ、構造的ナビゲーション性。
2. コンテンツE-E-A-T品質（重み: 25%） — 帰属品質、引用密度、コンテンツ深度、鮮度、権威シグナル。
3. 技術的GEOインフラ（重み: 15%） — クローラーアクセス、発見可能性シグナル、レンダリングアプローチ、MCP公開。
4. スキーマと構造化データ（重み: 15%） — スキーマカバレッジ、タイプ多様性、フィールド完全性、検証の正確さ。
5. ナレッジベースとMCP最適化（重み: 15%） — MCP完全性、マニフェスト品質、関連性密度、エージェントナビゲーション性。

---

フェーズ3: スコア集計とレポート

複合GEOスコアを計算します:

GEO_Score = (引用可能性 * 0.30) + (E-E-A-T * 0.25) + (技術 * 0.15) + (スキーマ * 0.15) + (MCP * 0.15)

確立された標準レポートテンプレートに従って docs/reports/GEO-AUDIT-REPORT.md を生成します。

$ARGUMENTS