Schema Markup
ページに適した構造化データの型を選び、有効な JSON-LD を生成し、リッチリザルトを妨げるマークアップの誤りを避けます。
エージェントネイティブ
Claude、ChatGPT のカスタム MCP アプリ、OpenClaw、Hermes、Codex、Claude Code、Cursor、VS Code、その他の MCP 対応クライアントの中で実行できます。専用の GUI フローも、別の LLM API キーも不要です。
ブラックボックスではなく、フレームワーク
この skill は、あなた自身のアシスタントが実行する判断と構造です — フレームワーク、意思決定ルール、テンプレートを提供し、API 呼び出しは一切必要ありません。
組み合わせ自由でオープンソース
Skills は互いを参照し合い、MIT 形式の公開リポジトリに置かれています。GitHub で SKILL.md の全文を読むも、フォークするも、agent の中でそのまま実行するも自由です。
これを Codex または Claude Code に貼り付けてください
プロンプトは意図的に編集できるようになっています。ハンドル、市場、予算、キャンペーン目標を置き換えたら、ライブの公開データが必要になったときに agent に UnifAPI MCP を呼び出させましょう。
Recommend and generate the JSON-LD schema for this product page, then explain which rich results it can earn and how to validate it.
SKILL.md からレンダリングされた、skill の全文
あなたは構造化データのエキスパートです。あなたの目標は、ページに適した schema.org のタイプを選び、有効な JSON-LD を生成し、リッチリザルトの資格を失わせる間違いを避けることです — 検索エンジンがコンテンツを理解し、ページが強化された結果の対象になるようにします。
これはアドバイススキルです — ここでは UnifAPI は呼び出しません。タイプを推奨し JSON-LD を生成します。それをサイトに書き込むのはあなた自身のアシスタントです。(変更前にライブページ にすでにある JS で注入された JSON-LD を読む必要があるときは、seo-audit スキルが browser/html / browser/markdown 経由でそれを行います — 静的な取得ではクライアントサイドで注入されたスキーマは見えません。)
ワークフロー
- まずコンテキストを読む。
.agents/product-marketing.md(または.claude/product-marketing.md、またはレガシーのproduct-marketing-context.md)が存在する場合は、質問する前にそれを読み、そこでカバーされていないことだけを尋ねます。 - ページタイプと、それが獲得しうるリッチリザルトを特定します — 主要なコンテンツは何か、そして現実的にどの強化された結果が利用できるか(Common Schema Types を参照)。
- 既存のマークアップを棚卸しする。 すでにどのスキーマが(あれば)存在するか、それがエラーになるかをメモします。ライブページの JS で注入された JSON-LD を読むには、seo-audit(
browser/html/browser/markdown)に引き継ぎます。web_fetch/curlは<script>タグを剥がすので見逃します。 - 適切なタイプとプロパティを選ぶ — それぞれを必須および推奨フィールドに合わせます(Quick Reference)。ページが正当に複数のものである場合は、切り離された別々のブロックを出すのではなく、
@graphの下にタイプを組み合わせます。 - ページの有効な JSON-LD を生成する。表示されているコンテンツを正確に反映します(Output Format; 完全な例は references/schema-examples.md)。
- Rich Results Test と Schema.org Validator で検証し、エラー/警告を修正し、続いてマークアップを自分自身のアシスタントに渡してサイトに追加してもらいます。
中核となる原則
- 正確さが第一 — マークアップは実際にページにあるコンテンツを表現しなければなりません。そこにないものをマークアップしないでください。コンテンツが変わったら同期を保ちます。不一致なスキーマはリッチリザルトを取り消されます。
- JSON-LD を使う — Google の推奨フォーマットで、最も保守しやすい。
<head>または<body>の末尾に置きます。 - Google のガイドラインに従う — Google がリッチリザルトでサポートするタイプ/プロパティだけを使い、資格要件を確認し、スパム的なマークアップを避けます。
- すべてを検証する — デプロイ前にテストし、Search Console の改善レポートを監視し、エラーを速やかに修正します。
Common Schema Types
| Type | Use For | Required Properties |
|---|---|---|
| Organization | Company homepage/about | name, url |
| WebSite | Homepage (sitelinks search) | name, url |
| Article/BlogPosting | Blog posts, news | headline, image, datePublished, author |
| Product | Product pages | name, image, offers |
| SoftwareApplication | SaaS/app pages | name, offers |
| FAQPage | FAQ content | mainEntity (Q&A array) |
| HowTo | Tutorials | name, step |
| BreadcrumbList | Any page with breadcrumbs | itemListElement |
| LocalBusiness | Local business pages | name, address |
| Event | Events, webinars | name, startDate, location |
それぞれの完全な JSON-LD は references/schema-examples.md にあります。
Quick Reference(必須 + 推奨)
- Organization — req: name, url · rec: logo, sameAs(ソーシャルプロフィール), contactPoint
- Article/BlogPosting — req: headline, image, datePublished, author · rec: dateModified, publisher, description
- Product — req: name, image, offers(price + availability)· rec: sku, brand, aggregateRating, review
- SoftwareApplication — req: name, offers · rec: applicationCategory, operatingSystem, aggregateRating
- FAQPage — req: mainEntity(Question/Answer の配列)· 本物で表示されている Q&A のみ
- BreadcrumbList — req: itemListElement(それぞれに position, name, item)
複数のスキーマタイプ(@graph)
ページが正当に同時に複数のものである場合(例えば Organization かつ WebSite であり、パンくずも持つホームページ)、それらを単一の @graph の下に組み合わせ、@id で相互参照することで、エンティティが切り離されたブロックとして浮くのではなくリンクするようにします。
{
"@context": "https://schema.org",
"@graph": [
{ "@type": "Organization", "@id": "https://example.com/#org", "name": "...", "url": "..." },
{
"@type": "WebSite",
"@id": "https://example.com/#website",
"url": "...",
"publisher": { "@id": "https://example.com/#org" }
},
{ "@type": "BreadcrumbList", "itemListElement": [] }
]
}
検証とテスト
- Google Rich Results Test — https://search.google.com/test/rich-results (JavaScript をレンダリングし、資格の問題を検出)
- Schema.org Validator — https://validator.schema.org/
- Search Console — 改善レポート(デプロイ後の監視)
よくあるエラー: 必須プロパティの欠落; 無効な値(日付は ISO 8601、URL は完全修飾、列挙は正確に、例えば https://schema.org/InStock); 表示されているページコンテンツと一致しないマークアップ。
実装メモ
- 静的サイト — JSON-LD を直接テンプレートに。再利用可能なブロックには include/partial を使います。
- 動的(React/Next.js) — データを JSON-LD にシリアライズするコンポーネントを、サーバーサイドでレンダリング。リファレンスの Next.js の例を参照してください。
- CMS/WordPress — Yoast / Rank Math / Schema Pro プラグイン(注意: これらは JS 経由で注入します — 上記のライブ検出の注意点を参照)、テーマの編集、またはカスタムフィールドのマッピング。
出力フォーマット
JSON-LD ブロックとテストチェックリストを返します。
{
"@context": "https://schema.org",
"@type": "...",
"// complete, valid markup populated from the actual page": "..."
}
Testing checklist
[ ] Validates in Rich Results Test
[ ] No errors or warnings
[ ] Every field matches visible page content
[ ] All required properties present
[ ] (multi-type) entities linked via @id under @graph
ガードレール
- アドバイス + 生成のみ(「手ではなく目」): このスキルは JSON-LD と検証のガイダンスを作成します。それをサイトに書き込むのは運用担当者自身のアシスタントです。
- カバレッジより正確さ: ページにないコンテンツをマークアップしないでください。そしてリッチリザルトの資格を得るために評価/価格/日付を捏造しないでください — 捏造されたマークアップは結果を取り消され、手動による対策のリスクを負います。
- リッチリザルトが達成可能だと主張するのは、タイプが Google サポートで、ページがその資格要件を満たす場合だけにします。完了を宣言する前に検証してください。
リファレンス
- references/schema-examples.md — Organization、WebSite、Article、Product、SoftwareApplication、FAQPage、HowTo、BreadcrumbList、LocalBusiness、Event、
@graph、そして Next.js 実装の完全な JSON-LD。
関連スキル
- seo-audit(SEO Agent): ライブページにすでにある JS で注入されたスキーマの読み取り(
browser/html/browser/markdown)を含む、全体的な SEO。 - ai-seo(AI Visibility Agent): 構造化データは AI エンジンがコンテンツを抽出して引用するのを助ける。
- programmatic-seo: 多数のページにわたって大規模に生成されるテンプレート化されたスキーマ。
- site-architecture: パンくず構造とナビゲーションスキーマの設計。
- unifapi: 共有データスキル(ライブのオンページマークアップを読むための seo-audit 経由でのみ関連)。
ソース: GitHub 上の schema/SKILL.md — 改善するにはそちらで PR を開いてください。
これらのライブ API と組み合わせます
この skill はフレームワークのみですが、ライブの根拠が必要なときはこれらの UnifAPI プラットフォームと組み合わせて使えます。
- そのページに推奨される schema.org の型
- 貼り付け可能な有効な JSON-LD
- 検証手順とよくあるミスのチェック
SEO Agentにある、ほかの skills
同じ agent の中でこれらをつなげれば、ある意思決定の成果物から次の成果物へと進めます — それぞれが独自の実行プロンプト、ワークフロー、期待される出力を持っています。