結論
コーポレートサイトが最初に入れるべきSchema.orgは、Organization・BreadcrumbList・FAQPageの3種類です。
型をむやみに増やすより、JSON-LDの記述がページの本文と一致し、正しく読み取られているかを確認することが優先です。
Schema.orgはどこまで入れるべきですか？
Schema.org には多くの型があり、全部入れようとすると終わりません。
入れる範囲は、自社サイトがいまどの状態かで決まります。
| いまの状態 | 入れる型 | 理由 |
|---|---|---|
| 構造化データが何も入っていない | Organization | 社名・URL・ロゴ・住所といった基礎情報。サイト全体で1つ置けば足りる |
| 下層ページが増えてきた | BreadcrumbList | 階層を伝える。サブページにそれぞれ置く |
| 本文に質問と答えの対がある | FAQPage | 本文にある内容のラベル付けなので、追加で書くものがない |
| 3種類が入っていて、記事や著者を個別に示したい | Article / Service / Person | 定番の次の一手。一気に全部入れる必要はない |
| 本文に書いていない情報を伝えたい | 入れない | 目に見える内容のラベル付けが原則。宣言だけするとガイドライン違反になる |
上から3行目までが、ほとんどのコーポレートサイトの到達点です。
4行目に進むのは、3種類が入って動作確認も済んでからにします。
まだ何も入っていない場合、どの型から入れればよいですか？
書き方は3種類 (Microdata、RDFa、JSON-LD) ありますが、2026年現在、Google も Schema.org も JSON-LD を推奨しています。
他の2つは古い書き方なので検討から外して構いません。
JSON-LD は HTML 本文を触らずに済みます。<head> か <body> 内のどこかに <script type="application/ld+json"> を貼るだけです。
Organization (会社情報)
会社名、URL、ロゴ、住所、メール。
これを1つ書いておくと、AIが会社について聞かれたときの基礎情報になります。
サイト全体で1つ置けば足ります。
BreadcrumbList (パンくずリスト)
「ホーム > サービス > LLMO」のような階層を伝えます。
サイトの構造を正しく読み取らせるためのもので、サブページにそれぞれ置きます。
FAQPage (よくある質問)
「Q. 〜ですか」「A. はい、〜です」のセットを3〜5個書きます。
3種類のうち、最初に足しやすいのがこれです。
本文にすでに質問と答えが書いてあれば、そのラベル付けになるので、新しく用意する文章がありません。
逆に本文にFAQがない場合は、JSON-LD より先に本文を書きます。
基本の3種類を入れたあと、さらに型を広げるべきですか？
型を増やす前に、入れた3つが実際に読み取られているかを確認します。
読み取られていない型をいくつ足しても、サイトの見え方は変わりません。
確認はリッチリザルトテストで足ります。
読み取られていることを確認したうえで、Article・Service・Person へ広げます。
判断の基準は、そのページで答えたい質問が決まっているかどうかです。
答えたい質問がないまま型だけ増やすのは、作業は増えますが見え方は変わりません。
構造化データが LLMO 全体のどこに位置するかはLLMO対策のページの用語の定義で整理しています。
Schema.orgで入れてはいけない情報は何ですか？
本文に存在しない情報です。
Googleの構造化データの仕組みについてが示すとおり、構造化データは目に見える内容のラベル付けが原則で、本文にない情報を JSON-LD だけで宣言するのはガイドライン違反にあたります。
よくあるのは、本文に書いていないFAQを JSON-LD にだけ書く形です。
型としては正しくても、原則から外れます。
本文に書く、それからラベルを付ける、の順にします。
30分で構造化データを確認・実装する手順は？
- リッチリザルトテストを開く (5分)
- 自社サイトのURLを入れて、現状の構造化データを確認する (5分)
- 上の表で、自社がどの行に当たるかを決める (5分)
- 足りない型の JSON-LD を書き、テーマの
head.phpか WordPress のカスタムHTMLブロックに貼る (10分) - もう一度リッチリザルトテストで動作確認する (5分)
3番目を飛ばして4番目から始めると、必要のない型まで入れることになります。
どこまで入れるかを先に決めてから書きます。
JSON-LDが反映されないときはどう切り分けますか？
JSON-LD を貼ったのにテストに出ない場合、キャッシュが原因のことが多くあります。
WordPress のキャッシュプラグインを使っているなら、一度クリアしてください。
それでも出ないときは、リッチリザルトテストのライブテストで実際のHTMLを確認します。
貼った場所が出力されていないのか、JSON の書式が壊れているのかで、直す先が変わります。
実装したあと本当に効いたかを確かめる方法は効果測定の記事に書きました。
構造化データの実装は前提条件の一つで、単独で被引用を生むものではありません。
自社サイトにどこまで入れるか相談するには？
自社がどの行に当たるか、いま入っている型が読み取られているかは、見れば分かります。
これまでの診断では、会社の構造化データに公式アカウント (sameAs) が無い、JSON-LD と canonical の URL が食い違うといった設定漏れや記述ミスがよく見つかっています。
無料のセルフ診断・簡易診断 (50,000円)・詳細診断 (150,000円から) の3段 (いずれも税別) で、サンプルレポートも公開しています。
よくある質問
3種類より多く入れたほうが有利ですか。
型の数と引用のされやすさは別の話です。
読み取られていない型や、本文に対応する記述のない型を足しても、見え方は変わりません。
3種類が読み取られていることを確認してから広げます。
Microdata で書いてあるページは書き直しますか。
急ぎません。
Microdata も読み取られます。
新しく書くぶんを JSON-LD にして、既存ページは改修のタイミングで寄せれば足ります。
両方を同じページに重ねて書くのは避けます。
FAQPage を入れたのにAI検索に出てきません。
JSON-LD だけでなく、本文にも同じFAQが書いてあるかを確認してください。
本文にない内容を宣言している場合、原則から外れています。
本文にある場合は、構造化データではなく到達の側に原因があります。
効果測定の記事で切り分けの手順を扱っています。
この記事の執筆・運営
株式会社Neo Vision (ブランド名: Neovision)。
AIを使ったWeb制作とSEO / LLMOコンサルを提供しています。
本記事の手順は自社サイトと診断案件での実装にもとづいています。
数値の書き方と、誤りが判明したときの直し方は訂正ポリシーに定めています。
