目次
最初に押さえるポイント 構造化データ(schema)とは何か リッチリザルトがSEOにもたらす効果 JSON-LDとMicrodataの違いと選び方 実装の基本手順とJSON-LDの書き方 ページ種別ごとのスキーマ設計のポイント リッチリザルトテストでの検証手順 Search Consoleでの監視と改善運用 よくある失敗とガイドライン遵守の注意点 実務で確認するチェックリスト よくある質問最初に押さえるポイント
- 構造化データはschema.orgの語彙で記述し、Googleが推奨するJSON-LD形式での実装が基本となります。
- 構造化データを入れても順位が直接上がるわけではなく、リッチリザルト表示を通じてクリック率改善に寄与します。
- リッチリザルトには種類ごとに必須プロパティがあり、ガイドラインを満たさないと表示対象になりません。
- 実装後はリッチリザルトテストで個別確認し、Search Consoleの拡張レポートで全体のエラーを監視します。
- ページに表示されない情報をマークアップするなどの違反はスパム扱いとなり、表示停止や手動対策の対象になります。
構造化データ(schema)とは何か
構造化データとは、ページに書かれた内容の意味を検索エンジンが理解しやすいよう、定められた形式で補足情報を記述する仕組みです。人間が読む本文とは別に、これは記事である、これは価格である、これは評価点であるといった分類を機械が解釈できる形で添えます。検索エンジンはこの情報を手がかりに、ページの中身をより正確に把握します。
記述に使う共通の語彙がschema.orgです。schema.orgはGoogle、Microsoft、Pinterest、Yandexらが参加する共同プロジェクトとして整備され、記事、商品、組織、イベントなど数百種類の型と、それぞれに紐づくプロパティを定義しています。世界中の多くのドメインがこの語彙でマークアップを行っており、事実上の標準として広く使われています。
構造化データを正しく設置すると、検索結果に通常の青いリンクと説明文だけでなく、評価の星やよくある質問、パンくず、価格などの追加要素が表示される場合があります。この拡張表示がリッチリザルトであり、検索結果上での占有面積や視認性を高める効果が期待できます。
ただし構造化データは万能ではありません。マークアップしたからといって必ずリッチリザルトが出るとは限らず、Googleが内容や品質を総合的に判断して表示可否を決めます。まずは仕組みと役割を正しく理解し、過度な期待を避けることが実務の出発点になります。
リッチリザルトがSEOにもたらす効果
構造化データの実装自体は、検索順位を直接押し上げるランキング要因ではありません。Googleは構造化データの有無で順位を優遇するとは明言しておらず、あくまでページ内容の理解を助ける補助情報として扱います。この前提を取り違えると、施策の効果測定を誤る原因になります。
実務上の主な価値はリッチリザルトによるクリック率の改善にあります。星評価やFAQ、価格、画像などが検索結果に表示されると、同じ順位でもユーザーの目に留まりやすくなり、結果として流入が増えるケースがあります。順位を変えずに獲得トラフィックを底上げできる点が魅力です。
もう一つの効果はページ内容の正確な理解促進です。本文だけでは曖昧になりがちな情報、たとえば著者や公開日、組織の所在地などを明示することで、検索エンジンがエンティティを把握しやすくなります。これはE-E-A-Tの評価材料の整理や、ナレッジパネル表示の手がかりにもつながります。
効果は記事や商品など型ごとに大きく異なります。FAQやレビューは視認性向上に効きやすい一方、Articleのように表示が控えめな型もあります。自社のページ種別とユーザーの検索意図を踏まえ、どの型で何を狙うのかを最初に整理しておくことが重要です。
主要なリッチリザルト種別と期待される効果
ページ種別ごとに、適した構造化データの型と検索結果での主な表示効果を整理しています。
| リッチリザルト種別 | 適したページ | 主な表示効果 |
|---|---|---|
| FAQ(よくある質問) | Q&A形式の解説ページ | 質問が折りたたみ表示され占有面積が広がる |
| レビュー・評価 | 商品やサービスの紹介ページ | 星評価が表示され信頼感と視認性が向上する |
| 商品(Product) | ECの商品詳細ページ | 価格や在庫、評価が結果に併記される |
| パンくず(Breadcrumb) | 階層の深い下層ページ | サイト内の位置がパスとして表示される |
| 記事(Article) | ニュースやブログ記事 | サムネイルや公開日が認識されやすくなる |
| イベント(Event) | セミナーや展示会の案内 | 開催日時と場所が結果に表示される |
JSON-LDとMicrodataの違いと選び方
構造化データの記述形式には主にJSON-LD、Microdata、RDFaの3種類があります。このうちGoogleが推奨するのはJSON-LDです。JSON-LDはHTMLの本文構造とは独立してscriptタグ内にまとめて記述できるため、テンプレートへの追加や保守がしやすく、本文の改修と切り離して管理できます。
MicrodataとRDFaは、HTMLタグの属性として情報を埋め込む方式です。本文のマークアップに直接書き込むため、既存テンプレートが複雑だと記述が散らばり、改修時に壊れやすくなります。新規実装であればJSON-LDを選ぶのが実務上の標準的な判断になります。
JSON-LDはCMSやタグマネージャーとの相性も良好です。WordPressであればプラグインで自動生成でき、Googleタグマネージャーを使えばコードを直接触らずに配信することも可能です。動的に変わる商品価格や在庫数も、テンプレート変数を差し込む形で柔軟に出力できます。
ただしタグマネージャー経由での配信は、JavaScriptの実行を前提とする点に注意が必要です。基本的にGoogleはレンダリング後のJSON-LDも認識しますが、確実性を重視するなら、可能な限りサーバー側でHTMLに直接出力する方式が安全です。配信方法は自社の運用体制に合わせて選びます。
実装の基本手順とJSON-LDの書き方
実装はまず対象ページの種別を決めることから始めます。記事ページならArticle、商品ページならProduct、Q&Aを含むならFAQPageというように、ページの主目的に合致する型を一つ選びます。一つのページに複数の型を併記することもできますが、まずは中心となる型から着手すると整理しやすくなります。
次にschema.orgやGoogleのドキュメントで、その型の必須プロパティと推奨プロパティを確認します。たとえばArticleであれば見出しや公開日、著者などが該当します。必須プロパティが欠けるとリッチリザルトの対象外になるため、最初に要件を満たすことを優先し、推奨項目は段階的に追加します。
JSON-LDはscriptタグにtype属性としてapplication/ld+jsonを指定し、その中にJSON形式でデータを記述します。先頭で@contextにschema.orgを、@typeに型名を指定し、続けて各プロパティを記述するのが基本構造です。値はページに実際に表示されている内容と一致させる必要があります。
記述したJSON-LDはheadタグ内かbody内に配置します。配置位置による優劣は基本的にありませんが、テンプレートで一元管理できる場所にまとめると保守が容易です。複数ページに展開する際は、変動する値を変数化し、共通テンプレートから動的に生成する設計にすると運用負荷を抑えられます。
代表的な構造化データタイプと主な必須プロパティ
実装頻度の高い型について、Googleがリッチリザルト表示の前提とする主な必須プロパティの例を示します。実装前に最新のガイドラインで詳細を確認してください。
| タイプ | 用途 | 主な必須・重要プロパティ |
|---|---|---|
| Article | ニュース・ブログ記事 | headline、image、datePublished |
| Product | 商品詳細 | name、image、offers(価格・通貨) |
| FAQPage | よくある質問 | question、acceptedAnswer |
| BreadcrumbList | パンくず | itemListElement、position、name |
| Organization | 企業情報 | name、url、logo |
| Event | イベント案内 | name、startDate、location |
ページ種別ごとのスキーマ設計のポイント
記事系ページではArticleやBlogPostingを基本に、著者をPerson、発行元をOrganizationとして紐づけます。著者や運営者を明確にマークアップすることは、専門性や権威性の整理に役立ち、E-E-A-Tの観点からも意味があります。公開日と更新日を正しく記述し、本文の日付表記と一致させることも欠かせません。
ECの商品ページではProductを中心に、offersで価格と通貨、在庫状況を記述します。レビューがあればAggregateRatingやReviewを併記すると星評価の表示が狙えます。価格や在庫は頻繁に変わるため、テンプレートで動的に出力し、表示価格と構造化データの値が常に一致する仕組みを整えておく必要があります。
サイト共通の要素として、全ページにBreadcrumbListとOrganizationまたはWebSiteを設置する設計が有効です。パンくずは下層ページの文脈を伝え、Organizationは企業情報やロゴ、SNSアカウントの関連付けに使われます。これらは一度テンプレートに組み込めば全ページで再利用でき、費用対効果が高い基盤施策です。
FAQPageやHowToは表示効果が大きい一方、実際にページ上にその質問と回答、または手順が表示されていることが前提です。コンテンツに存在しない情報をマークアップ目的で水増しすると違反になります。型を選ぶ際は、まず本文側に対応するコンテンツが揃っているかを確認してから実装します。
リッチリザルトテストでの検証手順
実装後はまずGoogleのリッチリザルトテストで個別ページを確認します。公開URLを入力するか、コードを直接貼り付けて検証でき、どのリッチリザルトが生成可能か、エラーや警告が含まれていないかを判定します。実装直後の一次チェックとして必ず通すべき工程です。
結果はエラー、警告、有効の三段階で示されます。エラーは必須プロパティの欠落など表示の妨げになる致命的な問題で、最優先で修正します。警告は推奨プロパティの不足など、なくても表示はされるが改善の余地がある項目を指します。まずエラーをゼロにし、続けて警告に対応する順序が効率的です。
構文そのものの妥当性を広く確認したい場合は、schema.orgが提供するスキーマ マークアップ検証ツールを併用します。こちらはGoogleのリッチリザルト要件に限定せず、schema.org語彙としての記述が正しいかを検証するため、Google非対応の型を使う場合や汎用的な妥当性確認に向いています。
テストはレンダリング後のHTMLを対象に行えるため、タグマネージャーで配信した構造化データも確認できます。ただしテストツールが取得するのは実行環境での結果であり、実際の検索結果での表示を保証するものではありません。あくまで実装の正しさを確かめる工程と位置づけ、最終判断はSearch Consoleで行います。
主要な検証ツールの役割比較
構造化データの検証に使う代表的なツールについて、検証範囲と適した用途を整理しています。
| ツール | 検証範囲 | 適した用途 |
|---|---|---|
| リッチリザルトテスト | Google対応のリッチリザルト要件 | 個別ページの公開前後チェック |
| スキーマ マークアップ検証ツール | schema.org語彙全般の構文 | 汎用的な記述の妥当性確認 |
| Search Console 拡張レポート | サイト全体の検出状況とエラー | 公開後の継続的な監視 |
| URL検査ツール | 個別URLのインデックス状況 | クロール・検出有無の確認 |
Search Consoleでの監視と改善運用
公開後の継続監視はSearch Consoleの拡張レポートで行います。実装した型ごとに専用のレポートが用意され、有効なアイテム数、警告付きのアイテム数、エラーのあるアイテム数が時系列で確認できます。サイト全体でどの程度正しく検出されているかを俯瞰できる点が、個別テストとの大きな違いです。
エラーが検出された場合はレポートから該当URLと原因を特定し、テンプレートを修正します。多くのエラーはテンプレート起因で同じ種類が大量に発生するため、一箇所の修正で広範囲を解消できることが少なくありません。修正後は同レポートの検証機能で再クロールを依頼し、解消を確認します。
リッチリザルトが実際に検索でどれだけ表示され、クリックされているかは検索パフォーマンスレポートで把握します。検索での見え方のフィルタを使うと、リッチリザルト経由の表示回数やクリック率を抽出でき、施策の効果を数値で確認できます。クリック率の変化を施策前後で比較すると効果検証が明確になります。
構造化データは一度設置して終わりではありません。サイト改修やCMS更新でマークアップが壊れることがあり、定期的なレポート確認が欠かせません。月次などの頻度でエラー件数とリッチリザルトの表示状況を点検し、異常があれば早期に対応する運用サイクルを定着させます。
よくある失敗とガイドライン遵守の注意点
最も重大な失敗は、ページに表示されていない情報をマークアップすることです。本文に存在しないFAQやレビューを構造化データだけで記述する行為はスパムポリシー違反にあたり、リッチリザルトの表示停止や手動による対策の対象になります。マークアップする内容は必ずページ上の表示と一致させます。
技術的な失敗として多いのが必須プロパティの欠落と値の不一致です。必須項目が欠けると型としては認識されてもリッチリザルトの対象外となり、価格や日付の表記が本文と食い違うと警告やエラーの原因になります。実装時は要件を一つずつ照合し、動的な値は本文と同じデータソースから出力する設計にします。
レビュー評価の自作自演や、関連性のない型の乱用も避けるべき行為です。自社が管理するレビューを根拠なく高評価で記述したり、内容と無関係な型を表示目的で付与したりすると、ガイドライン違反として扱われます。狙うべきは表示の獲得そのものではなく、正確な情報提供であるという原則を保ちます。
運用面では、施策の効果を順位上昇で測ろうとする誤解にも注意します。構造化データの成果はリッチリザルトの表示数とクリック率に表れるため、評価指標はそこに置きます。ガイドラインに沿った正確なマークアップを継続することが、長期的に安定した表示を維持する最も確実な方法です。
よくある失敗と対処方法
構造化データ実装で頻出する失敗と、その原因および推奨される対処を整理しています。
| 失敗の内容 | 主な原因 | 対処方法 |
|---|---|---|
| リッチリザルトが表示されない | 必須プロパティの欠落 | ガイドラインで要件を照合し補完する |
| 警告やエラーが出る | 本文と値が不一致 | 同じデータソースから動的出力する |
| 手動対策を受ける | 非表示情報のマークアップ | ページ表示と内容を完全に一致させる |
| 改修後に表示が消える | テンプレート変更で破損 | 拡張レポートで定期点検する |
| 効果が判断できない | 順位で成果を測っている | 表示回数とクリック率で評価する |
実務で確認するチェックリスト
- 対象ページの主目的に合致する構造化データの型を選定したか確認する
- 選んだ型の必須プロパティをすべて満たしているかガイドラインで照合する
- マークアップした内容がページ上の表示と完全に一致しているか確認する
- JSON-LD形式で記述し、価格や日付などの動的な値を本文と同じソースから出力する
- リッチリザルトテストでエラーと警告を確認し、エラーを優先的に解消する
- Search Consoleの拡張レポートでサイト全体の検出状況とエラーを監視する
- 検索パフォーマンスでリッチリザルトの表示回数とクリック率を定期的に点検する
よくある質問
構造化データ(schema)とは何ですか?
構造化データとは、ページの内容を検索エンジンが理解しやすい定められた形式で補足記述する仕組みです。schema.orgという共通語彙を使い、記事や商品、評価といった情報の意味を機械が解釈できる形で添えます。これにより検索結果でリッチリザルトが表示される可能性が生まれます。
構造化データを入れると検索順位は上がりますか?
構造化データの実装自体は直接のランキング要因ではなく、入れただけで順位が上がるわけではありません。主な効果はリッチリザルトの表示を通じたクリック率の改善です。同じ順位でも検索結果での視認性が高まり、流入の増加につながる点に価値があります。
JSON-LDとMicrodataのどちらを使うべきですか?
新規に実装するならGoogleが推奨するJSON-LDが基本です。HTML本文と独立してscriptタグにまとめて記述でき、保守や動的出力がしやすいためです。Microdataはタグ属性に埋め込む方式で改修時に壊れやすく、既存実装の事情がない限りJSON-LDが適しています。
リッチリザルトは構造化データを入れれば必ず表示されますか?
必ず表示されるとは限りません。必須プロパティを満たしガイドラインに準拠していても、最終的な表示可否はGoogleが内容や品質を総合的に判断して決めます。要件を満たすことは前提条件であり、表示を保証するものではないと理解しておく必要があります。
実装した構造化データはどうやって検証しますか?
まずGoogleのリッチリザルトテストで個別ページのエラーや警告を確認します。schema.org語彙としての構文を広く確かめたい場合はスキーマ マークアップ検証ツールを併用します。公開後はSearch Consoleの拡張レポートでサイト全体の検出状況を継続的に監視します。
ページに表示していない情報をマークアップしてもよいですか?
してはいけません。ページ上に表示されていないFAQやレビューなどを構造化データだけで記述する行為はスパムポリシー違反にあたります。リッチリザルトの表示停止や手動による対策の対象となるため、マークアップ内容は必ずページの表示と一致させてください。
構造化データの効果はどの指標で測ればよいですか?
順位ではなくリッチリザルトの表示回数とクリック率で評価します。Search Consoleの検索パフォーマンスで検索での見え方を絞り込むと、リッチリザルト経由の表示やクリックを抽出できます。施策の前後で数値を比較すると効果が明確になります。
構造化データは一度設置すれば運用は不要ですか?
継続的な点検が必要です。サイト改修やCMSの更新でマークアップが破損することがあり、放置すると表示が消える場合があります。月次などの頻度で拡張レポートのエラー件数と表示状況を確認し、異常を早期に発見して修正する運用サイクルを定着させてください。
この記事に出てくる用語
意味や計算式は用語集で確認できます。