<!-- new-v1 -->

構造化データジェネレーター比較5選｜JSON-LD を簡単に作成【2026年版】

この記事の結論: 構造化データを毎回手書きする時代は終わりました。Google公式のMarkup Helper、Merkle、Joonbug、Schema App、schemamarkup.devの5ツールを使い分ければ、ArticleからLocalBusinessまで主要スキーマを5分で生成でき、Rich Results Testで一発合格できます。

最終更新日: 2026-05-06

はじめに

「JSON-LDの構文が覚えられない」「@contextや@typeをタイポしてエラーになる」「Productスキーマのプロパティが多すぎて挫折した」という悩みは、構造化データを初めて触る人が必ず通る壁です。この記事では、ブラウザ上で項目を埋めるだけで正しいJSON-LDを吐き出してくれる代表的な5つのジェネレーターを比較し、用途別の最適解を示します。

構造化データは2014年にGoogleがJSON-LDを正式サポートして以来、検索結果のリッチリザルト獲得とAI検索エンジンの引用獲得の両方に効く施策へ進化しました。とくに2025年以降、ChatGPT SearchやPerplexity、Google AI Overviewが回答生成時にSchema.org語彙を参照する挙動が観測されており、「書ける/書けない」の差がそのまま流入差に変換される時代が到来しています。

→ 詳しくは構造化データ（JSON-LD）の書き方で基礎を確認してください。

本記事は、初心者から中級者までを対象に、(1) ジェネレーターを使うべき理由、(2) 5ツールの機能比較、(3) スキーマ種類別の最適ツール、(4) WordPress/Next.jsへの組み込み、(5) Rich Results Testでの検証、(6) 失敗事例と対処、までを一気通貫で解説します。読み終わる頃には、自分のプロジェクトに合うツールが1つ決まり、Article/FAQ/Productの3スキーマを今日から本番投入できる状態になります。

1. 構造化データを手書きする難しさとジェネレーターを使う利点

構造化データ自体はJSONフォーマットの一種で、@contextと@typeを指定し、Schema.org語彙のプロパティを並べていくだけ──と書くと簡単に聞こえます。しかし実際に書いてみると、datePublishedのISO 8601形式、image配列の絶対URL指定、authorの@type: PersonとOrganizationの使い分け、Productのoffersネスト、など細かい罠が無数に存在します。

→ 詳しくは構造化データ（JSON-LD）の書き方の「よくあるエラー」セクションも参照してください。

手書きで頻発する5つのミス

1つ目はプロパティ名の大文字小文字ミスです。datePublishedをdatepublishedと書いてもJSON自体は壊れませんが、Schema.orgとして認識されずRich Results Testで警告が出ます。2つ目は必須プロパティの欠落で、たとえばArticleではheadline、image、datePublished、authorが実質必須となっており、欠けるとリッチリザルト対象外になります。3つ目は画像URLの相対パス指定で、/images/hero.pngと書いてしまい、Googlebotが解決できないケースが頻発します。4つ目は重複定義で、サイト全体に共通のOrganizationを各ページで何度も定義し、整合性が取れなくなる問題です。5つ目はJSON構文エラーで、末尾カンマ・引用符の閉じ忘れなど、人間の目では発見しづらいタイプミスが原因となります。

ジェネレーターを使う3つの利点

第1に、プロパティ名の選択ミスがゼロになる点です。GUIで用意された入力欄に値を埋めるだけなので、headlineをtitleと書く事故が起きません。第2に、必須プロパティの抜け漏れ防止で、多くのジェネレーターが「必須」と「推奨」を視覚的に区別してくれます。第3に、プレビューと検証の即時実行で、生成と同時にRich Results Test相当のチェックが走るツールも増えています。

→ 詳しくはE-E-A-Tとは？信頼性を高める実践ガイドで、author情報の重要性を確認してください。

手書きとジェネレーターの工数比較

10倍以上の効率差があり、運用フェーズに入ったら手書きを継続する合理的理由はほぼありません。例外は「Schema.orgの語彙仕様を学習中」「自動生成スクリプトに組み込むテンプレを作成中」の2ケースのみです。

2. 構造化データジェネレーター5選の概要

ここからは2026年時点で実用に耐える5つのジェネレーターを順に紹介します。料金、対応スキーマ、UIの癖、強み・弱みをそれぞれ整理し、後段の比較表で総合判断できるようにします。

2-1. Google Structured Data Markup Helper (公式)

Googleが提供する公式ジェネレーターで、URLまたはHTMLを入力し、画面上の文字列を選択して「これは見出し」「これは著者」とマッピングしていくタグ付け方式が特徴です。Article、Event、Job Posting、Local Business、Restaurant、Movie、Product、Software Application、Datasetなど主要スキーマに対応しています。

長所はGoogleが直接メンテしている安心感と、既存ページから「逆向き」に構造化データを抽出できる点。短所は対応スキーマが限定的で、FAQやHowToなど近年追加されたスキーマに非対応な場合がある点です。また出力形式が古くMicrodataベースで、現代の主流であるJSON-LDに変換するには別途整形が必要なケースがあります。

→ 詳しくはサーチコンソール基礎ガイドで、生成後の検証フローを確認してください。

2-2. Merkle Schema Markup Generator

Merkle社が無料公開しているジェネレーターで、Article、Breadcrumb、Event、FAQ、How-to、Job Posting、Local Business、Organization、Person、Product、Recipe、Video、Websiteなど15種以上に対応する人気ツールです。フォームに入力するとリアルタイムで右側にJSON-LDが生成されます。

長所は対応スキーマの広さと、UIの分かりやすさ、そして無料で登録不要な手軽さ。SEO業界では実質的なデファクトとして広く使われています。短所は最新仕様への追随がやや遅いこと、そしてカスタムプロパティを追加する自由度がない点です。「標準的な使い方」をする限り、最初に試すべきツールです。

2-3. Joonbug (Saijo George) Schema Generator

Joonbug はSEOスペシャリストSaijo George氏が公開している無料ジェネレーターで、Article、Breadcrumb、Event、FAQ、How-to、Job Posting、Local Business、Organization、Person、Product、Recipe、Video、Websiteに対応しています。Merkleと似た位置付けですが、UIがやや軽量で動作が速いのが特徴です。

長所はモバイルブラウザでも快適に動く軽量設計と、シンプルで迷わないUI。短所はMerkleに比べると細かいプロパティのオプションが少ない点で、たとえばProductスキーマのaggregateRatingやreview配列の詳細指定が制限されています。「Article/FAQ/Breadcrumbだけサクッと作りたい」用途には最適です。

→ 詳しくはSEOとは？初心者向け完全ガイドで、Schema導入の全体像を確認してください。

2-4. Schema App Tools

Schema App はカナダのSchema App社が提供する商用構造化データ管理プラットフォームで、無料の単体ジェネレーターも公開しています。エンタープライズ向けに開発されているため、Schema.orgのほぼ全語彙に対応し、ネスト構造や複雑な関係性も柔軟に表現できます。

長所はカスタマイズ性の高さと、有償プランに移行すればサイト全体のスキーマ管理・自動更新まで一元化できる拡張性。短所は無料版のUIがエンジニア寄りで初心者には敷居が高い点と、有償プランが月額数百ドル〜と高額な点です。エンタープライズSEOチームが導入する選択肢の代表格です。

2-5. schemamarkup.dev (Schema Markup Generator)

schemamarkup.dev は2023年以降に台頭した新興ジェネレーターで、JavaScript/TypeScript開発者向けに設計されています。フォーム入力に加えて、生成されたJSON-LDをnext/scriptタグや<script type="application/ld+json">の形でコピーできるボタンが用意されており、Next.jsやAstroといったモダンフレームワークへの組み込みが速いのが特徴です。

長所はフレームワーク統合の手軽さと、最新スキーマ(2024〜2025年に追加されたもの)への素早い対応。短所はマイナーなため日本語ドキュメントがほぼなく、トラブルシューティング情報が少ない点です。Next.jsでサイトを運用するエンジニアには第一候補になります。

→ 詳しくはLLMOとは？AI検索時代のSEO新常識で、AI検索向け構造化データの考え方も確認してください。

3. 5ツール機能比較表

ここで5つを横並びで比較します。総合的な評価は使用目的によって変わるため、項目ごとに最適解を見極めてください。

対応スキーマと出力形式

JSON-LDが2026年現在の事実上の標準なので、Microdataのみ出力するツールは新規プロジェクトでは避けるのが無難です。

→ 詳しくは構造化データ（JSON-LD）の書き方で出力形式の違いを確認してください。

UIとプレビュー機能

「リアルタイムプレビュー」とは、フォーム入力と同時に右ペインのJSONが更新されることを指します。すべてのツールでこれは備わっていますが、Google Markup Helperだけは「タグ付け→生成ボタン」の手順を踏むため反応が遅く感じられます。

料金体系

無料で十分な用途が大半です。Schema Appの有償プランは「サイト全体のスキーマを管理画面で一元管理」「自動的に各記事のスキーマを更新」といった運用機能が必要な場合に検討対象となります。

学習コストと使い分け

→ 詳しくはE-E-A-Tとは？信頼性を高める実践ガイドで、Author/Organization関連のスキーマ重要性を確認してください。

4. スキーマ種類別おすすめツール

スキーマ種別ごとに各ツールの強みが微妙に異なります。ここでは主要6種について、最も使いやすいツールを根拠とともに示します。

4-1. Article (記事)

ブログ記事・ニュース記事に必須のスキーマです。Article、NewsArticle、BlogPostingの3種があり、内容に応じて使い分けます。最適ツール: Merkle。理由は、headline、image(配列)、author(Personネスト)、publisher(Organizationネスト)、datePublished、dateModifiedの必須プロパティをすべてフォームでカバーしており、画像配列や著者複数人にも対応している点です。

→ 詳しくは構造化データ（JSON-LD）の書き方のArticleセクションを参照してください。

4-2. FAQPage (よくある質問)

FAQ型コンテンツのスキーマで、Google検索の「よくある質問」リッチリザルトの獲得に直結します。最適ツール: Joonbug。理由は質問・回答のペアを動的に追加できるシンプルなUIで、5問・10問と増やしても操作が煩雑にならない設計だからです。なお2023年以降、Googleは「公的機関と医療機関のサイト以外ではFAQリッチリザルトを表示しない」方針に変わったため、リッチリザルト獲得目的では効果が薄れていますが、AI検索エンジンの引用には依然有効です。

→ 詳しくはLLMOとは？AI検索時代のSEO新常識で、FAQのLLMO効果を確認してください。

4-3. Product (商品)

ECサイト・商品紹介ページに必須です。最適ツール: MerkleまたはSchema App。Merkleはoffers(Offerネスト)、aggregateRating(集計レビュー)、review(個別レビュー)を扱え、無料で十分な機能があります。Schema Appは在庫状態・配送情報・GTIN/MPNといった上級プロパティまで網羅し、本格EC向けです。

4-4. Review (レビュー)

単独レビュー記事や星評価のスキーマです。最適ツール: Merkle。itemReviewedに何をレビューするか(Product/Movie/Bookなど)を指定し、reviewRatingで1〜5の評点を出力します。

4-5. HowTo (手順解説)

レシピ以外の手順型コンテンツのスキーマです。最適ツール: JoonbugまたはMerkle。手順(step)を順序付き配列で指定し、各ステップに画像・所要時間・必要な道具を含められます。なおGoogleは2023年に「HowToリッチリザルトの表示対象を縮小」方針を発表しており、現状はAI検索向けの意味合いが強くなっています。

→ 詳しくはLLMOとは？AI検索時代のSEO新常識も参照してください。

4-6. LocalBusiness (店舗・ローカルビジネス)

実店舗・サービス事業者向けスキーマです。最適ツール: Google Markup HelperまたはMerkle。Googleが運営しているMarkup Helperは、Googleマップとの連携を意識した推奨プロパティが揃っており、地名・住所・営業時間・電話番号・座標などをきれいに出力できます。

5. WordPress プラグインで自動生成する選択肢

ジェネレーターでJSON-LDを生成して埋め込むのも一つの方法ですが、WordPressサイトの場合はプラグインで全ページに自動生成する選択肢が現実的です。

主要プラグインの比較

Rank MathはFAQ、HowTo、Product、Eventなど20種以上のスキーマが完全無料で使え、最初の選択肢として優秀です。Yoast SEOは老舗で安定運用に強く、エンタープライズ採用も多い選択肢です。

→ 詳しくはサーチコンソール基礎ガイドで、プラグイン導入後のGoogle GSCでの確認方法を参照してください。

プラグイン vs 手動ジェネレーターの判断基準

• 記事数が100本未満かつ運用者が1〜2人: 手動ジェネレーターでも十分管理可能
• 記事数が100本以上または運用者が3人以上: プラグイン自動生成が現実的
• 記事ごとにスキーマを大幅にカスタマイズしたい: 手動ジェネレーター + 部分プラグイン

なおプラグインで生成した場合も、定期的にRich Results Testで検証する運用は必須です。プラグインのバージョンアップで思わぬスキーマ変化が起きるためです。

6. Next.js での Schema 実装テンプレート

Next.js (App Router) で構造化データを実装する場合、<Script>コンポーネントまたはMetadata APIのotherフィールド経由で挿入するのが定石です。schemamarkup.devで生成したJSON-LDをそのままコピーして使えます。

Article スキーマの実装例

// app/articles/[slug]/page.tsx
import Script from 'next/script';

export default function ArticlePage({ params }) {
  const articleSchema = {
    "@context": "https://schema.org",
    "@type": "Article",
    "headline": "記事タイトル",
    "image": ["https://example.com/og.png"],
    "datePublished": "2026-05-06T00:00:00+09:00",
    "dateModified": "2026-05-06T00:00:00+09:00",
    "author": {
      "@type": "Person",
      "name": "編集部"
    },
    "publisher": {
      "@type": "Organization",
      "name": "AISEO LLMO",
      "logo": {
        "@type": "ImageObject",
        "url": "https://example.com/logo.png"
      }
    }
  };

  return (
    <>
      <Script
        id="article-schema"
        type="application/ld+json"
        dangerouslySetInnerHTML={{ __html: JSON.stringify(articleSchema) }}
      />
      {/* 記事本文 */}
    </>
  );
}

BreadcrumbList スキーマの実装例

const breadcrumbSchema = {
  "@context": "https://schema.org",
  "@type": "BreadcrumbList",
  "itemListElement": [
    { "@type": "ListItem", "position": 1, "name": "ホーム", "item": "https://example.com/" },
    { "@type": "ListItem", "position": 2, "name": "記事一覧", "item": "https://example.com/articles" },
    { "@type": "ListItem", "position": 3, "name": "記事タイトル" }
  ]
};

FAQPage スキーマの実装例

const faqSchema = {
  "@context": "https://schema.org",
  "@type": "FAQPage",
  "mainEntity": [
    {
      "@type": "Question",
      "name": "ジェネレーターを使うと手書きより劣化しますか？",
      "acceptedAnswer": {
        "@type": "Answer",
        "text": "いいえ、出力されるJSON-LDは仕様準拠のため手書きと同等以上の品質です。"
      }
    }
  ]
};

Metadata API経由の方法

App RouterではgenerateMetadata内のotherフィールドにJSON-LD文字列を設定する方法もあります。ただしApp RouterのRSCコンテキストでは<Script>コンポーネント経由のほうが扱いやすく、推奨されています。

→ 詳しくは構造化データ（JSON-LD）の書き方で実装の全体像を確認してください。

7. Google Rich Results Test での検証方法

JSON-LDを実装したら、必ずGoogle公式のRich Results Testで検証します。これは構造化データのデバッグにおいて最も信頼できる手段です。

検証の手順

1. Rich Results Testのページを開く
2. 「URLでテスト」または「コードでテスト」を選択
3. 公開済みページならURLを、未公開ならJSON-LDコードを貼り付け
4. 「URLをテスト」ボタンをクリック
5. 結果画面で「有効なアイテム」「警告」「エラー」を確認

結果画面の見方

よくあるエラーと対処

「Either 'offers', 'review' or 'aggregateRating' should be specified」はProductスキーマでoffers/review/aggregateRatingのいずれかが必須ですよ、という警告です。価格情報のないProductでは少なくとも1つを追加しましょう。

「Missing field 'image'」はArticle/Productで画像URLが指定されていないエラーです。画像は配列形式かつ絶対URLで指定する必要があります。

「Invalid value type for property 'datePublished'」は日時形式エラーで、ISO 8601 (2026-05-06T00:00:00+09:00形式) で指定する必要があります。

→ 詳しくはサーチコンソール基礎ガイドで、Rich Results Test以外のGoogle Search Console上のGSCレポートでの確認方法を参照してください。

Schema Markup Validatorとの違い

Rich Results Testは「Googleがリッチリザルトとして処理できるか」を判定し、対応スキーマに限定して検証します。一方、Schema.org公式のSchema Markup Validator は「Schema.org仕様として正しいか」を判定し、より広範なスキーマに対応します。両方を併用するのが理想で、まずはSchema.org Validatorで構文チェック、次にRich Results Testでリッチリザルト適格性を確認、という流れになります。

8. AI クローラ (LLM) への影響

2024〜2025年にかけて急速に注目されているのが、構造化データのAI検索エンジンへの影響です。ChatGPT Search、Perplexity、Google AI Overview、Microsoft CopilotなどのLLMO文脈での挙動が話題になっています。

LLMがSchema.orgを参照する3つの場面

第1に、ファクト抽出です。Articleスキーマのheadline、author、datePublishedからタイトル・著者・日付を確実に取得し、回答内で「○○氏が2026年5月に発表した記事によれば」と引用しやすくなります。第2に、FAQ自動応答で、FAQPageスキーマがあるページはユーザーの質問とQ&Aがマッチしやすく、AI回答の根拠として採用されやすくなります。第3に、Productの仕様抽出で、価格・在庫・レビュー数などをLLMが構造的に取得して比較表を生成する用途に使われます。

→ 詳しくはLLMOとは？AI検索時代のSEO新常識で、AI検索最適化の全体像を確認してください。

Schema.orgが効くLLMと効かないLLM

完璧に「Schema.orgを書けばLLMに引用される」という単純な関係ではありませんが、書いていないより明らかに有利であることは複数の観測で一貫しています。

LLMO観点で優先すべきスキーマ

1. Article / NewsArticle / BlogPosting: 記事の主題・著者・日付の明示
2. FAQPage: 質問への直接回答獲得
3. Organization / Person: E-E-A-Tシグナル強化
4. Product: 商品比較系の引用獲得
5. HowTo: 手順解説系の引用獲得

→ 詳しくはE-E-A-Tとは？信頼性を高める実践ガイドで、E-E-A-Tと構造化データの関係を確認してください。

9. 失敗事例と対処法

実装時に見落としがちな落とし穴を、実例ベースで紹介します。

失敗事例1: 画像URLを相対パスで指定

「画像が表示されない」というのは構造化データで最も多い相談です。原因はほぼimageプロパティの相対パス指定で、"image": "/og.png"と書いてしまうとGooglebotが解決できません。対処: 必ず絶対URL (https://example.com/og.png) で指定し、複数画像をサポートするスキーマでは配列形式 (["url1", "url2"]) を使用します。

失敗事例2: 著者を文字列で指定

"author": "山田太郎" と書くとSchema.org仕様違反です。対処: "author": { "@type": "Person", "name": "山田太郎" } の形式で記述します。さらに著者のプロフィールページがあればurl、SNSアカウントがあればsameAs配列を追加することで、E-E-A-T評価とAI検索の引用率が向上します。

失敗事例3: FAQPageが多すぎて警告

FAQをページに30問載せ、mainEntityに30個全て突っ込んだ結果、Rich Results Testで「異常な数の質問」として警告が出るケースがあります。対処: FAQPageスキーマには10問前後までを掲載するのが安全圏です。それ以上は別ページに分割するか、スキーマからは抜粋して掲載します。

失敗事例4: dateModified を更新し忘れ

毎月リライトしているのにdateModifiedを初版日のまま放置するケースです。対処: CMSやNext.jsのfrontmatterにreviewedAtフィールドを設け、ビルド時に自動的にdateModifiedへ反映する仕組みを作ります。

失敗事例5: Organization の重複定義

トップページとフッター、各記事ページでOrganizationスキーマを少しずつ違う内容で定義してしまい、Googleが混乱するケースです。対処: Organizationはサイト全体で1箇所(トップページのhead内など)にのみ定義し、各ページからは@idで参照します。

{
  "@context": "https://schema.org",
  "@type": "Article",
  "publisher": { "@id": "https://example.com/#organization" }
}

失敗事例6: ChatGPTで生成したJSON-LDをそのまま使う

LLMが生成するJSON-LDは構文的には正しくても、@typeの選択ミス(NewsArticleにすべきところをArticleにする等)、Schema.orgに存在しないプロパティの混入、@contextのtypoなどがしばしば発生します。対処: LLM生成は出発点として使い、必ずジェネレーターで形式を整えてからRich Results Testで検証します。

→ 詳しくはE-E-A-Tとは？信頼性を高める実践ガイドで、信頼できるコンテンツ作成の原則を確認してください。

10. 運用フロー設計

ジェネレーターを単発で使うだけでなく、運用フローに組み込むことで効果が安定します。

推奨運用フロー (週次)

月次レビュー項目

• リッチリザルト表示数の推移
• エラー件数の推移
• 新たに追加されたSchema.org語彙のキャッチアップ
• AI検索での引用回数(BrandwatchやSparktoroで観測)

→ 詳しくはサーチコンソール基礎ガイドで、リッチリザルトレポートの読み方を確認してください。

スケール時のチェックポイント

記事数が500本を超えるとマニュアル運用は破綻するため、(1) Next.js等での自動生成スクリプト化、(2) Rank MathなどのCMSプラグインへの移行、(3) Schema App等のエンタープライズ管理ツール導入、のいずれかを検討します。

よくある質問

Q1. 無料ツールで本当に十分ですか？

A. 個人〜中小規模サイトであれば、Merkle・Joonbug・schemamarkup.devの3つで十分カバーできます。エンタープライズ規模(数千記事以上)になって初めてSchema App等の有償ツールを検討すれば良いでしょう。

Q2. Google公式のMarkup Helperが時代遅れと聞きました。本当ですか？

A. 半分本当です。出力形式が古くJSON-LD直接出力に対応していないため、現代の実装には不向きです。ただし「既存ページから構造化データを抽出する」「LocalBusinessをGoogleマップと連携を意識して書く」用途では今も有用です。

Q3. ジェネレーターで作ったJSON-LDをそのまま使うのは安全ですか？

A. 基本的には安全ですが、必ずRich Results Testで検証してから本番投入してください。ツール側のバグや、サイト固有の事情(ドメイン・著者情報など)による不整合が起きる可能性があります。

Q4. WordPressプラグインとジェネレーターはどちらを優先すべきですか？

A. WordPressサイトでサイト全体に統一スキーマを適用するならプラグイン優先、特定ページだけカスタムスキーマを入れたいならジェネレーターが向きます。Rank Math + 必要に応じてジェネレーター、というハイブリッド運用がおすすめです。

Q5. JSON-LDとMicrodataは混在させても大丈夫ですか？

A. 技術的には混在可能ですが、Googleは混在を非推奨としています。同じページに両方ある場合、Googleがどちらを優先するか保証されません。JSON-LDに統一するのが2026年現在の正解です。

Q6. AI検索向けには特別なスキーマが必要ですか？

A. 現時点では「AI検索専用スキーマ」は存在せず、既存のSchema.org語彙(Article、FAQPage、Person、Organization等)を正しく実装することがそのままLLMO効果につながります。将来的にOpenAI等が独自拡張を提案する可能性はあります。

Q7. Rich Results Testで「警告」が出ているけど大丈夫ですか？

A. 警告は「リッチリザルト対象外ではないが推奨プロパティが欠けている」状態です。リッチリザルト自体は表示される可能性が高いものの、推奨プロパティを追加することでより目立つ表示や追加情報が出る可能性があります。優先度は中程度で、時間を見つけて対応するのがおすすめです。

Q8. 構造化データを入れると検索順位は上がりますか？

A. 構造化データそのものは直接的なランキング要因ではないとGoogleは公式に述べています。ただし(1) リッチリザルトによるCTR向上、(2) AI検索での引用獲得、(3) E-E-A-Tシグナル強化、を通じて間接的に流入が増える効果が観測されています。

→ 詳しくはSEOとは？初心者向け完全ガイドで、ランキング要因全体の話も確認してください。

関連用語

• SEO
• 構造化データ
• JSON-LD
• Schema.org
• E-E-A-T
• LLMO
• GSC

関連記事

• 構造化データ（JSON-LD）の書き方
• SEOとは？初心者向け完全ガイド【2026年版】
• LLMOとは？AI検索時代のSEO新常識
• E-E-A-Tとは？信頼性を高める実践ガイド
• サーチコンソール基礎ガイド

参考文献・出典

• Google Search Central — 構造化データ概要 — Google公式
• Google Rich Results Test — リッチリザルト検証ツール
• Schema.org公式 — 構造化データ語彙仕様
• Schema Markup Validator — Schema.org公式バリデーター
• Merkle Schema Markup Generator — 無料ジェネレーター