「構造化データを入れたらSEOに効くって聞いたけど、本当に順位は上がるの？」
サイトの相談を受けていると、ときどき出る質問。制作会社の提案書に「構造化マークアップ対応」と書かれていて、何のお金なのか分からない、という形で聞かれることもあります。
分からなくて当然だと思います。構造化データは画面に何も出ないコードで、しかもGoogleの扱いがここ3年で大きく入れ替わった。
この記事は2025年3月に書いたものを2026年9月に全面的に書き直した版。当時の版には、いまは表示されないFAQやHowToを「ほぼすべてのサイトで有効」と書いていた箇所や、出どころを確かめられない数字が入っていました。事実はGoogle検索セントラルの公式ドキュメントで確かめ直し、出典を本文に置いています。
構造化データ（構造化マークアップ）とは、ページの中身をGoogleに説明するための書き方
構造化データは、ページに書いてあることが「何なのか」を決まった形式で書き添えたもの。
人が商品ページを見れば、どれが商品名でどれが価格かはすぐ分かる。検索エンジンにとっては文字の並びでしかないので、この文字列は商品名、この数字は税込価格、これは在庫あり、とラベルを付けてあげる。Googleのドキュメントでは、料理のページで材料や調理時間、カロリーを示す例が使われています（出典はGoogle 検索セントラル「構造化データの仕組みについて」）。
ラベルの語彙は、schema.org という共通の辞書から取ります。Product（商品）、LocalBusiness（店舗）、JobPosting（求人）といった型が並んでいる辞書。
「構造化データ」と「構造化マークアップ」の違いを聞かれることもあります。実務ではほぼ同じ意味で使われていて、前者は書き添える情報そのもの、後者はそれをHTMLに書き込む作業を指すことが多い、くらいの差です。
どちらで呼んでも話は通じる。
構造化データのSEO効果は、順位ではなく検索結果での見え方に出る
期待していた人には残念な話かもしれません。
Googleのドキュメントが構造化データの役目として書いているのは2つです。ページの内容を理解する手がかりにすること。そして、検索結果をより目を引く形で表示するリッチリザルトの対象にすること。順位を押し上げる仕組みとしては書かれていません。
2025年6月に一部の構造化データの表示を終えたときも、Googleは「この更新がページの順位に影響することはない」と明記しています（出典はGoogle 検索セントラル ブログ「Simplifying the search results page」）。構造化データに問題があって手動による対策を受けた場合でも、失うのはリッチリザルトの資格で、ウェブ検索での順位には影響しないとされています（出典は構造化データに関する一般的なガイドライン）。
効果が出る場所は、検索結果の見た目です。
商品なら価格や在庫、評価の星。料理なら写真と調理時間。求人なら勤務地や給与。こうした情報が普通の青いリンクより多く並ぶことで、クリックされやすくなる、という筋道。
レシピや求人のような特殊な検索結果には、構造化データが入口になる
Googleの検索結果には、ただのリンク一覧とは違う枠があります。求人を探す人向けの一覧、イベントの一覧、料理のカルーセル（横に並ぶカード）などです。
こうした特殊な検索結果に載るには、それぞれの種類の構造化データを、必須の項目をそろえて書く必要があります。ガイドラインには、必須のプロパティ（項目）が欠けているものはリッチリザルトの対象にならない、とはっきり書かれている。構造化データの実用的な使いどころは、ほぼここに集まっています。
もう1つ覚えておきたいのは、正しく書いても表示が約束されるわけではないこと。Googleは、リッチリザルト テストで問題がなくても表示は保証しないと書いていて、検索する人の履歴や場所、端末によって、普通のテキストの結果のほうがよいと判断することもあるとしています。
Googleが載せている事例の数字は、どう読むか
Googleの入門ページには、構造化データを入れたサイトの事例が載っています。Rotten Tomatoes は構造化データを入れたページのクリック率が入れていないページより25%高かった、Nestlé はリッチリザルトとして表示されたページのクリック率が82%高かった、という数字です（出典は先ほどの構造化データの仕組みについて）。
出典のはっきりした数字なので引いておきます。ただ、どれも大手サイトの事例で、いつ測ったものかは書かれていません。自分のサイトでも同じだけ伸びると読むのは無理がある。私は「リッチリザルトが出ればクリックされやすくなる、とGoogle自身が示している」という向きの話として受け取っています。
AI検索のために特別な構造化データは要らない
最近はこちらを聞かれることのほうが増えました。AI Overviews（Google検索の上に出るAIの回答）やAIモードに載るには、構造化データが必要なのか。
Googleの答えは、要らない、です。AI機能に表示されるために新しいマークアップや特別なschema.orgの構造化データを追加する必要はない、とAI機能のページに書かれています（出典はGoogle 検索セントラル「AI 機能とウェブサイト」）。2026年に出た生成AI向けのガイドでも、構造化データに力を入れすぎることは誤解の1つとして挙げられ、リッチリザルトの対象になるためにSEOの一部として使い続けるのはよい、という書き方になっています（出典はAI optimization guide）。
AIに引用されるかを自分のサイトで測った話は、LLMOとは｜AIに自社が引用されるか20問で実測した記録にまとめています。
2023年から2026年に、FAQやHowToのリッチリザルトは表示が終わった
旧版で直す必要が大きかったのはここ。
構造化データの解説記事には、いまでも「FAQPageを入れると検索結果に質問と回答が展開される」と書いてあるものが残っています。私の旧版もそうだった。Googleの発表を時系列に並べると、こうなります。
| 時期 | 変わったこと |
|---|---|
| 2023年8月 | FAQのリッチリザルトが、よく知られた権威ある政府・医療のサイトだけに限られる。HowToはパソコンだけに |
| 2023年9月 | HowToのリッチリザルトがパソコンでも出なくなり、廃止 |
| 2024年11月 | サイトリンク検索ボックス（検索結果の中のサイト内検索窓）の表示を終了 |
| 2025年1月 | スマホの検索結果でパンくずの表示をやめ、ドメインだけに。パソコンでは残る |
| 2025年6月 | Course Info、ClaimReview、Estimated Salary、Learning Video、Special Announcement、Vehicle Listing の表示終了を告知 |
| 2025年11月 | 練習問題（Practice problem）の表示を終了。Dataset はGoogle検索ではなくDataset Search専用と明記 |
| 2026年5月7日 | FAQのリッチリザルトがGoogle検索に表示されなくなる。6月に説明ページも削除 |
出典は、HowTo と FAQ のリッチリザルトの変更（2023年8月）、サイトリンク検索ボックスの終了（2024年10月）、モバイルのパンくずの変更（2025年1月）、検索結果の簡素化（2025年6月）、それと2025年11月と2026年5月・6月の分はGoogle 検索のドキュメント更新履歴です。2025年6月の告知では当初 Book Actions も対象でしたが、2025年11月の更新履歴で、まだこのマークアップを使う機能があるとして廃止の告知が外されています。
流れは一方向。Googleは検索結果を簡素にする方針をはっきり出していて、使われる場面の少ない表示から順に減らしている。
では、もう入っているFAQPageはどうするか。
Googleは2023年の発表で、FAQの構造化データは消してもよいが、急いで消す必要はないと書いています。サイトリンク検索ボックスのときも、サポートされなくなった構造化データが検索で問題を起こすことはなく、Search Consoleのレポートでエラーにもならない、と説明していました。
放っておいても害はない。ただ、FAQの表示を狙って新しく入れる理由は、Google検索に関してはもうありません。
2026年9月時点でGoogleが対応している構造化データの種類
いま使える種類は、Googleの検索ギャラリー（Google 検索がサポートする構造化データ マークアップ）に載っています。2026年9月に確かめたとき、最終更新は2026年6月15日で、並んでいたのは次の種類でした。
- 記事（Article）、パンくず（Breadcrumb）、カルーセル
- 商品（Product）、レビュー スニペット、ソフトウェア アプリ、宿泊施設（Vacation rental）
- ローカル ビジネス（LocalBusiness）、組織（Organization）、プロフィール ページ
- 求人情報（Job posting）、雇用主の総合評価
- イベント（Event）、映画、動画（Video）、画像のメタデータ
- 料理（Recipe）、Q&A、ディスカッション フォーラム
- コース リスト、教育 Q&A、数式ソルバー、データセット
- 読み上げ（Speakable）、有料コンテンツ（Subscription and paywalled content）
FAQとHowToの名前は、もうこの一覧にない。
schema.org には何百もの型がありますが、Google検索の見た目に関わるのはこの中にあるものだけです。一覧にない型を書いても違反にはならないものの、Google検索での見た目は変わらない。優先順位は、この一覧と自分のページの種類を突き合わせて決める。
サイトの種類ごとに、まず入れるもの
| サイト | まず入れる | あれば足す |
|---|---|---|
| ネットショップ | 商品（Product） | パンくず、組織 |
| 店舗・クリニック | ローカル ビジネス | 組織、パンくず |
| 会社のサイト | 組織（Organization） | パンくず |
| ブログ・メディア | 記事（Article） | パンくず、動画 |
| 求人ページ | 求人情報（JobPosting） | 組織 |
| イベントの告知 | イベント（Event） | 組織 |
ネットショップの場合、商品の構造化データには価格や在庫のほか、送料や返品の条件も書けます。Shopifyの送料設定を整えたときに、配送ポリシーと商品ページと構造化データの金額をそろえた話をShopifyの送料設定に書きました。数字が食い違うと、どれが正しいのか分からなくなる。
求人は、構造化データが結果に直結しやすい分野です。求人ページそのものの作り方は採用LPの作り方で扱っています。
このブログが出している構造化データと、FAQPageを残している理由
実物を見たほうが早いので、このブログの記事ページが出している構造化データを確かめました。2026年9月28日に、公開中の記事の1つを curl（ページのHTMLをそのまま取得するコマンド）で取り、application/ld+json の中身を抜き出しています。
出ていたのは次の5つ。
| 型 | 中身 |
|---|---|
| Organization | 屋号、連絡先、提供しているサービス。同名のソフトとは別の事業者だという説明文 |
| WebSite | サイト名と、ブログ内検索の SearchAction |
| BlogPosting | 記事のタイトル、説明、公開日、更新日、著者、カテゴリー |
| FAQPage | 記事の frontmatter に書いた質問と答え |
| BreadcrumbList | ホーム、ブログ、カテゴリー、記事のパンくず |
記事の部分は、Next.js のページのコードで次のように組み立てています（抜粋）。
const articleJsonLd = {
'@context': 'https://schema.org',
'@type': 'BlogPosting',
headline: frontmatter.title,
datePublished: iso,
dateModified: modifiedIso,
author: { '@id': SCHEMA_IDS.person },
publisher: { '@id': SCHEMA_IDS.organization },
}
著者と発行元を名前で書かず @id で参照しているのは、トップページの人物・組織と同じ実体だと機械に伝えるためです。表記が「あおい」と「Stellarium」で揺れても、別人として扱われないようにしています。
見直してみると、Google検索の見た目に効かなくなったものが2つ混ざっていました。
1つは WebSite の SearchAction。サイトリンク検索ボックスのための記述で、この表示は2024年11月に終わっています。もう1つがFAQPage。この記事にも frontmatter に質問を3つ書いてあり、FAQPage として出力されますが、2026年5月以降、Google検索にFAQの枠は出ません。
それでも両方とも消していません。
理由は、Googleが消す必要はないと書いていて、残しても検索で問題は起きないからです。FAQPageの質問と答えは、記事の末尾に同じ内容を見える形で載せているので、ページに見えない情報をマークアップしてはいけないというガイドラインにも反しない。WebSite の構造化データ自体は、サイト名の表示に使うものとして引き続きサポートされています。
逆に言うと、残しているのは「害がなく、消す手間に見合う得もない」からで、効果を期待しているからではない。Google以外の検索エンジンやAIのサービスがFAQPageをどう使っているかは、私はまだ確かめられていないので、ここでは書きません。
正直に言うと、このブログを作ったときはFAQPageに期待していました。ページのコードにも「AI検索はQ&A形式を引用しやすい」という趣旨のコメントが残っています。いまのGoogleのドキュメントを読む限り、その期待はGoogle検索については根拠がない、というのが今回確かめた結果です。
JSON-LDで書き、見えている内容と一致させる
書き方は3つ。
JSON-LD、Microdata、RDFa。GoogleはどれもサポートしていますがJSON-LDを推奨していて、ガイドラインにも「JSON-LD（推奨）」と書かれています。HTMLのタグに属性を埋め込むほかの2つと違い、<script type="application/ld+json"> のかたまりを1つ置くだけなので、デザインを触らずに足したり直したりできる。新しく入れるならJSON-LD一択です。
WordPressやShopifyのようなCMSを使っているなら、自分でコードを書かずに済むこともあります。Googleの入門ページでも、CMSの設定画面やプラグインで構造化データを指定できる場合がある、と案内されています。まずは今のサイトがすでに何を出しているかを確かめるのが先。
書くときのルールは、ガイドラインから押さえておきたいものが4つあります。
- ページで見えていない内容をマークアップしない。JSON-LDに書いた価格や評価は、本文にも同じものが出ている必要がある
- ページの主な内容を表していない構造化データや、誤解を招くものを書かない（作ったレビューはもちろん、関係のない型を貼るのも含む）
- 種類ごとの必須プロパティをそろえる。欠けているとリッチリザルトの対象にならない
- robots.txt や noindex で、構造化データのあるページをGooglebotから隠さない
推奨プロパティは多いほどよい、とは限らない。Googleは、推奨プロパティを全部埋めようとして不完全なデータを入れるより、数は少なくても正確で完全なものを出すほうが大事だと書いています。
旧版には「関係のない構造化データを詰め込むとページの表示が遅くなる」とも書いていましたが、根拠を確かめられなかったので消しました。ページの速さを気にするなら、見るべきは構造化データより画像やスクリプト。広告の着地ページで速度を測った話は広告のLPが遅いと広告費が上がるに書いています。
確認はリッチリザルト テストとスキーマ マークアップ検証ツールで
旧版で「Google構造化データテストツールで検証する」と書いていたところも古くなっていました。
そのツールは、2020年12月の発表でGoogle検索向けのチェックをやめてschema.orgの側へ移すことが決まり、2021年に「スキーマ マークアップ検証ツール（Schema Markup Validator）」として独立しています（出典はAn update on the Structured Data Testing Tool）。いま使い分けるのは次の3つです。
| 道具 | 確かめること |
|---|---|
| リッチリザルト テスト | Google検索のリッチリザルトの対象になるか、エラーや警告がないか |
| スキーマ マークアップ検証ツール | schema.org の書き方として正しいか。Googleが使わない型も確かめられる |
| Search Console | 公開後に、サイト全体でエラーが出ていないか。URL 検査で最新の状態も見られる |
流れは、作っている途中にリッチリザルト テストで1ページずつ確かめ、公開後はSearch Consoleのレポートで見張る。Googleの入門ページも、テンプレートや配信の問題で公開後に壊れることがあるから、公開後もレポートで監視するように書いています。
リッチリザルト テストに出てこない項目を書いていても、それ自体は問題ありません。Google検索の見た目に関係しない型や項目は、テストの結果に表示されないだけ。型ごとの書き方の正しさは、スキーマ マークアップ検証ツールのほうで確かめます。
CONTACT
構造化データ、何が出ているか見てみませんか
いまのサイトがどんな構造化データを出しているか、Googleの対応表と照らして、足すもの・直すもの・放っておいてよいものを分けてお伝えします。
ご相談は無料です。そのまま依頼しなくても大丈夫です。
構造化データで、最初にやること
順番をつけるなら、こう。
- 自分のサイトの主なページが何か（商品、店舗、求人、記事など）を決める
- Googleの検索ギャラリーで、その種類がいまも載っているかを確かめる
- 今のサイトがすでに出している構造化データを、リッチリザルト テストで見る
- 足りない種類をJSON-LDで足し、必須プロパティをそろえる
- 公開後はSearch Consoleでエラーが出ていないか見る
入っているFAQPageやHowToを急いで外す必要はありません。新しく作る必要もない。
構造化データは、正しく書いても順位が上がるわけではない地味な作業です。そのかわり、商品や求人のようにGoogleが専用の見せ方を用意している分野では、入れていないと候補にすら入れない。自分のサイトがその分野かどうかを先に見極めるのが、手間の少ない進め方だと思っています。構造化データはSEOの内部対策の一部で、制作会社の「SEO対策込み」に入っていないことも多い作業です。発注先にどこまで頼めるかの確かめ方は、SEOの内部対策と外部対策にまとめました。
- 構造化データを入れると検索順位は上がりますか？
- Googleのドキュメントは、構造化データをページの内容を理解するための手がかりであり、リッチリザルト（検索結果の拡張表示）の対象になるための条件として説明しています。2025年に一部の構造化データの表示を終えたときも、Googleは順位には影響しないと書いています。順位を上げる施策ではなく、検索結果での見え方を変える施策と考えるのが正確です。
- FAQの構造化データ（FAQPage）はまだ意味がありますか？
- Google検索では、FAQのリッチリザルトは2023年8月に政府・医療の権威あるサイトに限定され、2026年5月7日からは表示されなくなりました。Googleは使われなくなった構造化データを急いで消す必要はなく、残しても検索で問題は起きないとしていますが、FAQの表示を目的に新しく入れる理由はなくなっています。
- 構造化データの確認にはどのツールを使えばいいですか？
- Google検索のリッチリザルトの対象になるかはGoogleの「リッチリザルト テスト」で、schema.orgの書き方として正しいかは「スキーマ マークアップ検証ツール」で確かめます。以前の「構造化データ テストツール」は2021年に役目を終え、検証ツールはschema.orgの側に移りました。公開後はSearch Consoleのレポートで状態を見ます。
関連記事
SEO対策XMLサイトマップの作り方とSEO｜料金ページがGoogleに見つけてもらえていなかった実例と直し方
XMLサイトマップ（sitemap.xml）は、Googleに「このサイトにはこのURLがあります」と渡す一覧です。自社サイトで料金ページがサイトマップから漏れ、Googleに知られていなかった実例をもとに、作り方（WordPress・手書き・Next.js）、入れるURLと外すURL、lastmodの扱い、サーチコンソールでの登録と確認方法、BingのIndexNowまでまとめました。
SEO対策SEO対策の費用相場｜外注するといくら？月額の中身と、記事だけの見積もりとの違い
SEO対策を外注したときの費用相場を、公開されている調査から確かめました。月額固定・成果報酬・スポットの料金の違い、記事だけの見積もりと内部から見る見積もりの差、自社サイトで料金ページがGoogleに見つけてもらえていなかった実例、見積もりを比べるときの質問をまとめています。
SEO対策SEOの内部対策と外部対策とは｜「SEO対応済み」の中身を発注前に見分ける方法
SEOの内部対策はサイトの中を直すエンジニア寄りの仕事、外部対策はサイトの外で名前とリンクを集める企画・広報寄りの仕事です。両方を分かる人が少ない理由、相談されたサイトで見たh1が3つ・構造化データゼロの実例、外部リンクの今のルール、自社サイトの実測、発注前に聞く質問をまとめました。