SEO・AIO

構造化データ（Schema/JSON-LD）の入れ方｜2026年版

Schema.orgの意味とGoogle検索機能を分け、どこに何を置き、公開後までどう検証するかをBtoB実務目線で解説します。

この記事の要点

構造化データは「内容を正しく伝える補助」です。検索順位やリッチリザルトの表示、AIでの引用を保証するものではありません。
実態と異なるSchemaは逆効果です。ページに書かれていない情報をマークアップしてはいけません。
JSON-LDは有力な実装形式です。Schema.orgとしての妥当性、Google機能の適格性、本番でGoogleが取得した状態を別々に検証します。

— 01

構造化データとは何か

構造化データとは、Webページに書かれている情報の「意味」を、検索エンジンやAIが理解しやすい形式で明示する仕組みです。人間は「株式会社○○」という文字列を見れば会社名だと分かりますが、機械にとっては単なる文字の並びです。そこで「これは会社名」「これは所在地」「これは公開日」といったラベルを、決められた語彙（ボキャブラリ）で付けます。この共通の語彙がSchema.org（スキーマ・ドット・オルグ）です。

Schema.orgはGoogle・Microsoft・Yahoo・Yandexが共同で立ち上げた語彙の標準で、Organization（組織）やArticle（記事）といった「型（Type）」と、name（名前）やurlといった「プロパティ（Property）」が定義されています。構造化データは、このSchema.orgの語彙を使ってページの内容を注釈します。

ここで最初に分けるべきなのが、Schema.orgで意味を表せることと、Google検索がその型を特定のSearch featureとしてサポートしていることです。同じではありません。たとえばServiceはSchema.orgの型ですが、Google Search Galleryに独立したService rich-result featureはありません。一方ProductはSchema.orgでは「提供されるproductまたはservice」を含み得ますが、GoogleのProduct snippetやmerchant listingにはページ内容やOfferなど別の要件があります。

重要なのは、構造化データはあくまで「伝え方」だという点です。ページの内容そのものを良くするものではありません。中身の薄いページに構造化データを足しても、中身が充実するわけではありません。構造化データは、すでにページにある情報を、機械が正しく解釈できるように整理して渡す役割を担います。

構造化データで起こり得ること・起こらないこと

起こり得ること	起こらないこと（保証されないこと）
検索エンジンがページの内容を正確に解釈する補助になる	検索順位が上がる
リッチリザルト表示の条件を満たす場合がある	リッチリザルトが必ず表示される
AIがページの事実を解釈する手がかりになり得る	AIに必ず引用される

構造化データを入れたのに順位が変わらない、リッチリザルトが出ない、という相談は珍しくありません。これは構造化データの役割を正しく理解すれば想定の範囲です。構造化データは「正しく伝える」ための投資であり、「成果を保証する」ものではありません。

— 02

種類別の役割と使いどころ

Schema.orgには数百の型がありますが、BtoBサイトで実務上把握しておきたいのは限られています。代表的な種類と役割を整理します。

Organization（組織）

会社名・ロゴ・所在地・連絡先・公式SNSなどを伝えます。Googleは、ホームページまたは会社を説明する単一ページ（会社概要など）へ置くことを推奨しており、全ページへ重複させる必要はありません。name・url・logoに加え、sameAsなど実在する公式プロフィールを、visible contentと矛盾しない範囲で使います。

WebSite（サイト）

サイト全体の情報を表します。Googleで希望するsite nameを明示する用途では、WebSite構造化データをdomainまたはsubdomainのホームページへ置くことが重要です。全下層ページへ重複させる型ではありません。SearchActionによるサイトリンク検索ボックスは廃止済みなので、その目的で実装しません。

BreadcrumbList（パンくずリスト）

ページがサイト内のどの階層にあるかを伝えます。「ホーム > サービス > SIGNAL」のような階層を機械可読にします。検索結果のURL表示がパンくず形式になる場合があり、サイト構造を伝えるうえで効果が分かりやすい型です。実装の手間が小さく、効果も把握しやすいため、優先度が高い種類です。

Article / BlogPosting（記事）

ブログやコラム記事の見出し・著者・公開日・更新日などを伝えます。ニュースに近い記事にはNewsArticle、一般的なブログ記事にはBlogPostingを使うのを目安とします。著者（author）や発行元（publisher）を示すことは、誰が書いた情報かという信頼性の手がかりになります。

FAQPage（よくある質問）

ページ内のよくある質問と回答を構造化します。Google FAQ rich resultは2026年5月7日から表示されなくなり、関連ドキュメントも6月15日に削除されました。一方、Schema.orgのFAQPage型は残っています。このページでもvisible FAQと同じ内容をFAQPageとして出力していますが、これはsemantic markupであり、Google SearchのFAQ featureが現在存在するという意味ではありません。

Product / Service（製品・サービス）

Schema.orgではProductは「提供されるproductまたはservice」を含み得て、Service型も別に存在します。したがって「サービスだからProductは誤り」と単純化しません。まずvisible contentを最も正確に表すsemantic typeを選びます。そのうえでGoogleのProduct snippetを狙うなら単一のspecific productに焦点があるか、review・aggregateRating・offers等の要件を満たすかを別に確認します。merchant listingはさらに、ページ上で購入できることやOfferの要件があります。

LocalBusiness（実店舗・拠点）

実店舗や来訪を受ける拠点がある事業で使います。営業時間・所在地・電話番号などを伝えます。BtoBでも、オフィスへの来訪や地域での認知が重要な場合に検討します。一方、来訪のないオンライン中心の事業ではOrganizationで足りることが多く、無理にLocalBusinessを付ける必要はありません。

型の選び方の原則

型は「ページの実態に合うもの」を選びます。そのうえで、Schema.org上で意味が正しいかと、Googleの特定Search featureへ適格かを別に判定します。主役となるentityやcontent typeを決め、BreadcrumbListなど必要な補助型を組み合わせます。OrganizationやWebSiteはページごとの飾りではなく、推奨配置を守って正本化します。

— 03

JSON-LDの書き方の基本

構造化データの記述方式にはJSON-LD・Microdata・RDFaがありますが、現在はJSON-LDでの記述が一般的で、Googleも推奨しています。JSON-LDは本文のHTMLと分離して<script>タグにまとめて書けるため、保守がしやすい点が利点です。

基本の構文

JSON-LDは、<head>内（<body>内でも動作しますが<head>が一般的）に次の形で置きます。

<script type="application/ld+json">
{
  "@context": "https://schema.org",
  "@type": "Organization",
  "name": "株式会社サンプル",
  "url": "https://example.com/",
  "logo": "https://example.com/logo.png"
}
</script>

@contextは語彙の出どころで、https://schema.org を指定します。
@typeはこのデータが何を表すかの型です。
それ以降は、その型に定義されたプロパティと値の組です。

値は必ず、ページに実際に表示されている内容と一致させます。これが構造化データの大前提です。

Organizationの例

<script type="application/ld+json">
{
  "@context": "https://schema.org",
  "@type": "Organization",
  "name": "株式会社サンプル",
  "url": "https://example.com/",
  "logo": "https://example.com/logo.png",
  "sameAs": [
    "https://x.com/example",
    "https://www.linkedin.com/company/example"
  ]
}
</script>

BreadcrumbListの例

<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/services/"
    },
    {
      "@type": "ListItem",
      "position": 3,
      "name": "SIGNAL",
      "item": "https://example.com/services/signal"
    }
  ]
}
</script>

positionは階層の順番、nameは表示名、itemはそのページのURLです。実際のパンくず表示と順序・名称を揃えます。

BlogPostingの例

<script type="application/ld+json">
{
  "@context": "https://schema.org",
  "@type": "BlogPosting",
  "headline": "構造化データ実装ガイド",
  "datePublished": "2026-06-26",
  "dateModified": "2026-06-26",
  "author": {
    "@type": "Organization",
    "name": "株式会社サンプル"
  },
  "publisher": {
    "@type": "Organization",
    "name": "株式会社サンプル",
    "logo": {
      "@type": "ImageObject",
      "url": "https://example.com/logo.png"
    }
  }
}
</script>

headlineはページのタイトルと整合させ、datePublished・dateModifiedは実際の公開日・更新日を入れます。日付はISO 8601形式（2026-06-26など）が無難です。

複数の型を1ページに置くとき

1ページに複数の構造化データを置くのは問題ありません。たとえばブログ記事ページなら、BlogPosting・BreadcrumbList・（必要なら）FAQPageを別々の<script>で並べる、あるいは@graphを使って1つのスクリプトにまとめる方法があります。いずれの方法でも、各データの内容がページの実態と一致していることが前提です。

— 04

BtoBで優先すべきもの

すべての型を入れる必要はありません。BtoBサイトでは、効果が分かりやすく実態とのズレが起きにくいものから優先します。優先度の目安を示します。

優先度	種類	主な対象ページ	理由
高	Organization	トップまたは会社概要	会社entityの正本。全ページへ重複させる必要はない
高	WebSite	ドメイン／サブドメインのトップ	Googleへ希望するサイト名を明示する主要シグナル
高	BreadcrumbList	パンくずがある階層ページ	表示上のパンくずと同じ階層を機械可読にする
中	Article / BlogPosting	ブログ・コラム	記事の著者・公開日・更新日を伝える
条件付き	Product	特定の提供物を主役にしたページ	Schema.orgではserviceも含み得る。Google Product機能の適格性は別判定
条件付き	Service	役務・コンサル・受託の説明ページ	サービスの意味付け。独立したGoogle rich-result featureを意味しない
状況次第	LocalBusiness	来訪を受ける実拠点	所在地・営業時間など地域利用が重要な場合
補助	FAQPage	本文にFAQがあるページ	Schema.org semantic type。Google FAQ rich resultは2026-05-07終了

BtoBサイトでの出発点は「全ページへ同じ型を足すこと」ではなく、配置と役割を決めることです。Organizationはhome/about、WebSiteはhome、BreadcrumbListは階層ページ、Article系は記事へ置きます。Product/Serviceはsemantic typeを選んだ後にGoogle Product featureの適格性を別判定します。FAQPageはSchema.org上のsemantic typeとして扱い、2026年5月7日に終了したGoogle FAQ rich resultとは分離します。

— 05

実装時の確認ポイントと検証方法

構造化データの相談で頻出する確認ポイントを挙げます。多くは「実態とのズレ」と「検証の省略」に起因します。

実装時の確認ポイント

ページにない情報をマークアップする：本文に表示していない価格・評価・レビューを構造化データだけに書く。これは規約違反で、最優先で避けるべき項目です。
必須プロパティの欠落：型ごとに推奨・必須とされるプロパティが抜けていて、対象として認識されない。
構文エラー：カンマの過不足、引用符の閉じ忘れ、波括弧の対応ミスなどでJSONとして壊れている。
型と実態のズレ：記事ページにProduct、サービスページにArticleなど、ページの種類に合わない型を付ける。
URLや日付の不整合：itemのURLが実在しない、datePublishedが実際の公開日と違う。
noindexページへのマークアップ：そもそもインデックスされないページに構造化データを入れても表示対象にならない。
画像URLの絶対パス漏れ：ロゴや画像を相対パスで書き、検索エンジンが取得できない。

検証方法

公開前と公開後に、必ず次のツールで検証します。

Schema Markup Validator：まずSchema.orgの語彙・型・構文として妥当かを確認します。Googleがrich resultを提供しない型もここで検証できます。
Rich Results Test（Google）：Googleが対応するSearch featureについて、必要なstructured dataを検出できるか、エラーや警告がないかを確認します。Schema.orgとして正しいだけでGoogle featureへ適格とは限りません。
URL Inspection / Search Console：公開後のURLをGoogleがどう取得したかを確認し、対応するstructured-dataレポートやPerformanceを継続観測します。validator通過だけでProduction完了とは扱いません。

検証は一度きりではありません。サイト改修やテンプレート変更で構造化データが壊れることがあるため、公開後もSearch Consoleで定期的に確認します。「入れて終わり」にしないことが、構造化データを健全に保つコツです。

— Netsujoの運用

構造化データは3つのGateを分けて確認する

Netsujoでは、構造化データを「validatorが通ったから完了」とは扱いません。少なくとも、1. Schema.orgとして意味・構文が妥当か、2. Googleの対象Search featureへ適格か、3. 本番URLをGoogleが取得した状態で問題がないかを分けます。この分離が、semantic markupと検索表示への期待を混同しないための実装ルールです。

このページ自身もvisible FAQと同じQ&AをFAQPageとして出力しています。しかしGoogle FAQ rich resultは2026年5月7日に終了しており、ここでのFAQPageはsemantic markupです。Schema.orgの語彙が残ることと、Google Search featureが存在することは別の状態です。

2026年9月20日に確認した公式資料

— 06

AIに伝えるうえでの構造化

AI検索（AI Overviews・ChatGPT・Perplexityなど）の文脈で「構造化データを入れればAIに載るのか」という質問が増えています。ここは前提を丁寧に整理したい領域です。

まずGoogleについては、AI OverviewsやAI Modeへ表示されるための特別なSchema.org markupは不要と案内されています。通常のSearch要件を満たし、structured dataはvisible textと一致させるのが前提です。Google以外のAIサービスについては、このGoogle仕様から引用・推薦条件を一般化しません。

構造化データは、会社名・サービス内容・所在地・連絡先・公開日など、visible contentとして存在する事実に明示的な意味を付けるレイヤーです。ただし、それ自体をAI掲載施策とは扱いません。重要情報が画像やPDFだけにあるなら、まず本文として取得できる状態を整える方が先です。

AIに事実を伝えるうえで効くのは、構造化データという「形式」だけでなく、本文そのものの整理です。次のような書き方が、機械にも人にも伝わりやすくなります。

結論を最初に書く（answer-first）
1つの段落で1つの論点を扱う
数値・条件・出典を具体的に添える
質問形の見出しに対して、直後で簡潔に答える

構造化データは、こうして整理された事実に正しいラベルを付ける役割です。本文の整理（中身）と構造化データ（伝え方）は両輪であり、構造化データだけを足してもAIに伝わる量は大きく変わりません。AI向けの本文の書き方は関連記事「AIに引用されないサイトの共通点」、AI向けの要点ファイルの位置づけは関連記事「llms.txtは必要か」も参照してください。

— 07

直し方の優先順位

構造化データを一度にすべて整えようとすると工数が膨らみます。インパクトと手間で段階を分けると効率的です。

段階	主な作業	ねらい
第1段階（配置と実態）	Organizationはhome/about、WebSiteはhome、BreadcrumbListは表示上のパンくずと一致させる	page roleとsemantic typeを一致させる
第2段階（記事・offering）	Article/BlogPostingを記事へ。Product/Serviceは実態に合わせ、Google Product feature適格性を別判定する	Schema.orgの意味とGoogle機能を混同しない
第3段階（検証とProduction）	Schema Markup Validator→Rich Results Test→公開URL→URL Inspection/Search Consoleの順で確認する	構文・Google機能・本番観測を別Gateで閉じる

順番は「共通型を全ページへ足す」ではありません。OrganizationやWebSiteは推奨配置を守り、ページ固有のsemantic typeをvisible contentから決めます。その後、Google Search featureの対象ならRich Results Testで確認し、最後にProduction URLをURL Inspection/Search Consoleで観測します。

構造化データの整備は、本文の整理（中身を分かりやすくする）とセットで進めると効果が出やすくなります。構造化データは伝え方の改善であり、伝える中身の改善と両輪で捉えてください。

まとめ

構造化データはvisible contentの意味を機械可読にする補助です。順位・rich result・AI引用を保証するものではありません。
実態と異なるSchemaは逆効果です。ページに表示している情報だけをマークアップします。
Schema.orgで意味を表せることと、Googleが特定Search featureとしてサポートすることは別です。
Organizationはhome/about、WebSiteはhome、BreadcrumbListは階層ページへ。Product/Serviceはsemantic typingとGoogle Product feature eligibilityを分けて判断します。
Schema Markup Validator、Rich Results Test、公開URL、URL Inspection/Search Consoleを別Gateとして確認します。
AIに伝えるうえでは、構造化データ（伝え方）と本文の整理（中身）の両輪が重要です。
整備は土台→記事/サービス→検証運用の順で、本文の整理とセットで進めます。

よくあるご質問

構造化データを入れれば検索順位は上がりますか？

上がるとは限りません。構造化データはページの内容を正確に伝える補助であり、検索順位を直接上げるものではありません。順位は内容の質や検索意図との一致など、別の要因で決まります。

構造化データを入れればリッチリザルトは必ず表示されますか？

必ずではありません。リッチリザルトの表示は検索エンジン側の判断であり、構造化データが正しくても表示されないことがあります。リッチリザルトテストで対象として認識されることと、実際に表示されることは別です。

JSON-LDとMicrodataはどちらで書くべきですか？

現在はJSON-LDが一般的で、Googleも推奨しています。本文のHTMLと分離して<head>内にまとめて書けるため、保守がしやすい点が利点です。

FAQPageの構造化データは入れるべきですか？

Google FAQ rich resultは2026年5月7日からSearch resultsに表示されなくなりました。一方、Schema.orgのFAQPage型は残っています。本文のFAQは読者のために残し、FAQPageをsemantic markupとして使うかはGoogle Search featureとは別に判断します。

ページに表示していない価格やレビューをマークアップしてもよいですか？

いけません。ページに表示していない情報を構造化データだけに書くのは規約違反で、評価上も逆効果です。実際に表示している情報だけをマークアップします。

構造化データが正しいかはどう確認すればよいですか？

まずSchema Markup ValidatorでSchema.orgとしての構文・型を確認し、Googleが対応する検索機能を狙う場合はRich Results Testで適格性を確認します。公開後はURL InspectionでGoogleが取得したページを確認し、Search Consoleの該当レポートを継続観測します。

BtoBサイトでまず入れるべき構造化データは何ですか？

一律の「基本セット」を全ページへ入れるのではなく、配置を分けます。Organizationはhomeまたは会社概要、WebSiteはdomain/subdomainのhome、BreadcrumbListはパンくずのある階層ページ、Article/BlogPostingは記事です。Product/Serviceは提供物の実態とGoogle機能の要件を分けて判断します。

構造化データを入れればAIに引用されますか？

保証はありません。GoogleはAI OverviewsやAI Mode向けの特別なSchema.org markupは不要と案内しています。まず通常の検索要件とvisible textとの整合を満たします。Google以外のAIサービスの引用条件はこの仕様から一般化せず、各サービスを別に観測します。

この記事の著者

飯田友広

代表取締役

Netsujo株式会社代表取締役。京都発のWeb3・AI実装スタートアップを2023年6月に創業。Webサイトを営業基盤として捉え、経営・営業・検索・生成AI・コンバージョン・計測を横断して課題と改善優先順位を整理する「Netsujo SIGNAL」を設計・運営。さらに、ChatGPT・Codex・Claude Codeを状態再構築、競合回避、独立QC、Exact-head検証、停止、復旧まで含む制御ループで運用する社内AI開発基盤「Netsujo Agent OS」を設計・実運転。Netsujoとして京都ビッグデータ活用プラットフォームに参画(小規模企業会員（ベンチャー）)し、同プラットフォーム発のワーキンググループ「Chain Up KYOTO」にも参画(2026年3月10日〜)。IVS2026サイドイベント「なぜ京都でWeb3.0ビジネスなのか」はNetsujoとして京都府庁旧議場で主催・企画・登壇・運営(2026年7月2日／京都府総合政策環境部デジタル政策推進課は共催)。京都美術工芸大学・龍谷大学での講義に加え、京都高度技術研究所（ASTEM）、旅館業界、就労支援施設、Open Source Conference等で登壇実績。ITコミュニティ「みやこでIT」(connpassメンバー638名・イベント175件・2019年2月から運営)運営。NPO法人NEMTUS理事、BAR KRYPTO運営。Netsujoはソーシャル企業認証制度「S認証」の認証企業(2026年2月認証・2026年4月公表)。技術領域はWeb3/ブロックチェーン/DID/NFT/生成AI/コミュニティ運営。

プロフィールを見る

この記事が向いている方

自社サイトに構造化データを入れたいが、何から手を付ければよいか分からない方
OrganizationやBreadcrumbListなど、BtoBで優先すべき種類を整理したい方
入れたつもりの構造化データが正しいか不安なWeb担当者
AIに事実を正しく伝えるための土台づくりを検討している方

— 壁打ち相談

読者のよくある相談

記事を読んだ後に「自分の状況だとどう判断すべきか」を整理するための壁打ち相談を受け付けています。下記のような相談例が当てはまる方は、お気軽にご連絡ください。

Q. どの構造化データから入れればよいか分かりません。

Organization・WebSite・BreadcrumbListの基本セットから、現状に合わせて優先順位を整理します。

Q. 入れた構造化データが正しいか不安です。

Schema Markup Validator、対象機能のRich Results Test、公開後のURL Inspection/Search Consoleを分けて確認します。

Q. AIに事実を正しく伝えたいです。

構造化データ（伝え方）と本文の整理（中身）の両輪で、AIに解釈されやすい土台づくりを壁打ちできます。

上記いずれかが該当する場合、初回30分の壁打ち相談で論点整理に対応します。記事に書ききれない個別事情を踏まえた判断材料が必要な段階こそ、壁打ちが活きやすいフェーズです。

壁打ち相談を送る

検索・AI時代のWeb営業基盤をつくる

公開情報からの無料Web診断で構造化データの有無や実態とのズレを確認し、その先の有料メニューではページの実態に合ったJSON-LDをコードとして納品します。検索順位やAI掲載を保証するものではありません。

SIGNALのプランを見る