schema.orgの書き方3形式をJSON-LDサンプルコード付きで解説

schema.orgの書き方には、JSON-LD・Microdata・RDFa Liteという3つの記述形式があり、Googleが公式に推奨しているのはJSON-LDです。本記事では同一データを3形式で書き分けた比較コードと、Article・BreadcrumbList・Product・FAQPageなどコピペで使えるJSON-LDサンプルを提示し、リッチリザルトテストなど検証方法まで解説します。3形式の違いが分からず実装に踏み出せない担当者でも、この記事だけで書き方から検証までの一連の作業を完了できる内容です。

schema.orgの書き方とは？結論はJSON-LDで書くこと

schema.orgの書き方に迷ったら、まずはJSON-LD形式で記述すれば実務上は問題ありません。schema.orgが定める意味の語彙に対して、Googleがサポートする記述方法はJSON-LD・Microdata・RDFa Liteの3種類あり、この中でGoogleが公式に推奨しているのがJSON-LDだからです（出典）。TechSuite株式会社の「AI検索パートナーズ」は、構造化データの設計もサイトの業種や商材、既存のCMS構成に合わせて個別に方式や範囲を検討し、テンプレートの当てはめではなく実装まで伴走する形で支援しています。

構造化データと構造化マークアップの違いとは？

構造化データとは、ページの内容を検索エンジンが理解できる形で意味づけした情報そのものを指し、構造化マークアップとはその情報をHTMLやスクリプトの中に実際に書き込む作業を指します。両者は表裏一体の関係にあり、構造化データという設計図を構造化マークアップという作業でページに反映すると理解すると分かりやすいです。この違いを押さえておくと、後述するJSON-LDやMicrodataといった記述形式の話がスムーズに理解できます。

ボキャブラリーとシンタックスはどう違う？

ボキャブラリーとは「何を意味するタイプやプロパティを使うか」を定めた語彙集で、schema.orgはGoogle・Yahoo!・Microsoftが共同で策定してきたボキャブラリーです（出典）。一方シンタックスとは、そのボキャブラリーを「どのような文法で書くか」を定めた記述形式のことで、JSON-LD・Microdata・RDFa Liteの3つが該当します。両者を区別すると、schema.orgのタイプ選びと記述形式選びを別の問題として整理しやすくなります。

用語	意味	具体例
構造化データ	ページ内容を意味づけした情報そのもの	記事タイトルや著者名などの情報群
構造化マークアップ	構造化データをHTMLに実装する作業	JSON-LDスクリプトの埋め込み
ボキャブラリー	タイプやプロパティを定めた語彙集	schema.org（Article・Productなど）
シンタックス	ボキャブラリーの記述形式	JSON-LD・Microdata・RDFa Lite

この記事で3形式の書き方をどう解説する？

本記事では、まず同一データを3形式で書き分けた比較コードで違いを理解し、そのうえでGoogle推奨のJSON-LDを軸に、代表的なタイプ別サンプルと検証手順まで一気通貫で解説します。コードをコピーして自サイトに貼り、リッチリザルトテストで確認するところまで進めれば、この記事の内容は完了です。次章から、実際の3形式の書き分けを見ていきます。

schema.orgの書き方3形式はどう書き分ける？

schema.orgの書き方には、JSON-LD・Microdata・RDFa Liteの3形式があり、いずれも正しく実装されていればGoogleに有効に読み取られますが、記述方法と記述場所が大きく異なります。実際に同じ「記事タイトルと著者名」というデータを3形式で書き分けると、違いが一目で分かります。TechSuite株式会社の「AI検索パートナーズ」は、技術面を担う人材とコンテンツ制作を担う人材が同じチームで連携し、形式選定から実装、効果測定までを一つの体制で伴走できる点を強みとしています。

同じ内容を3形式で書くとどう変わる？

JSON-LDはHTMLの表示部分に影響を与えずスクリプトとして1カ所にまとめて書けるのに対し、MicrodataとRDFa Liteは表示用のHTMLタグに直接属性を埋め込む点が大きな違いです（出典）。Microdataはitemscope・itemtype・itemprop属性をタグに追加し、RDFa Liteはvocab・typeof・property属性を追加するため、既存のHTML構造をそのまま活かして意味づけできます。以下は「記事タイトルが構造化データの書き方、著者名がAI検索パートナーズ編集部」という同一データの記述例です。

JSON-LDでは次のように、表示用のHTMLとは別にscriptタグの中でデータをまとめて記述します。

• <script type=”application/ld+json”>
• {
• “@context”: “https://schema.org”,
• “@type”: “Article”,
• “headline”: “構造化データの書き方”,
• “author”: { “@type”: “Person”, “name”: “AI検索パートナーズ編集部” }
• }
• </script>

Microdataでは、表示用のHTMLタグ自体に属性を追加してデータを埋め込みます。

• <div itemscope itemtype=”https://schema.org/Article”>
• <h1 itemprop=”headline”>構造化データの書き方</h1>
• <span itemprop=”author”>AI検索パートナーズ編集部</span>
• </div>

RDFa Liteでは、Microdataに近い考え方でvocab・typeof・propertyという属性を使います。

• <div vocab=”https://schema.org/” typeof=”Article”>
• <h1 property=”headline”>構造化データの書き方</h1>
• <span property=”author”>AI検索パートナーズ編集部</span>
• </div>

3形式のメリットとデメリットは？

3形式にはそれぞれ得意な場面と苦手な場面があり、サイトの状況によって使い分けの判断が変わります。JSON-LDはHTMLに影響を与えず管理しやすい一方、表示内容と別に記述するため二重管理になりやすい点がデメリットです。MicrodataとRDFa Liteは表示内容と一致させやすい反面、HTMLソースが煩雑になりメンテナンスコストが高くなりがちです（出典）。

形式	記述場所	メリット	デメリット
JSON-LD	head・bodyのscriptタグ	1カ所にまとめて記述でき管理しやすい	表示内容と別に二重管理になりやすい
Microdata	各HTMLタグの属性	表示内容とデータが一致しやすい	ソースが煩雑になりやすい
RDFa Lite	各HTMLタグの属性	XHTMLベースの厳密な構造を表現できる	採用例が少なく支援ツールが手薄
使い分けの目安	基本はJSON-LDを選択	既存HTML改修が難しい場合はMicrodataも検討	RDFa Liteは新規実装では優先度が低い

なぜJSON-LDが推奨されるのか？

Googleが一般的にJSON-LDを推奨する理由は、実装と管理が最も容易でユーザーエラーが起きにくいためです。ただし正しく実装されていれば3形式のいずれもGoogleに有効に扱われます（出典）。JSON-LDは2014年1月にW3Cの勧告となったオープンな規格であり、CMSやJavaScriptで動的に挿入されたものもGoogleは正しく読み取れます。この後の章で扱うサンプルも、すべてJSON-LDで統一しています。

JSON-LDの基本構文はどう書く？

JSON-LDの基本構文は、@contextでボキャブラリーを宣言し、@typeでタイプを指定し、その下に各プロパティを並べるという構造です。この骨格を覚えれば、どのタイプでも同じルールで記述を組み立てられます。TechSuite株式会社の「AI検索パートナーズ」は、構造化データ・意味的文脈・エンティティ認識といった生成AIが引用や推薦を行う仕組みを技術的に捉え、一次情報設計まで踏み込んでLLMO・GEO・AEOの施策に落とし込んでいます。

JSON-LDはどこに記述する？

JSON-LDは、ページのheadタグ内、またはbodyタグ内のscriptタグの中に記述します。表示用のHTML本体には影響を与えないため、既存デザインを変更せずに追加できるのが特徴です（出典）。1つのページに複数のJSON-LDブロックを置くことも可能で、CMSのテンプレートに1カ所組み込めば全ページへ自動反映できます。次の章で紹介するタイプ別サンプルも、このscriptタグの中に貼り付けて使います。

@contextと@typeは何を意味する？

@contextは「どのボキャブラリーを使って解釈するか」を示す宣言で、通常は”https://schema.org”を指定します。@typeは「このデータが何のタイプか」を示す指定で、Article・Product・FAQPageなどschema.orgで定義されたタイプ名を入れます。この2つが揃うことで、後続のプロパティが何を意味するのかが検索エンジンに正しく伝わります。

入れ子や配列や@graphはどう書く？

JSON-LDは、authorやpublisherのように別のオブジェクトを持つ場合、その中に@typeとプロパティを持つ入れ子構造で表現します。複数の値を持つプロパティは配列で、1ページに複数のエンティティを結びつけたい場合は@graphを使ってまとめて表現できます。イベント内の会場、会場内の住所、住所内の国名のように多段階のネストも表現できる柔軟さがJSON-LDの強みです（出典）。

記述	意味	記述例
@context	使用するボキャブラリーの宣言	“@context”: “https://schema.org”
@type	データのタイプ指定	“@type”: “Article”
@id	エンティティを一意に識別するID	“@id”: “https://example.com/#article”
@graph	複数エンティティをまとめて表現	“@graph”: [ {…}, {…} ]
プロパティ	タイプに紐づく個別の項目	“headline”: “記事タイトル”

タイプ別のJSON-LDサンプルコードは？

schema.orgの書き方は、Article・BreadcrumbList・Product・FAQPageなど、ページの内容に合わせたタイプを選んで@typeに指定し、そのタイプに応じたプロパティを埋めていくことで完成します。以下は代表的な4タイプについて、そのままコピーして使えるJSON-LDサンプルです。TechSuite株式会社の「AI検索パートナーズ」は、AIを活用したコンテンツ制作の仕組みを「バクヤスAI記事代行」事業で培っており、その制作エンジンとナレッジを転用して、検索意図や想定質問の分解に沿ったタイプ別の構造化データを高速に設計できます。

Article記事のJSON-LDはどう書く？

記事ページでは@typeにArticleを指定し、headline・author・datePublished・imageなどのプロパティを埋めます。headlineと実際の見出しの文言を一致させることが、後述する内容不一致を避けるうえで重要です。

• <script type=”application/ld+json”>
• {
• “@context”: “https://schema.org”,
• “@type”: “Article”,
• “headline”: “schema.orgの書き方3形式を解説”,
• “image”: “https://example.com/images/thumbnail.jpg”,
• “author”: { “@type”: “Organization”, “name”: “AI検索パートナーズ編集部” },
• “datePublished”: “2026-01-10”,
• “dateModified”: “2026-01-10”
• }
• </script>

BreadcrumbListパンくずリストはどう書く？

パンくずリストでは@typeにBreadcrumbListを指定し、itemListElementの配列で階層ごとのpositionとURLを記述します。positionは1から始まる連番で、実際のパンくずの表示順と一致させる必要があります。

• <script type=”application/ld+json”>
• {
• “@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/blog/” },
• { “@type”: “ListItem”, “position”: 3, “name”: “schema.orgの書き方” }
• ]
• }
• </script>

Product商品情報はどう書く？

商品ページでは@typeにProductを指定し、name・image・offers・aggregateRatingなどを組み合わせることで、価格やレビュー評価をリッチリザルトとして表示できる可能性があります。

• <script type=”application/ld+json”>
• {
• “@context”: “https://schema.org”,
• “@type”: “Product”,
• “name”: “サンプル商品A”,
• “image”: “https://example.com/images/product-a.jpg”,
• “offers”: { “@type”: “Offer”, “priceCurrency”: “JPY”, “price”: “3000”, “availability”: “https://schema.org/InStock” },
• “aggregateRating”: { “@type”: “AggregateRating”, “ratingValue”: “4.5”, “reviewCount”: “20” }
• }
• </script>

FAQPageとOrganizationはどう書く？

よくある質問ページでは@typeにFAQPageを指定し、mainEntityの配列でQuestionとacceptedAnswerを繰り返します。企業情報や店舗情報はOrganizationやLocalBusinessで、名称・URL・電話番号などを記述します。FAQPageのマークアップは現在リッチリザルトの対象外となっている場面がありますが、AIが質問と回答の対応関係を理解しやすくなる点で有効です（出典）。

• <script type=”application/ld+json”>
• {
• “@context”: “https://schema.org”,
• “@type”: “FAQPage”,
• “mainEntity”: [
• { “@type”: “Question”, “name”: “JSON-LDはどこに書きますか”, “acceptedAnswer”: { “@type”: “Answer”, “text”: “head内またはbody内のscriptタグに記述します” } }
• ]
• }
• </script>

タイプ	主な必須プロパティ	リッチリザルト対応
Article	headline・image・datePublished	対応
BreadcrumbList	itemListElement・position	対応
Product	name・offers・aggregateRating	対応
FAQPage	mainEntity・acceptedAnswer	非対応（AI理解には有効）
Organization／LocalBusiness	name・url・telephone	対応

書いた構造化データはどう検証する？

schema.orgの書き方が正しいかどうかは、開発中は「リッチリザルト テスト」、公開後は「スキーマ マークアップ検証ツール」と「Google Search Console」の3段階で確認するのが基本です。テンプレートの改修や配信の都合で、公開後にエラーが発生することもあるため、実装したら終わりにせず継続的な確認が欠かせません（出典）。TechSuite株式会社の「AI検索パートナーズ」は、自社サイトでAI Share of Voiceが高水準を維持しており、支援先でもAI Overviewの引用率を改善した実績があります。

リッチリザルトテストで何が分かる？

リッチリザルトテストは、URLまたはコードを直接貼り付けて、Googleがそのページの構造化データをどう解釈するかを開発中に確認できるツールです。エラーや警告が表示された場合は、必須プロパティの欠落やJSONの構文崩れが多いため、該当箇所を修正して再度チェックします。公開前にこの確認を済ませておくと、後工程での手戻りを減らせます。

スキーママークアップ検証ツールは何に使う？

スキーマ マークアップ検証ツールは、Google独自の判定に限らずschema.org全体の仕様に沿って構造化データの記法を確認できるツールです。Googleの検索結果に反映されるかどうかとは別に、記述そのものが仕様通りかを広く検証したいときに向いています。両方のツールを併用すると、Google向けの適合性とschema.org仕様への適合性を両面から確認できます。

Search Consoleでは何を確認できる？

Google Search Consoleの拡張機能レポートでは、公開済みページ全体の構造化データについて、有効・警告・エラーの件数を継続的に監視できます。個別ページのテストだけでは気づきにくい、サイト全体への影響範囲やエラーの傾向を把握できる点が最大の利点です。定期的にこのレポートを確認する運用を組み込んでおくと安心です。

ツール	使うタイミング	確認できること
リッチリザルト テスト	実装中・公開前	個別ページの解釈結果とエラーの有無
スキーマ マークアップ検証ツール	実装中	schema.org仕様全体への適合性
Search Console 拡張レポート	公開後の継続監視	サイト全体のエラー・警告件数の傾向
表示内容との目視比較	公開前後どちらでも	構造化データと実際の表示内容の一致

実装で失敗しないための注意点とAI検索時代の意義は？

schema.orgの書き方で失敗しないための注意点は、表示内容と構造化データを一致させること、過剰なマークアップを避けること、そして仕様変化に合わせた定期的なメンテナンスを続けることの3点に集約されます。これらを守ったうえで実装すると、検索エンジンの理解が進むだけでなく、AI検索が回答を生成する際にも情報を正確に引用しやすくなります（出典）。TechSuite株式会社の「AI検索パートナーズ」の支援先では、AI検索経由での受注率が従来のSEO経由の約3倍という結果も出ており、構造化データのような技術的な土台づくりが受注という成果に直結するケースが増えています。

実装時に注意すべき点は？

構造化データに書いた内容が実際のページ表示と一致していない場合や、関係の薄いタイプを無理に付与する過剰マークアップは、いずれもガイドライン違反や評価低下につながる恐れがあります。実装したからといって必ずリッチリザルトが表示されるわけではない点も理解しておく必要があります（出典）。表示内容を変更した際は、構造化データ側も忘れずに更新することが大切です。

必須プロパティはどこまで満たすべき？

拡張表示を得るには、対象タイプの必須プロパティをすべて満たす必要があります。不完全な推奨プロパティを多数入れるより、少数でも正確な推奨プロパティを提供するほうが重要とされています（出典）。まずは必須項目を確実に満たし、そのうえで余力があれば推奨プロパティを段階的に追加していく進め方が現実的です。

AI検索やLLMOにどう役立つ？

構造化データは、FAQ・Product・Organizationなどの情報を明示することで、AIが回答生成時にページの内容を正確に引用・要約しやすくなるという役割も持ちます（出典）。検索順位を直接上げる要因ではなくとも、検索エンジンとAIの両方に内容を正しく伝える土台になる点が、LLMOやGEOの観点でも重要です。この分野の全体像はLLMOとは何かやGEOとは何かで整理しており、実際のAI検索対策の進め方と合わせて確認すると理解が深まります。

効果分類	具体的な効果	該当ページ例
検索エンジンの理解促進	クエリとページ内容の結びつきが強まる	すべてのページ
リッチリザルト表示	星評価や画像付き表示によるCTR向上	商品・レシピ・イベントページ
ナレッジグラフへの反映	企業・人物情報の正確な表示	企業ページ・著者プロフィール
AI検索・LLMOでの活用	回答生成時の正確な引用・要約	FAQ・記事・製品情報ページ

よくある質問

構造化データを実装すれば必ずリッチリザルトが表示されますか

必ず表示されるわけではありません。構造化データはGoogleに内容を正しく伝えるための情報であり、表示するかどうかは検索結果側の判断に委ねられます。必須プロパティを満たし、表示内容と一致させることで表示される可能性が高まります。

構造化データは全ページに実装すべきですか。SEO順位は上がりますか

構造化データは直接のランキング要因ではないため、実装すれば必ず順位が上がるとは限りません。ただし検索エンジンとAIの理解を助け、間接的に評価やクリック率の改善につながる可能性があるため、記事・商品・パンくずなど該当するタイプがあるページから優先的に取り入れる進め方が現実的です。

JSON-LD・Microdata・RDFa Liteを混在させてもよいですか

技術的には混在も可能ですが、同一要素に複数形式で重複してマークアップすると管理が複雑になりミスの原因になります。基本はJSON-LDに統一し、既存のMicrodataがすでに正しく機能している部分はそのまま残す、といった実務的な整理がおすすめです。

書いた構造化データが正しいか無料で確認する方法はありますか

はい。Googleのリッチリザルトテストとスキーマ マークアップ検証ツールはいずれも無料で使えます。URLまたはコードを貼り付けるだけで、タイプの認識状況やエラー・警告の有無を確認できます。

まとめ

schema.orgの書き方には JSON-LD・Microdata・RDFa Liteの3形式があり、Googleは実装と管理が容易なJSON-LDを推奨しています。@context・@typeを核にした基本構文を覚えれば、Article・BreadcrumbList・Product・FAQPageなど代表的なタイプにも応用できます。

実装後はリッチリザルトテストやスキーマ マークアップ検証ツール、Search Consoleを使って継続的に検証し、表示内容との一致や必須プロパティの充足を保つことが失敗を防ぐ鍵です。こうした地道な整備が、検索エンジンとAI検索の双方からの正確な引用につながっていきます。

参考にした情報源

• 構造化データとは（デジタルアイデンティティ）
• 構造化データとは（SEO Hacks）
• 構造化データに関する一般的なガイドライン（Google検索セントラル）
• 構造化データとは（sem-plus）
• 構造化データとは（Promonista）