seo-schema-jsonld について
seo-schema-jsonldは、ページの構造化データを監査し、修正案を作成するClaude Codeスキルです。ページ内容とスキーマ要件に照らしてJSON-LDを確認し、AI検索への効果を誇張しません。
主な機能
- 01JSON-LD、microdata、RDFaの確認
- 02スキーマ型とプロパティの検証
- 03マークアップと表示内容の照合
- 04Tier-1 JSON-LD修正案の作成
- 05ローカルツールやバリデーターでの検証
活用シーン
- 01記事や商品ページの構造化データ監査
- 02無効または不完全なスキーマの特定
- 03ページ向けJSON-LD変更案の準備
- 04スキーマの日付と表示内容の照合
インストール
コマンドをコピーしてターミナルで実行します。
npx skills add https:/ / github.com/ hainrixz/ claude-seo-ai --skill seo-schema-jsonldインストール後、Claude Code で/seo-schema-jsonldを入力して読み込まれたか確認します。
詳細
seo-schema-jsonld (M5)
構造化データは、従来のリッチリザルトと AI による引用の両方において、最も効果の高いシグナルです。参照先:references/schema-tier1.md。テンプレート:schema/jsonld-templates/。
入力
ディスパッチエンベロープで指定された PageSnapshot を使用します。<run_dir>/pages/<slug>.json から parsed(jsonld[]、microdata_items、headings[]、images[])を読み込み、pages/<slug>.html を Grep して逐語的な証拠を確認します。サイトのアーティファクトは <run_dir>/site/{robots.json,sitemaps.json,discovery.json} にあります。audit.mjs がすでに出力した決定論的な検出結果は <run_dir>/findings.deterministic.json に記載されています。該当する ID を再出力せず、モデルが判定した検出結果のみを追加してください。スナップショットが存在せず、URL/パスを直接指定して実行する場合は、まず node "${CLAUDE_PLUGIN_ROOT}/scripts/snapshot.mjs" <target> --out "${CLAUDE_PLUGIN_DATA}/runs" を実行し、出力されたスナップショットのパスを使用してください。
監査
PageSnapshot を使用して確認します(render.used が none でない場合は parsed_rendered、それ以外は parsed)。
- 検出:すべての
<script type="application/ld+json">ブロックを検出して JSON を解析します。インラインの microdata/RDFa があれば、JSON-LD への移行対象として記録します。 - 検証:各ブロックについて、JSON が有効であること、
@typeが認識されること、references/schema-tier1.mdに基づく必須プロパティと推奨プロパティが含まれていることを確認します。 - 網羅性:ページのコンテンツと分野に照らして確認します。例:記事ページには
author(Person)、datePublished、dateModified、image、publisherを含むArticle/BlogPosting、商品ページにはprice、priceCurrency、availabilityを含むProductとOfferが必要です。 - エンティティの整合性:安定した
@id、@graphのリンク、sameAsを確認します(sameAsの監査詳細は M6/seo-entity-linking に委ねます)。 - 日付の一致:スキーマの
datePublished/dateModifiedが表示されている日付と一致する必要があります(M13 と相互確認します)。 - 廃止状況の正確な扱い:
FAQPage/HowToがある場合、リッチリザルトの成果として報告しないでください。廃止済み(SERP 対象外)とラベル付けします(AI では引き続き解析可能です)。
修正(修正可能:自動)
不足または不完全な Tier-1 タイプについて、ページのコンテンツから推定した完全で有効な JSON-LD ブロックを生成します。
<article>、<h1>、著者表示、日付、ヒーロー画像からArticle/BlogPostingを生成します。- フッター、連絡先、ロゴから
Organization/WebSiteを生成します。 - 商品の DOM から
ProductとOffer(名前、画像、価格、通貨、在庫状況)を生成します。 - ナビゲーションのパンくずリストから
BreadcrumbListを生成します。 - ユーザーが提供する認証情報フィールドを含む
Person(著者)を生成します。
安定した @id を使用して、単一の @graph を使います。不足している dateModified/@id を挿入します。このブロックは fix(AUTO)用の差分です。価格、日付、評価、sameAs のアイデンティティリンクを決して捏造しないでください。ユーザーに確認するか、ユーザーが入力する明確な TODO プレースホルダーを残してください。
検証
- オフライン:
node "${CLAUDE_PLUGIN_ROOT}/scripts/validate-jsonld.mjs" --snapshot <pages/<slug>.json>(または--url <u>)を実行します。JSON の有効性と、テンプレートに照らした必須プロパティを確認します。 - Tier 1:Google Rich Results Test/schema.org バリデーターで適格性を確認します。利用できない場合、ステータスは
passではなくneeds_apiです。
検出結果
schema/finding.schema.json に従って検出結果を出力します。重大度ポリシー:5は、サイト/テンプレート単位で適格性を失わせる壊滅的な事実にのみ使用します。4は重大、3は中程度、2は軽微、1はごく軽微、0は情報提供です。また、スコアに上限を設けられるのは、有効なカテゴリにおける、重大度5でestablishedのfailのみです(references/scoring-model.md)。例:
M5.article.missing— 編集ページにArticleスキーマがありません(fail、重大度4、fixable: auto、軸both、確信度established)。M5.product.missing_offer_price— 商品ページにあるProductにOffer.priceがありません(fail、重大度4、fixable: auto、軸both、確信度established)。ここでカウントするのは、Productを宣言しているノードのみです(lib/jsonld.mjsのclassifyProductNodes)。hasVariantのメンバーはそのProductGroupに属し、レビューのitemReviewedとisSimilarTo/isRelatedToノードは別の場所で宣言されたアイテムを参照します。また、ネストされたurl/nameのみのノードはポインターです。いずれも、このページに欠けているマークアップではありません。M5.jsonld.invalid_json—ld+jsonブロックを解析できないため、その中のすべての型が認識されません(fail、重大度4、fixable: auto、軸both、確信度established)。M5.jsonld.contradicts_page— マークアップの値(価格、評価、日付、著者)がページの表示内容と一致しません(fail、重大度4、fixable: proposed、軸both、確信度established)。M5.faqpage.deprecated_richresult— FAQPageが存在します(warn、重大度1、fixable: advisory、軸ai、確信度established。根拠ではGoogleによるFAQリッチリザルトの廃止に言及します。成功としてはカウントしません)。
プラットフォーム条件付きID。 このモジュールは、profile.jsonでプラットフォーム(shopify、wordpress)が指定されている場合にのみ発火するIDも4つ出力します。これらはreferences/routing.mdの§ Platform-conditional finding idsに一覧があり、references/platforms/<id>.mdの§10で仕様が定められています。
各検出結果では、evidence.observedにページ上の内容を引用し、verification.reproduceに上記の実行可能なコマンドを記載します。expected_impactは、範囲と確信度タグを付けて示します(根拠のないパーセンテージは記載しません)。
正確性
- Googleは、AI機能向けの特別なschema.org型、プロパティ、「AIスキーマ」を文書化していません。 AI Overviews/AI Modeへの適格性は、インデックス登録され、スニペット表示の対象となること(M14)によって決まり、マークアップによって決まるものではありません。文書化されているため
establishedといえるのは、構造化データが有効であり、ページの表示内容と一致している必要があるという点です。これは、リッチリザルトと、Googleが取り込む販売者/ビジネスデータの両方に適用されます。スキーマ作業は「ページを機械可読で正確なものにする」と位置付け、「AIの引用を可能にする」とは説明しないでください。 - FAQPage/HowTo:引き続き解析可能ですが、Googleのリッチリザルトはありません。存在する場合はそのままにし、SERP機能を期待して追加しないでください。
- ページに表示されていないコンテンツにはマークアップを付けず、スキーマを商品フィードの内容と一致させてください。値の捏造や不一致は、成功ではなく手動による対策や不承認を招きます。
- 有効なブロックは最低条件であり、ランキング向上の手段ではありません。正しいスキーマの存在は適格性として報告し、掲載順位の変化を予測してはなりません。