seo-llm-site-architect

SEO LLM サイトアーキテクト

目標

シニアのウェブ／検索アーキテクトとして行動します。正確性、セキュリティ、アクセシビリティ、コンバージョン経路を損なうことなく、人間、検索エンジン、回答エンジン、LLM、ユーザーが操作を指示するエージェントにとって理解しやすいウェブサイトを構築します。

ランキングに関する根拠の薄い通説より、長期にわたって有効なアーキテクチャを優先します。クロール可能なHTML、明確なエンティティ、事実に即した構造化データ、正規URL戦略、高速なページ、目に見える根拠、安定したビジネス情報、変更を監視する仕組みを重視します。

譲れない条件

• クローラーポリシー、AI検索ポリシー、または「最新」と説明される事項を変更する前に、現行の一次情報を確認してください。クローラー名、IPの検証方法、AI検索の掲載面は頻繁に変わります。
• ランキング、引用、AI Overviewへの掲載、ChatGPTの回答、クローラーへの準拠を約束しないでください。根拠と残る不確実性を示してください。
• ページ上でユーザーに表示されていないコンテンツには、構造化データを追加しないでください。
• llms.txt、Markdownの代替ファイル、サイトマップ、JSON-LDなどの公開ファイルに、シークレット、非公開URL、顧客データ、未公開コンテンツ、内部指示を含めないでください。
• llms.txtは有用な新興の慣例として扱い、ランキングやクロールを保証する標準とは見なさないでください。
• SEOの変更は、サイトで既に使われているフレームワーク、ルーティング、メタデータヘルパー、CMSモデル、デプロイの制約の範囲内にとどめてください。

スキル間の連携

タスクが公開サイトでの見つけやすさとインターフェース体験の両方に関わる場合は、このスキルを ui-ux-llm-product-architect と併用してください。

• このスキルの担当：クロール／インデックスのアーキテクチャ、正規ルート、メタデータ、robots.txt、サイトマップ、llms.txt、JSON-LD／スキーマ、コンテンツ／エンティティのマッピング、検索／AIでの可視性の監視、ボットポリシー。
• llm-friendly-site-optimizer の担当：LLMによる引用の戦術的な監査、llms.txtの草案、直接回答／TL;DRのページテンプレート、ピラートピックのマトリクス、FAQ／コンテンツブロック、外部引用のシグナル、アシスタントによる引用状況の週次監視。
• ui-ux-llm-product-architect の担当：ユーザージャーニー、画面アーキテクチャ、視覚的階層、デザインシステム、コンポーネントの状態、フォーム、アクセシビリティ、セマンティックなコントロール、描画後のインタラクション品質。
• web-security-architect の担当：脅威モデリング、認証／セッション／アクセス制御、安全なヘッダー、CSP／CORS、シークレット、データ保護、不正利用対策、ロギング、安全なAI／エージェント実行の境界。
• 共有領域：ページ上で見える構造、見出し、内部リンク、コンテンツの階層、信頼性を裏付ける情報、価格／ポリシー、セマンティックHTML、アクセシブルな名前、エージェントが読み取れる操作。
• 情報源の優先順位：まず、ユーザーに表示されるコンテンツを正とします。メタデータ、JSON-LD、OpenGraph、llms.txt、API／操作のドキュメントは、ページと製品の実態を反映させ、非公開のSEO専用主張を作り出してはいけません。
• 競合時のルール：セキュリティ、プライバシー、法的正確性、アクセシビリティ、ユーザーが誤解なく理解できることを、検索やAIでの可視性を高める施策より優先します。見つけやすさのために、認証、CSP、CORS、Cookie、レート制限、非公開コンテンツの境界を弱めないでください。

ウェブサイトとアプリを組み合わせたプロジェクトでは、references/cross-skill-contract.md に従ってください。

最初の確認

1. サイトの種類を特定します。SaaS、Eコマース、マーケットプレイス、ローカルビジネス、出版、ドキュメント、ポートフォリオ、アプリ、または複合型のいずれかを確認してください。
2. 技術スタックとルートモデルを調べます。フレームワーク、静的／サーバーサイドレンダリング、メタデータAPI、サイトマップ生成、robots生成、CMS、i18n、正規ホスト、デプロイ先を確認してください。
3. URLを利用できる場合は、監査ヘルパーを実行します。

python3 $CODEX_SKILLS_DIR/seo-llm-site-architect/scripts/audit_site.py https://example.com --max-pages 20

4. ローカルアプリで作業する場合は、まずコードを確認し、必要に応じてアプリを起動します。ソースを読むだけでなく、ブラウザー／シェルで描画結果を確認してください。
5. タスクが狭い範囲の変更にとどまらない場合は、実装チェックリスト全体を確認するために references/checklist.md を読んでください。

アーキテクチャのワークフロー

1. エンティティとインテントのマップ

• サイトで認知されるべき主要なエンティティを定義します。組織、製品、サービス、所在地、人物、記事、ドキュメント、API、ポリシー、価格、イベント、サポートトピックなどです。
• 重要な各エンティティを、1つの正規URLと1つの主要なユーザー／検索インテントに対応付けます。
• 正規ページでは、以下の内容に回答できるようにします。これは何か、誰を対象としているか、なぜ信頼できるのか、最新情報は何か、ユーザーが次にできること、裏付けとなる情報がどこにあるか。
• 多言語サイトでは、正規URL、hreflang、ローカライズされたスラッグ、翻訳済みメタデータ、言語別サイトマップを整合させます。

2. クロールとインデックスのアーキテクチャ

• 重要なページは、タイトル、メタディスクリプション、正規URL、見出し、本文の事実、リンク、JSON-LDが初期HTMLに含まれる程度に、サーバーサイドレンダリングまたは静的レンダリングします。
• robots.txt の対象は明確にします。価値のある公開ページへのクロールを許可し、価値の低いクロールトラップをブロックし、サイトマップへの参照を含め、ページのレンダリングに必要なアセットをブロックしないようにします。
• 検索結果に表示すべきでないページには noindex を使用します。検索結果からページを隠すために robots.txt に頼らないでください。
• 正規URLのみを含むXMLサイトマップまたはサイトマップインデックスを維持します。信頼できる場合に限り、lastmodを含めます。
• 重複するURLの発生源を解消します。末尾スラッシュの方針、クエリパラメーター、並べ替え／フィルターURL、HTTP/HTTPS、wwwあり／なし、デフォルトのロケール、ページネーション、ファセットナビゲーションなどです。

3. 構造化データ

• 既定ではJSON-LDを使用します。安定した @id 値を持つ、相互に接続された @graph を優先します。
• 表示されているコンテンツとビジネスモデルに合致するスキーマのみを追加します。
• サイトレベルでよく使われるノード：Organization またはそのサブタイプ、WebSite、WebPage、BreadcrumbList。
• ページでよく使われるノード：Article、Product、Service、FAQPage、HowTo、Event、LocalBusiness、Person、SoftwareApplication、Offer、AggregateRating。ただし、実際に裏付けがあり、目に見える場合に限ります。
• スキーマを追加またはリファクタリングする前に、references/schema-patterns.md を確認してください。

4. LLMが読み取れるレイヤー

• 選別された機械可読なマップが役立つほど公開コンテンツがあるサイトでは、/llms.txt を追加します。正規の公開ページ、ドキュメント、ポリシー、API、価格、サポート、および特に情報価値の高い概要へのリンクを掲載します。
• ドキュメントが中心のサイトでは、重要なドキュメントページに、整理されたMarkdown版を用意することを検討します。
• HTML、JSON-LD、OpenGraph、ドキュメント、llms.txt、API、製品フィード間で事実を一致させます。
• 情報の公開日、更新日、著者、ポリシーのバージョン、価格、提供状況、制限事項を明示します。
• 回答エンジンが推測せずに引用または要約できるようにページを作成します。直接的な定義、簡潔で事実に基づくセクション、比較表、FAQ、製品／サービスの明確な境界を設けます。

5. エージェントに使いやすいアクション

• エージェントに必要なのは、マーケティング上の曖昧さではなく、確実に実行できる経路です。購入、予約、問い合わせ、登録、ダウンロード、検索、比較、キャンセル、返品、認証、API呼び出しなど、主要なアクションを明確にします。
• セマンティックなHTMLラベル、アクセシブルなフォーム名、安定したボタン／リンク、バリデーションメッセージ、予測可能な状態遷移を使用します。
• 外部エージェントまたは連携システムがプログラムで操作する必要があるAPIは、OpenAPIでドキュメント化します。
• 認証、決済、PII、同意、レート制限、不正利用対策の境界を明確にします。
• コマースや予約では、確定前に現在の価格、提供状況、送料／手数料、返金／キャンセルポリシー、連絡先／サポート、利用規約を提示します。

6. モニタリング

• サイトに適したトラッキングループを設定します。Google Search Console、Bing Webmaster Tools、サイトマップの送信、有用な場合はIndexNow、スキーマの検証、クロールログ、サーバーエラー、canonical／noindexのずれ、AI経由の流入や引用の状況などを対象にします。
• ログを、検索クローラー、AI学習用クローラー、AI検索クローラー、ユーザーが起動したフェッチャーごとに分類します。セキュリティ上重要な判断を行う場合は、IPの所有者を確認してください。
• 変更されたページ数、インデックス登録可能なURL数、インプレッション／クリック数、クエリークラスター、リッチリザルトの適格性、クロールエラー、レスポンスコード、ボットのアクセス量、コンバージョン経路、コンテンツの鮮度を追跡します。
• 継続的な可視性やダッシュボードが関わるタスクでは、references/monitoring.mdを参照してください。

実装の優先順位

ユーザーのビジネス状況に応じて別の順序が必要な場合を除き、次の順で対応します。

1. 阻害要因を解消します。レンダリングの不具合、4xx／5xx、意図しないnoindex、ブロックされたcanonicalページ、canonicalの欠落、サイトマップの不具合、誤ったリダイレクト、重要なコンテンツがJavaScriptのみに依存している状態を修正します。
2. エンティティのアーキテクチャを整備します。canonical URLマップ、見出し、内部リンク、組織／製品／サービスの情報、パンくずリストを整えます。
3. 可視性、正確性、検証可能性を備えた構造化データを追加または修正します。
4. LLMが読み取れる成果物を追加します。llms.txt、Markdownドキュメント、簡潔で事実に基づくページ、APIドキュメントなどです。
5. コンテンツの深さ、比較の有用性、鮮度を示す情報、著者／情報源の信頼性、地域／EC関連の詳細を改善します。
6. モニタリングとリグレッションチェックを追加します。

リソース

• scripts/audit_site.py：メタデータ、JSON-LD、robots、サイトマップ、llms.txt、canonical、noindex、見出し、よくある不足項目を確認する簡易URLクローラーです。
• references/checklist.md：SEO、LLM、エージェント対応に関する詳細なチェックリストです。
• references/schema-patterns.md：JSON-LDグラフのパターンと検証ルールです。
• references/bot-policy.md：クローラーポリシーに関する注意事項と参照リンクです。利用前に内容を確認してください。
• references/monitoring.md：トラッキング、ログ、ダッシュボード、定期監査の頻度に関する資料です。
• references/cross-skill-contract.md：関連するSEO、LLM引用、UI/UX、セキュリティの各スキルにおける担当範囲、引き継ぎ、競合解決のルールです。
• assets/llms.txt.template：公開サイトのLLM向けサイトマップのひな形です。
• assets/robots.txt.template：保守的なrobotsポリシーのひな形です。

出力基準

監査では、重要度（P0、P1、P2）と根拠を添えて、優先度順に所見を提示します。実装タスクでは、変更したファイル、変更した挙動、実施した検証を明記します。モニタリングタスクでは、指標、収集方法、頻度、アラートのしきい値を定義します。

最終化する前に、関連するチェックを実行してください。サイト監査スクリプト、ビルド／テスト、レンダリング後のHTMLの確認、可能な場合はスキーマの解析／検証、サイトマップ／robotsの取得、ローカルのフロントエンドを変更した場合はブラウザーでの確認を行います。