LLMO向けに構造化データを整備するとき、LLMO専用の構造化データ規格を探す必要はありません。ページ上に実際に表示している情報を、Schema.orgの語彙で正確に表し、JSON-LDで継続管理できる状態にすることが基本です。

JSON-LDは、検索エンジンや各種システムが、ページの主体・情報の種類・属性を機械的に読み取るための補助情報です。ただし、AI検索での引用、検索順位の上昇、リッチリザルトの表示を直接保証する施策ではありません。

本記事では、ページ種別ごとの実装の優先順位、コード例、WordPressでの導入方法、公開前後の検証方法を順に解説します。

LLMOにおける構造化データとは？JSON-LDでできること・できないこと

構造化データは、人には文脈で分かる情報を、機械が誤解しにくい形で明示するデータです。会社名、住所、著者、商品価格、公開日などは、人には読み取れても、機械には意味を判定しにくい場合があります。

LLMO・GEO・AIOといった用語の定義は、発信者によって異なります。そのため施策は呼び方ではなく、正確な情報、アクセス可能性、明瞭な本文、整合した構造化という基準で評価するのが実務的です。

LLMO対策の全体像は、「LLMO対策とは？SEOとの違いと初心者が最初にやるべき基本施策」で解説しています。

Schema.org・構造化データ・JSON-LDの関係を3分で理解する

Schema.orgは情報の共通語彙、構造化データは意味づけされたデータ、JSON-LDはそのデータをページに記述する形式です。

Schema.orgには、Organization、Article、Productのように対象を示す@typeと、name、url、author、priceのように詳細を示すpropertyがあります。JSON-LDでは、これらを通常script要素の中に記述します。

<script type="application/ld+json">
{
  "@context": "https://schema.org",
  "@type": "Organization",
  "name": "架空株式会社",
  "url": "https://www.example.com/"
}
</script>

本文は人に事実を伝え、JSON-LDは同じ事実の意味を機械に補足します。両者は別の情報ではないため、必ず一致させましょう。語彙やpropertyはSchema.orgで確認できます。

LLMO・SEO・リッチリザルトでの効果範囲：引用や順位は保証されない

JSON-LDは意味の理解を補助しますが、検索順位、リッチリザルト、AI検索での引用・回答掲載を保証しません。

構造化データは、本文の品質、クロール可能性、インデックス状況、技術的な健全性、外部評価の代わりにはなりません。Googleの検索機能に関する要件は、Google Search Centralの構造化データに関する案内で個別に確認してください。

期待できること	保証できないこと
会社・記事・商品などの主題を機械に伝えやすくする	検索順位の上昇
特定の検索機能の要件確認対象になり得る	リッチリザルトの実際の表示
サイト内の表記を整理し、一貫性を保ちやすくする	AI検索での引用・回答掲載
更新対象をデータとして管理しやすくする	コンテンツ品質や外部評価の代替

 

構造化マークアップの基本的な書き方は、「構造化マークアップとは？書き方やSEOへの効果・検証方法を解説」で解説しています。

最初に何を実装する？ページ種別ごとのJSON-LD優先順位と選び方

実装対象は、使えるtypeをすべて追加するのではなく、ページが実際に提供している主な情報から選びます。

企業サイトでは、運営主体とサイト構造を先に整え、その後に記事・商品・サービスなどの主要テンプレートへ広げると管理しやすくなります。

推奨type	対象ページ・優先度	主なpropertyと注意点
Organization	全サイト共通 優先度：高	主なproperty：name、url、logo、sameAs 実装条件：公開済みで維持できる企業情報がある 避けたい誤用：非公開情報や未管理SNSの記述
WebSite	サイト共通 優先度：中	主なproperty：name、url 実装条件：サイト名と正規URLが定まっている 避けたい誤用：別サイトURLの混在
BreadcrumbList	階層ページ 優先度：中	主なproperty：itemListElement 実装条件：画面上にパンくずがある 避けたい誤用：実導線と異なる階層の記述
Article	解説記事 優先度：高	主なproperty：headline、author、datePublished 実装条件：記事本文と著者・日付が表示されている 避けたい誤用：固定ページの一律Article化
Service	サービス詳細 優先度：中	主なproperty：name、description、provider 実装条件：独立したサービス説明がある 避けたい誤用：販売商品ではないページのProduct化
Product	商品詳細 優先度：高	主なproperty：name、image、offers 実装条件：個別商品を販売し、表示値と同期できる 避けたい誤用：カテゴリーページへの一律出力
FAQPage	Q&Aページ 優先度：条件付き	主なproperty：mainEntity 実装条件：質問と回答が画面上にある 避けたい誤用：非表示Q&Aや水増しQ&A

 

サイト共通はOrganization・WebSite・BreadcrumbListから整える

企業サイトでは、Organizationで運営主体を明確にし、WebSiteとBreadcrumbListでサイトとページの階層を補うところから始めます。

Organizationには、公開済みの正式名称、公式URL、ロゴを設定します。公式SNSを継続して管理しているならsameAs、問い合わせ窓口を公開・運用しているならcontactPointも候補です。

• name：正式な組織名
• url：公式サイトの正規URL
• logo：公開中の公式ロゴ画像のURL
• sameAs：運営者が管理する公式プロフィールのURL
• contactPoint：利用者に公開し、継続して管理できる問い合わせ先

実店舗や拠点の住所・営業時間・電話番号を公開している場合は、LocalBusinessも検討できます。存在しない拠点、非公開の電話番号、管理していないSNSアカウントは記述しません。

記事・サービス・商品・FAQは「ページの主役」で選ぶ

typeは検索表示を狙って選ぶのではなく、ページの主役となる情報に合わせて選びます。

ケース（主な候補）	選ぶ条件	注意点
ブログ記事 （Article）	解説・ニュース・コラム本文が中心	見出し、著者、日付を表示内容と一致させる
サービス詳細 （Service）	提供内容、対象者、支援範囲が中心	Schema.orgの語彙として使えても、特定のリッチリザルトに直結するとは限らない
EC商品ページ （Product）	個別商品を購入でき、価格や在庫を示している	価格・在庫・通貨を画面表示と同期させる
質問回答ページ （FAQPage）	質問と回答が利用者に見える形で掲載されている	検索機能の対象や要件は変更され得るため、最新の公式ガイドを確認する

 

1ページに複数のtypeを記述することもありますが、主役が曖昧なら無理に増やす必要はありません。

＜AI時代のSEO/AIO戦略を整理したい方へ＞

無料で資料をダウンロード

JSON-LD実装手順：設計からコード配置までの実務フロー

JSON-LDは、コードを貼るだけの施策ではありません。公開情報を、誰が、どのデータから、どのページに出力するかを決める工程が重要です。

1. URLを棚卸しする：URL一覧を作り、ページ種別とテンプレートを分類する
2. 主エンティティを決める：ページの主役となるtypeと、必要なpropertyを決める
3. 情報の正本を定義する：会社情報、著者、価格、画像などの参照元と更新担当を決める
4. JSON-LDを生成・配置する：CMSの設定、テンプレート、カスタムコードなどの経路を選ぶ
5. 公開前後に検証する：構文、表示内容、機能要件、公開後の検出状況を確認する

URL一覧、ページ種別の対応表、項目定義表、JSON-LD、テスト結果を成果物として残すと、担当者が変わっても運用を再現できます。

実装前に行うページ棚卸しとエンティティ設計

コードを書く前に、ページの主役、情報の参照元、更新担当者を決めておくと、誤記・重複・更新漏れを減らせます。

項目	/about/	/blog/example/	/product/item-a/
テンプレート	会社案内	記事	商品詳細
主type	Organization	Article	Product
必須property	name、url、logo	headline、author	name、offers
情報の参照元	会社概要ページ	CMS投稿情報	商品管理システム
更新担当	広報	編集担当	EC担当
実装方法	テンプレート	CMS連携	API・テンプレート
検証日	YYYY-MM-DD	YYYY-MM-DD	YYYY-MM-DD

 

正式社名、住所、電話番号、URLの正規形は先に決めておきましょう。価格・在庫・営業時間などの変わる値は、できるだけCMSや商品管理システムの正本データから生成します。

コピペ前提にしないJSON-LDコード例：OrganizationとArticleの最小構成

JSON-LDは最小構成から始め、画面上で確認でき、正確に維持できる値だけを追加します。

以下の社名、URL、著者、画像は架空の値です。そのまま公開せず、自社サイトで公開している事実とCMSの値に置き換えてください。

<script type="application/ld+json">
{
  "@context": "https://schema.org",
  "@type": "Organization",
  "@id": "https://www.example.com/#organization",
  "name": "架空株式会社",
  "url": "https://www.example.com/",
  "logo": "https://www.example.com/images/logo.png"
}
</script>

<script type="application/ld+json">
{
  "@context": "https://schema.org",
  "@type": "Article",
  "@id": "https://www.example.com/blog/json-ld-guide/#article",
  "url": "https://www.example.com/blog/json-ld-guide/",
  "headline": "JSON-LD実装の基本ガイド",
  "datePublished": "YYYY-MM-DD",
  "dateModified": "YYYY-MM-DD",
  "author": {
    "@type": "Person",
    "name": "山田 花子"
  },
  "image": "https://www.example.com/images/json-ld-guide.jpg",
  "publisher": {
    "@id": "https://www.example.com/#organization"
  }
}
</script>

property	意味	実装時の確認点
@context	使用する語彙の文脈	Schema.orgのURLを指定する
@type	情報の種別	ページの主役に合うtypeを選ぶ
@id	エンティティを識別するID	同一エンティティで一貫させる
url	対象ページのURL	canonicalと整合する正規URLを使う
name / headline	組織名・記事見出し	画面表示と一致させる
datePublished / dateModified	公開日・更新日	実際に表示・管理している日付だけを出す
author	著者	画面上で著者を確認できる場合に出す
image	代表画像	利用者が確認できる画像を使う
publisher	発行者	Organizationの@idと対応させる

 

JSONでは、末尾カンマ、コメント、シングルクォートは使えません。著者・更新日・画像も、画面上で確認できる場合だけ出力します。

WordPress・CMSでの導入方法と重複マークアップの防ぎ方

CMSでは、テーマ、SEO機能、専用プラグイン、カスタムコード、Googleタグマネージャーなど、複数の経路からJSON-LDが出力されることがあります。新しい設定を追加する前に、ページソースで既存の出力を確認してください。

テーマ・SEOプラグイン・カスタムコード・GTMの使い分け

固定の情報は一元管理し、ページごとに変わる情報はCMSの正本データとテンプレートで連携すると、保守しやすくなります。

実装方法	向いているケース・長所	弱点・公開前の確認
テーマ・CMS標準機能 （担当：サイト管理者）	基本的な共通情報を出す場合 長所：導入負荷が低い	弱点：細かな出力調整が難しい場合がある 公開前：既存出力と設定画面を確認
SEO機能・プラグイン （担当：編集・SEO担当）	一般的な記事情報を管理する場合 長所：編集画面で設定しやすい	弱点：テーマや他機能との重複に注意が必要 公開前：ページソースでtypeを確認
カスタムコード・テンプレート （担当：開発担当）	商品・サービスなど独自データがある場合 長所：CMSデータと連携しやすい	弱点：開発・テスト体制が必要 公開前：動的値と画面表示を照合
Googleタグマネージャー （担当：マーケティング・開発担当）	暫定検証や限定追加 長所：変更を試しやすい	弱点：恒久運用では同期漏れ・重複のリスクがある 公開前：配信条件と既存コードを確認

 

重複・矛盾・テンプレート誤出力を見つける確認ポイント

問題になりやすいのは単純な重複ではなく、同じ情報が複数のJSON-LDで食い違うことです。

よくある誤り	なぜ問題か	修正方法
Organizationが複数あり、nameやurlが異なる	運営主体の識別が不安定になる	正本を決め、不要な出力元を停止または統一する
全ページにProductやFAQPageを出力する	ページ内容と関係ないtypeが混在する	対象テンプレートだけで出力する条件を設定する
JSON-LDのURLとcanonicalが異なる	正規ページの解釈が揺れる可能性がある	正規URLのルールを統一する
価格・在庫が画面と異なる	利用者向け情報との整合性を失う	商品データから自動連携し、更新フローを見直す
著者・更新日が実ページにない	表示事実と構造化データが一致しない	表示を追加するか、propertyを出力しない

 

確認は、ページソース、レンダリング後のHTML、テストツールの3つの視点で行います。削除する前に、必ず出力元を特定してください。

構造化データ実装のご相談はこちら

公開前後の検証方法：Rich Results TestとSchema Markup Validatorの使い分け

構造化データの検証では、「Schema.orgとして正しく書けているか」と「Googleの特定の検索機能の要件を満たすか」は別の確認事項です。

確認先（役割）	確認できること	確認できないこと
JSON構文チェック （JSONの書式確認）	括弧、引用符、カンマなどの構文エラー	Schema.orgの意味や検索表示
Schema Markup Validator （Schema.orgの妥当性確認）	type・propertyの構造、記述内容	Googleのリッチリザルト表示保証
Rich Results Test （Google向け機能要件の確認）	対象機能で検出された項目やエラー	実際の検索結果での表示保証
Google Search Console （公開後の継続確認）	検出状況や改善項目の把握	即時反映や掲載順位の保証

 

エラーがゼロでも、検索成果やAI検索での引用は保証されません。画面表示との一致、クロール可能性、本文の明瞭さもあわせて確認します。

検証の5手順：JSON構文、Schema.org妥当性、Google要件、画面表示、公開後

検証は、JSON構文 → Schema.orgの妥当性 → Google向け要件 → 画面表示 → 公開後の順に進めると、問題の原因を切り分けやすくなります。

1. JSON構文を確認する

• 確認項目：ダブルクォート、波括弧、配列、末尾カンマ、URL形式
• 一次対応：コードを整形し、JSONとして解釈できない箇所を直す

2. Schema.orgとしての妥当性を確認する

• 確認項目：@typeとpropertyの組み合わせ、値の形式、不要なtypeの混在
• 一次対応：ページの主役に立ち返り、誤ったtypeや不要なpropertyを見直す

3. Google向けの要件を確認する

• 確認項目：Rich Results Testのエラーと警告
• 一次対応：対象機能の最新要件を確認し、実ページに表示できる情報だけを追加する

4. 画面表示と照らし合わせる

• 確認項目：会社名、価格、著者、日付、画像、パンくず、URLが画面上の情報と一致するか
• 一次対応：JSON-LDだけでなく、画面側とデータの正本のどちらを直すべきか判断する

5. 公開後も継続して確認する

• 確認項目：Search Consoleの検出状況、問題の有無、テンプレート変更後の影響
• 一次対応：公開URL、クロール制御、canonical、変更履歴を確認する

コードを貼り付けるテストは公開前の構文・設計の確認に、URLを指定するテストは公開ページの実際の出力の確認に向いています。ログインが必要なページや、robots.txtで制限しているページは、ツールが取得できないことがあります。

Search Consoleの設定・使い方は、「Googleサーチコンソールの使い方・設定を初心者に分かりやすく解説！」で解説しています。

AIに引用されやすいコンテンツの特徴は「AIに引用されるコンテンツの6つの共通点【具体例付きで解説】」で、AIOの基本は「AIに“選ばれる”コンテンツとは何か？AIOの基本と実務チェックリスト」で解説しています。

構造化データとLLMO実装でよくある質問

Q. JSON-LDを入れればAI検索に引用されますか？

いいえ、引用は保証されません。

JSON-LDは、ページ内容の意味を機械に伝えやすくする補助情報です。引用されるかどうかは、本文の正確性、更新性、クロール可能性、利用者にとっての分かりやすさなど、複数の要素に左右されます。

Q. すべてのSchema.orgプロパティを埋める必要はありますか？

いいえ、すべて埋める必要はありません。

項目は多いほど良いわけではありません。対象機能で必要な項目、画面に表示している項目、正確に維持できる項目を優先します。推測値や未確認の情報で埋めるより、最小構成から始めるほうが安全です。

まとめ

構造化データの実装では、typeを増やすことよりも、公開情報と一致させ、更新し続けられる仕組みを作ることが優先です。進め方は次のとおりです。

1. 現状の出力を確認する：ページソースとテストツールで、既存のJSON-LD、type、出力元を確かめる
2. Organizationなど共通情報を整える：正式名称、正規URL、ロゴ、公式SNS、問い合わせ先を公開情報と一致させる
3. 主要ページにtypeを追加する：記事はArticle、個別商品はProductなど、ページの主役に合わせてテンプレート単位で追加する
4. 公式ツールで検証する：JSON構文、Schema.orgの妥当性、Google向け要件、画面との一致を順に確認する
5. 更新ルールを文書化する：情報の正本、更新担当、検証日、変更時の確認方法を台帳に残す

サイトの規模が大きい場合は、全ページに一度に入れず、記事・商品・サービスなどのテンプレート単位で段階的に導入しましょう。小さく検証して出力内容と運用手順を固めてから、対象を広げるのが現実的です。

構造化データの設計や、既存サイトの重複・矛盾の洗い出しを自社だけで進めるのが難しい場合は、専門家に相談するのも一つの方法です。

パンタグラフでは、SEO・AIO・LLMOを活用したコンテンツマーケティングの知見を活かし、AI検索時代を見据えたサイト改善のご相談も承っております。

まずはお気軽にご相談ください（無料）。

お問い合わせはこちら