構造化データは、記事・商品・店舗・イベントなど、ページにある情報の種類や意味を検索エンジンへ伝えやすくするための記述です。SEOでは、Googleがページ内容を理解する手がかりになり、対応する検索機能で情報が豊富に表示される対象になる可能性があります。
ただし、構造化データだけで順位や表示は保証されません。実装の目的は検索結果を装飾することではなく、ページで実際に提供している情報を、検索エンジンにも正確に伝えることです。
新規に設定する場合は、一般にJSON-LDを選びます。ページ本文と構造化データを一致させ、公開前にリッチリザルト テストで確認し、公開後はGoogle Search Consoleで継続的に状態を確認することが基本です。
構造化データとは？SEOでの役割と先に知っておきたい結論
構造化データとは、Webページ上の情報を「これは記事」「これは商品の価格」「これは店舗の住所」のように、意味が分かる形式で記述するデータです。人間向けに表示するHTML本文を補い、検索エンジンがページを解釈しやすくする役割を持ちます。
Googleは構造化データをページ理解の手がかりとして利用し、要件を満たす場合には、検索結果で通常より多くの情報を表示することがあります。たとえば商品ページの価格や在庫状況、レシピページの調理時間、パンくずリストのサイト階層などが検索結果に反映される可能性があります。
一方で、構造化データは検索順位を直接上げるためのタグではありません。Googleの要件に沿って記述しても、検索語句、端末、地域、検索結果全体の構成などを踏まえてGoogleが表示を判断するため、リッチリザルトになるとは限りません。
出典：Google Search Central「Introduction to structured data markup in Google Search」
出典：Google Search Central「General Structured Data Guidelines」
構造化データ・schema.org・リッチリザルトの関係
schema.orgは構造化データで使う語彙の標準です。たとえば、記事を表すArticle、商品を表すProduct、組織を表すOrganizationなどのタイプや、名前・価格・住所といった項目名を定義しています。
構造化データは、schema.orgなどの語彙を使ってページに記述するデータそのものです。リッチリザルトは、構造化データを含むさまざまな情報をGoogleが利用し、検索結果で通常より情報を充実させて表示する形式を指します。
つまり、「schema.orgを記述した」ことと「Google検索で特別な表示が出る」ことは同じではありません。schema.orgにはGoogle検索のリッチリザルトの対象ではないタイプやプロパティもあります。Google検索での扱いを判断する際は、schema.orgの定義だけでなく、Google Search Centralの機能別ガイドを確認してください。
構造化データで対応し得るGoogle検索機能
構造化データは、すべてのページに同じものを入れる施策ではありません。ページの主目的に合うタイプを選ぶことが基本です。記事には記事、購入できる商品詳細ページには商品、実店舗の案内ページにはローカルビジネスといったように、実在するコンテンツに対応する情報だけを記述します。
Googleが対応を案内している構造化データには、記事、パンくずリスト、商品、イベント、求人、レシピ、動画、組織、ローカルビジネスなどがあります。ただし、対応機能、必要なプロパティ、対象地域や言語は変更されることがあります。実装前には検索ギャラリーと各機能の公式要件を確認しましょう。
出典：Google Search Central「Structured Data Markup that Google Search Supports」
記事・商品・パンくずリストなど汎用性が高いタイプ
多くのWebサイトで検討しやすいのが、Article、Product、BreadcrumbListです。ただし、採用の可否はページ内容と更新体制に応じて決めます。
| タイプ | 主な対象ページ | 記述を検討する主な情報 |
|---|---|---|
| Article | ブログ記事、ニュース、解説記事 | 見出し、画像、公開日、更新日、著者 |
| Product | 商品詳細ページ、商品レビュー記事 | 商品名、画像、価格、在庫、評価、配送・返品情報など |
| BreadcrumbList | 階層構造があるサイトの各ページ | ユーザーがたどる自然なカテゴリー階層 |
Articleは、記事の見出し、著者、公開日・更新日などをGoogleへ伝える補助になります。著者や更新日を記述するなら、読者もページ上で確認でき、実態と一致していることが重要です。
ECサイトではProductが有用になり得ます。価格や在庫のように変動する情報は、ページ表示と構造化データの不一致が起きないように更新の仕組みを整える必要があります。レビュー評価を記述する場合も、実在するレビューに基づく情報だけを扱います。
パンくずリストは、URLの文字列をそのまま並べるものではありません。ユーザーがサイト内の位置を理解し、移動しやすい自然な階層を表現します。Googleも、URL構造を単に写すより、典型的なユーザー経路を表すパンくずを案内しています。
出典：Google Search Central「Article structured data」
出典：Google Search Central「Introduction to Product structured data」
出典：Google Search Central「Breadcrumb structured data」
イベント・求人・レシピ・動画・組織・店舗情報のタイプ
イベント開催ページにはEvent、求人詳細ページにはJobPosting、レシピページにはRecipe、動画が主コンテンツのページにはVideoObjectを検討できます。これらは、対象コンテンツが実際に存在するページにのみ使うものです。
イベントでは開催日時・場所・参加条件、求人では職種・雇用形態・勤務地・応募期限など、利用者の判断に直結する情報の正確性が重要です。終了したイベントや募集終了の求人を公開し続ける場合は、ページ本文だけでなく構造化データも見直してください。
企業サイトのトップページや会社案内ページではOrganization、実店舗や地域に根ざした事業の案内では、より具体的なLocalBusinessを検討できます。組織名、公式URL、電話番号、住所などは、ユーザーにとって有用で実態に合う情報を設定します。
出典：Google Search Central「Organization structured data」
FAQやHowToは検索表示を目的に新規実装しない
FAQとHowToは過去の記事の情報を鵜呑みにしないでください。Googleは2023年にFAQリッチリザルトの表示対象を大幅に限定し、政府・健康分野で著名かつ権威性のあるサイトを主な対象とする方針を案内しました。一般的な企業サイトやブログが、FAQ表示を期待してFAQPageを追加しても、検索結果に表示される可能性は限定的です。
HowToリッチリザルトは、Google検索のデスクトップおよびモバイルで表示されなくなりました。FAQコンテンツや手順解説そのものは、読者の疑問を解消するために有益です。しかし、検索結果の表示枠を狙って質問・手順を水増ししたり、ページに表示していない回答を構造化データだけに書いたりする運用は避けるべきです。
出典：Google Search Central Blog「Changes to HowTo and FAQ rich results」
設定形式はJSON-LDが基本｜microdata・RDFaとの違い
新規に構造化データを実装するなら、原則としてJSON-LDを第一候補にします。GoogleはJSON-LD、microdata、RDFaの3形式をサポートしています。JSON-LDはHTML本文の要素へ細かな属性を加えずに記述でき、実装や保守の負担を抑えやすいためです。
ただし、既存のmicrodataやRDFaが適切に実装され、運用できているサイトで、形式を変えること自体が目的になるわけではありません。変更時には重複出力や情報欠落のリスクがあるため、既存実装と保守体制を見て判断しましょう。
出典：Google Search Central「Introduction to structured data markup in Google Search」
JSON-LD・microdata・RDFaの比較と選び方
3形式の主な違いは、構造化データをどこに書くかです。
| 形式 | 主な記述場所 | 特徴 | 向いているケース |
|---|---|---|---|
| JSON-LD | scriptタグ内 |
HTML本文と分離しやすく、階層的なデータを管理しやすい | 新規実装、CMS・テンプレートでの一元管理 |
| microdata | HTML要素の属性 | 表示中のHTMLと情報を対応付けやすい | 既存テンプレートに実装済みの場合 |
| RDFa | HTML要素の属性 | リンクトデータ向けの拡張を利用できる | RDFaを前提とする既存サイト |
JSON-LDでは、application/ld+json形式のスクリプトとしてデータを記述します。商品情報や住所のように入れ子が多いデータでも、HTMLの見た目を崩さずに管理しやすい点が利点です。
一方、テーマ機能がmicrodataを出力し、SEOプラグインがJSON-LDを出力するなど、複数形式が同じ情報を別々に出すと値の不一致や重複が起こることがあります。形式の違いよりも、同じページの主情報を一貫して正確に伝えられるかを優先してください。
構造化データを設定する手順
構造化データはコードを追加して終わりではありません。ページ内容の整理から公開後の監視までが1セットです。検索結果で見せたい項目から逆算するのではなく、まずページがユーザーに提供している情報を整えます。
1. 対象ページと実在情報を整理する
最初に、そのページの主目的を確認します。解説記事ならArticle、商品詳細ならProduct、店舗案内ならLocalBusinessというように、主コンテンツを最も正確に表すタイプを選びます。
次に、構造化データに含める情報を読者もページ上で確認できるか点検してください。商品価格、在庫、評価、イベント日時、営業時間、著者名などは、構造化データだけに存在してはいけません。ページ表示・管理画面・構造化データの内容がずれない運用を決めることが重要です。
2. 機能別要件を確認して記述する
Google検索の対応機能を利用したい場合は、Google Search Centralの機能別ページで必須・推奨プロパティを確認します。そのうえで、必要な項目だけを正確に記述してください。推奨項目を埋めるために、曖昧な値や仮の値を入れてはいけません。
たとえば商品であれば、商品名、画像、価格、通貨、在庫状況などを実際の販売情報に合わせます。記事なら、ページに表示している見出し、著者、公開日、更新日、画像などを整合させます。複数の構造化データを置く場合も、ページの中心がレシピならRecipeのように、主目的を表すタイプを欠かさないようにしましょう。
出典：Google Search Central「General Structured Data Guidelines」
3. テスト後に公開し、Search Consoleで継続確認する
公開前には、リッチリザルト テストでGoogleが対応する構造化データとして読み取れるかを確認します。テストは、構文エラーだけでなく、Google検索向けの必須項目や重大な問題を把握する際に役立ちます。
公開後はURL検査ツールでGoogleがページを取得できる状態かを確認し、該当するSearch Consoleの拡張レポートを監視します。テンプレート、プラグイン、商品情報の一括更新などにより、以前は正常だった構造化データが壊れることもあります。
schema.org全般の構文確認にはSchema Markup Validatorを利用できます。ただし、Google検索の機能要件を確認する用途では、リッチリザルト テストを優先してください。
出典：Schema.org「Schema Markup Validator」
WordPressで構造化データを設定する方法
WordPressでは、SEOプラグイン、構造化データ専用プラグイン、テーマの標準機能、手動でのJSON-LD追加が主な方法です。どの機能が何を出力するか管理できる方法を選びます。
記事とパンくずリスト程度であれば、テーマまたはSEOプラグインの標準機能で足りる場合があります。一方、独自性の高い商品情報、イベント情報、複雑な組織情報を扱う場合は、専用プラグインや開発者による手動実装が必要になることもあります。
SEOプラグイン・専用プラグイン・テーマ機能を使う場合
プラグインを使う利点は、著者、画像、商品情報、パンくずリストなどを管理画面から入力・連携しやすいことです。しかし、プラグインを有効化しただけで、すべてのページに適切な構造化データが出力されるとは限りません。
特に注意したいのは、テーマ、SEOプラグイン、ECプラグイン、構造化データ専用プラグインが、同じページに同種のデータを出力するケースです。ArticleやBreadcrumbListが複数出力され、著者名やURLが食い違うことがあります。設定画面だけで判断せず、ページソースとリッチリザルト テストで実際の出力を確認してください。
JSON-LDを手動で追加する場合
独自のコンテンツタイプを扱う場合や、出力項目を細かく制御したい場合は、テーマのテンプレートやカスタムプラグインでJSON-LDを追加する方法があります。投稿情報や商品情報からJSON-LDを自動生成する設計にすれば、手入力による更新漏れを減らせます。
ただし、手動実装では本文の修正後に構造化データだけが古いまま残る問題が起きがちです。価格・在庫・日付・営業時間など変動する情報は、できるだけ同じデータ元から本文とJSON-LDを出力する設計が望まれます。JavaScriptで動的に出力する場合も、Googleがレンダリング後に情報を確認できるかテストしてください。
出典：Google Search Central「Generate Structured Data with JavaScript」
設定時の注意点｜エラー・警告・重複を防ぐ
構造化データで最も大切なのは、検索エンジン向けに都合のよい情報を作ることではなく、ユーザーに見せている内容を正確に表すことです。構文が正しくても内容が不正確なら問題になります。
ページに表示されない情報や誤った情報は記述しない
存在しないレビュー、実際には掲載していないFAQ、販売していない商品の価格、更新されていない在庫、本文にない著者情報などを記述してはいけません。Googleのガイドラインでは、ユーザーに見えない情報、ページの主内容を表していない情報、誤解を招く情報をマークアップしないよう求めています。
特にECサイトでは、セール価格の終了、在庫切れ、配送条件や返品条件の変更が起こりやすいため注意が必要です。情報更新の担当者とサイト実装の担当者が異なる場合は、どの更新で構造化データを更新するかを事前に決めておきましょう。
出典：Google Search Central「General Structured Data Guidelines」
同種の構造化データの重複・競合を確認する
構造化データの出力を確認するには、まず対象ページでリッチリザルト テストを実行します。次にブラウザのページソースでapplication/ld+jsonを検索し、どのテーマ・プラグイン・コードが出力しているかを確認します。
複数のJSON-LDがあること自体は問題ではありません。たとえば、記事ページにArticleとBreadcrumbList、運営者を示すOrganizationがあることは自然です。ただし、同じArticleが二重に出力されていたり、同じ商品の価格が異なっていたりする場合は、出力元を整理して一方に統一してください。
エラーは優先して修正し、警告は意味を確認して判断する
必須項目の欠落や値の不整合は優先して修正します。これらは対象機能の利用資格に影響する可能性があります。商品情報で必要な価格関連項目が欠ける、URL形式が不正である、日付形式が正しくないといった問題が例です。
警告は、推奨項目が不足している場合などに出ることがあります。すべてを機械的に埋めるのではなく、その項目が実際にページに存在し、正確に管理できるかを確認してください。正確な情報を提供できないなら、無理に追加しない判断も必要です。
構造化データに関する手動による対策を受けた場合、通常のWeb検索順位そのものではなく、リッチリザルトの対象資格に影響します。Search Consoleの手動による対策レポートも定期的に確認しましょう。
出典：Google Search Central「General Structured Data Guidelines」
構造化データに関するよくある質問
ここでは、導入時に誤解されやすい点を簡潔に整理します。
構造化データを入れると必ずリッチリザルトが表示されますか？
いいえ、表示は保証されません。Googleの要件に沿って実装しても、検索クエリ、端末、地域、ほかの検索機能との兼ね合いなどを踏まえてGoogleが表示を判断します。まずは対象となるための要件を満たし、正確なデータを維持することが重要です。
JSON-LD以外の形式は使えませんか？
使えます。GoogleはJSON-LD、microdata、RDFaをサポートしています。ただし新規実装では、HTMLと分離して管理しやすいJSON-LDが一般的です。既存形式を変更する場合は、重複出力や情報欠落が起きないよう段階的に検証してください。
WordPressプラグインを入れるだけで設定は完了しますか？
完了ではありません。プラグインが出力するタイプと項目を確認し、本文表示との一致、テーマとの重複、リッチリザルト テストの結果、Search Consoleでの公開後の状態まで確認してください。プラグインは実装を補助する手段であり、情報の正確性まで自動で保証するものではありません。
まとめ：ページ内容に合う構造化データを正確に運用する
構造化データは、検索エンジンがページ内容を理解するための手がかりを明確にする施策です。適切に実装すれば、記事、商品、パンくずリスト、イベント、店舗情報などで、Google検索の対応機能に利用される可能性があります。
ただし、順位上昇やリッチリザルト表示を約束する施策ではありません。新規実装ではJSON-LDを基本に、ページの主目的に合うタイプを選び、実際に表示している情報だけを記述してください。
最後に、実装後はリッチリザルト テストで確認し、Search Consoleでエラーや有効項目を監視します。Google検索の対応機能や要件は変わるため、導入時・更新時には公式ドキュメントを確認する運用が欠かせません。
