構造化データとは？SEO効果と書き方・設定手順を実測で解説

「構造化データを入れた方がいい」とは聞くものの、どの種類を、どこまで書けばいいのか分からない。

そのまま後回しになっていないでしょうか。

結論からいうと、最初にやることは書くことではなくいま自社サイトが何を出力しているかを確認することです。

テーマやプラグインがすでに出しているケースが多く、手で足すべきものは実際には4種類ほどに絞れます。

この記事では、自社で運営するサイトの出力を実測した結果と、Google検索セントラルの記述を突き合わせながら、書き方・設定手順・確認方法を順に解説します。

構造化データとは？ページの意味を検索エンジンとAIに伝える記述

構造化データとは、ページに書かれている情報が何を指すのかを、決められた語彙で機械に伝えるための記述のことです。

使う語彙はschema.orgという共通の辞書で、GoogleやMicrosoftなどが共同で策定しています。

この辞書を使って「これは会社名」「これは公開日」「これは著者」とラベルを貼る作業が、構造化データのマークアップです。

HTMLは見た目を伝えるが、意味までは伝えない

ページに「3,600」という数字が載っていたとします。

人間なら前後の文脈で価格か件数かを判断できますが、HTMLのタグが伝えているのは「これは見出し」「これは段落」という体裁の情報だけです。

構造化データは、この空白を埋める補足情報にあたります。

本文の内容を変えずに、「この数字は価格である」「この日付は更新日である」と機械が誤解しない形で示せるのが役割です。

書き方の形式は3つ、覚えるのはJSON-LDだけでよい

記述形式は3種類ありますが、GoogleはJSON-LDを推奨しています。

本文のHTMLに触れずに済むため、あとから修正や削除がしやすいという実務上の利点があります。

形式	書く場所	扱いやすさ
JSON-LD （推奨）	<script>タグの中にまとめて記述	本文と分離しているため修正しやすい
Microdata	HTMLタグの属性として本文に混ぜて記述	本文を編集するたびに崩れやすい
RDFa	同上（属性として記述）	同上

データ分野でいう「構造化データ」とは別の話

紛らわしいのですが、同じ言葉が2つの分野で使われています。

検索してたどり着いた記事が噛み合わないと感じたら、この違いが原因です。

分野	指しているもの	対になる言葉
データ活用・分析	表形式で整理されたデータ（顧客名簿・売上データなど）	非構造化データ（メール本文・画像・音声）
SEO・Web （この記事の対象）	Webページの意味を機械に伝えるマークアップ	マークアップしていない通常のHTML

構造化データはAI検索に効くのか｜公式見解と実際の使われ方

「AIに引用されるには構造化データが必須」という説明を見かけますが、Google自身はそう言っていません。

ここは誤解が多いところなので、一次情報を確認しておきます。

Google検索セントラルの「AI機能とウェブサイト」には、次のように書かれています。

追加する必要のある、特別なschema.orgの構造化データもありません。

引用元：Google 検索セントラル「AI features and your website」（原文を和訳）

AI OverviewsやAI Modeは通常の検索と同じ仕組みでページを見つけています。

つまり構造化データを入れたから引用される、という直接の経路は公表されていないと理解しておくのが正確です。

それでも実装する価値がある3つの理由

では不要かというと、そうではありません。

効く場所が「AIへの直通ルート」ではないだけで、次の3点は実装した側にしか得られない利益です。

1. リッチリザルトの対象になる：パンくず・商品・レビュー・求人などは、マークアップがないと表示条件を満たしません。検索結果での見え方が変わり、クリック率に影響します
2. 書かれている内容の裏取りになる：著者・公開日・運営会社が本文と一致した形で機械可読になっていれば、誰が書いた情報なのかを取り違えられにくくなります
3. 会社の輪郭が一貫する：社名・ロゴ・公式SNS・所在地をサイト全体で同じ値として示せます。表記ゆれが減れば、企業として同一の存在だと扱われやすくなります

3つとも「AIに媚びる施策」ではなく、情報の正確さをサイト側から担保する作業です。

AI検索への対応をどこから手をつけるかを整理したい場合は、LLMO対策の全体像と優先度の高い施策をまとめた記事も参考にしてください。

あわせて読みたい

LLMO対策とは？AIに引用される5つの施策と効果測定を解説 LLMO対策とは、ChatGPTやAI検索の回答に自社が引用されるようにする最適化です。SEO・AIO・GEOとの違い、優先度の高い5つの施策、費用と依頼先の見極め方、引用数の測り方を、Googleの公式見解と自社メディアの実測データをもとに解説します。

「引用率が◯倍」という数字は根拠を確認する

構造化データの解説記事には、引用されやすさが何倍になるといった数字が並ぶことがあります。

ただし、誰が・どのサイト群を・どの期間で測ったのかが書かれていない数字は、判断材料になりません。

構造化データは施策として地味で、単独での効果を切り出しにくい領域です。

数字を見たら調査主体と対象範囲を確認し、無ければ「そういう主張がある」程度に留めておくのが安全です。

優先順位が変わった｜FAQとHowToはリッチリザルトの対象外に

実装の順番を決める前に、押さえておくべき変更があります。

これまで定番とされてきたFAQとHowToは、現在は検索結果のリッチリザルトとして表示されません。

FAQリッチリザルトは段階的に縮小され、2026年5月7日をもって表示されなくなりました。

その後、Search Consoleの検索での見え方フィルタやリッチリザルトテストの対応も順次終了しています。

種類	現在の扱い	どうするか
FAQPage	リッチリザルトの表示は終了	新規実装の優先度は下げる。既存分は残しても問題ない
HowTo	すでに表示対象外	同上。手順の分かりやすさは本文で担保する
Article・Breadcrumb Organization	引き続き対象	最優先で整える
Product・Review Event・JobPosting など	引き続き対象	該当する事業なら実装する価値が大きい

すでに入れているFAQPageは消さなくてよい

Googleは、使われていない構造化データが検索上の問題を引き起こすことはないとしています。

そのため撤去作業に工数をかける必要はありません。

ただし、これから新規に時間を使う先としては優先度が下がりました。

同じ工数をかけるなら、次章以降で挙げる4種類を先に整える方が回収できます。

まず確認する｜自社サイトがいま出力している構造化データ

ここが実務でいちばん飛ばされる工程です。

WordPressのテーマやプラグインは、設定した覚えがなくても構造化データを自動出力していることがあります。

確認せずに手で足すと、同じ内容が二重に出たり、値の食い違う記述が並んだりします。

最初にやるのは書くことではなく、現状を見ることです。

確認に使う3つのツール

ツール	分かること	使う場面
リッチリザルトテスト	Googleのリッチリザルトの対象になるか	実装した種類が機能として有効か確かめる
スキーマ マークアップ検証ツール	出力されている構造化データの全内容と構文エラー	いま何が出ているかを一覧で把握する
Search Console （URL検査・拡張レポート）	公開後に実際に認識された内容とエラー件数	サイト全体の状況を継続して監視する

ブラウザでページを開き、ソースをld+jsonで検索するだけでも中身は読めます。

ツールに通す前に、何個のブロックが出力されているかを数えておくと、二重出力に気づきやすくなります。

実測で見つかった、よくある4つの崩れ

自社で運営するWordPressサイトの出力を実際に確認したところ、テーマが自動生成したJSON-LDに次の崩れが見つかりました。

いずれもコードの不具合ではなく、管理画面の入力欄の使い方に起因するものです。

出力されていた状態	何が起きているか	原因
英語の社名が2つの別名に分割 （alternateName）	カンマを含む社名が、別々の呼び名として扱われる	設定欄に「Sample Co., Ltd.」のようにカンマ入りで入力した
公式アカウントのURL5件が1件に （sameAs）	改行区切りの文字列が、1本のURLとして出力される	複数URLを1つの入力欄にまとめて入れた
著者名がログインID （author）	記事の書き手が人名として伝わらない	ユーザーの表示名を設定していない
画像がテーマの初期画像 （image）	記事と無関係な画像がページの代表画像になる	アイキャッチ画像を設定していない

特にsameAsと著者名は、「誰が運営している会社なのか」を機械に伝える中心の項目です。

ここが壊れたまま新しい構造化データを足しても、土台が抜けている状態は変わりません。

自社がAIにどう認識されているかを先に確かめたい場合は、無料のAI引用診断で7つのAIにおける現在の引用数を実測してお渡ししています。

技術対応の前後で数字を比べられる状態にしておくと、施策の判断がしやすくなります。

優先度が高い4種類の書き方【JSON-LDテンプレート】

コーポレートサイトやオウンドメディアで最初に整えるのは、次の4種類です。

会社を示すもの2つと、ページを示すもの2つと考えると分かりやすくなります。

種類	伝える内容	設置するページ
Organization	社名・ロゴ・公式アカウント・問い合わせ先	全ページ（サイト共通）
WebSite	サイト名と運営者の紐づけ	全ページ（サイト共通）
Article	記事タイトル・著者・公開日・更新日	記事・コラム
BreadcrumbList	階層構造（ホーム＞カテゴリー＞記事）	下層ページ全般

OrganizationとWebSite（サイト共通で1つ）

会社の情報は全ページで同じ値になるため、まとめて1つの@graphに入れます。

@idを付けておくと、記事側から参照して同じ会社だと示せます。

<script type="application/ld+json">
{
  "@context": "https://schema.org",
  "@graph": [
    {
      "@type": "Organization",
      "@id": "https://example.com/#organization",
      "name": "株式会社サンプル",
      "alternateName": "Sample Inc.",
      "url": "https://example.com/",
      "logo": {
        "@type": "ImageObject",
        "url": "https://example.com/logo.png",
        "width": 512,
        "height": 512
      },
      "sameAs": [
        "https://x.com/example",
        "https://www.youtube.com/@example",
        "https://www.wantedly.com/companies/example"
      ],
      "contactPoint": {
        "@type": "ContactPoint",
        "contactType": "customer support",
        "url": "https://example.com/contact/"
      }
    },
    {
      "@type": "WebSite",
      "@id": "https://example.com/#website",
      "url": "https://example.com/",
      "name": "株式会社サンプル",
      "publisher": { "@id": "https://example.com/#organization" }
    }
  ]
}
</script>

sameAsには、自社が運営していると確認できるアカウントだけを配列で並べます。

公式SNSのほか、法人番号公表サイトや登録している公的データベースのページも有効です。

ArticleとBreadcrumbList（記事ページごと）

記事側では、書き手と日付、そしてサイト内での位置を示します。

パンくずリストは検索結果に表示されるパスの元になるため、階層のあるサイトでは必ず入れておきたい種類です。

<script type="application/ld+json">
{
  "@context": "https://schema.org",
  "@graph": [
    {
      "@type": "Article",
      "mainEntityOfPage": {
        "@type": "WebPage",
        "@id": "https://example.com/column/sample/"
      },
      "headline": "記事タイトル（ページのh1と同じ文言にする）",
      "image": ["https://example.com/uploads/sample.jpg"],
      "datePublished": "2026-04-01T09:00:00+09:00",
      "dateModified": "2026-07-20T15:30:00+09:00",
      "author": {
        "@type": "Person",
        "name": "山田 太郎",
        "url": "https://example.com/author/yamada/"
      },
      "publisher": { "@id": "https://example.com/#organization" }
    },
    {
      "@type": "BreadcrumbList",
      "itemListElement": [
        { "@type": "ListItem", "position": 1, "name": "ホーム", "item": "https://example.com/" },
        { "@type": "ListItem", "position": 2, "name": "コラム", "item": "https://example.com/column/" },
        { "@type": "ListItem", "position": 3, "name": "記事タイトル" }
      ]
    }
  ]
}
</script>

パンくずの最後の項目にはitemを付けません。

現在地そのものなので、リンク先を指定する必要がないためです。

書くときに守る3つのルール

• ページに表示されている内容と一致させる：本文に出ていない情報を構造化データにだけ書くのはガイドライン違反です
• 存在しない値を埋めない：著者名やレビュー評価を、実体がないまま形式的に入れないでください
• 1ページに同じ種類を重複させない：テーマ・プラグイン・手書きが競合すると、どの値が正か判断できなくなります

Googleは、構造化データを置くためだけの空のページを作らないことも明記しています。

構造化データはコンテンツの説明であって、コンテンツの代わりにはならないという前提を外さないでください。

WordPressでの設定方法｜プラグインを入れる前に確認する

WordPressの場合、すでに大部分が出力済みというのがよくある状況です。

プラグインを追加する前に、テーマの出力を確認してください。

テーマが自動出力している範囲を実測する

自社サイトで使っているテーマの出力を確認したところ、記事ページでは次の種類が自動で出ていました。

手を加えなくても、必要なものはひととおり揃っている状態です。

ページ	自動出力されていた種類	自分で足すもの
トップページ	Organization／WebSite／SearchAction	基本的に不要
記事ページ	Organization／WebSite／WebPage／Article／BreadcrumbList	基本的に不要
サービスページ	同上	該当する事業ならService・Productなど

この場合にやることは、新しく書くことではありません。

テーマの設定画面で社名・ロゴ・SNSのURL・著者の表示名を正しく入れ直すことが、そのまま構造化データの修正になります。

プラグインを足すときは二重出力に注意する

SEO系プラグインの多くは、有効化するだけで独自の構造化データを出力します。

テーマと機能が重なると、同じページにArticleが2つ、Organizationが2つという状態になりかねません。

• プラグイン側に構造化データの出力をオフにする設定があるか確認する
• テーマ側とプラグイン側のどちらを正にするか先に決める
• 有効化した直後に検証ツールへ通し、ブロック数が増えていないか見る

手動で追加する場合の置き場所

テーマが対応していない種類を足すときは、子テーマのfunctions.phpからwp_headで出力するのが基本です。

コードを触りたくない場合は、ヘッダーにスクリプトを差し込めるプラグインでも代用できます。

記事本文にカスタムHTMLとして貼る方法は、編集のたびに壊れるリスクがあるため避けてください。

AIにサイトの要点を伝える別の手段を検討している場合は、llms.txtの書き方と設置手順を解説した記事で効果の実際も含めて整理しています。

あわせて読みたい

llms.txtとは？書き方・設置手順と効果の実データを解説 llms.txtとは、AIにサイトの要点を伝えるためのテキストファイルです。読み方や基本の書き方、ルートディレクトリへの設置手順、WordPressでの作り方に加え、13万ドメインの調査データから見た実際の効果と設置すべきかの判断基準まで解説します。

エラーが出たときの直し方

Search Consoleから「構文にエラーがある構造化データが検出されました」と通知が届くことがあります。

まず確認するのは、エラーなのか警告なのかです。

種別	意味	対応
エラー	必須項目が欠けており、機能の対象にならない	優先して直す
警告	推奨項目が欠けているが、対象にはなる	余力があれば埋める

よくある3つの原因

1. 必須項目の欠落：Articleのheadlineや画像が空になっている。多くはアイキャッチ未設定が原因です
2. 値の型の間違い：配列で書くべき項目を1つの文字列で入れている。sameAsで頻発します
3. 表示内容との不一致：ページに存在しない情報を書いている。手書きのコードを使い回すと起きます

直したあとは、Search ConsoleのURL検査で再クロールを申請します。

反映には時間差があるため、検証ツールで正しく直っていることを先に確認してから申請してください。

構造化データに関するよくある質問

まとめ：足す前に、いま出ているものを確認する

構造化データの実装でつまずく原因は、書き方が難しいことではありません。

現状を見ないまま足してしまい、何が正しい値なのか分からなくなることです。

• 構造化データはページの意味を機械に伝える記述で、形式はJSON-LDだけ覚えればよい
• GoogleはAI機能のために特別なマークアップは不要としており、効くのは正確さの担保という側面
• FAQとHowToはリッチリザルトの対象外になり、優先すべき種類が入れ替わった
• まず検証ツールでいま出力されている内容を確認する。多くはテーマが出力済み
• 整えるのはOrganization・WebSite・Article・BreadcrumbListの4種類から

作業量としては、初回の確認に30分、修正に1時間ほどの話です。

自社サイトのソースを開いて、ld+jsonで検索してみる。

ここから始めてください。