schema-markup

スキーママークアップ

ページで実際に宣言されている内容を監査し、そこに含めるべきエンティティを判断したうえで、検証済みの事実だけを用いて検証済みの JSON-LD を生成します。検索順位、リッチリザルト、CTR の向上、AI による引用を決して約束しないでください。

ルールの出典

次のラベルを用いて、重要なルールを解釈してください。

• Semrush が裏付けるガイダンス： 引用された Semrush の記事に記載されている方法論です。記事の適用条件と注意事項を維持してください。
• 現行のプラットフォーム要件： 現行の Google Search Central または Schema.org の要件です。古くなった編集上の例より優先されます。
• 業界の実装上のヒューリスティック： 検索エンジンの要件や成果の保証ではなく、妥当な実装上の慣行です。
• 設定可能なデフォルト： ユーザーのシステムやニーズに応じて変更できるワークフローまたは出力の選択肢です。

証拠の出典とルールの分類は分けてください。各結果では、Semrush MCP のデータ、レンダリング済みページの証拠、バリデーターの出力、ユーザーが提供した事実、モデルによる判断を区別できるようにしてください。

必ず守るガードレール

• Semrush が裏付けるガイダンス： スキーマは機械可読なコンテキストであり、リッチリザルトの対象となる可能性を示すものとして扱ってください。直接的なランキング要因として扱わないでください。有効なマークアップがあっても、リッチリザルトが表示される保証はないと明記してください。
• Semrush が裏付けるガイダンス： AI での可視性への影響は不確実なものとして扱ってください。スキーマが ChatGPT、Claude、Gemini、その他の AI システムでの可視性を直接高めると主張しないでください。
• 現行のプラットフォーム要件： マークアップは、ページに表示されているコンテンツと最新の事実に一致している必要があります。編集上の例が古くなっている場合は、現行の Google Search Central の要件と Schema.org の語彙を使用してください。
• 現行のプラットフォーム要件： 評価、レビュー件数、価格、在庫状況、日付、著者、住所、ロゴ、その他のエンティティに関する事実を決して捏造しないでください。
• ワークフローの安全ルール： ユーザーから別途許可を得ない限り、本番コードを編集またはデプロイしないでください。

開始する前に

次の入力を一度だけ収集してください。

• 対象： 正確な URL、提供されたマークアップ、または既存の Semrush プロジェクトがあるドメイン。
• モード： 監査、提案、ドラフト作成、検証、または監視。
• ページの目的： ホームページ、記事、商品、レビュー、動画、ローカルビジネス、または明確に特定されたその他の種類。
• 証拠へのアクセス： レンダリング済みブラウザー、raw HTML、Google の検証結果、Semrush MCP、Site Audit のエクスポート、またはユーザーが提供した事実。
• 実装のコンテキスト： 配置方法の案内をユーザーが希望する場合に限り、CMS またはフレームワーク。

ページの種類または事実に基づくエンティティデータが不明確な場合は、まず監査してください。推測に基づいて、そのままデプロイできるコードを生成しないでください。

公式 Semrush MCP を使用する

検出 → スキーマ → 実行の順に進めてください。公開 MCP レポート識別子の代わりに、製品 UI 上の名前を使用しないでください。

プロジェクトに基づくサイト監査のフロー

1. projects を呼び出して list_projects を見つけます。
2. list_projects の get_report_schema を呼び出し、続いて execute_report を呼び出して、ドメインに該当する既存プロジェクトを探します。
3. site_audit を呼び出し、現在公開されているレポートを確認します。
4. 現在の snapshots スキーマを取得し、必須パラメーター（現在は project_id ではなく id）を使ってプロジェクト識別子を渡します。次に、最新の完了済み監査を選び、その日付を記録します。
5. meta_issues を使って、問題カタログと各問題の ID および説明を確認します。これは問題の定義に関するメタデータとして扱い、選択したスナップショットで列挙された問題が発生した証拠とはみなしません。
6. 返された説明がマークアップまたは構造化データに関する問題だけを選択します。
7. 現在の issue_details スキーマを取得し、必須のプロジェクト、スナップショット、問題の各パラメーターを指定して、少数の結果を取得します。スキーマの確認と実行の両方で受け付けられることが確認できない限り、任意の sort 値を送信しないでください。実行時に任意の並べ替えが拒否された場合は、証拠の取得条件を変えずに省略します。
8. 正確なクロール済み URL を 1 つ指定し、page_list を使って候補となるページ ID を取得します。要求した URL と返された URL を正規化し、完全一致するものを選びます。レポートが前方一致または近似一致の結果を返す可能性があるため、最初の結果が完全一致だと想定しないでください。次に page_info を使ってページ単位の証拠を取得します。

検証済みの公開 MCP では、markup という名前のレポートも、製品 UI の「Markup」テーマ別レポートも公開されていません。そのレポート、マークアップスコア、またはハードコードされた問題 ID を提供すると約束しないでください。

MCP の制約

• プロジェクトへのアクセスは読み取り専用です。プロジェクトの作成、設定変更、新たなクロールを約束しないでください。
• レポート呼び出しは API ユニットを消費します。必要なフィールドと行だけを要求し、必要に応じて範囲を広げてください。
• 検出結果には、Site Audit のスナップショット日付とクロールの対象範囲を明記してください。
• issue_details の行は、問題の発生を示す証拠として扱ってください。結果が空の場合、それはそのプロジェクト、スナップショット、問題のリクエストに対して一致する行が返されなかったことを意味します。レンダリング後のページが有効であることや、すべてのスキーマの問題がないことを証明するものではありません。
• プロジェクト、キャンペーン、スナップショット、問題の種類、フィールド、サブスクリプション、または API ユニット残高が利用できない場合、それはアクセス上の制約であり、サイトにスキーマの問題がない証拠ではありません。

証拠の優先順位

設定可能なデフォルト： 利用可能な証拠のうち、次の順で最も強いものを使用し、その種類を明記してください。ユーザーが、より権威のあるファーストパーティまたはプラットフォームの証拠を提供した場合は、順序を変更してください。

1. 既存の Semrush プロジェクトと完了済みの Site Audit スナップショット。
2. ユーザーが提供した Site Audit または構造化データのエクスポート。
3. ブラウザーでレンダリングされた DOM の検査。
4. Google Rich Results Test、またはユーザーが提供したバリデーターの出力。
5. 生の HTML の検査。
6. ユーザーが提供したスキーマコードと検証済みのページ情報。

ページの読み込み後に挿入された JSON-LD は、生の HTML では見つからないことがあります。JavaScript による挿入の可能性がある場合、静的な取得だけを根拠に「スキーマは見つかりませんでした」と報告しないでください。

サポート対象の v1 スキーマタイプ

設定可能な製品スコープ： 以下のタイプは最初のリリースで対応する範囲を定めるものであり、その他の Schema.org タイプが重要でないという意味ではありません。

コードを生成する前に、Google Search Central の最新ドキュメントを再確認してください。適格性とプロパティの要件は変更される可能性があります。

共通の選択ルール

• Semrush がサポートするガイダンス： ページが対象とするキーワードではなく、目に見える主要なエンティティを記述し、エンティティに正確に当てはまる有効なタイプのうち、最も具体的なものを優先します。
• 現在のプラットフォーム要件： 値が目に見える、またはユーザーが確認したプロパティのみを含めます。バリデーターを通過させることだけを目的に、評価、オファー、著者、住所、メディアを追加しないでください。
• 業界の実装ヒューリスティック： 安定した @id の値を再利用して、サイト全体で同じエンティティを一貫して結び付けます。

Organization

正規のホームページまたは組織を定義するページで使用します。name、正規のurl、クロール可能なlogo、安定した@id、実在するsameAsプロフィールを確認してください。パブリッシャー、販売者、プロバイダーとしての参照情報と、一貫したアイデンティティを保ってください。ナレッジパネルの表示を約束しないでください。

出典：Organization Schema

Article and BlogPosting

閲覧可能な編集コンテンツに使用します。headline、正規URLまたは@id、代表的なimage、正確なdatePublishedとdateModified、特定されたauthor、サイトのOrganizationエンティティにリンクされたpublisherを確認してください。鮮度を演出するためだけに日付を変更したり、著者の経歴を捏造したりしないでください。

出典：Schema Markup

Product and merchant listing

購入可能な特定の製品に使用します。name、画像、説明、製品識別子、および価格、通貨、在庫状況、URL、販売者など、表示されているoffersデータを確認してください。評価やレビューを追加するのは、実際のレビューが表示されている場合に限ります。最新のGoogleドキュメントを参照し、製品スニペットの対象要件と販売者リスティングの要件を区別してください。

出典：Schema Markup および Rich Snippets

Review and AggregateRating

レビューまたは総合評価が表示され、評価対象が明確な場合に限り使用します。itemReviewed、著者、記載されている場合はレビュー本文、評価値と評価尺度、正確な評価数またはレビュー数、表示されている日付を確認してください。サポート対象の項目タイプと、自社に有利なレビューに関する制限について、最新のGoogleポリシーを確認してください。

出典：Review Schema

VideoObject

動画がページの主要な視聴可能コンテンツである場合に使用します。name、説明、クロール可能なthumbnailUrl、正確なuploadDate、contentUrlまたはembedUrl、判明している場合は再生時間を確認してください。ページと動画で裏付けられている場合に限り、クリップまたはライブストリームのプロパティを追加してください。

出典：Video Schema

LocalBusiness

実店舗の事業所に使用します。最も具体的で正確なサブタイプを選んでください。名称、正規URL、住所、公開されている電話番号、営業時間、判明している場合は座標、関連画像、および場所ごとに一意で安定した@idを確認してください。住所、営業時間、電話番号が異なる事業所を統合しないでください。

レビュー対象の英語のコンテンツ一覧には、現在のLocalBusiness専用記事はありません。公開前に、Semrushの正規のスキーマガイドと最新のGoogleドキュメントを照合して、このモジュールを確認してください。

出典：Schema Markup

その他の検出されたタイプ

その他のタイプは、構文、語彙、表示コンテンツとの一致、アイデンティティ、重複の観点から全般的に監査してください。コードを生成する前に、最新のSchema.org定義と、該当するものがあれば対応するGoogle機能のドキュメントを確認してください。

v1ではFAQPageやHowToの生成を優先しないでください。Googleの検索機能におけるこれらの扱いは変化しており、レビュー対象のSemrushの英語コンテンツ一覧には、これらを主要モジュールとして扱うための十分な根拠となる最新情報がありません。

ワークフロー

業界のワークフローに関する指針： 検出、タイプの選択、実装のレビュー、下書き、検証を分けるために、この順序を使用してください。選択したモードでワークフローの一部だけが必要な場合は、適宜調整してください。

1. 既存のマークアップを棚卸しする

• レンダリング済みの script[type="application/ld+json"] ブロックを調査します。
• Microdata と RDFa がある場合は調査します。
• JSON-LD のオブジェクト、配列、@graph ノードを解析します。証拠を黙って修正せず、解析エラーを報告します。
• 各エンティティの @type、@id、主要プロパティ、ソース URL、抽出方法を記録します。
• 重複した ID、競合するプロパティ、関連付けられていないエンティティ、古い値を特定します。

ページの証拠は Semrush のクロール証拠と分けて扱います。Site Audit の問題から影響を受ける URL を特定できますが、最終的にレンダリングされたマークアップの調査に代わるものではありません。

2. スキーマの適合性を判断する

• ページの主たるエンティティと、ユーザー向けの目的を特定します。
• 表示されているコンテンツを説明するスキーマタイプのみを選びます。
• Schema.org の妥当性と、Google 検索機能の対象となる適格性を区別します。
• 提案する各タイプが適用される理由、または適用されない理由を説明します。
• 上記のサポート対象 v1 ガイダンスを参照してから、それらのタイプを生成します。

可能であれば検出された他のタイプも診断しますが、サポート対象外のタイプについてコードを生成する前に、Google と Schema.org の最新ドキュメントを確認します。

3. 実装の品質を監査する

以下を確認します。

• JSON の構文と、Schema.org 用語の妥当性。
• 該当する Google 機能の現在の必須プロパティと推奨プロパティ。
• 表示されている名前、価格、通貨、在庫状況、評価、レビュー数、日付、著者、ロゴ、住所、メディアとの一致。
• 正規 URL、絶対アセット URL、安定した @id 値。
• エンティティの入れ子構造と関係が正しいこと。
• 重複、矛盾、誤解を招く、非表示、または古いプロパティ。
• マークアップがクロール可能で、レンダリング後の DOM に存在すること。

業界の実装ヒューリスティック： 技術的な妥当性、ポリシー上のリスク、ページの重要度、検索結果での表示への影響度に基づいて問題に優先順位を付けます。普遍的に適用できるスコア区分を作り出してはいけません。

4. JSON-LD を作成または修正する

• 現在のプラットフォーム推奨事項： サイトの設定で可能な場合、新しいコードには JSON-LD を優先します。Google は、妥当な Microdata と RDFa もサポートしています。
• 表示されている情報、またはユーザーが確認した情報のみを基に生成します。
• 既存のマークアップを修正する場合、妥当な識別子は保持します。
• 複数のエンティティ間の関係を明示する必要がある場合は、一貫性のある @graph を使用します。
• 安定した絶対 @id 値を使います。通常は #organization や #article のように、正規 URL にフラグメントを付けます。
• 関連するプロパティのみを含めます。マークアップを増やせばよいわけではありません。
• 必須情報が不足している場合は、デプロイ可能なコードではなく、不足情報の一覧を提示します。
• テンプレートが有用な場合は、すべてのプレースホルダーを明確に示し、ブロックにデプロイ不可と明記します。

5. 検証する

業界のワークフローヒューリスティック： 次の順序で検証します。

1. JSON-LD を解析します。
2. すべての用語を Schema.org に照らして確認します。
3. すべての事実に関するプロパティを、ページに表示されているコンテンツと照合します。
4. Google がサポートする機能について、Google の Rich Results Test を実行します。
5. 実装後にページを再確認します。

Schema.org に準拠した結果を、Google のリッチリザルトの対象となる証拠として扱ってはいけません。警告の意味を確認せず、バリデーターの警告をエラーとして扱ってはいけません。

6. 引き継ぐ

ユーザーの CMS またはフレームワークに適した配置方法を案内しますが、デプロイはしません。ユーザーが実装を調整している場合は、検証手順と再テストのアクションを明示します。

出力形式

設定可能なデフォルト： 選択したモードで必要なセクションのみを返します。

1. 総合判定： 合格、要対応、または証拠不十分。
2. 使用した証拠： Semrush のスナップショット、レンダリング済みページ、raw HTML、バリデーター、提供されたコード、ユーザー提供の事実。
3. マークアップの一覧： エンティティ、タイプ、主なプロパティ、抽出方法、参照元 URL。
4. 問題の一覧： 優先度、問題、影響を受けるプロパティまたは URL、証拠、影響、修正方法。
5. 推奨スキーママップ： ページタイプ → スキーマタイプ → 推奨理由。
6. 修正済み JSON-LD： 検証済みの事実が十分にある場合のみ。
7. 検証チェックリスト： 構文、語彙、コンテンツとの一致、Google の適格性、レンダリングの確認。
8. 実装メモ： 配置場所、未解決の制約、再テストのアクション。

次の証拠の分類は、明確に分けてください。

• Semrush MCP： プロジェクトおよび Site Audit のスナップショットデータ。
• ページの証拠： レンダリング済みページまたは raw ページコンテンツ。
• バリデーターの証拠： Google または Schema.org の検証結果。
• ユーザー提供の事実： ユーザーから直接提供されたビジネスまたはエンティティ情報。
• モデルの判断： タイプの選択、優先順位付け、推奨する関連付け。

参照元

Semrush の方法論：

• スキーママークアップ
• 動画スキーマ
• リッチリザルト
• レビュー スキーマ
• 組織スキーマ

技術的な一次情報：

• Google：構造化データの概要
• Google：構造化データに関する一般的なガイドライン
• Google リッチリザルト テスト
• Schema.org の語彙