LLMO対策で構造化データを使う目的は、検索エンジンへページ上の実体や関係を明示し、対応する検索機能の対象になれる状態を整えることです。Googleは、AI OverviewsやAI Modeに特別なschema.orgマークアップは不要であり、構造化データだけで生成AI検索へ掲載されるわけではないと明記しています。本記事では、できることと保証できないことを分け、公開中の自サイトをGoogle公式ツールで実測して修正しました。

結論：構造化データは説明書であり、推薦状ではない

JSON-LDは、ページが組織、記事、商品、イベントなどの何を表し、名称、著者、日付、階層がどう関係するかを機械可読にします。Googleが対応する種類と要件を満たせば、リッチリザルトの対象になれる場合があります。

しかし、有効判定は検索順位、インデックス登録、AI回答への掲載や引用を保証しません。Googleの生成AI検索向け公式ガイドは、通常検索と同じクロール、インデックス、スニペット表示、内部リンク、有用で信頼できる本文を基礎とし、特別なAI用schema.orgは不要だと説明しています。

  • できる：ページ上の事実と実体の関係を明示する
  • できる：Googleが対応する検索機能の対象になるための技術要件を満たす
  • できる：テンプレートの欠損や矛盾を検査・監視しやすくする
  • できない：検索順位やインデックス登録を保証する
  • できない：ChatGPT、Gemini、Perplexityなどでの言及・引用を保証する
  • できない：本文にない実績、法人情報、価格、評価を正当化する

公開サイトをGoogle公式ツールで実測

2026年7月27日、日本LLMOセンターのホームと「LLMOツール比較2026」を、Googleリッチリザルト テストの公開URL・スマートフォン検査で取得しました。修正後はこの2ページと本記事を再検査しました。成功画面だけではなく、検出件数、警告、修正内容、再検査結果をCSVでも公開しています。

ホームはOrganization 1件が有効で重大な問題は0件でした。公開HTMLにはFAQPageもありましたが、対応するリッチリザルト項目として検出されませんでした。記事はArticle 1件とBreadcrumbList 1件の計2件が有効でしたが、Articleの公開日と更新日に「日時値が無効」「タイムゾーンなし」が各2件、合計4件の重大ではない問題として表示されました。

これはサイト運営者自身による自己監査です。Googleの検査結果をそのまま記録しており、順位やAI引用への効果を示す事例ではありません。

修正後の比較記事はArticleとBreadcrumbListの2件が有効で、重大・重大ではない問題とも0件になりました。本記事も同じ2件が警告なしで有効、ホームもOrganization 1件が警告なしで有効でした。

実測を受けて直した4項目

第一に、ArticleのdatePublishedとdateModifiedを日付だけの値から、日本時間を含むISO 8601の日時へ変更しました。見た目の公開日は変えず、機械可読な値を明確にします。

第二に、編集部と発行組織の識別子を分けました。修正前は「日本LLMOセンター編集部」と「日本LLMOセンター」が同じ@idを共有していたため、同一実体に二つの名称が付く状態でした。編集部は#editorial-team、発行者は#organizationに分けます。

第三に、Organizationのロゴを24×24のfaviconから512×512の専用URLへ変更しました。GoogleのOrganizationガイドは112×112以上で、クロール可能な代表画像を案内しています。

第四に、ホームとサービスページのFAQ本文は残し、FAQPage JSON-LDだけを削除しました。Googleは一般の商用サイトでFAQリッチリザルトを通常表示せず、今回の公開URL検査でも対象項目として検出されませんでした。削除は順位施策ではなく、対応外のマークアップを成果のように数えないための整理です。

構造化データでできること

Organizationでは、組織名、別名、公式URL、ロゴ、問い合わせ先などの公開事実を同じ実体へまとめられます。Articleでは、見出し、著者、発行者、公開・更新日時、画像、正規ページの関係を表せます。BreadcrumbListでは、閲覧者に表示するサイト階層と機械可読な階層を一致させられます。

重要なのは、schema.orgに存在する語彙を大量に足すことではありません。Google検索での表示を目的にする場合は、Schema.orgの定義だけでなく、Google Search Centralが対応する機能と必須・推奨項目を確認します。Googleは、少数でも完全で正確な推奨項目を、曖昧な値で大量に埋めることより優先するよう案内しています。

構造化データでできないこと

構造化データは、本文の品質や外部からの信頼を置き換えません。JSON-LDへ「業界No.1」「顧客評価5.0」「導入1,000社」と書いても、公開本文と根拠がなければ不一致や誤認になります。存在しない住所、法人名、価格、在庫、レビューを追加してはいけません。

有効な構造化データがあっても、Googleはリッチリザルトを表示すると保証していません。さらに、GoogleのAI OverviewsやAI Modeへ出るための専用マークアップでもありません。対象ページがクロール・インデックス可能で、通常検索に表示でき、有用な本文と内部リンクを持つことが前提です。

「LLMO用schema」とllmo.jsonを混同しない

Googleは、生成AI検索向けの特別なschema.orgやAI用マークアップを追加する必要はないと案内しています。既存のOrganizationやArticleへ「LLMO対策用」という独自プロパティを足しても、Googleが理解する保証はありません。

検索結果には、schema.orgのJSON-LDとは別に、llmo.orgが提案するllmo.jsonという仕様も現れます。これは第三者による新しい提案であり、Google Search CentralやSchema.orgの標準機能ではありません。採用を検討するときは、誰が利用する仕様か、署名や更新を誰が管理するか、公開する主張に法的責任を持てるかを別途確認します。順位向上だけを理由に導入しません。

ページ種類から必要な型を選ぶ

サイト全体の発行主体にはOrganization、個別の記事にはArticleまたはBlogPosting、画面に表示する階層にはBreadcrumbListを検討します。実店舗がある場合だけ、公開中の住所や営業時間と一致するLocalBusinessを選びます。商品ページでは、実際の価格、在庫、レビューなど必要な事実を維持できる場合にProductを検討します。

Serviceはschema.orgでサービスを記述する語彙ですが、追加すれば特別なGoogleリッチリザルトが出るという意味ではありません。「語彙として表現できること」と「Googleが検索機能として対応していること」を分けます。

  • 組織トップ・会社概要：Organization
  • 記事・調査・ニュース：Article、BlogPosting、NewsArticleから実態に合う型
  • 表示中の階層：BreadcrumbList
  • 実店舗：公開事実を維持できる場合だけLocalBusiness
  • 商品：GoogleのProduct要件と可視本文を満たせる場合だけProduct
  • よくある質問：ユーザーのための本文は作るが、一般商用サイトではFAQリッチリザルトを期待しない

JSON-LDの実装と検証手順

最初に、名称、説明、著者、発行者、公開日、価格など、閲覧者が同じページで確認できる事実を決めます。次に、同じ組織や人物へはページをまたいで安定した@idを使い、別の編集部やブランドは別の識別子へ分けます。

JSON-LDは、一般のHTTP取得で返るHTMLに含めます。タグマネージャーやログイン後だけに依存せず、公開URLをGoogleリッチリザルト テストで確認します。Googleが対応しない語彙を含む全体の文法確認にはSchema Markup Validatorを併用し、本番公開後も同じURLを再検査します。

  • 1. 可視本文にある事実だけを一覧にする
  • 2. ページの主題に合う最小限の@typeを選ぶ
  • 3. 組織、編集部、記事、Webサイトの@idを設計する
  • 4. 正規HTTPS URL、日時のタイムゾーン、画像URLを確認する
  • 5. 一般取得したHTMLにJSON-LDが出ることを確認する
  • 6. Googleリッチリザルト テストとSchema Markup Validatorで検査する
  • 7. 本番公開後に再テストし、Search Consoleの拡張レポートを監視する

検証テンプレートと公開データ

本記事には、公開URLの監査結果、20項目チェックリスト、OrganizationとArticleの安全テンプレートを添付しました。テンプレートの例示値は、そのまま公開せず、画面に表示し根拠を持てる事実へ置き換えます。

監査CSVでは、テスト日時、対象URL、検出項目、有効件数、重大・重大ではない問題、観測事実、修正、再テスト結果を分けています。「有効」を成果と読み替えず、実装品質の検査記録として使ってください。

公開後14日で確認すること

公開直後の14日間では、順位上昇の因果を断定できません。まず、対象URLがクロールされ、インデックス可能で、構造化データの重大な問題が増えていないことを確認します。次にSearch Consoleで、構造化データ、JSON-LD、Article、Organizationなど関連クエリの表示回数、クリック、平均掲載順位をページ単位で見ます。

AI回答では、同じ質問、サービス、検索機能、日時を記録し、記事が引用されたかだけでなく、どのURLと記述が根拠になったかを複数回観測します。表示がなければschemaを増やすのではなく、検索意図、本文の独自性、内部リンク、インデックス、外部情報を順に見直します。

  • 技術：公開URLの取得、インデックス可否、重大・任意警告
  • 検索：対象ページの表示回数、クリック、CTR、平均掲載順位
  • AI回答：候補掲載、公式URL引用、説明の正確性、回答ごとの差
  • 相談：記事から診断・問い合わせへの遷移と、実際の相談内容
  • 判断：警告は直す。表示があるなら本文と比較軸を強化し、表示がなければ意図・発見性・独自情報を再診断する