JSON-LDの種類は、Schema.orgの語彙上では数百に及びますが、実務で押さえるべきは代表10タイプに絞れます。結論として、記事なら「Article／BlogPosting」、店舗なら「LocalBusiness」、商品なら「Product」、質問集なら「FAQPage」というように、ページの中身に合うタイプを選ぶのが基本です。本記事では、代表10タイプを「用途・向いているページ・効果・注意点」で一覧化し、ページ種別からの逆引き、最小コード例、検証手順まで解説します。読了後、迷わず自サイトに適切なJSON-LDを選び実装できる状態を目指します。
- 代表10タイプの用途と使い分けが一覧でわかる
- 自分のページに何を入れるべきか逆引きで判断できる
- 実装後の検証とよくあるエラー対策までわかる
実務で使うのは代表10タイプで十分であり、記事はArticle、店舗はLocalBusiness、商品はProductが軸になります。ページ種別ごとに「基本セット＋固有タイプ」を組み合わせれば迷いません。実装後はリッチリザルトテストなど3ツールで検証し、本文と一致しないマークアップは避けるのが安全です。
JSON-LDの種類とは？まず全体像を把握する
JSON-LDの種類とは、Schema.orgで定義された「エンティティの型」のことで、Article（記事）やLocalBusiness（店舗）などを@typeで指定して使います。数は膨大ですが、Googleが検索結果で特別表示するリッチリザルト機能は約30種類にとどまり、実務で頻出するのはさらに絞った代表10タイプです。
まずは、JSON-LDと関連用語の関係を整理します。混同しやすい3つの言葉を分けて理解すると、種類選びの見通しが一気に良くなります。
JSON-LDとSchema.orgとリッチリザルトの違いは？
JSON-LDは「記述形式」、Schema.orgは「語彙」、リッチリザルトは「表示結果」という役割分担です。JSON-LDという書き方の器に、Schema.orgという単語帳で意味を入れ、その成果として検索画面にリッチリザルトが出る関係になります。JSON-LDは「JSON for Linked Data」の略で、2014年にW3Cが勧告した仕様です（GMO TECH）。語彙のSchema.orgはGoogle・Microsoft・Yahoo!などが共同策定したものを用います。
なぜJSON-LDが推奨されるのか？
Googleは実装・保守が最も容易なJSON-LDを推奨しています。構造化データの記述形式はJSON-LD・Microdata・RDFaの3種類がありますが、正しく実装されていれば等価に扱われます（Google検索セントラル）。HTMLと切り離してscript内にまとめて書けるため、後からの修正や複数タイプの併記がしやすい点が大きな利点です。以下に3形式を比較します。
| 形式 | 書く場所 | 保守性 | Google推奨 |
|---|---|---|---|
| JSON-LD | scriptにまとめて記述 | 高い | 推奨 |
| Microdata | HTMLタグに直接付与 | やや低い | 対応 |
| RDFa | HTMLタグに属性付与 | やや低い | 対応 |
全タイプを入れる必要はある？
すべてを入れる必要はなく、ページの中身に該当するタイプだけを選ぶのが正解です。Schema.orgのタイプ数（数百）に対し、Googleが視覚的に反映するのは約30機能で、代表7種類を紹介する整理もあります（GIG）。優先順位を付け、効果の高いものから段階的に実装する考え方が現実的です。この考え方はGoogleのランキング要因ではなく、AI検索やAI Overviewでの引用を見据えた設計とも相性が良いといえます。
TechSuite株式会社の「AI検索パートナーズ」は、生成AIが引用・推薦する仕組みを構造化データや意味的文脈、エンティティ認識の観点から技術的に捉え、LLMO/GEO/AEOを一次情報設計まで踏み込んで支援しています。
種類は多くても、まず器と語彙と表示結果を分けて捉えれば、選ぶべきタイプは自然と見えてきますよ。
代表10タイプの用途と効果を一覧で知りたい
代表10タイプは、記事・パンくず・組織・店舗・商品・質問・手順・評価・イベント・サイト情報をカバーします。まずは横断できる早見表で「何に使い、どのページに向き、リッチリザルト対応か」を把握しましょう。
次の表は、用途と向いているページ、リッチリザルト対応の有無、AI検索やナレッジグラフでの効果を一覧化したものです。自サイトのページを思い浮かべながら照らし合わせると選びやすくなります。
| タイプ | 用途 | 向くページ | リッチリザルト |
|---|---|---|---|
| Article / BlogPosting | 記事の著者・日付明示 | 記事・ニュース | 対応 |
| BreadcrumbList | 階層の可視化 | 全ページ | 対応 |
| Organization | 企業情報の明示 | トップ・会社概要 | 知識パネル寄与 |
| LocalBusiness | 店舗の所在・営業 | 店舗ページ | 対応 |
| Product＋Offer | 価格・在庫の明示 | EC商品 | 対応 |
| FAQPage | 質問と回答 | FAQ・記事内Q&A | 対応 |
| HowTo | 手順の明示 | 使い方解説 | 対応 |
| Review / AggregateRating | 評価の明示 | 商品・店舗 | 対応 |
| Event | 開催日時・場所 | セミナー告知 | 対応 |
| WebSite | サイト名・検索 | トップ | 検索ボックス |
リッチリザルト対応タイプと表示されないタイプの違いは？
リッチリザルト対応タイプは検索画面に視覚的な変化をもたらし、非対応でも入れる価値のあるタイプは意味づけを補強します。Organizationやサービス系のタイプは見た目に出なくても、AI検索やナレッジグラフでの理解を助ける土台になります。Service等はリッチリザルト非対応でもAI Overviewでの参照が増える傾向が指摘されています（Webries）。表示狙いと理解狙いを分けて考えるのがコツです。
構造化データで得られる効果は？
構造化データは直接的なランキング要因ではありませんが、間接的な効果があります。リッチリザルトによるクリック率向上、知識パネルへの採用、AI検索への引用採用が代表的な効果です（ENVY DESIGN）。コードは通常1KB未満で表示速度への影響はほぼ無視でき、費用対効果の高い施策といえます。順位そのものより、露出後の選ばれやすさを底上げする役割です。
TechSuite株式会社の「AI検索パートナーズ」は、自社サイトでAI Share of Voiceを高水準に保ち、支援事例でAI Overviewの引用率を改善した実績をもとに、タイプ選定の優先順位を提案しています。
まずは早見表で当たりを付け、表示狙いと理解狙いを分けて選ぶと、無駄なく効果を積み上げられます。
AI検索パートナーズでは、
AIに”選ばれる”ための戦略設計から実行まで支援！
代表10タイプを実例のコードで理解したい
ここでは各タイプの用途と最小コードの要点、注意点を解説します。共通ルールは、scriptで囲み、@contextはSchema.org固定、@typeで型を指定することです。まずは記事系から見ていきます。
ArticleとBlogPostingはどう使う？
記事・ブログ・ニュースにはArticleまたはBlogPostingを使い、見出し・著者・公開日を明示します。headlineとauthorとdatePublishedを揃えるだけで、記事としての意味づけが大きく前進します。最小構成では@type、headline、author、datePublished、imageを含めます。オウンドメディアの各記事に共通で入れる基本タイプで、著者性の明示はE-E-A-Tの補強にもつながります。
BreadcrumbListとOrganizationは何を伝える？
BreadcrumbListはページ階層を、Organizationは企業情報を検索エンジンに伝えます。パンくずはpositionを1から順に振り、途中で番号を飛ばさないことがエラー回避の要点です。Organizationにはname、url、logo、sameAs（公式SNS等）を記述します。Organizationはサイト内で重複させず、原則1か所に集約するのが安全な運用です。両者はほぼ全サイトで共通して入れる土台になります。
LocalBusinessとProductはどう書く？
LocalBusinessは店舗の所在地・営業時間を、ProductはOfferと組み合わせて価格・在庫を伝えます。LocalBusinessはGoogleビジネスプロフィールと両方実装し、住所や電話番号を完全一致させるのが推奨です（Webries）。Productではname、image、offers（priceとpriceCurrencyとavailability）を最小構成とします。ECではReviewやAggregateRatingの併記で訴求力が高まります。
FAQPageとHowToの違いは？
FAQPageは独立した質問と回答の集合、HowToは順序のある手順を表します。FAQは本文に実際に掲載している質問数とJSON-LDの数を必ず一致させることが重要です。HowToはstepごとにnameとtextを配置し、必要に応じて画像を添えます。いずれもページに表示されていない内容をマークアップするのはガイドライン違反となり、反映されません（GIG）。AEO対策の観点でも、FAQは問いと答えを明快に対応させる設計が有効です。
ReviewとEventとWebSiteの使いどころは？
Reviewは個別評価、AggregateRatingは平均評価、Eventは開催情報、WebSiteはサイト名と検索ボックスを伝えます。Eventはname・startDate・location・offersを揃えると、開催前の告知として拾われやすくなります。WebSiteにpotentialActionを加えるとサイトリンク検索ボックスの対象になります。このほかPerson・Recipe・JobPosting・VideoObjectも、該当ページがあれば追加していく補足タイプです。
TechSuite株式会社の「AI検索パートナーズ」は、AIを活用した高度なコンテンツ制作の仕組みを「バクヤスAI記事代行」で培い、その制作エンジンとナレッジを転用して、想定質問の分解に沿った高品質なマークアップ設計を高速に行えます。
各タイプの最小実装でまず押さえたい必須プロパティです。
- Article＝headline・author・datePublished
- LocalBusiness＝name・address・telephone・openingHours
- Product＝name・offers（price・priceCurrency・availability）
- FAQPage＝mainEntity（question・acceptedAnswer）
最小構成の必須プロパティから始め、余裕が出たら推奨項目を足していくのが失敗しない進め方です。
AI検索パートナーズでは、AIに”選ばれる”ための戦略設計から実行まで一気通貫で支援！
AI検索パートナーズでは、AI検索の専門知識と支援実績を持つ専任コンサルタントが、AIに“引用される・選ばれる”ための戦略設計からコンテンツ最適化、効果測定・改善まで一気通貫でご支援いたします。
ご興味のある方は、ぜひ資料をダウンロードして詳細をご確認ください。
どのタイプを入れる？ページ種別から逆引きしたい
ページ種別からの逆引きなら、サイト共通の基本セットに、ページ固有のタイプを足すだけで迷いません。結論として、全ページ共通でOrganization・WebSite・BreadcrumbListを入れ、記事にはArticle、店舗にはLocalBusinessを追加します。
まずはサイト全体で入れる最低限の構成を押さえ、次にページ種別ごとの追加タイプを確認します。この二段構えが、種類選びで手が止まらないための実装マップになります。
サイト共通の基本セットは何か？
サイト全体で共通して入れる基本セットは、Organization・WebSite・BreadcrumbListの3つです。この3つは企業・サイト・階層という土台情報を伝えるため、ページ種別を問わず入れておく価値があります。最低限構成としてOrganization＋LocalBusiness＋BlogPosting＋FAQPage＋Service＋BreadcrumbListの6種を挙げ、必要に応じてRecipeやJobPostingを足す考え方も紹介されています（ENVY DESIGN）。
ページ種別ごとの推奨タイプは？
ページの中身に応じて、固有タイプを1〜2種類追加します。次の対応表を目安にすると選びやすくなります。記事はArticle、店舗はLocalBusiness、EC商品はProduct＋Offerという主軸を先に決めるのが近道です。以下に代表的なページ種別と推奨タイプを整理しました。
| ページ種別 | 基本セット＋追加タイプ | |
|---|---|---|
| トップ | Organization・WebSite | |
| 記事 | Article・BreadcrumbList | |
| 店舗 | LocalBusiness・FAQPage | |
| EC商品 | Product・Review | |
| 求人 | JobPosting | |
| イベント | Event |
優先順位はどう付ける？
優先順位は最優先・高・中・低で段階的に付けると迷いません。店舗サイトでは最優先がLocalBusiness、高優先がBreadcrumbListとFAQPage、中優先がReviewやOrganization、低優先だが有効なものにEventやProductという整理があります（Webries）。効果が大きく実装が容易なものから着手し、成果を見ながら追加していくのが現実的です。
TechSuite株式会社の「AI検索パートナーズ」は、業種・規模・商材・課題に合わせて対象サイトの構造を捉え、ボトルネックを特定して優先順位を組み立て、実装まで顧客ごとに個別設計で伴走します。
逆引きで迷わないための実装マップのチェックリストです。
- 全ページにOrganization・WebSite・BreadcrumbListを入れた
- ページの主軸タイプ（Article／LocalBusiness／Product）を決めた
- 該当しないタイプは無理に入れていない
- 最優先タイプから段階的に実装している
基本セットに主軸タイプを足すだけ、と割り切れば、種類の多さに振り回されずに済みますね。
複数タイプの併記と実装後の検証はどうする？
複数タイプは@graphで1つのscriptにまとめると管理しやすく、実装後はリッチリザルトテストなど3ツールで検証します。同一ページに複数の意味づけを重ねる場面が多いため、この2点を押さえると運用が安定します。
まずは複数タイプの併記方法を確認し、次に検証フローとよくあるエラーを整理します。ここを丁寧にやると、後からの手戻りが大きく減ります。
@graphで複数タイプをまとめるには？
@graphを使うと、1つのscript内に複数のノードを配列で並べ、関連付けて記述できます。scriptを分割する方法もありますが、@graphでまとめるとエンティティ同士の関係を@idで結び付けやすくなります（Web担当者Forum）。例えばOrganizationをWebSiteのpublisherとして@idで参照すれば、重複記述を避けつつ一貫した知識のまとまりを表現できます。
基本の書き方ルールは何か？
JSON-LDの基本ルールは、scriptで囲み、@contextを固定し、@typeで型を指定することです。記述はtype属性をapplication/ld+jsonにしたscriptで囲み、@contextはhttps://schema.orgに固定します（SEGO）。プロパティ名はSchema.org仕様に従い、記述場所はheadでもbodyでも動作します。JSON構文のカンマや括弧の閉じ忘れがエラーの多くを占めるため、丁寧な確認が欠かせません。
検証ツールとよくあるエラーは？
検証はリッチリザルトテスト・Schema Markup Validator・Search Consoleを使い分けます。リッチリザルトテストで対象判定を確認し、Validatorで文法検証、Search Consoleの拡張レポートで継続監視するのが基本フローです（AI検索パートナーズ）。つまずきやすいのは、FAQ本文と質問数の不一致、回答内のダブルクォートによるJSON破損、画像の相対パス、Organizationの重複、positionが1から始まっていない点です（ENVY DESIGN）。
TechSuite株式会社の「AI検索パートナーズ」は、技術実装を担う人材とコンテンツ制作人材が一つのチームで連携し、戦略設計から検証・改善まで一気通貫で伴走できる体制を整えています。AI検索経由での受注率は従来のSEO経由の約3倍で、露出だけでなく成果に直結させる設計を重視しています。
| ツール | 主な役割 | 使う場面 |
|---|---|---|
| リッチリザルトテスト | 対象判定の確認 | 実装直後 |
| Schema Markup Validator | 文法検証 | 構文チェック |
| Search Console | 継続監視 | 公開後の運用 |
公開前に確認したいエラー回避のチェックリストです。
- FAQの質問数が本文と一致している
- 画像URLが絶対パスになっている
- BreadcrumbListのpositionが1から連番
- Organizationを重複させていない
併記は@graphで整理し、公開前に3ツールで確認すれば、AI検索時代にも通用する土台になります。
よくある質問
JSON-LDの種類選びで多い疑問に、短く答えます。TechSuite株式会社の「AI検索パートナーズ」は、こうした疑問の背景にある構造的な課題を捉え、顧客ごとに個別設計で解決策を提示しています。
- 構造化データを入れれば検索順位は上がりますか？
直接的なランキング要因ではありません。ただしリッチリザルトによるクリック率向上や、AI検索への引用採用といった間接的な効果が期待でき、露出後に選ばれやすくなる土台になります。
- 全部のタイプを入れるべきですか？何個まで併用できますか？
すべて入れる必要はなく、ページの中身に該当するタイプだけを選びます。併用に厳密な上限はなく、@graphで複数タイプを1つのscriptにまとめて関連付けられます。
- リッチリザルトが表示されないのはなぜですか？
文法エラーやガイドライン違反、対象外タイプなどが原因となります。特にページに表示されていない内容のマークアップは反映されません。リッチリザルトテストで対象判定を確認してください。
まとめ
JSON-LDの種類はSchema.org上では膨大ですが、実務で押さえるのは代表10タイプで十分です。記事はArticle、店舗はLocalBusiness、商品はProductを主軸に、Organization・WebSite・BreadcrumbListの基本セットを全ページへ入れるのが基本形になります。
ページ種別から逆引きで選び、複数タイプは@graphでまとめ、公開前に3つのツールで検証すれば手戻りを防げます。ページに存在しない情報はマークアップしないなど、ガイドライン遵守も欠かせません。
これらを積み重ねれば、リッチリザルトだけでなくAI検索での引用も見据えた設計に近づきます。まずは基本セットと主軸タイプから、段階的に着手してみてください。
参考にした情報源
