構造化データとは？JSON-LDの書き方と種類、SEOとAI検索での効果を解説

構造化データとは、ページに書かれた情報の意味を、検索エンジンが読み取れる決まった形式で伝えるためのデータです。

Googleが勧めるJSON-LDで、ページに表示している内容だけを正しく書くことが基本です。本記事では、仕組みと種類、書き方、確認の方法、AI検索との関係を解説します。

なお、構造化データを含めた内部対策をどこから手をつければよいか迷っている方は、カルテットコミュニケーションズのSEOコンサルティングの無料相談もご活用ください。

サイトの状況を伺い、広告運用とあわせたWeb集客の中で、優先して直すところを一緒に整理します。

構造化データとは？検索エンジンに中身を「意味つき」で伝えるしくみ

人はページの文章や写真を見れば、どれが会社名でどれが電話番号かをすぐに読み取れます。検索エンジンも文章を読みますが、構造化データがあれば「これは組織の名前」「これは電話番号」と、意味のラベルつきで受け取れます。

上の図のように、1つのページには人とGoogleという2つの読み手がいます。構造化データは、同じ内容を検索エンジン向けの形でも載せておくしくみです。

定義①｜ページの情報を決まった形式で伝えるデータ

Googleは、構造化データを次のように説明しています。

構造化データとは、ページに関する情報をさまざまなサイトで活用できるように標準化したデータ形式で、たとえばレシピページでは材料、加熱時間と加熱温度などを詳細に提供できます。

引用元：Google検索セントラル「構造化データの仕組みについて」

ポイントは「標準化した」形式であることです。サイトごとに自由な書き方をするのではなく、決まった項目名と書き方に合わせることで、検索エンジンが同じルールで読み取れます。

構造化データは、ページの中身を決まった形式で検索エンジンに渡すためのデータです。

定義②｜語彙はschema.org、書き方はJSON-LDなど

構造化データで使う項目名の辞書にあたるのがschema.orgです。Organization（組織）、Article（記事）、Product（商品）といったタイプと、name（名前）やaddress（住所）といったプロパティが定義されています。

一方で、その辞書の言葉をページにどう書き込むかが「形式」で、JSON-LD・microdata・RDFaの3つがあります。辞書と書き方は別のものなので、「schema.orgの語彙を、JSON-LDの形式で書く」と覚えると整理しやすくなります。

schema.orgは言葉の辞書、JSON-LDはその言葉を書き込む形式です。

定義③｜リッチリザルトとの関係

構造化データを入れたページは、検索結果で星の評価や価格、パンくずリストなどが付いた見え方になることがあります。こうした見え方をリッチリザルトと呼びます。

ただし、構造化データの役割は見た目を変えることだけではありません。Googleは、構造化データをページの中身を理解するためにも使っています。

リッチリザルトは、構造化データをもとに検索結果の見え方が変わったものです。

構造化データの3つの形式とJSON-LDの読み方

構造化データの形式は3つあり、Googleはどれも使えるとしています。ただし、実装と管理のしやすさから、多くのサイトではJSON-LDを選ぶのが一般的です。

形式①｜JSON-LD（Googleが推奨）

JSON-LDは、ページの中に「script」タグを置き、その中に構造化データをまとめて書く形式です。画面に表示する文章のHTMLとは分けて書けるので、デザインを崩さずに追加や修正ができます。

Googleも、JSON-LDを勧める理由を次のように説明しています。

一般的に、Google はサイトの設定で許容されている限り、JSON-LD を構造化データに使用することを推奨します。これは、ウェブサイトの所有者が実装と管理を最も容易に行うことができる（つまり、ユーザーエラーの発生する可能性が低い）ソリューションであるためです。

引用元：Google検索セントラル「構造化データの仕組みについて」

これから構造化データを入れるなら、JSON-LDで書くのが基本です。

形式②｜microdata

microdataは、画面に表示する文章のHTMLタグに、itemscopeやitemprop といった属性を付けて意味を書き込む形式です。表示する文章と構造化データが同じ場所にあるため、中身のずれは起きにくい一方で、HTMLが複雑になりやすくなります。

昔から使われているテーマやテンプレートでは、すでにmicrodataが入っていることがあります。新しくJSON-LDを足すときは、同じ情報を二重に書いていないかも確かめます。

microdataは表示の文章に直接書き込むため、古いテーマに残っていないか確かめます。

形式③｜RDFa

RDFaも、HTMLタグに属性を付けて意味を書き込む形式で、HTML5の拡張として使われます。考え方はmicrodataに近く、使われる場面はそれほど多くありません。

すでにRDFaで書かれているページを無理に書き換える必要はありません。新しく作るページや、まとめて直すタイミングで、JSON-LDにそろえるかを判断すれば十分です。

RDFaのページは無理に直さず、作り直しのときにJSON-LDへそろえます。

読み方④｜@context・@type・プロパティの役割

上の図のJSON-LDは、パンくずリストの例です。「@context」で使う語彙（schema.org）を指定し、「@type」で何のデータか（ここではBreadcrumbList）を示します。

その下に、タイプごとに決まったプロパティ（項目名）と値を並べます。項目の中に別のタイプを入れ子にできるのもJSON-LDの特徴で、住所（PostalAddress）を組織（Organization）の中に入れる、といった書き方をします。

JSON-LDは「語彙・タイプ・プロパティ」の3つを押さえれば読めます。

Googleがサポートする主な構造化データの種類

schema.orgには数多くのタイプがありますが、Googleの検索結果の機能に使われるのはその一部です。どのタイプがサポートされているかは、Google検索セントラル「Google 検索がサポートする構造化データのマークアップ」の一覧で確かめられます。

種類①｜どのサイトにも合う「組織」と「パンくずリスト」

Organization（組織）は、会社の名前、ロゴ、住所、連絡先などを伝えるタイプです。Googleは、ホームページに組織の構造化データを追加すると、検索結果で組織を明確にしやすくなると説明しており、必須のプロパティはありません。

BreadcrumbList（パンくずリスト）は、そのページがサイトの階層のどこにあるかを示すタイプです。Googleのドキュメントでは、パンくずリストの表示はパソコン版の検索結果に対応した機能とされています。

どのサイトでも、まずは組織とパンくずリストから始めると取り組みやすくなります。

種類②｜ブログやメディアの「記事」

Article（記事）は、ニュースやブログの記事のページに使うタイプで、BlogPostingやNewsArticleといった細かいタイプもあります。見出し（headline）、画像、公開日と更新日、著者などを書きます。

Articleにも必須のプロパティはなく、記事に当てはまる推奨のプロパティをできるだけ書くよう案内されています。著者の名前とプロフィールのページを結びつけておくと、誰が書いた記事かを正しく伝えられます。

記事のページは、見出し・日付・著者をArticleで正しく伝えます。

種類③｜ネットショップの「商品」と「クチコミ抜粋」

Product（商品）は、価格、在庫の状況、クチコミの評価などを伝えるタイプです。商品の評価を表示するクチコミ抜粋（Review snippet）と組み合わせて使われることもあります。

Google 広告のショッピング広告を出している会社は、Merchant Centerにも商品データを登録しているはずです。価格や在庫がページ・構造化データ・Merchant Centerの間で食い違わないように、更新の手順を決めておきます。

商品のデータは、ページと広告の商品データで食い違わないように管理します。

種類④｜店舗・事業所の「ローカルビジネス」

LocalBusiness（ローカルビジネス）は、店舗や事業所の住所、営業時間、電話番号などを伝えるタイプです。飲食店や医院、美容室など、来店してもらう業種のサイトで使います。

地図の検索に表示される情報は、主にGoogleビジネスプロフィールで管理します。サイトの構造化データとビジネスプロフィールで、名前・住所・電話番号の書き方をそろえておくことが大切です。

店舗のサイトは、構造化データとビジネスプロフィールで基本情報をそろえます。

種類⑤｜求人・イベント・動画・レシピなど

ほかにも、JobPosting（求人情報）、Event（イベント）、VideoObject（動画）、Recipe（レシピ）など、業種やページの種類に合わせたタイプがあります。

求人のページならGoogleの求人検索、動画なら動画の検索結果といったように、表示される場所も変わります。

自社のサイトにどんな種類のページがあるかを書き出し、Googleの一覧にあるタイプと照らし合わせると、使うべきタイプが見えてきます。

自社のページの種類を書き出し、Googleがサポートするタイプと照らし合わせます。

種類⑥｜よくある質問（FAQ）のリッチリザルトは表示終了

以前はFAQPage（よくある質問）の構造化データを入れると、検索結果に質問と答えが表示されることがありました。しかしGoogleの最新ドキュメントの更新内容によると、この機能は2026年5月7日以降、Google検索に表示されなくなり、同年6月にはドキュメントも削除されました。

これからFAQの構造化データを入れても、Google検索で質問と答えのリッチリザルトが表示されることはありません。よくある質問のページそのものは読者の役に立つので、内容を充実させることに力を使いましょう。

FAQのリッチリザルトは終了したため、質問と答えの中身そのものを充実させます。

構造化データの書き方と実装の手順

構造化データは、いきなりコードを書き始めるより、「どのページに、どのタイプを」を先に決めるほうが早く進みます。図の5つのステップで進めましょう。

STEP①｜ページの種類ごとに使うタイプを決める

トップページと会社概要ならOrganization、ブログの記事ならArticle、商品のページならProduct、というように、ページの種類ごとに主なタイプを1つ決めます。パンくずリストは、ほとんどのページに共通して入れられます。

1つのページに複数のタイプを入れることもできますが、ページの主な目的を表すタイプを中心にします。たとえばレシピが主なページなら、動画やレビューの構造化データに加えてRecipeを入れる、という考え方です。

ページの主な目的に合うタイプを、ページの種類ごとに1つ決めます。

STEP②｜Googleのドキュメントで必須・推奨プロパティを確かめる

使うタイプが決まったら、Google検索セントラルにあるそのタイプのページで、必須のプロパティと推奨のプロパティを確かめます。schema.orgのサイトにも説明はありますが、Googleの検索での扱いはGoogleのドキュメントが基準です。

検索用の構造化データでは主に schema.org のボキャブラリが使用されていますが、Google 検索の動作の定義には、schema.org のドキュメントではなく、Google 検索セントラルのドキュメントを使用してください。

引用元：Google検索セントラル「構造化データの仕組みについて」

Googleは、不完全なデータを多く入れるより、少なくても完全で正確なプロパティを入れるほうが大事だとしています。わからない項目を無理に埋めず、正しく書ける項目から入れていきます。

項目の書き方は、schema.orgではなくGoogle検索セントラルのページで確かめます。

STEP③｜JSON-LDを書く（組織と記事の例）

会社のトップページや会社概要に入れる、組織（Organization）のJSON-LDの例です。Googleのドキュメントの例をもとに、日本の会社向けに値を置き換えています。

<script type="application/ld+json">
{
  "@context": "https://schema.org",
  "@type": "Organization",
  "name": "株式会社〇〇",
  "url": "https://www.example.com",
  "logo": "https://www.example.com/images/logo.png",
  "telephone": "+81-52-000-0000",
  "address": {
    "@type": "PostalAddress",
    "postalCode": "460-0000",
    "addressRegion": "愛知県",
    "addressLocality": "名古屋市中区",
    "streetAddress": "〇〇1-2-3",
    "addressCountry": "JP"
  },
  "sameAs": ["https://www.example.net/profile/example"]
}
</script>

次は、ブログの記事のページに入れる記事（Article）のJSON-LDの例です。見出しや日付、著者は、ページに表示している内容と同じものを書きます。

<script type="application/ld+json">
{
  "@context": "https://schema.org",
  "@type": "Article",
  "headline": "構造化データとは？",
  "image": ["https://www.example.com/photos/16x9/photo.jpg"],
  "datePublished": "2026-11-03T09:00:00+09:00",
  "dateModified": "2026-11-03T09:00:00+09:00",
  "author": [{
    "@type": "Person",
    "name": "山田 太郎",
    "url": "https://www.example.com/profile/yamada"
  }]
}
</script>

サンプルの値は、自社のページに表示している内容にすべて置き換えて使います。

STEP④｜CMSのプラグインやタグマネージャーで入れる

WordPressなどのCMSを使っている場合は、HTMLを直接編集するより、テーマの機能やSEO用のプラグインで構造化データを入れるほうが簡単なことがあります。Googleも、CMSに統合されたプラグインを使う方法を案内しています。

Googleタグマネージャーで、カスタムHTMLのタグとしてJSON-LDを入れる方法もあります。その場合Googleは、ページと構造化データの中身がずれないよう、ページの情報をタグに書き写すのではなく変数でページから取り出すよう勧めています。

テーマやプラグインがすでに構造化データを出力していることもあるため、新しく足す前に、今のページに何が入っているかをテストツールで確かめておきます。

入れ方を決める前に、今のテーマやプラグインが出している構造化データを確かめます。

STEP⑤｜テストしてから公開する

書いた構造化データは、公開する前にリッチリザルト テストでGoogleが読み取れるかを確かめます。エラーが出た項目を直し、テストが通ってから公開します。

最初からすべてのページに広げず、数ページで公開して様子を見てから、テンプレート全体に広げると安全です。構造化データの実装を社内で進める時間がない場合は、カルテットコミュニケーションズのSEOコンサルティングでも内部対策とあわせてご相談を承っています。

テストが通ってから、数ページで試し、そのあとテンプレート全体に広げます。

構造化データの確認方法とSearch Consoleでの見方

構造化データは、書いている途中から公開の数か月後まで、段階ごとに使うツールが変わります。図の順番で確かめていけば、見落としを減らせます。

確認①｜リッチリザルト テストでGoogleが読めるかを見る

リッチリザルト テストは、URLかコードを入れると、Googleが読み取れる構造化データと、リッチリザルトの対象になるかを表示してくれるGoogleのツールです。重大なエラーがあれば、その項目が示されます。

重大ではない警告は、直さなくてもリッチリザルトの対象になる場合があります。それでも、構造化データの質を上げるために、直せるものは直しておくとよいでしょう。

公開の前に、リッチリザルト テストで重大なエラーがないことを確かめます。

確認②｜Schema Markup Validatorで書き方を見る

Schema Markup Validatorは、schema.orgの書き方として正しいかを確かめるツールです。Googleの検索の機能に関係しないタイプも含めて、構造化データ全体の書き方を見られます。

Googleのリッチリザルトの対象かどうかはリッチリザルト テストで、schema.orgとしての書き方はSchema Markup Validatorで、と役割を分けて使います。

書き方の正しさはSchema Markup Validator、Googleでの扱いはリッチリザルト テストで見ます。

確認③｜URL検査ツールで公開後のページを見る

公開したあとは、Search ConsoleのURL検査ツールで、Googleが取得したページに構造化データが含まれているかを確かめます。JavaScriptで入れた構造化データも、Googleが読み取れているかをここで確認できます。

問題がなければ、URL検査ツールから再クロールを依頼できます。Search Consoleの基本の使い方は、Google Search Consoleについてでも解説しています。

公開後は、URL検査ツールでGoogleが取得したページを確かめます。

確認④｜リッチリザルトのレポートでエラーを見守る

Search Consoleには、構造化データのタイプごとに、有効なページとエラーのあるページの数を示すレポートがあります。Googleは、開発中はリッチリザルト テストを、公開後はこのレポートを見るよう勧めています。

テーマの更新やテンプレートの変更で、あとから構造化データが壊れることもあります。月に一度など、レポートを見る日を決めておくと安心です。

公開後もリッチリザルトのレポートを定期的に見て、壊れていないかを確かめます。

確認⑤｜効果は入れる前と後で比べる

構造化データの効果を知りたいときは、Googleが勧める「ビフォー・アフター」の比べ方が使えます。季節や公開時期の影響を受けにくいページを選び、Search Consoleで数か月分のデータを集めてから構造化データを入れます。

入れたあとも数か月分の検索パフォーマンスを記録し、URLで絞り込んで、表示回数やクリック率がどう変わったかを比べます。ページの閲覧数はほかの要因でも変わるため、結果は慎重に読み取ります。

効果は、同じページの入れる前と後の数か月を比べて判断します。

構造化データでよくある6つの間違い

テストツールで見つかるのは、主に書き方の誤りです。ガイドラインに沿っているかどうかは、自分の目で確かめる必要があります。

間違い①｜ページに表示されていない情報をマークアップする

いちばん多いのが、ページに書いていない情報を構造化データにだけ書いてしまう間違いです。Googleのガイドラインは、はっきりとこれを禁じています。

ページの読者に表示されないコンテンツをマークアップしないでください。たとえば、JSON-LD マークアップでパフォーマーが記述されている場合、HTML の本文でも同じパフォーマーが記述されている必要があります。

引用元：Google検索セントラル「構造化データに関する一般的なガイドライン」

営業時間や価格を変えたときに、ページの表示だけを直して構造化データが古いまま、というずれもよく起きます。

構造化データには、ページに表示している内容だけを書きます。

間違い②｜ページの中身と違うタイプを使う

構造化データは、ページの中身を正確に表している必要があります。Googleは、木工のやり方をレシピとしてラベル付けするような例を、関連性が低いデータとして挙げています。

リッチリザルトに出やすそうなタイプを、中身に関係なく選ぶのは逆効果です。ページの主な内容に合う、schema.orgで最も具体的なタイプを選びます。

タイプは、見え方ではなくページの中身に合わせて選びます。

間違い③｜自作のレビューや評価を入れる

星の評価が検索結果に出ると目立つため、自社で作った評価やレビューを構造化データに入れたくなるかもしれません。しかしGoogleは、虚偽のレビューなど誤解を招くコンテンツのマークアップを禁じています。

実際の利用者によらないレビューや評価は、手動による対策の対象とみなされることもあります。評価を入れるのは、実際の利用者から集めたものがページに表示されている場合だけにします。

レビューや評価は、実際の利用者のものをページに載せている場合だけ書きます。

間違い④｜必須プロパティが抜けている

リッチリザルトのタイプによっては、必須のプロパティが決まっています。必須のプロパティが抜けていると、そのアイテムはリッチリザルトに表示されません。

一方で、OrganizationやArticleのように必須のプロパティがないタイプもあります。どちらのタイプかは、STEP②のとおりGoogleのドキュメントで確かめます。

タイプごとの必須プロパティは、Googleのドキュメントで確かめて漏れなく書きます。

間違い⑤｜robots.txtやnoindexでページをブロックしている

構造化データを入れても、robots.txtでクロールを止めていたり、noindexを付けていたりすると、Googleはそのページを検索結果に使えません。Googleのガイドラインも、アクセス制御でページをブロックしないよう求めています。

noindexの使い方は、noindexとnofollowの記事でも解説しています。

構造化データを入れたページを、robots.txtやnoindexで止めていないか確かめます。

間違い⑥｜テンプレートの変更で壊れたままにする

テーマの更新やプラグインの入れ替えで、構造化データが消えたり、二重に出力されたりすることがあります。テンプレートに入れた構造化データは多くのページに一度に影響するため、気づかないと被害が広がります。

サイトの改修のあとは、代表的なページをリッチリザルト テストで確かめ、数日後にSearch Consoleのレポートも見ます。改修の手順の中に、この確認を組み込んでおくと忘れません。

サイトの改修のあとは、構造化データの確認を手順に組み込みます。

構造化データのSEO効果とAI検索との関係

構造化データは、入れれば順位が上がる、という種類の施策ではありません。Googleの説明をもとに、期待できることとできないことを分けて考えましょう。

効果①｜検索結果での見え方が変わり、クリック率に影響することがある

リッチリザルトになると、価格や評価、パンくずリストなどが検索結果に表示され、ほかの結果より情報が多い見え方になります。

Googleは、構造化データを10万ページに追加したRotten Tomatoesで、構造化データのあるページのクリック率が25%高くなった例を紹介しています。

ただし、これはGoogleが紹介する1つの事例で、どのサイトでも同じ結果になるわけではありません。自社の効果は、前の章のビフォー・アフターの方法で確かめます。

構造化データは、検索結果の見え方を通じてクリック率に影響することがあります。

効果②｜入れても表示されるとは限らない

Googleは、構造化データを正しく入れても、リッチリザルトが表示されるとは限らないと明記しています。検索した人の状況などに合わせて、Googleが最適と判断した見え方が選ばれるためです。

また、ガイドラインに反する構造化データには、手動による対策がとられることがあります。

構造化データに関する手動による対策が実施されると、ページがリッチリザルトとして表示されなくなります。ただし、Google ウェブ検索でのページの掲載順位には影響しません。

引用元：Google検索セントラル「構造化データに関する一般的なガイドライン」

手動による対策がとられたかどうかは、Search Consoleの「手動による対策」のレポートで確かめられます。

構造化データは表示の保証ではなく、ガイドラインに沿って入れてこそ意味があります。

効果③｜生成AI検索に特別なマークアップは要らない

AIによる概要（AI Overviews）などの生成AI検索のために、構造化データを増やすべきかを気にする方も増えています。Googleは、生成AI機能向けの最適化のガイドで、次のように説明しています。

生成 AI 検索に構造化データは必要ありません。追加する必要がある特別な schema.org マークアップもありません。

引用元：Google検索セントラル「Google 検索の生成 AI 機能向けにウェブサイトを最適化する」

同じガイドでは、リッチリザルトの対象となる助けになるため、SEO全体の取り組みの一部として構造化データを使い続けることを勧めています。AI検索への対策の全体像は、AIO最適化（AI Overview）やSEO・AEO/GEO・AIO・LLMOの違いでも紹介しています。

生成AI検索のための特別な構造化データはなく、通常のSEOの一部として使います。

効果④｜構造化データとページの文章をそろえる

Googleの「AI 機能とウェブサイト」のページでも、SEOのベストプラクティスの1つとして、構造化データをページに表示されるテキストと一致させることが挙げられています。

ページの文章を直したら構造化データも直す、価格や営業時間を変えたら両方を変える、という運用を続けることが、AI検索の時代にも変わらない基本です。

構造化データとページの文章は、いつも同じ内容にそろえておきます。

まとめ｜構造化データは、ページに表示している内容を正しく伝える道具

構造化データは、ページそのものの質を上げる施策ではなく、良いページの中身を検索エンジンに正しく伝える道具です。組織とパンくずリストから始め、ページの種類ごとに少しずつ広げていきましょう。

公開して終わりにせず、テストツールとSearch Consoleで確かめ続けることが、成果につながる近道です。

構造化データを含めた内部対策の進め方に迷ったら、カルテットコミュニケーションズのSEOコンサルティングの無料相談をご利用ください。サイトの状況に合わせて、どこから直すかを一緒に整理します。