seo

SEO

• 該当するもの： 検索での可視性を高めるための一元的な窓口です。エビデンスに基づく監査、実装、需要調査、ライター向けブリーフの作成、検索エンジンと AI 検索全体でのパフォーマンス測定を扱います（検索内の AI 回答に対する AEO、独立したアシスタントに対する GEO。references/answer-engines.md を参照してください）。
• 該当しないもの： 記事や独立したマーケティングコピーの執筆（ghostwriter）、ビジュアルの再設計（ui-design）、テナントのインフラストラクチャ（multi-tenant-architecture）、または AFDocs / Is Agentic / Is It Agent Ready のスコアカードの実装（agent-ready）。依頼された実装の一部として SEO 用のコピーやマークアップを修正する場合は除きます。

タスクの振り分け

依頼	読み込むもの	成果物
サイトの監査、インデックス登録の問題の診断、移行のレビュー	references/audit.md と references/validation-evidence.md	URL、観察されたエビデンス、影響、修正方法を含む優先順位付きの指摘事項
SEO の修正または実装	監査用リファレンス、および以下の該当する実装用リファレンス	コードの変更、対象を絞ったチェック、変更した動作に関する配信ページのエビデンス
需要の調査、ターゲットの選定、ページのブリーフ作成	references/research-protocol.md。ブリーフには references/brief-template.md	出典付きの需要テーブルと判断、または長期的に活用できるライター向けブリーフ
トラフィック変動の説明、AI での可視性の測定、SEO のモニタリング	references/monitoring.md	プロパティの範囲に基づく診断、またはデータの不足を明示したモニタリング設定

複合的な依頼では、各モードで同じプロパティと URL インベントリを再利用してください。監査の依頼では指摘事項をまとめます。修正の依頼では、ユーザーが許可した範囲内で実装と検証まで進めます。調査のみの依頼では、すべての URL をクロールしたり、コードを変更したりする必要はありません。

エビデンスの範囲を確定する

対象となる公開ホスト、URL プレフィックスまたはドメインのプロパティ、本番環境、プロジェクトまたはサブパス、対象ユーザー、ビジネス上の成果を特定してください。共有ドメインでは、プロジェクトごとにパスを絞り込んでください。アナリティクスでは、数値を解釈する前にホスト名、パス、コンバージョンイベント、アトリビューション期間を確認してください。

まず、接続済みのツールと既存のプロジェクトバインディングを確認してください。確立済みのレポートソースを優先し、次に利用可能な同等のソース、その次にサインイン済みのブラウザーを使用してください。特定のベンダーは必須ではありません。所有権の確認、API の同意、対象を絞ったクエリの成功は、それぞれ別の状態です。隣接する別のプロパティのエクスポートは代替手段になりません。

アクセス不可、データ欠落、非対応、または未測定の指標には、その理由とともに No data を使用してください。これらを、測定済みのゼロと区別してください。過去のエクスポートには、実際の日付を明記してください。認証が必要な指標を利用できない間も、有用な公開情報のチェックを行ってください。

作業手順

複数の作業が混在する大規模な作業では、該当する手順のみを記録します。

• 対象のプロパティ、範囲、ベースライン、意図する成果を確認します。
• 実際の証拠を調査し、影響を受けるルートのパターンまたは調査上の問いを整理します。
• 作業を妨げる不具合と価値の高い機会を優先し、観察事項と仮説を分けます。
• 許可された修正を実施するか、依頼された調査や概要資料を作成します。
• 変更後の動作を再確認し、テストした環境を特定して、残っている課題を報告します。

見た目だけのメタデータ変更より、クロールやインデックス登録の不具合を優先してください。ページタイトル、見出し、コンテンツ構成は、そのページの目的と読者の意図に沿うものにします。ブランド名を含まない説明的な用語はカテゴリの発見に役立ちますが、ブランドを前面に出したポートフォリオページや製品ページが適切な場合もあります。タイトルの文字数に一律の上限を設けることも、見出しを疑問文にすることも、ランキング要件ではありません。タイトルや説明文の書き換えはポジショニングの変更であり、技術的な修正ではありません。references/metadata-copy.md に従い、技術修正のコミットに文章の変更を含めないでください。

AI からの可視性を高めるには、オーナーがクロール可能なアクセス、コンテンツ、抽出可能な構造を整えます。一方、独立したレビュー、比較記事、掲載情報は自然に獲得するものであり、ブランドについての回答内容の大半はそれらによって決まります。まず自社で管理できる領域を修正し、そのうえでサイトを水増しするのではなく、残る改善余地がどこにあるかを説明してください。独自の証拠、有用な比較、製品の制約を正直に伝えることは、作為的なキーワードのバリエーションを量産するよりも重要です。読者が抱きそうな問いを調査してください。検索エンジンのテレメトリーであるかのように、作り上げたクエリの派生を示したり、あらゆるバリエーションごとにページを作成したりしないでください。

参考資料

ファイル	読むタイミング
references/audit.md	サイト監査のクロール、診断、優先順位付けを行うとき。カノニカル、リダイレクト、除外、プログラマティックページ、hreflang、CDN、レスポンスヘッダー、または発見に影響するプレビュー環境について確認するとき
references/nextjs-implementation.md	App Router のメタデータ、サイトマップ、レンダリング、ステータスコード、Markdown の代替ページ、またはスキーマを実装するとき。API はインストール済みの Next.js のドキュメントで確認してください
references/answer-engines.md	SEO、AEO、GEO の用語、AI からの可視性、クローラーのポリシー、自社で管理できる掲載情報と自然に獲得する掲載情報、Markdown の代替ページ、または llms.txt について確認するとき
references/metadata-copy.md	ページタイトル、メタディスクリプション、ソーシャルタイトルを作成または変更するとき。メタデータの変更が機械的なものか、オーナーの承認が必要かを判断するとき
references/validation-evidence.md	調査結果、ビルド済みページ、またはデプロイ済みの修正を検証するとき
references/research-protocol.md	キーワードやプロンプトの指標、機会の選定、問いのマップについて確認するとき
references/brief-template.md	ライター向けブリーフを作成するとき
references/monitoring.md	検索や AI のパフォーマンス、アトリビューション、異常、または定期作業について確認するとき
references/sources.md	主張が、最新のエンジンの動作、対応レポート、またはベンダー調査に基づくとき

提出物

ファイルの指定がない限り、調査結果はチャットで共有します。ライター向けブリーフは、指定されたプロジェクトの保存先に置きます。新しい版を作成する場合も、日付入りの既存ブリーフは保持してください。スクラッチ用のクロールデータやエクスポートはリポジトリに含めないでください。作成するレポートやブリーフでは、エムダッシュを使わないでください。

何を変更したか、その理由、具体的な検証証拠、まだ測定できていないことを報告してください。ローカルビルドの成功、デプロイ可能な状態、公開 URL のプローブ、Google のインデックス記録、測定されたコンバージョンは、それぞれ異なる証拠です。実際に検証できた最も確かな状態を明記してください。

他者への要約の送信、定期作業のスケジュール設定、ツールへの支出、本番環境へのデプロイは、ユーザーの許可とホストのルールに従ってください。既存の適合する監視設定を再利用し、別のオーナーやスケジュールを作成しないでください。

注意点

• サイトマップは、意図的に404を返す/studioを掲載していても解析できてしまいます。XMLの妥当性だけでなく、URLを確認してください。
• マウント後の状態に依存するキャンバスでは、ホームページやカテゴリーハブの初期HTMLにナビゲーションしか残らない場合があります。深い階層のページだけでなく、これらのハブも確認してください。use clientがあるだけで、サーバー側でレンダリングされたコンテンツがないとは限りません。
• lastModified: new Date()やビルド時刻が示すのは生成時刻であり、必ずしもページの重要な更新時刻とは限りません。コンテンツの日付を使用するか、このフィールドを省略してください。
• 各URLにcanonicalタグがあっても、どちらも自身をcanonicalとしている2つの複製ページの問題は解決しません。コンテンツを比較し、優先するURLを選んでください。
• 一貫性のあるJSON-LDスクリプトが2つあってもエラーではありません。スクリプトの数ではなく、エンティティの同一性、対象プロパティ、目に見える裏付けコンテンツを確認してください。
• DNS検証に、架空のメタトークンは必要ありません。スコープを限定したデータアクセスは別途確認してください。
• クローラーのユーザーエージェントを使ったプローブでは、ボットのIPアドレスを認証できず、インデックス登録も確認できません。CDNログと検索エンジンによる調査は、別々の証拠として扱ってください。
• プロンプトの需要、測定された引用、メンション、AIでの表示回数、参照元からのセッション数は、それぞれ異なる指標です。検索エンジン、ソース、マッチタイプ、対象範囲、期間を保持してください。
• 1回のプロンプト実行や、複数の検索エンジンで平均した1つのスコアは、可視性の測定値ではありません。各プロンプトを繰り返し実行し、検索エンジンごとに報告してください。また、再現率は引用とは分けてください。
• Schema、llms.txt、固定長の回答ブロックは、測定された引用の向上要因ではありません。実際の利用者のために保持し、AI可視性の施策として売り込まないでください。
• 優先ページやキャンペーンページのタイトルも書き換えた監査PRは、文言の決定権はオーナーにあるため、その書き換えを差し戻したうえで再提出されました。機械的なメタデータの修正だけを反映し、残りはオーナー向けに一覧化してください。
• ベンダーのSearch Consoleコネクターでは、報告が過少になる場合があります。減少を診断する前に、プロパティ、フィルター、集計結果をSearch Consoleのネイティブデータと照合してください。

保守専用：evals/evals.jsonには、動作シナリオとルーティング用プロンプトが含まれています。スキルを変更するときに読み込まれるもので、通常のSEO作業では読み込まれません。