Astro SEO は何をしますか？
AstroサイトのSEO設定を、Astro SEO: the definitive guide に記載されているフルスタックに対して監査・改善します。このスキルは9つの領域（技術基盤、構造化データ、コンテンツ、サイト構造、パフォーマンス、サイトマップとインデックス、エージェントディスカバリー、リダイレクト、アナリティクス）をカバーし、不足または弱い部分に対してはドロップインコードを生成します。
このスキルの意見の中核は @jdevalk/astro-seo-graph です。ほとんどの修正はこのパッケージを通じて行われます。プロジェクトでまだ使用されていない場合は、インストールが最初の推奨事項です。
コードレシピは AGENTS.md にあります — 特定の修正を実装する必要がある場合はそれを読んでください。このファイルにはワークフローと監査チェックリストが含まれています。
ワークフロー
- プロジェクトを検出する — これがAstroサイトであることを確認し、その構造を理解します。
- 監査する — 9つのカテゴリをスコアリングし、実行可能な発見事項を生成します。
- 改善する — ギャップを埋めるためにファイルを生成または修正します。レシピは
AGENTS.mdにあります。 - メタデータパス — スキルが生成したすべてのショート文字列（タイトル、説明、スキーマ
descriptionフィールド、FAQの回答、フロントマターの抜粋）に対してmetadata-checkを呼び出します。 - 検証する — ビルドを実行し、検証が成功することを確認し、ファイル以外のタスク（Search Console、Bing Webmaster Tools、IndexNowキー検証）についてユーザーに注意を促します。
フェーズ 0: プロジェクトを検出する
監査前に基本事項を確認します。
astro.config.mjs/astro.config.tsが存在するか。package.jsonにastroが依存関係として含まれているか。astro.configでsite:が設定されているか — カノニカルURL、サイトマップ、OG画像URLはすべてこれから派生します。欠落している、空である、またはhttp://localhostの場合は、他のすべてに先立ってブロッキング問題としてフラグを立ててください。これは最も一般的な設定ミスです。src/content/（またはレガシーsrc/pages/のマークダウン）のコンテンツコレクション。- デプロイメントターゲット —
package.json、vercel.json、netlify.toml、wrangler.toml、またはpublic/_headersを読み取り、ホストを特定します。これにより、フェーズ2でのリダイレクトおよびヘッダー構文が決まります。 @jdevalk/astro-seo-graphはすでにインストールされているか？ インストールされている場合は、バージョンと配線されている機能（<Seo、seoGraph(、createSchemaEndpoint、createSchemaMap、FuzzyRedirect、createIndexNowKeyRoute、createMarkdownEndpoint、createApiCatalog、gitLastmodをgrep）を記録します。インストールされているバージョンをnpmの最新バージョンと比較 するにはnpm view @jdevalk/astro-seo-graph versionを実行します。プロジェクトが古い場合は、機能ギャップの監査を行う前に、フェーズ2でアップグレードを推奨します — このパッケージは新しいデフォルトと修正を定期的に出荷しており、古いバージョンは監査結果の原因として考えられます。フェーズ2はこれに基づいて分岐します。- サイトは多言語ですか？
astro.configのi18nまたはsrc/content/以下の複数のロケールディレクトリを確認します。多言語の場合はhreflangが重要です。そうでない場合はスキップします。
検出できないことだけを質問してください。サイトの内容をユーザーに尋ねないでください — astro.config.mjs とホームページのコンテンツを読んでください。
フェーズ 1: 監査
各カテゴリを10点満点でスコアリングします。それぞれについて、実際のコードまたは設定を引用した2～4つの具体的な発見事項を示します。各カテゴリ内では、チェックは階層化されています。
- Must — 出荷をブロックするもの。ここでの失敗は、目に見えるSEOの後退を引き起こします。
- Should — 標準的なプラクティス。スキップするとリーチが犠牲になります。
- Nice — 将来を見据えたもの、または状況に応じたもの。すべてのサイトのベースラインではありませんが、役立ちます。
ユーザーが完全な処理を要求しない限り、小規模な個人ブログでは Nice チェックをスキップします。
1. <Seo> コンポーネントとheadメタデータ (/10)
- Must — すべてのheadメタデータのための単一コンポーネント（レイアウトに分散していないこと）。
- Must —
astro.configのsite:がプロダクションオリジンに設定されていること。 - Must —
site設定から派生したカノニカルURLで、トラッキングパラメータが削除されていること。 - Must —
noindexが true の場合、カノニカルを省略すること（Googleの推奨による）。 - Must — 欠落したSEOフィールドのためのフォールバックチェーン:
seo.title → title → siteName;seo.description → excerpt → first paragraph。空白のタイトルまたは説明を持つページは、フォールバックが壊れている最も一般的な症状です。 - Should —
robotsメタにmax-snippet:-1、max-image-preview:large、max-video-preview:-1が含まれていること。 - Should — TwitterカードがOpen Graphと重複する場合、抑制されていること（Twitterは自動的にフォールバックします）。
- Should — 多言語サイトには
hreflangの代替が存在すること。単一言語の場合はスキップします。 - Nice — 手書きではなく
@jdevalk/astro-seo-graphの<Seo>コンポーネントを使用していること。（上記のすべてをカバーする手書きのものは問題ありません。このスキルはデフォルトでフォールバックチェーンとロボットルールを処理するため、パッケージを推奨します。）
2. 構造化データ / JSON-LD グラフ (/10)
- 単一のフラットな
Articleオブジェクト、またはリンクされた@graphと複数のエンティティ？ - エンティティは
@id参照で配線されているか？ WebSite、Blog/WebPage、Person/Organization、BlogPosting/Article、BreadcrumbList、ImageObjectはすべて関連する場合に存在するか？- 信頼シグナル:
publishingPrinciples、copyrightHolder、copyrightYear、knowsAbout、SearchAction？ - リッチリザルトテスト と ClassySchema で検証されるか？
3. コンテンツコレクションとSEOスキーマ (/10)
- コンテンツコレクションはZodスキーマで定義されているか？
@jdevalk/astro-seo-graphのseoSchemaがタイトル（5～120）と説明（15～160）の長さを強制しているか？- 必須フィールド（
publishDate、title、excerpt）がビルド時に強制されているか？ - マークダウンが除去された
articleBodyがスキーマエンドポイントで公開されているか（最大10K文字）？
4. Open Graph 画像 (/10)
- すべてのページにOG画像があるか、それとも多くが欠落しているか？
- 1200×675（Google Discoverの最低幅1200px、16:9比）？
- satori + sharp を使用してビルド時に生成されているか、それとも手動か？
- JPEG（ソーシャルプラットフォームはWebP/AVIFを確実にサポートしていない）？
- ルートはスラッグから自動的にOG URLを導出するか？
- レンダリングされたHTML内のすべての
<img>にalt属性（または装飾画像の場合はalt=""/role="presentation"）があるか？ ≥ 1.1.0 のseoGraph()のvalidateImageAltがビルド時にこれをキャッチします。
5. サイトマップとインデックス (/10)
- Must —
@astrojs/sitemapがインストールされ、サイトマップインデックスにアクセス可能であること。 - Must —
robots.txtがサイトマップインデックスを参照していること。 - Must — RSSフィードが存在し（
@astrojs/rss）、<link rel="alternate" type="application/rss+xml">で告知され、完全な投稿コンテンツ（切り詰められていない抜粋ではない）を含んでいること。 - Should —
chunksオプションを使用してコレクションごとに分割されていること（sitemap-posts-0.xmlなど） — GSCでのインデックスデバッグがはるかに簡単になります。 - Should —
lastmodがフロントマターの日付やCIファイルのタイムスタンプではなく、gitコミットタイムスタンプから設定されていること。@jdevalk/astro-seo-graph≥ 1.4.0 はこのためのgitLastmod(filePath, { excludeCommits, depth })をエクスポートします — これはファイルに触れた最新の除外されていないコミットのコミッター日付を返すか、gitが利用できない場合はnullを返します。サイトマップのserializeコールバックに配線します。コードベースに手書きのexecSync('git log ...')ヘルパーがある場合は、パッケージのエクスポートに置き換えてください — このエクスポートは、単純な-1ルックアップでは処理できないバルクコミットの除外（インポート、再フォーマット）を処理します。 - Should — IndexNowが統合され、各ビルドで送信され、
/[key].txtにキー検証ルートがあること。≥ 1.0.1 はデフォルトで/404を送信から除外します。プロダクションホストで送信をゲート します（例：process.env.CF_PAGES === '1' && CF_PAGES_BRANCH === 'main'、VERCEL_ENV === 'production'、CONTEXT === 'production'）。無条件の送信は、ローカルのnpm run buildとプレビューデプロイのたびに、プロダクションホストがまだ提供していないURLでエンドポイントをpingし、その結果キーが無効（403）とマークされ、ローテーションを強制します。
6. エージェントディスカバリー (/10)
- Should — コーパス全体のJSON-LDを公開するスキーマエンドポイント（
/schema/*.json）があること。 - Should — すべてのエンドポイントをリストアップしたスキーママップ（
/schemamap.xml）があり、robots.txtにSchemamap:ディレクティブがあること。 - Should — サイトルートに
llms.txtがあり、LLMコンシューマー向けにページ（タイトル + 説明）をリストアップしていること。@jdevalk/astro-seo-graph≥ 0.9.0 はllmsTxt統合オプションを介してこれを生成します。 - Should — AIエージェントがHTML解析なしで消費できるように、YAMLフロントマター付きのクリーンなマークダウンを提供するマークダウン代替URL（
/blog/post.mdが/blog/post/の隣にある）があること。@jdevalk/astro-seo-graph≥ 1.2.0 は、ルート用のcreateMarkdownEndpointと、すべてのページに<link rel="alternate" type="text/markdown">を出力するmarkdownAlternate: true統合オプションを出荷しています。≥ 1.3.0 はビルド後検証を追加します。統合はビルド出力をウォークし、.mdターゲットがディスク上にないリンクを（発生ごとにwarnを付けて）削除します — これにより、設定ミスのあるエンドポイントは、出荷された404ではなくビルド警告として表面化します。SSRを必要とせずにAccept: text/markdownでのコンテンツネゴシエーションを行うために、Cloudflare Transform Rule（wildcard_replaceを使用したURL書き換え、Vary: Acceptヘッダーなし — CFはカスタムVary値を削除します）と組み合わせます。 - Should — RFC 9727 に従って
/.well-known/api-catalogにAPIカタログがあること。@jdevalk/astro-seo-graph≥ 1.4.0 はcreateApiCatalogを出荷しており、これはスキーマエンドポイントをhttps://schema.org/<Type>URLに自動型付けし、パスをsiteUrlに対して絶対パスにします。スキーマエンドポイント、スキーママップ、およびサイト固有のAPI（/ask、/feed.xmlなど）をリストアップします。RFCは確定しているため、フォーマットは安定しています。採用は初期段階ですが、コストは1つのルートファイルです。 - Should —
robots.txtのContent Signalsディレクティブ（例：Content-Signal: ai-train=yes, search=yes, ai-input=yes）。クロールアクセスとは独立して、AIトレーニング、検索グラウンディング、AI入力使用に関する設定を宣言します。仕様は IETFドラフト であり、採用は初期段階ですが、すべてのサイトがすでに持っているファイルの1行です。 - Should — ディスカバリーファイル（サイトマップ、llms.txt、api-catalog、schemamap、およびサイトが公開するMCP / A2Aカード）を指す
Linkヘッダーが/*にあること。応答ヘッダーを読み取るエージェントは、HTMLを解析せずにそれらを見つけます。Cloudflare Pages / Netlify ではpublic/_headersに、Vercel ではvercel.jsonにあります。 - Nice —
/.well-known/mcp/server-card.jsonのMCPサーバーカード（SEP-1649）および/または/.well-known/agent-card.jsonのA2Aエージェントカード（A2Aプロトコル）。サイトが実際にMCPサーバーまたはA2Aエージェントを公開している場合にのみ関連します。どちらも、エンドポイント、機能、スキルを宣言する静的JSONファイルです。それ以外の場合はスキップします。 - Nice — 会話型エンドポイントを指す
<link rel="nlweb">。NLWebは初期段階です。タグは1行であり、持つ価値がありますが、2026年時点ではスコアリングのブロッカーではありません。 - Nice —
/.well-known/ai-catalog.jsonのARD（Agentic Resource Discovery）カタログ。ドメインが提供するもの（MCPサーバー、A2Aエージェント、OKFバンドル、サイト固有のAPI）をリストアップします。v0.9ドラフトのためオプションですが、MCP / A2AカードとOKFバンドルがその価値を発揮するためのディスカバリーレイヤーです。2つの注意点があります。ベース仕様（Agent-Card/ai-catalog）はメディアタイプフィールドにmediaTypeという名前を付けているのに対し、ARDレイヤー（ards-project/ard-spec）はtypeという名前を付けています — エントリがいずれかの読み取りで検証されるように、同じ値を持つ両方のキーを出力 します（両方の仕様はコンシューマーが未知のキーを無視することを要求しています）。ARDはまた、エントリごとにオプションのrepresentativeQueries配列（サンプルプロンプト）を追加します。 - Nice — OKF（Open Knowledge Format）バンドル。型付けされたマークダウンコンセプトファイル（ページごとに1つ、パスはカノニカルURLをミラーリング）のツリーで、単一の
.tar.gzとしてパッケージ化され、間にインデックスファイルがあります。提供とディスカバリーはOKFの明示的な非目標です — それがARDカタログエントリの目的です。v0.9ドラフト、オプション。登録されたメディアタイプはまだないため、中間的な文字列はapplication/okf-bundle+gzipです（knowledge-catalog#111 と ard-spec#27 で追跡されています）。中間的なものであり、変更される可能性があることに注意してください。手動で管理されたコピーではなく、既存のコンテンツパイプラインのもう1つの出力として生成するのが最適です。
7. パフォーマンス (/10)
- デフォルトで静的出力（必要ないページにSSRを使用していない）？
- アイランドが必要でない限り、クライアント側JSはゼロ？
- すべてのコンテンツ画像にAstro
<Image>コンポーネントが使用されているか（レスポンシブsrcset、WebP、遅延ロード、非同期）？ - プライマリWebフォントがwoff2でプリロードされているか？
- プリフェッチのために
defaultStrategy: 'viewport'の<ClientRouter />が使用されているか？ /_astro/の下にあるハッシュ化されたアセットはCache-Control: public, max-age=31536000, immutableを提供しているか？- キャッシュキーからUTMパラメータを削除する
No-Vary-Search応答ヘッダーがあるか？
8. リダイレクトとエラー処理 (/10)
- 存在して移動したすべてのURLに対して
public/_redirects（または同等のもの）が維持されているか？ - 恒久的な移動には301、302ではないか？
@jdevalk/astro-seo-graphのFuzzyRedirectコンポーネントが404ページに配線されているか？- 404ページ自体が200ではなく404ステータスを返しているか？
9. ビルド時間検証とコンテンツ品質 (/10)
- Must —
seoGraph()統合が各ビルドで実行され、validateH1とvalidateUniqueMetadataが有効になっていること。JSON-LD検証のために、seo-graph-coreのassembleGraph()にwarnOnDanglingReferences: trueを渡します — これは統合オプションではなく、アセンブリ時のチェックです。 - Should —
seoGraph()でvalidateImageAlt、validateMetadataLength、およびvalidateInternalLinksが有効になっていること（すべて ≥ 1.1.0 でデフォルトtrue）。これらは、altテキストの欠落、SERP境界外のタイトルまたは説明（デフォルト: タイトル30～65、説明70～200）、および404になるか末尾スラッシュの不一致に当たる内部リンクをキャッチします。プロジェクトが1.1.0の場合、≥ 1.1.1 にアップグレードしてください — そのパッチリリースは2つのバリデーターバグを修正します。validateInternalLinksはpublic/アセットを有効なターゲットとして認識するようになりました（/images/*や/fonts/*での誤検出はもうありません）。また、validateMetadataLengthは、特定の文字（絵文字、アクセント付き文字、スマート引用符など）を含む説明を切り詰めなくなりました。代わりにそれらを適切にカウントします。