Webサイトを運営していると、「検索結果でもっと目立つ表示にしたい」「検索順位を上げたい」と考えることはありませんか?
そんなときに役立つのが「構造化データ」です。
構造化データを正しく実装すると、検索結果にレビューの星マークや価格情報、FAQなどが表示される「リッチリザルト」として表示される可能性が高まります。
実際に、構造化データを実装した企業ではクリック率が25%から82%も向上したという事例も報告されています。
しかし、「構造化データって難しそう」「どうやって実装すればいいの?」と感じる方も多いでしょう。
この記事では、構造化データの基礎知識から具体的な実装方法、注意点まで、初心者の方にも分かりやすく徹底解説します。
SEO対策として構造化データの導入を検討している方は、ぜひ最後までお読みください。
目次
構造化データの基礎知識

構造化データを理解するためには、まず基本的な概念を押さえることが重要です。
ここでは、構造化データとは何か、なぜ必要なのかについて詳しく解説していきます。
構造化データとは
構造化データとは、Webページの内容を検索エンジンが理解しやすい形式で記述したデータのことです。
通常のHTMLだけでは、検索エンジンは文字情報を「単なる文字列」として認識するだけで、その意味や文脈まで完全には理解できません。
そこで、あらかじめ決められた形式で情報を整理し、「これは会社名です」「これは電話番号です」といった意味を明確に伝えるのが構造化データの役割です。
例えば、Webページに「サクラ商事」という文字列があったとします。
人間が見れば「会社名だな」と分かりますが、検索エンジンにとっては、それが会社名なのか、商品名なのか、人名なのかを判断することは困難です。
構造化データを使うことで、検索エンジンに対して正確な情報の意味を伝えることができるようになります。
| 項目 | 説明 |
| 定義 | Webページの内容を検索エンジンが理解しやすいデータ形式 |
| 目的 | 情報の意味や文脈を明確に伝える |
| 主な規格 | Schema.org、JSON-LD、Microdataなど |
| 効果 | リッチリザルト表示、検索エンジンの理解促進 |
検索エンジンが理解しやすいデータ形式
検索エンジンは、クローラーと呼ばれるプログラムを使ってWebページを巡回し、情報を収集しています。
しかし、クローラーは人間のように文章の意図や背景を読み取ることができません。
構造化データは、クローラーにとって「読み取りやすい地図」のような役割を果たします。
例えば、レストランのWebページに「営業時間:11:00-22:00」と書かれていたとします。
人間なら「このお店は午前11時から午後10時まで営業しているんだな」と理解できますが、クローラーは単なる文字列として認識するだけです。
構造化データを使って「openingHours」というプロパティで営業時間を明示することで、検索エンジンは「この情報は営業時間を示している」と正確に理解できるようになります。
その結果、Googleマップや検索結果に正しい営業時間が表示されるようになります。
構造化データには様々な要素を定義できます。
- 会社名や組織名
- 住所や電話番号
- 商品の価格や在庫状況
- レビューや評価
- イベントの日時や場所
- レシピの材料や調理時間
これらの情報を構造化することで、検索エンジンはWebページの内容をより深く理解できるようになります。
セマンティックWebとの関係
構造化データを理解する上で、「セマンティックWeb」という概念を知っておくことも大切です。
セマンティックWebとは、Web上の情報に意味を持たせ、コンピューターが自動的に情報を理解・処理できるようにするという構想です。
この概念は、Webの生みの親として知られるティム・バーナーズ=リー氏によって1990年代後半に提唱されました。
従来のWebでは、人間がページを見て情報を理解し、判断する必要がありました。
しかし、セマンティックWebの考え方では、コンピューターが情報の意味を理解し、自動的に情報を収集・分析・活用できるようになります。
構造化データは、このセマンティックWebを実現するための重要な技術の一つです。
例えば、あるWebサイトに「1994年8月19日」という日付が書かれていたとします。
通常のHTMLだけでは、それが誕生日なのか、設立日なのか、イベント開催日なのかを判断できません。
しかし、構造化データで「birthDate」というプロパティを使えば、「これは誕生日である」という意味情報をコンピューターに伝えることができます。
このように、データに意味を付与することで、検索エンジンやAIがより賢く情報を扱えるようになるのです。
構造化データとリッチリザルトの違い
構造化データとリッチリザルトは、混同されやすい用語ですが、明確な違いがあります。
**構造化データは「データの記述方法」であり、リッチリザルトは「検索結果の表示形式」**です。
構造化データは、HTMLに特定の形式で記述するコードそのものを指します。
一方、リッチリザルト(リッチスニペット)は、構造化データをもとにGoogleが検索結果に表示する拡張された情報のことです。
具体的には、以下のような表示がリッチリザルトに該当します。
- 星マークのレビュー評価
- 商品の価格や在庫状況
- レシピの画像や調理時間
- FAQの質問と回答
- イベントの日時や場所
- パンくずリストのナビゲーション
つまり、構造化データを実装することで、リッチリザルトとして表示される可能性が生まれるという関係性です。
ただし、重要なポイントとして、構造化データを実装したからといって、必ずリッチリザルトが表示されるわけではありません。
| 項目 | 構造化データ | リッチリザルト |
| 性質 | データの記述方法(コード) | 検索結果の表示形式 |
| 実装場所 | WebページのHTML内 | Google検索結果画面 |
| 制御 | サイト管理者が実装可能 | Googleのアルゴリズムが判断 |
| 関係性 | リッチリザルトの前提条件 | 構造化データがあれば表示される可能性がある |
Googleは、検索履歴、位置情報、デバイスの種類など、様々な要因を考慮して、リッチリザルトを表示するかどうかを判断しています。
また、ページの品質やコンテンツの正確性も重要な判断材料となります。
構造化データが必要な理由
なぜ、わざわざ手間をかけて構造化データを実装する必要があるのでしょうか?
その理由は、大きく分けて3つあります。
第一に、検索エンジンの理解を深めることができるからです。
Googleをはじめとする検索エンジンは、年々進化していますが、それでも人間のように文脈を完全に理解することはできません。
構造化データを使うことで、ページの内容をより正確に検索エンジンに伝えられます。
第二に、リッチリザルトによる視認性の向上が期待できるからです。
検索結果で目立つ表示になれば、ユーザーの目に留まりやすくなり、クリック率の向上につながります。
実際に、多くの企業がリッチリザルトによってクリック率を大幅に改善しています。
第三に、音声検索やAIアシスタントへの対応という側面もあります。
スマートスピーカーやスマートフォンの音声検索が普及する中、構造化データは音声検索の回答ソースとして活用されるケースが増えています。
構造化データがあることで、Googleアシスタントやスマートスピーカーが正確な情報を読み上げられるようになります。
また、将来的な検索エンジンの進化に備えるという意味でも、構造化データの実装は重要です。
Googleは継続的にリッチリザルトの種類を増やしており、今後も新しい表示形式が登場する可能性があります。
早めに構造化データを実装しておくことで、新しい機能にもスムーズに対応できるというメリットがあります。
さらに、競合他社がまだ構造化データを実装していない場合、先行して実装することで差別化を図ることもできます。
| 理由 | 具体的なメリット |
| 検索エンジンの理解促進 | ページ内容を正確に伝えられる、インデックスの質が向上する |
| 視認性の向上 | リッチリザルト表示でクリック率アップ、競合との差別化 |
| 音声検索対応 | スマートスピーカーやAIアシスタントの回答ソースになる |
| 将来性 | 新しい検索機能への対応、技術トレンドへの適応 |
名古屋でWebサイトのSEO対策を検討されている方は、構造化データの実装も含めた総合的な施策が効果的です。
構造化データがSEOに与える影響

構造化データを実装することで、SEOにどのような影響があるのでしょうか?
ここでは、検索順位への影響やクリック率の改善効果について、具体的なデータとともに解説します。
検索順位への直接的な影響の有無
多くの方が気になるのは、「構造化データを実装すれば検索順位が上がるのか?」という点でしょう。
結論から言うと、構造化データは検索順位に直接的な影響を与えません。
これは、GoogleのJohn Mueller(ジョン・ミューラー)氏が公式に明言しています。
2017年のウェブマスターハングアウトで、ミューラー氏は「構造化データをマークアップしているからといって、それをランキングの変更に使用していない」と述べています。
つまり、構造化データを実装したからといって、それだけで検索結果の1ページ目に表示されるようになるわけではないのです。
しかし、これは「構造化データがSEOに無意味」ということではありません。
構造化データは、間接的にSEO効果をもたらす重要な要素です。
| 影響の種類 | 詳細 | SEO効果 |
| 直接的影響 | 検索順位のランキング要因 | なし(公式に否定されている) |
| 間接的影響 | クリック率の向上 | あり(ユーザー行動の改善) |
| 間接的影響 | クローラビリティの向上 | あり(インデックスの質向上) |
| 間接的影響 | ユーザーエクスペリエンスの向上 | あり(滞在時間や回遊率の改善) |
構造化データを実装することで、リッチリザルトが表示され、クリック率が向上します。
クリック率が上がると、Googleはそのページを「ユーザーにとって有益なページ」と評価する可能性があります。
また、構造化データによってクローラーがページの内容を正確に理解できるようになり、適切なキーワードでインデックスされやすくなります。
さらに、ユーザーが求める情報にすぐにアクセスできることで、サイト全体のユーザーエクスペリエンスが向上します。
このように、直接的ではないものの、様々な経路を通じてSEOにポジティブな影響を与えるのが構造化データの特徴です。
クローラビリティの向上効果
構造化データがSEOに与える重要な効果の一つが、クローラビリティの向上です。
クローラビリティとは、検索エンジンのクローラーがWebページを巡回し、情報を収集しやすいかどうかを示す指標です。
構造化データを実装することで、クローラーはページの内容をより正確に、効率的に理解できるようになります。
通常のHTMLだけでは、クローラーはテキストを順番に読み取っていくだけですが、構造化データがあれば「このセクションは会社情報」「この部分は商品情報」と、情報の種類や関係性を瞬時に把握できます。
これにより、クローラーの処理時間が短縮され、より多くのページを効率的にクロールできるようになります。
特に大規模なWebサイトの場合、クローラビリティの改善は重要です。
Googleのクローラーには、各サイトに割り当てられる「クロールバジェット」という概念があり、一定期間内にクロールできるページ数には制限があります。
構造化データによってクローラビリティが向上すれば、限られたクロールバジェットをより効果的に活用できるようになります。
また、構造化データがあることで、ページの内容がより正確にインデックスされます。
- 会社名や商品名が正しく認識される
- 住所や電話番号が正確に登録される
- イベント日時が適切にインデックスされる
- レビュー評価が正しく反映される
これらの情報が正確にインデックスされることで、関連するキーワードで検索されたときに、適切に表示される可能性が高まるのです。
さらに、構造化データは、Googleがページの主要なトピックやテーマを理解する手助けにもなります。
例えば、レシピページに構造化データを実装すれば、「このページは料理のレシピについて書かれている」とGoogleが明確に理解できます。
その結果、「レシピ」関連の検索クエリに対して、より適切にページが表示されるようになります。
リッチリザルト表示によるCTR改善
構造化データの最も分かりやすいメリットは、リッチリザルトによるクリック率(CTR)の改善です。
リッチリザルトとは、通常の検索結果に加えて、追加情報が表示される形式のことです。
通常の検索結果は、青いリンクテキスト、URL、メタディスクリプションの3つで構成されています。
しかし、リッチリザルトでは、これらに加えて、星マーク付きの評価、価格情報、画像、FAQなど、様々な情報が表示されます。
この視覚的に目立つ表示が、クリック率の大幅な向上につながるのです。
視認性とクリック率の関係
検索結果ページでは、限られたスペースに多くの情報が表示されます。
ユーザーは、その中から自分が求める情報を素早く見つけ出そうとします。
リッチリザルトは、通常の検索結果よりも多くのスペースを占有し、視覚的に目立つため、ユーザーの目に留まりやすくなります。
特に、以下のような要素は視認性を大きく高めます。
- 星マーク(★)による評価表示
- カラフルな画像やサムネイル
- 価格や割引情報
- FAQの質問と回答の展開
- パンくずリストによるサイト構造の表示
これらの要素があることで、ユーザーは検索結果を見ただけで、「このページには自分が求める情報がありそうだ」と判断できます。
その結果、クリックされる確率が高まるのです。
| 表示要素 | 効果 | ユーザーへの訴求ポイント |
| 星マーク評価 | 信頼性の向上 | 他のユーザーの評価が分かる |
| 価格表示 | 情報の明確化 | 事前に予算が分かる |
| 画像 | 視覚的訴求 | 商品やサービスのイメージが掴める |
| FAQ | 情報量の増加 | よくある疑問が事前に解決できる |
また、リッチリザルトは、単に目立つだけでなく、ユーザーにとって有益な情報を事前に提供するという役割も果たします。
例えば、レストランを探しているユーザーが、検索結果で営業時間や評価、予算感を確認できれば、わざわざサイトを訪問しなくても基本情報が分かります。
しかし、詳しいメニューや予約方法を知りたければ、サイトをクリックするでしょう。
このように、リッチリザルトはユーザーにとって価値のある情報を提供しつつ、サイトへの訪問も促すという、バランスの取れた機能なのです。
実際の改善事例と数値データ
構造化データによるCTR改善の効果は、実際の数値データでも明らかになっています。
Googleが公式に発表している事例では、以下のような驚くべき改善結果が報告されています。
Rotten Tomatoes(映画レビューサイト)では、10万ページに構造化データを追加した結果、構造化データを含むページでのクリック率が、構造化データのないページに比べて25%増加しました。
The Food Network(料理レシピサイト)では、全ページの80%で検索結果の機能を有効にした結果、アクセス数が35%増加しました。
楽天(ECサイト)では、構造化データを実装したページでのユーザーの滞在時間が、構造化データのないページに比べて1.5倍長くなりました。
さらに、検索機能があるAMPページでのインタラクション率は、検索機能がないAMPページに比べて3.6倍高くなっています。
Nestlé(食品メーカー)では、検索でリッチリザルトを表示するページのクリック率が、表示しないページに比べて82%高くなっています。
- Rotten Tomatoes: CTR 25%増加
- The Food Network: アクセス数 35%増加
- 楽天: 滞在時間 1.5倍、インタラクション率 3.6倍
- Nestlé: CTR 82%向上
これらの数値は、構造化データが単なる技術的な施策ではなく、実際のビジネス成果につながる重要な施策であることを示しています。
特に、ECサイトやレビューサイト、レシピサイトなど、具体的な商品やサービス情報を提供するサイトでは、効果が顕著に現れる傾向があります。
また、地域ビジネスを展開する企業にとっても、構造化データは重要です。
営業時間、住所、電話番号などの基本情報を構造化データで記述することで、Googleマップや音声検索で正確な情報が表示されるようになります。
名古屋で店舗やオフィスを構える企業の場合、地域に根ざした検索結果での表示を強化できるというメリットもあります。
主要な構造化データの種類

構造化データには、様々な種類があり、それぞれ異なる用途や目的があります。
ここでは、Webサイト運営で特に活用頻度が高い主要な構造化データの種類について、詳しく解説していきます。
記事・ブログ(Article/BlogPosting)
Article(記事)やBlogPosting(ブログ投稿)は、最も広く使われている構造化データの一つです。
ニュース記事、ブログ記事、コラム記事など、テキストコンテンツを中心としたページに実装します。
この構造化データを実装することで、検索結果に記事のタイトル、著者名、公開日、更新日、アイキャッチ画像などが適切に表示されるようになります。
Article構造化データで指定できる主な情報は以下の通りです。
- headline(見出し): 記事のタイトル
- author(著者): 記事を書いた人の名前
- datePublished(公開日): 記事が最初に公開された日時
- dateModified(更新日): 記事が最後に更新された日時
- image(画像): 記事を代表する画像のURL
- publisher(発行者): 記事を公開している組織や会社の情報
これらの情報を構造化データとして記述することで、Googleが記事の内容や鮮度を正確に把握できるようになります。
特に、ニュース記事の場合は、Googleニュースに掲載される可能性も高まります。
また、AMP(Accelerated Mobile Pages)を実装している場合は、Article構造化データの実装が必須となります。
ブログやオウンドメディアを運営している企業にとって、記事構造化データは基本中の基本と言えるでしょう。
| プロパティ | 必須/推奨 | 説明 |
| headline | 必須 | 記事のタイトル(110文字以内推奨) |
| image | 必須 | 記事の代表画像(複数指定可能) |
| datePublished | 必須 | 記事の公開日時 |
| dateModified | 推奨 | 記事の最終更新日時 |
| author | 推奨 | 著者の名前または組織名 |
| publisher | 必須 | 発行者の情報(名前とロゴ) |
商品情報(Product)
ECサイトや商品紹介ページで重要なのが、Product(商品)構造化データです。
商品名、価格、在庫状況、レビュー評価、商品画像などの情報を構造化することで、検索結果に豊富な商品情報を表示できます。
特に、価格や在庫状況、星マーク付きのレビュー評価が検索結果に表示されると、ユーザーの購買意欲を大きく刺激することができます。
Product構造化データで指定できる主な情報は以下の通りです。
- name(商品名): 商品の正式名称
- image(商品画像): 商品の画像URL
- description(説明): 商品の説明文
- sku(商品コード): 商品の識別番号
- brand(ブランド): 商品のブランド名
- offers(販売情報): 価格、通貨、在庫状況など
- aggregateRating(総合評価): レビューの平均評価と件数
- review(個別レビュー): 具体的なレビュー内容
特に重要なのが、**offers(販売情報)とaggregateRating(総合評価)**です。
価格情報と評価が検索結果に表示されることで、ユーザーは事前に商品の価格帯や評判を知ることができます。
また、在庫状況(InStock、OutOfStock、PreOrder)を明示することで、在庫がある商品のみを探しているユーザーに訴求できます。
さらに、商品構造化データは、Googleショッピング広告との連携にも有効です。
構造化データがあることで、商品情報がGoogle Merchant Centerに正確に反映されやすくなります。
ECサイトを運営している企業にとって、商品構造化データの実装は、売上向上に直結する重要な施策と言えるでしょう。
パンくずリスト(BreadcrumbList)
パンくずリスト構造化データは、Webサイトの階層構造を示すための構造化データです。
パンくずリストとは、「ホーム > カテゴリー > サブカテゴリー > 現在のページ」のように、ユーザーが現在どの階層にいるかを示すナビゲーション要素のことです。
このパンくずリストを構造化データとして記述することで、検索結果にもサイトの階層構造が表示されるようになります。
パンくずリスト構造化データのメリットは以下の通りです。
- 検索結果でサイト構造が一目で分かる
- ユーザーがサイト内の位置を把握しやすい
- サイト全体の階層構造をGoogleが理解しやすい
- 内部リンク構造が明確になる
パンくずリスト構造化データでは、各階層の名前とURLを順番に記述していきます。
例えば、「ホーム」→「ブログ」→「SEO対策」→「構造化データとは」といった階層構造を、position(位置)プロパティで順序付けて記述します。
パンくずリスト構造化データは、実装が比較的簡単で、効果も分かりやすいため、構造化データ導入の第一歩として最適です。
特に、商品カテゴリーが多いECサイトや、コンテンツが階層的に整理されているメディアサイトでは、必須の構造化データと言えます。
| 要素 | 説明 | 重要度 |
| itemListElement | リストの各項目 | 必須 |
| position | 階層の順序(1から始まる) | 必須 |
| name | 各階層の表示名 | 必須 |
| item | 各階層のURL | 必須 |
FAQ(FAQPage)
FAQ構造化データは、よくある質問と回答を構造化するためのデータです。
FAQページやヘルプページに実装することで、検索結果に質問と回答が直接表示されるようになります。
FAQ構造化データを実装すると、検索結果で質問が折りたたみ形式で表示され、ユーザーがクリックすると回答が展開される形式になります。
この表示形式により、検索結果ページでユーザーの疑問が即座に解決される可能性があります。
FAQ構造化データで指定する主な要素は以下の通りです。
- Question(質問): よくある質問の内容
- acceptedAnswer(受け入れられた回答): その質問に対する回答
- name(質問文): 具体的な質問のテキスト
- text(回答文): 具体的な回答のテキスト
FAQ構造化データは、特にサポートページやトラブルシューティングページで効果的です。
ユーザーが具体的な疑問を持って検索している場合、検索結果で即座に回答が見つかれば、ユーザー満足度が大きく向上します。
また、FAQ構造化データを実装することで、検索結果での占有面積が増え、他の競合サイトよりも目立つ表示になります。
ただし、FAQ構造化データには注意点もあります。
広告目的の質問や、ユーザーが実際に疑問に思わないような質問は、Googleガイドラインに違反する可能性があります。
あくまで、ユーザーが本当に知りたいと思う質問と、それに対する正確な回答を記述することが重要です。
動画(VideoObject)
動画コンテンツを含むページでは、VideoObject構造化データの実装が推奨されます。
YouTube、Vimeo、自社サーバーにホストされた動画など、あらゆる動画に対して構造化データを設定できます。
VideoObject構造化データを実装することで、検索結果に動画のサムネイル、再生時間、アップロード日などが表示されるようになります。
また、Google動画検索での表示機会も増加します。
VideoObject構造化データで指定できる主な情報は以下の通りです。
- name(タイトル): 動画のタイトル
- description(説明): 動画の内容を説明するテキスト
- thumbnailUrl(サムネイル): 動画のサムネイル画像URL
- uploadDate(アップロード日): 動画が公開された日時
- duration(再生時間): 動画の長さ(ISO 8601形式)
- contentUrl(動画URL): 実際の動画ファイルのURL
- embedUrl(埋め込みURL): 動画プレイヤーのURL
特に重要なのが、**thumbnailUrl(サムネイル)とduration(再生時間)**です。
検索結果でサムネイル画像と再生時間が表示されることで、ユーザーは動画の内容や長さを事前に把握できます。
動画マーケティングに力を入れている企業にとって、VideoObject構造化データは検索からの動画視聴を増やすための重要な施策です。
また、動画構造化データは、Googleアシスタントやスマートディスプレイでの表示にも活用されます。
| プロパティ | 必須/推奨 | 説明 |
| name | 必須 | 動画のタイトル |
| description | 必須 | 動画の説明(5,000文字以内) |
| thumbnailUrl | 必須 | サムネイル画像URL(複数可) |
| uploadDate | 必須 | 動画の公開日(ISO 8601形式) |
| duration | 推奨 | 動画の長さ(例: PT1M30S = 1分30秒) |
| contentUrl | 推奨 | 動画ファイルの実際のURL |
レビュー・評価(Review/AggregateRating)
商品やサービスのレビュー情報を構造化するのが、ReviewとAggregateRating構造化データです。
Review(個別レビュー)は、特定のユーザーによる個別の評価とコメントを記述します。
一方、AggregateRating(総合評価)は、複数のレビューをまとめた平均評価と件数を記述します。
これらの構造化データを実装することで、検索結果に星マーク付きの評価が表示されるようになります。
星マークは非常に目立つ視覚要素であり、ユーザーのクリック率を大きく向上させる効果があります。
Review構造化データで指定できる主な情報は以下の通りです。
- reviewRating(評価): 5段階評価などの数値
- author(レビュアー): レビューを書いた人の名前
- reviewBody(レビュー本文): 実際のレビュー内容
- datePublished(公開日): レビューが投稿された日時
AggregateRating構造化データで指定できる主な情報は以下の通りです。
- ratingValue(平均評価): 平均評価値(例: 4.5)
- bestRating(最高評価): 評価の最高値(通常は5)
- ratingCount(評価数): レビューの総数
レビュー構造化データは、ECサイトやレストラン、ホテル、サービス紹介ページで特に効果的です。
ただし、レビュー構造化データには厳格なガイドラインがあります。
自社で勝手に作成した架空のレビューや、金銭を払って書いてもらったレビューを構造化データとして記述することは禁止されています。
実際にユーザーが投稿した本物のレビューのみを構造化データとして記述する必要があります。
イベント(Event)
セミナー、コンサート、展示会、スポーツイベントなどの情報を構造化するのが、Event構造化データです。
イベント構造化データを実装することで、検索結果にイベント名、開催日時、場所、チケット価格などが表示されるようになります。
また、Googleカレンダーへの追加機能や、イベント専用の検索結果にも表示される可能性があります。
Event構造化データで指定できる主な情報は以下の通りです。
- name(イベント名): イベントの正式名称
- startDate(開始日時): イベントの開始日時
- endDate(終了日時): イベントの終了日時
- location(場所): イベントの開催場所(住所または会場名)
- description(説明): イベントの詳細説明
- image(画像): イベントのポスターや画像
- offers(チケット情報): チケットの価格や販売状況
イベント構造化データは、オンラインイベントにも対応しています。
新型コロナウイルス以降、オンラインセミナーやウェビナーが増加しており、location(場所)プロパティでオンライン開催を示すことができます。
イベント運営者や、定期的にセミナーを開催する企業にとって、Event構造化データは集客力を高める重要なツールです。
また、地域のイベント情報を発信するメディアやコミュニティサイトでも、積極的に活用したい構造化データです。
| プロパティ | 必須/推奨 | 説明 |
| name | 必須 | イベント名 |
| startDate | 必須 | 開始日時(ISO 8601形式) |
| location | 必須 | 開催場所または”オンライン” |
| description | 推奨 | イベントの説明 |
| image | 推奨 | イベントの画像 |
| offers | 推奨 | チケット価格や販売情報 |
| endDate | 推奨 | 終了日時(ISO 8601形式) |
組織・企業情報(Organization)
企業の基本情報を構造化するのが、Organization構造化データです。
会社概要ページやトップページに実装することで、企業名、ロゴ、住所、電話番号、ソーシャルメディアのアカウントなどを検索エンジンに正確に伝えることができます。
Organization構造化データには、さらに細分化されたタイプがあります。
- Corporation(株式会社): 営利企業
- NGO(非政府組織): 非営利団体
- EducationalOrganization(教育機関): 学校や大学
- GovernmentOrganization(政府機関): 公的機関
企業の形態に応じて、適切なタイプを選択することが重要です。
Organization構造化データで指定できる主な情報は以下の通りです。
- name(組織名): 正式な企業名や団体名
- url(URL): 公式WebサイトのURL
- logo(ロゴ): 企業ロゴの画像URL
- contactPoint(連絡先): 電話番号やメールアドレス
- address(住所): 本社や事業所の住所
- sameAs(ソーシャルメディア): FacebookやTwitterなどのURL
Organization構造化データを実装することで、ナレッジパネル(検索結果の右側に表示される情報ボックス)に企業情報が表示される可能性が高まります。
ナレッジパネルには、企業ロゴ、説明文、住所、営業時間、関連するソーシャルメディアのリンクなどが表示されます。
これにより、企業のブランド認知度向上や信頼性の向上につながります。
名古屋を拠点とする企業の場合、住所情報を正確に記述することで、地域検索での表示も強化されます。
地域ビジネス(LocalBusiness)
実店舗を持つビジネスや地域密着型のサービスを提供する企業にとって重要なのが、LocalBusiness構造化データです。
LocalBusinessは、Organizationを継承したより具体的な構造化データで、営業時間、住所、電話番号、提供サービスなどの情報を詳細に記述できます。
LocalBusinessにも、さらに細分化されたタイプがあります。
- Restaurant(レストラン): 飲食店
- Store(店舗): 小売店
- AutoDealer(自動車販売店): 自動車ディーラー
- MedicalClinic(医療クリニック): 病院や診療所
- LegalService(法律サービス): 法律事務所
業種に応じて、最も適切なタイプを選択することが、Googleマップや地域検索での表示を最適化するポイントです。
LocalBusiness構造化データで指定できる主な情報は以下の通りです。
- name(店舗名): 店舗やビジネスの名称
- address(住所): 詳細な住所情報
- geo(緯度経度): 店舗の正確な位置情報
- telephone(電話番号): 問い合わせ先の電話番号
- openingHours(営業時間): 曜日ごとの営業時間
- priceRange(価格帯): サービスや商品の価格帯(例: $$)
- acceptsReservations(予約可否): 予約が可能かどうか
LocalBusiness構造化データを実装することで、Googleマップでの表示が最適化され、地域検索での上位表示につながる可能性があります。
特に、「地域名+業種」で検索するユーザーにとって、営業時間や住所、電話番号などの情報が検索結果に表示されることは非常に便利です。
| 情報項目 | 効果 |
| 営業時間 | 「今すぐ営業しているか」が分かる |
| 住所・地図 | 店舗への行き方が分かる |
| 電話番号 | すぐに問い合わせできる |
| 価格帯 | 予算に合うか判断できる |
名古屋で飲食店、美容院、クリニック、小売店などを運営されている方は、LocalBusiness構造化データの実装が集客力向上の鍵となります。
構造化データの記述形式

構造化データを実装する際、どのような記述形式(シンタックス)を使うかは重要な選択です。
ここでは、主要な記述形式とその特徴、そしてGoogleが推奨する形式について詳しく解説します。
JSON-LD形式の特徴とメリット
JSON-LD(JavaScript Object Notation for Linked Data)は、現在最も推奨されている構造化データの記述形式です。
JSON-LDの最大の特徴は、HTMLとは独立してデータを記述できるという点です。
通常のHTMLコードとは別に、scriptタグ内にJSON形式でデータを記述するため、既存のHTMLコードを変更する必要がありません。
JSON-LD形式のメリットは以下の通りです。
- HTMLコードを汚さない
- 既存のHTMLを変更せずに実装できる
- ページのどこに記述しても動作する(headタグ内でもbodyタグ内でも可)
- 複雑な階層構造も分かりやすく記述できる
- CMSやプラグインで一括実装しやすい
特に、HTMLコードを汚さないという点は大きなメリットです。
Microdataなど他の形式では、HTMLの各要素に直接属性を追加する必要がありますが、JSON-LDではそのような変更は不要です。
| JSON-LDの特徴 | 具体的なメリット | 実務上の効果 |
| HTMLから独立 | 既存コードの変更不要 | 実装の手間が少ない |
| 記述場所の自由度 | headでもbodyでもOK | メンテナンスしやすい |
| JSON形式 | 読みやすく理解しやすい | エラーが起きにくい |
| CMS対応 | 一括実装が容易 | 大規模サイトでも管理しやすい |
また、JSON-LDはJavaScript開発者にとって馴染みのある記法であるため、エンジニアが理解しやすく、実装ミスも少ないという利点があります。
さらに、Google Tag Managerなどのタグマネジメントツールを使えば、HTMLファイルを直接編集することなく、JSON-LD構造化データを追加・管理することも可能です。
これにより、マーケティング担当者が自らSEO施策を実行できるという環境も整えられます。
Microdata形式の特徴
Microdataは、HTML5で導入された構造化データの記述形式です。
HTMLの各要素に直接属性を追加することで、その要素の意味を明示します。
Microdataの特徴は、表示される内容とデータが直接結びついているという点です。
例えば、「サクラ商事」という会社名を表示するHTMLが以下だとします。
<span>サクラ商事</span>
“`
これをMicrodataで構造化すると、以下のようになります。
“`
<span itemprop=”name”>サクラ商事</span>
このように、HTMLタグに直接「itemprop=”name”」という属性を追加することで、「この部分は名前である」という意味を持たせます。
Microdataのメリットは以下の通りです。
- 表示内容とデータが一致するため、データの整合性が保たれやすい
- HTMLを見れば、どの部分が構造化されているか一目で分かる
- 動的に生成されるコンテンツにも対応しやすい
一方で、Microdataにはデメリットもあります。
- HTMLコードが複雑になる
- 既存のHTMLを大幅に変更する必要がある
- 階層構造が複雑な場合、記述が煩雑になる
JSON-LDの登場以降、Microdataの使用頻度は減少傾向にあります。
ただし、既存のサイトでMicrodataを使用していて、正しく動作している場合は、無理に変更する必要はありません。
Googleが推奨する記述形式
Googleが公式に推奨しているのは、JSON-LD形式です。
Google Search CentralのドキュメントやGoogle Developer向けガイドラインでは、明確にJSON-LDの使用が推奨されています。
その理由は、以下の通りです。
- 実装と管理が最も容易である
- HTMLコードへの影響が最小限である
- エラーが起きにくく、デバッグしやすい
- 動的に生成されるコンテンツにも対応しやすい
Googleの公式ドキュメントには、「一般的に、Googleは実装と管理が最も容易な形式(ほとんどの場合はJSON-LD)を推奨します」と明記されています。
ただし、重要な注意点として、MicrosoftのBingはJSON-LDを公式にサポートしていないという点があります。
Bing検索でのSEOも重視する場合は、MicrodataやRDFaの使用を検討する必要があります。
しかし、日本国内の検索市場ではGoogleが圧倒的なシェアを持っているため、多くの企業にとってはJSON-LDの実装で十分と言えるでしょう。
また、JSON-LDとMicrodataを併用することも可能です。
例えば、主要な構造化データはJSON-LDで実装し、特定の要素だけMicrodataで補完するという方法も選択肢の一つです。
| 記述形式 | Googleの推奨度 | 実装の容易さ | Bingの対応 |
| JSON-LD | ★★★(強く推奨) | ★★★(簡単) | ×(非対応) |
| Microdata | ★★(対応) | ★★(やや複雑) | ○(対応) |
| RDFa | ★★(対応) | ★(複雑) | ○(対応) |
Schema.orgのボキャブラリー
構造化データを記述する際、「何を」記述するかを定義するのがボキャブラリーです。
Schema.orgは、Google、Microsoft、Yahoo!が共同で策定した構造化データのボキャブラリーで、最も広く使われています。
Schema.orgでは、様々な「タイプ」と「プロパティ」が定義されています。
タイプとは、「これは何についてのデータか」を示すもので、例えば以下のようなものがあります。
- Person(人物)
- Organization(組織)
- Product(商品)
- Article(記事)
- Event(イベント)
- Place(場所)
- Recipe(レシピ)
これらのタイプは階層構造になっており、より具体的なタイプほど、詳細な情報を記述できるようになっています。
例えば、Organizationタイプには、以下のようなサブタイプがあります。
- Corporation(株式会社)
- EducationalOrganization(教育機関)
- GovernmentOrganization(政府機関)
- NGO(非政府組織)
- SportsOrganization(スポーツ団体)
プロパティとは、各タイプに関する具体的な属性を示すもので、例えばOrganizationタイプには以下のようなプロパティがあります。
- name(名前)
- url(URL)
- logo(ロゴ)
- address(住所)
- telephone(電話番号)
- email(メールアドレス)
- foundingDate(設立日)
- founder(創業者)
Schema.orgのボキャブラリーは継続的に更新されており、新しいタイプやプロパティが定期的に追加されています。
最新の情報は、Schema.org公式サイト(https://schema.org/)で確認できます。
Schema.orgを使う際のポイントは、自社のビジネスやコンテンツに最も適したタイプを選択することです。
例えば、レストランのWebサイトであれば、単なるLocalBusinessではなく、より具体的なRestaurantタイプを使うことで、メニューや料理の種類、価格帯などの詳細情報も記述できます。
名古屋のWebコンサル会社として、様々な業種の企業様をサポートしてきた経験から言えることは、業種ごとに適切なSchema.orgのタイプを選ぶことが、構造化データの効果を最大化する鍵だということです。
構造化データの実装方法

構造化データの重要性を理解したら、次は実際の実装方法を学びましょう。
ここでは、様々な実装方法について、具体的な手順とサンプルコードを交えて解説します。
手動でHTMLに記述する方法
最も基本的な実装方法が、HTMLファイルに直接JSON-LDコードを記述する方法です。
この方法は、細かい調整が可能で、自由度が高いという特徴があります。
手動実装の基本的な流れは以下の通りです。
- Schema.orgで適切なタイプとプロパティを確認する
- JSON-LD形式でコードを作成する
- HTMLファイルのheadタグまたはbodyタグ内に記述する
- リッチリザルトテストで検証する
- 問題がなければ本番環境に反映する
手動実装のメリットは、完全にカスタマイズできるという点です。
自社のビジネスに最適な構造化データを、細部まで調整しながら実装できます。
一方で、HTMLやJSON形式の知識が必要であり、ページ数が多い場合は作業量が増えるというデメリットもあります。
| 手動実装のメリット | 手動実装のデメリット |
| 完全にカスタマイズ可能 | HTMLやJSONの知識が必要 |
| 細かい調整ができる | ページ数が多いと時間がかかる |
| 外部ツールに依存しない | 更新作業に手間がかかる |
| コードの品質を管理できる | ヒューマンエラーのリスクがある |
JSON-LDのサンプルコード例
実際のJSON-LDコードを見てみましょう。
まず、記事(Article)の基本的なサンプルコードです。
json
<script type=”application/ld+json”>
{
“@context”: “https://schema.org”,
“@type”: “Article”,
“headline”: “SEOの構造化データとは?実装方法とメリットを徹底解説”,
“image”: “https://example.com/images/structured-data.jpg”,
“author”: {
“@type”: “Person”,
“name”: “山田太郎”
},
“publisher”: {
“@type”: “Organization”,
“name”: “株式会社エッコ”,
“logo”: {
“@type”: “ImageObject”,
“url”: “https://example.com/logo.png”
}
},
“datePublished”: “2025-01-15”,
“dateModified”: “2025-01-20”
}
</script>
このコードの構造を分解すると、以下のようになります。
- @context: Schema.orgを使用することを宣言
- @type: これは記事(Article)であることを示す
- headline: 記事のタイトル
- image: 記事の代表画像URL
- author: 著者情報(Personタイプのオブジェクト)
- publisher: 発行者情報(Organizationタイプのオブジェクト)
- datePublished: 公開日
- dateModified: 最終更新日
次に、企業情報(Organization)のサンプルコードです。
json
<script type=”application/ld+json”>
{
“@context”: “https://schema.org”,
“@type”: “Corporation”,
“name”: “株式会社エッコ”,
“url”: “https://example.com”,
“logo”: “https://example.com/logo.png”,
“description”: “名古屋を拠点とするWebコンサルティング会社”,
“address”: {
“@type”: “PostalAddress”,
“streetAddress”: “○○区○○町1-2-3”,
“addressLocality”: “名古屋市”,
“addressRegion”: “愛知県”,
“postalCode”: “460-0000”,
“addressCountry”: “JP”
},
“telephone”: “+81-52-1234-5678”,
“email”: “info@example.com”,
“foundingDate”: “2010-04-01”,
“sameAs”: [
“https://www.facebook.com/example”,
“https://twitter.com/example”,
“https://www.linkedin.com/company/example”
]
}
</script>
このコードでは、address(住所)がPostalAddressタイプのネストされたオブジェクトになっている点に注目してください。
これにより、住所を構成する各要素(都道府県、市区町村、番地など)を詳細に記述できます。
最後に、地域ビジネス(LocalBusiness)のサンプルコードです。
json
<script type=”application/ld+json”>
{
“@context”: “https://schema.org”,
“@type”: “Restaurant”,
“name”: “レストランさくら”,
“image”: “https://example.com/restaurant.jpg”,
“address”: {
“@type”: “PostalAddress”,
“streetAddress”: “栄3-4-5”,
“addressLocality”: “名古屋市”,
“addressRegion”: “愛知県”,
“postalCode”: “460-0008”,
“addressCountry”: “JP”
},
“geo”: {
“@type”: “GeoCoordinates”,
“latitude”: 35.1706,
“longitude”: 136.9066
},
“telephone”: “+81-52-9876-5432”,
“servesCuisine”: “日本料理”,
“priceRange”: “¥¥”,
“openingHoursSpecification”: [
{
“@type”: “OpeningHoursSpecification”,
“dayOfWeek”: [“Monday”, “Tuesday”, “Wednesday”, “Thursday”, “Friday”],
“opens”: “11:30”,
“closes”: “22:00”
},
{
“@type”: “OpeningHoursSpecification”,
“dayOfWeek”: [“Saturday”, “Sunday”],
“opens”: “11:00”,
“closes”: “23:00”
}
],
“acceptsReservations”: “True”
}
</script>
このコードでは、営業時間を平日と週末で分けて記述している点がポイントです。
openingHoursSpecificationを配列で記述することで、複数の営業時間パターンを設定できます。
必須プロパティと推奨プロパティ
構造化データには、必須プロパティと推奨プロパティがあります。
必須プロパティは、そのタイプの構造化データを有効にするために必ず記述しなければならない項目です。
推奨プロパティは、必須ではありませんが、記述することでリッチリザルトが表示される可能性が高まる項目です。
例えば、Article(記事)タイプの場合、以下のプロパティが必要です。
必須プロパティ:
- headline(見出し)
- image(画像)
- datePublished(公開日)
推奨プロパティ:
- author(著者)
- publisher(発行者)
- dateModified(更新日)
- description(説明)
Product(商品)タイプの場合は、以下のようになります。
必須プロパティ:
- name(商品名)
- image(商品画像)
- offers(販売情報) – 価格と在庫状況を含む
推奨プロパティ:
- description(商品説明)
- brand(ブランド)
- aggregateRating(総合評価)
- review(レビュー)
- sku(商品コード)
重要なのは、必須プロパティを満たさないと、構造化データがエラーとなり、リッチリザルトが表示されないという点です。
一方、推奨プロパティは、多く記述するほどリッチリザルトの表示確率が高まります。
ただし、Googleの公式ドキュメントには「完全でないデータ、不正な形式のデータ、不正確なデータを含む多数の推奨プロパティを提供するより、少数であっても完全で正確な推奨プロパティを提供するほうが重要」と記載されています。
つまり、量よりも質を重視し、正確なデータを記述することが最も大切です。
| タイプ | 必須プロパティ | 推奨プロパティの重要度 |
| Article | headline, image, datePublished | 高(author, publisherが特に重要) |
| Product | name, image, offers | 非常に高(価格と評価が表示に直結) |
| Event | name, startDate, location | 高(チケット情報が重要) |
| LocalBusiness | name, address | 高(営業時間と電話番号が重要) |
| FAQ | mainEntity(質問と回答) | 中(質問の質が重要) |
各タイプの詳細な必須・推奨プロパティは、Google Search Central(https://developers.google.com/search/docs/appearance/structured-data/search-gallery)で確認できます。
構造化データマークアップ支援ツールの使い方
HTMLやJSONの知識がない方でも構造化データを実装できるのが、Googleが提供する構造化データマークアップ支援ツールです。
このツールを使えば、画面上でテキストを選択するだけで、自動的にJSON-LDコードを生成できます。
ただし、2021年以降、このツールは段階的に機能が縮小されており、現在は限定的な用途でのみ利用可能です。
それでも、初めて構造化データを実装する方にとっては、学習教材として有用です。
マークアップ支援ツールの基本的な使い方を見ていきましょう。
タグ付けの手順
構造化データマークアップ支援ツールを使ったタグ付けの手順は以下の通りです。
ステップ1: ツールにアクセスする
Googleで「構造化データマークアップ支援ツール」と検索し、公式ツールにアクセスします。
ステップ2: データタイプを選択する
以下のデータタイプから、マークアップしたい種類を選択します。
- 記事
- 地域のお店やサービス
- レストラン
- 映画
- 書籍
- イベント
- 商品
- ソフトウェアアプリケーション
- テレビ番組のエピソード
例えば、ブログ記事をマークアップする場合は「記事」を選択します。
ステップ3: URLまたはHTMLを入力する
マークアップしたいページのURLを入力するか、HTMLコードを直接貼り付けます。
公開前のページの場合は、HTMLコードを貼り付ける方法が便利です。
ステップ4: タグ付けを開始する
「タグ付けを開始」ボタンをクリックすると、ページが読み込まれます。
ステップ5: 要素を選択してタグ付けする
ページ内のテキストや画像をマウスでドラッグして選択すると、データタイプに応じたタグの選択肢が表示されます。
例えば、記事のタイトルをドラッグすると、以下のような選択肢が現れます。
- 名前(記事のタイトル)
- 著者
- 公開日
- 画像
- 記事のセクション
「名前」を選択すると、右側のパネルに選択した内容が追加されます。
同様に、著者名、公開日、画像など、必要な要素を順次タグ付けしていきます。
ステップ6: すべての必須項目をタグ付けする
右側のパネルに、赤い警告マークが付いている項目は必須項目です。
これらをすべてタグ付けするまで、有効な構造化データは生成されません。
| タグ付けのポイント | 説明 |
| 正確に選択する | タグ付けしたい部分だけを正確にドラッグする |
| 必須項目を優先する | 赤い警告マークの項目を先に埋める |
| 推奨項目も追加する | 時間があれば推奨項目も追加してリッチ度を高める |
| 誤ったタグ付けは削除する | 右側パネルで不要な項目は削除できる |
HTMLの取得と実装
タグ付けが完了したら、生成されたコードを取得します。
ステップ7: HTMLを作成する
画面右上の「HTMLを作成」ボタンをクリックします。
すると、タグ付けした内容がJSON-LD形式のコードに変換されて表示されます。
ステップ8: コードをコピーする
生成されたJSON-LDコードをコピーします。
コードは以下のような形式になっています。
json
<script type=“application/ld+json”>
{
“@context”: “https://schema.org”,
“@type”: “Article”,
…
}
</script>
ステップ9: HTMLファイルに貼り付ける
コピーしたコードを、対象ページのHTMLファイルの<head>タグ内または<body>タグ内に貼り付けます。
一般的には、headタグ内に記述することが推奨されています。
ステップ10: テストして公開する
リッチリザルトテストで生成されたコードをテストし、エラーがなければ本番環境に公開します。
マークアップ支援ツールの注意点として、生成されるコードが必ずしも完璧ではないという点があります。
特に、複雑な構造のページや、動的に生成されるコンテンツには対応しきれない場合があります。
そのため、生成されたコードは必ずテストツールで検証し、必要に応じて手動で修正することが重要です。
WordPressでの実装方法
WordPressを使っている場合、プラグインを活用することで、より簡単に構造化データを実装できます。
WordPressは世界中のWebサイトの約40%で使用されているCMSであり、構造化データ対応のプラグインも豊富に揃っています。
主要なWordPress構造化データプラグインは以下の通りです。
1.Yoast SEO
最も人気のあるSEOプラグインの一つで、構造化データの自動生成機能も備えています。
- 記事、ページ、商品の構造化データを自動生成
- Schema.orgのタイプを詳細に設定可能
- パンくずリスト構造化データも自動対応
- 組織情報や個人情報の設定が可能
Yoast SEOの無料版でも基本的な構造化データは実装できますが、プレミアム版では、より高度な設定が可能になります。
2.Rank Math
Yoast SEOと並ぶ人気のSEOプラグインで、構造化データ機能も充実しています。
- 15種類以上のSchema.orgタイプに対応
- 記事ごとにカスタム設定が可能
- FAQやHow-toブロックの追加機能
- リッチリザルトのプレビュー機能
Rank Mathは無料版でも多くの機能が使えるため、コストパフォーマンスが高いのが特徴です。
3.Schema Pro
構造化データに特化した専門プラグインです。
- 30種類以上のSchema.orgタイプに対応
- 条件分岐による自動設定が可能
- カスタムフィールドとの連携
- WooCommerceとの完全統合
Schema Proは有料プラグインですが、ECサイトや複雑な構造のサイトには特に効果的です。
| プラグイン | 特徴 | 価格 | 適している用途 |
| Yoast SEO | 総合的なSEO対策 | 無料/有料(€99/年) | ブログ、企業サイト |
| Rank Math | 豊富な無料機能 | 無料/有料($59/年) | 中小規模サイト |
| Schema Pro | 構造化データ特化 | 有料($79/年) | ECサイト、複雑なサイト |
| WP Recipe Maker | レシピ特化 | 無料/有料 | 料理ブログ |
WordPressプラグインで構造化データを実装する際の注意点は、プラグインの重複です。
複数のSEOプラグインを同時に有効化すると、同じ構造化データが重複して出力される可能性があります。
そのため、一つのプラグインに絞って使用することが推奨されます。
また、テーマによっては、標準で構造化データが実装されている場合もあります。
プラグインを導入する前に、現在のサイトでどのような構造化データが既に出力されているか確認することが重要です。
名古屋を拠点とする企業様で、WordPressを使ったWebサイトを運営されている場合、適切なプラグイン選定から実装までをサポートすることも可能です。
データハイライターの活用
データハイライターは、HTMLコードを一切変更せずに、構造化データをGoogleに伝えられるツールです。
Google Search Console内で提供されており、マウス操作だけで構造化データを設定できます。
データハイライターは、以下のような状況で特に有効です。
- HTMLの編集権限がない場合
- CMSが構造化データに対応していない場合
- 一時的に構造化データを試したい場合
- 技術的な知識がない担当者でも設定したい場合
データハイライターの使い方は以下の通りです。
ステップ1: Google Search Consoleにログインする
まず、対象サイトのGoogle Search Consoleにアクセスします。
ステップ2: データハイライターを開く
左側メニューから「データハイライター」を選択します。
(注: 現在、データハイライターは段階的に廃止される方向にあり、一部のサイトでは利用できない可能性があります)
ステップ3: ハイライト表示を開始する
「ハイライト表示を開始」ボタンをクリックし、対象ページのURLとデータタイプを選択します。
ステップ4: ページ内の要素をタグ付けする
ページが読み込まれたら、マウスで要素を選択し、その意味を指定していきます。
例えば、イベント情報ページの場合:
- イベント名をクリック → 「名前」を選択
- 開催日をクリック → 「開始日」を選択
- 場所をクリック → 「場所」を選択
ステップ5: 類似ページを指定する
一つのページでタグ付けを完了すると、「このページだけをタグ付けする」または「このページをタグ付けし、他のページも同様にタグ付けする」を選択できます。
後者を選択すると、同じレイアウトの他のページにも、自動的にタグ付けが適用されます。
ステップ6: ページセットを作成する
複数ページに適用する場合、どのページに適用するかをURLパターンで指定します。
例: https://example.com/event/* (eventディレクトリ配下のすべてのページ)
ステップ7: 公開する
設定が完了したら「公開」ボタンをクリックします。
データハイライターのメリットは、HTMLを変更しなくて良いという点です。
しかし、いくつかの制限もあります。
- 対応しているデータタイプが限定的
- Google専用であり、他の検索エンジンには効果がない
- ページ構造が変わると再設定が必要
- JSON-LDに比べて表現力が限定的
そのため、データハイライターは一時的な対応や、技術的な制約がある場合の代替手段として考えるのが適切です。
長期的には、HTMLに直接JSON-LDを実装する方が、柔軟性と安定性が高いと言えます。
| 実装方法 | メリット | デメリット | 推奨される状況 |
| 手動でHTML編集 | 完全にカスタマイズ可能 | 技術知識が必要 | 小規模サイト、完全な制御が必要な場合 |
| WordPressプラグイン | 簡単に実装できる | プラグインへの依存 | WordPressサイト |
| マークアップ支援ツール | 技術知識不要 | 複雑な構造に対応しづらい | 学習目的、シンプルなページ |
| データハイライター | HTML変更不要 | 機能が限定的 | 一時的な対応、技術的制約がある場合 |
構造化データのテストと検証

構造化データを実装したら、必ずテストと検証を行うことが重要です。
正しく実装されていない構造化データは、エラーを引き起こしたり、リッチリザルトが表示されなかったりする可能性があります。
ここでは、Googleが提供する各種テストツールの使い方と、よくあるエラーの対処法について解説します。
リッチリザルトテストツールの使い方
リッチリザルトテストは、構造化データが正しく実装されているかを確認する最新のツールです。
2020年以降、Googleは構造化データテストツールから、このリッチリザルトテストへの移行を推奨しています。
リッチリザルトテストの特徴は以下の通りです。
- リッチリザルト対応の構造化データのみをテストする
- モバイルとデスクトップの両方でテスト可能
- 実際の検索結果でどのように表示されるかプレビューできる
- Googleがサポートしている機能に特化している
リッチリザルトテストの使い方は以下の通りです。
ステップ1: ツールにアクセスする
Google検索で「リッチリザルトテスト」と検索し、公式ツールにアクセスします。
URLは: https://search.google.com/test/rich-results
ステップ2: URLまたはコードを入力する
以下の2つの方法でテストできます。
- 公開済みのページの場合: URLを入力してテスト
- 未公開ページの場合: HTMLコード全体を貼り付けてテスト
ステップ3: テストを実行する
「URLをテスト」または「コードをテスト」ボタンをクリックします。
数秒から数十秒で、テスト結果が表示されます。
ステップ4: 結果を確認する
テスト結果は、以下の3つの状態で表示されます。
- 有効: 構造化データが正しく実装されており、リッチリザルトが表示される可能性がある
- 有効(警告あり): 基本的に有効だが、推奨プロパティが不足している
- 無効: 必須プロパティが不足しているか、エラーがある
ステップ5: エラーや警告を修正する
エラーや警告が表示された場合、詳細をクリックすると、どのプロパティに問題があるかが表示されます。
- エラーメッセージを読む
- 該当するプロパティを確認する
- コードを修正する
- 再度テストする
このプロセスを繰り返し、すべてのエラーを解消します。
ステップ6: プレビューを確認する
「プレビュー」タブをクリックすると、実際の検索結果でどのように表示されるかのイメージが見られます。
ただし、これはあくまで参考イメージであり、実際の検索結果と完全に一致するわけではない点に注意してください。
| テスト項目 | 確認ポイント |
| エラーの有無 | 赤いエラーマークがないか |
| 警告の内容 | 黄色の警告は推奨プロパティの不足を示す |
| 検出された機能 | どのリッチリザルトタイプが検出されたか |
| プレビュー | 期待通りの表示になっているか |
構造化データテストツールでのエラー確認
構造化データテストツールは、すべての構造化データをテストできる旧来のツールです。
リッチリザルトテストがリッチリザルト対応の構造化データのみをテストするのに対し、このツールはSchema.orgのすべてのタイプをテストできるという特徴があります。
そのため、リッチリザルト以外の構造化データ(例: 組織情報、個人情報など)をテストする場合は、このツールが有効です。
構造化データテストツールの使い方は以下の通りです。
ステップ1: ツールにアクセスする
URLは: https://validator.schema.org/
(Googleの構造化データテストツールは2021年に廃止されましたが、Schema.org公式のバリデーターが利用可能です)
ステップ2: コードを入力する
URLまたはコードスニペットを入力します。
ステップ3: 構造化データの構造を確認する
右側のパネルに、検出された構造化データの構造がツリー形式で表示されます。
- どのタイプが検出されたか
- どのプロパティが設定されているか
- ネストされた構造がどうなっているか
これにより、構造化データの全体像を視覚的に把握できます。
ステップ4: エラーと警告を確認する
赤い「エラー」と黄色の「警告」が表示されます。
エラーは必ず修正が必要ですが、警告は推奨プロパティの不足などを示すため、状況に応じて対応を判断します。
構造化データテストツールとリッチリザルトテストの使い分けは以下の通りです。
- リッチリザルトテスト: リッチリザルト表示を目的とする構造化データのテスト
- Schema.orgバリデーター: すべての構造化データの文法チェック
両方のツールを使って、多角的に検証することが理想的です。
Google Search Consoleでの確認方法
構造化データを実装して公開した後は、Google Search Consoleで継続的に監視することが重要です。
Search Consoleでは、サイト全体の構造化データの状況を一覧で確認できます。
Search Consoleでの確認手順は以下の通りです。
ステップ1: Search Consoleにログインする
対象サイトのGoogle Search Consoleにアクセスします。
ステップ2: 拡張メニューから該当項目を選択する
左側メニューの「拡張」セクションに、実装されている構造化データのタイプごとに項目が表示されます。
- パンくずリスト
- FAQ
- 商品
- レシピ
- 記事
- イベント
- ビデオ
など、サイトに実装されている構造化データのタイプが表示されます。
ステップ3: エラーや警告を確認する
各項目をクリックすると、以下の情報が表示されます。
- 有効なページ数
- エラーがあるページ数
- 警告があるページ数
グラフで推移を確認できるため、新たにエラーが発生していないか定期的にチェックすることができます。
ステップ4: 個別のエラーを確認する
「エラーがあるアイテム」をクリックすると、どのページでどのようなエラーが発生しているか詳細が表示されます。
エラーメッセージをクリックすると、該当するURLの一覧が表示されます。
ステップ5: エラーを修正する
エラーを特定したら、該当ページのHTMLを修正します。
修正後、Search Console上で「修正を検証」ボタンをクリックすると、Googleが再クロールしてエラーが解消されたか確認します。
検証には数日から数週間かかる場合があります。
ステップ6: リッチリザルトのパフォーマンスを確認する
「検索パフォーマンス」レポートで、「検索での見え方」フィルターを使うと、リッチリザルトが表示されたクエリでのパフォーマンスを確認できます。
これにより、構造化データの実装がクリック率向上にどの程度貢献しているかを測定できます。
| Search Consoleでできること | 具体的な内容 |
| エラーの検出 | サイト全体の構造化データエラーを一覧表示 |
| パフォーマンス測定 | リッチリザルト表示時のクリック率や表示回数 |
| 修正の検証 | エラー修正後の再クロールを依頼 |
| 推移の確認 | 時系列でエラー数の増減を確認 |
よくあるエラーと解決方法
構造化データの実装でよく発生するエラーと、その解決方法をまとめます。
エラー1: 必須プロパティが不足している
最も頻繁に発生するエラーが、必須プロパティの不足です。
- エラーメッセージ: 「必須フィールド “○○” がありません」
- 原因: そのタイプに必要な必須プロパティが記述されていない
- 解決方法: Google Search Centralのドキュメントで必須プロパティを確認し、追加する
例えば、Articleタイプでimageプロパティが不足している場合、以下のように追加します。
json
“image”: “https://example.com/article-image.jpg”
エラー2: 日付形式が不正
日付の形式が間違っているケースも多く見られます。
- エラーメッセージ: 「datePublishedの値が無効です」
- 原因: 日付がISO 8601形式になっていない
- 解決方法: YYYY-MM-DDまたはYYYY-MM-DDTHH:MM:SS+09:00形式に修正する
正しい形式の例:
json
“datePublished”: “2025-01-15”
“datePublished”: “2025-01-15T10:30:00+09:00”
エラー3: 画像URLが不正
画像のURLに問題があるケースです。
- エラーメッセージ: 「imageプロパティのURLにアクセスできません」
- 原因: 画像URLが間違っているか、アクセスできない
- 解決方法: 画像URLが正しいか、画像ファイルが存在するか確認する
また、画像は以下の条件を満たす必要があります。
- httpまたはhttpsプロトコルを使用
- robots.txtでクロールがブロックされていない
- 推奨サイズ: 幅1,200px以上
- アスペクト比: 16:9、4:3、1:1
エラー4: 価格情報の通貨が不足
商品構造化データで価格を記述する際のエラーです。
- エラーメッセージ: 「priceCurrencyが不足しています」
- 原因: 価格は記述したが通貨コードが不足している
- 解決方法: ISO 4217通貨コードを追加する
json
“offers”: {
“@type”: “Offer”,
“price”: “5000”,
“priceCurrency”: “JPY”
}
エラー5: 構造化データが重複している
同じページに同じタイプの構造化データが複数存在する場合のエラーです。
- エラーメッセージ: 「重複する構造化データが検出されました」
- 原因: テーマとプラグインの両方から構造化データが出力されている
- 解決方法: どちらか一方を無効にする
WordPressの場合、テーマの機能とプラグインの機能が競合することがあります。
どちらか一方を無効化することで解決します。
エラー6: ユーザーに表示されないコンテンツのマークアップ
Googleガイドラインに違反するエラーです。
- エラーメッセージ: 「マークアップされたコンテンツがページに表示されていません」
- 原因: 構造化データに記述した内容が、実際のページには表示されていない
- 解決方法: ページ上に表示されている情報のみを構造化データとして記述する
これは非常に重要なガイドラインで、違反すると手動ペナルティの対象となる可能性があります。
| エラーの種類 | 深刻度 | 対処の優先度 |
| 必須プロパティ不足 | 高 | 最優先(リッチリザルトが表示されない) |
| 推奨プロパティ不足 | 中 | 中程度(表示の質に影響) |
| 形式エラー | 高 | 最優先(認識されない) |
| ガイドライン違反 | 非常に高 | 最優先(ペナルティのリスク) |
構造化データのエラーは、定期的にSearch Consoleでチェックし、早期に対処することが重要です。
特に、サイトのデザイン変更やCMSのアップデート後は、構造化データが正常に出力されているか必ず確認しましょう。
構造化データ実装時の注意点

構造化データは正しく実装すれば大きな効果を生みますが、誤った使い方をするとペナルティのリスクもあります。
ここでは、構造化データを実装する際に必ず守るべき注意点について解説します。
ページ内容と一致した情報を記述する
構造化データに記述する情報は、必ずページ上に表示されている内容と一致していなければなりません。
これは、Googleの構造化データガイドラインの中でも、最も重要なルールの一つです。
例えば、以下のような行為は禁止されています。
- 実際の商品価格は5,000円なのに、構造化データには3,000円と記述する
- ページに存在しないレビューを構造化データに記述する
- 実際の著者と異なる人物を構造化データに記述する
- ページに表示されていない営業時間を構造化データに記述する
なぜこのルールが重要なのでしょうか?
それは、構造化データがユーザーに誤った情報を提供し、期待と実際の内容にギャップを生む可能性があるからです。
例えば、検索結果で「3,000円」と表示されていたのに、実際のページを開いたら「5,000円」だった場合、ユーザーは騙されたと感じるでしょう。
このようなユーザー体験の悪化を防ぐため、Googleは非常に厳格にこのルールを適用しています。
違反した場合、以下のようなペナルティが科される可能性があります。
- リッチリザルトの表示停止
- 手動による対策(ペナルティ)
- サイト全体での構造化データ機能の無効化
実装時のチェックポイントは以下の通りです。
| チェック項目 | 確認方法 |
| 価格情報 | ページ表示価格と構造化データの価格が一致しているか |
| 在庫状況 | 実際の在庫状況と構造化データが一致しているか |
| 営業時間 | 最新の営業時間が反映されているか |
| レビュー | 実在するレビューのみが記述されているか |
| イベント日時 | 正確な開催日時が記述されているか |
定期的にページ内容を更新する場合は、構造化データも同時に更新する仕組みを整えることが重要です。
ユーザーに見えない情報は記述しない
ユーザーがページ上で見ることができない情報を、構造化データに記述してはいけません。
これは、前述の「ページ内容との一致」とも関連する重要なルールです。
具体的に禁止されている例は以下の通りです。
- CSSでdisplay: none;にしている要素の情報を構造化データに記述する
- ページの見えない場所(画面外)に配置した情報を構造化データに記述する
- モーダルウィンドウやタブで非表示になっている情報を無条件に記述する
- ユーザーがアクションを起こさないと見られない情報を記述する
ただし、例外もあります。
折りたたみ式のアコーディオンメニューや、タブ切り替えで表示される情報は、構造化データに記述しても問題ありません。
これは、ユーザーがクリックすれば見られる情報だからです。
特にFAQ構造化データでは、質問と回答がアコーディオン形式になっているケースが多く、これは許容されています。
判断の基準は、**「通常のユーザー操作で、簡単にその情報にアクセスできるか」**です。
- ページを開いた時点で見える → OK
- スクロールすれば見える → OK
- タブやアコーディオンをクリックすれば見える → OK
- 特定の条件下でのみ表示される → NG
- CSSで完全に非表示にしている → NG
また、構造化データを使って、検索結果にだけ表示される特別な情報を追加することも禁止されています。
例えば、ページには書いていない割引情報を、構造化データにだけ記述して検索結果に表示させる、といった行為は違反です。
構造化データは、あくまでページ上の情報を検索エンジンに分かりやすく伝えるためのものであり、新しい情報を追加するためのものではありません。
Googleガイドラインの遵守
構造化データを実装する際は、Googleの構造化データに関するガイドラインを必ず遵守する必要があります。
主要なガイドラインは以下の通りです。
技術に関するガイドライン:
- 構造化データは正しい形式(JSON-LD、Microdata、RDFa)で記述する
- 必須プロパティをすべて含める
- 複数のタイプの構造化データを1ページに記述できる
- ページの複数の場所に構造化データを配置できる
品質に関するガイドライン:
- 最新の情報を提供する
- オリジナルのコンテンツを提供する
- ページの主要コンテンツをマークアップする
- 誤解を招く情報を記述しない
- ユーザーに表示されない情報を記述しない
コンテンツに関するガイドライン:
- スパム的な情報を含めない
- 不適切なコンテンツをマークアップしない
- 著作権を侵害する情報を記述しない
- 違法な活動に関する情報を記述しない
特に重要なのが、レビュー構造化データに関するガイドラインです。
自社で作成した架空のレビューや、金銭を支払って書いてもらったレビューを構造化データとして記述することは、明確に禁止されています。
構造化データに記述できるレビューは、実際のユーザーが自発的に投稿した本物のレビューのみです。
また、商品構造化データにおいても、以下のような行為は禁止されています。
- 在庫がないのに「在庫あり」と記述する
- 実際の価格より安い価格を記述する
- 販売していない商品を「販売中」と記述する
| ガイドラインの種類 | 違反した場合の影響 |
| 技術ガイドライン | 構造化データが認識されない、エラーが発生する |
| 品質ガイドライン | リッチリザルトが表示されない可能性がある |
| スパムガイドライン | 手動ペナルティ、サイト全体での機能無効化 |
Googleのガイドラインは定期的に更新されるため、最新のガイドラインを定期的に確認することが重要です。
公式ドキュメント: https://developers.google.com/search/docs/appearance/structured-data/sd-policies
実装してもリッチリザルトが必ず表示されるわけではない
構造化データを正しく実装しても、リッチリザルトが必ず検索結果に表示されるとは限りません。
これは、多くの方が誤解しやすいポイントです。
構造化データは、リッチリザルト表示の必要条件ではあるが、十分条件ではないのです。
Googleは、以下のような様々な要因を考慮して、リッチリザルトを表示するかどうかを判断しています。
- 検索クエリとの関連性: そのクエリでリッチリザルトが適切かどうか
- ページの品質: コンテンツの質やユーザー体験
- 検索履歴: ユーザーの過去の検索行動
- 位置情報: ユーザーの所在地
- デバイスの種類: モバイルかデスクトップか
- 検索結果全体のバランス: 他の結果との兼ね合い
例えば、同じページでも、あるキーワードではリッチリザルトが表示され、別のキーワードでは表示されないということもあります。
また、Googleのアルゴリズムは、通常の青いリンクが最適だと判断することもあります。
リッチリザルトが表示されない主な理由は以下の通りです。
- 構造化データにエラーがある: まずはエラーを修正する
- ページの品質が低い: コンテンツの質を改善する
- ページがまだインデックスされていない: 時間を置いて再確認する
- Googleがそのクエリでリッチリザルトを表示しないと判断している: アルゴリズムの判断なので待つしかない
重要なのは、リッチリザルトが表示されなくても、構造化データには価値があるという点です。
構造化データがあることで、検索エンジンはページの内容をより正確に理解できます。
これは、適切なキーワードでのインデックス、ナレッジパネルへの情報提供、音声検索への対応など、様々な形でSEO効果をもたらします。
| リッチリザルトが表示されない理由 | 対処方法 |
| 構造化データにエラーがある | リッチリザルトテストでエラーを修正する |
| ページがインデックスされていない | Search Consoleでインデックスリクエストを送る |
| ページの品質が低い | コンテンツの質を改善する |
| Googleのアルゴリズム判断 | 引き続き正しい構造化データを維持する |
構造化データは、長期的なSEO戦略の一環として捉えることが重要です。
すぐに目に見える効果が出なくても、継続的に正しい構造化データを実装し続けることで、検索エンジンからの評価が高まっていきます。
名古屋でWebコンサルティングを行う株式会社エッコでは、構造化データの実装から効果測定まで、トータルでサポートしています。
「構造化データを実装したけど効果が見えない」「どのように改善すればいいか分からない」といったお悩みがあれば、お気軽にご相談ください。
まとめ

ここまで、SEOにおける構造化データについて、基礎知識から実装方法、注意点まで詳しく解説してきました。
最後に、重要なポイントをまとめます。
構造化データとは、検索エンジンがWebページの内容を理解しやすくするためのデータ形式です。
Schema.orgで定義されたボキャブラリーを使い、JSON-LD形式で記述することが推奨されています。
構造化データを実装することで、以下のようなメリットが得られます。
- リッチリザルトによるクリック率の向上(25%~82%の改善事例あり)
- 検索エンジンのクローラビリティ向上
- ナレッジパネルやGoogleマップでの情報表示
- 音声検索やAIアシスタントへの対応
ただし、構造化データは検索順位に直接的な影響を与えません。
あくまで、間接的にSEO効果をもたらす施策です。
主要な構造化データの種類としては、以下のものがあります。
- Article/BlogPosting(記事・ブログ)
- Product(商品情報)
- BreadcrumbList(パンくずリスト)
- FAQPage(よくある質問)
- VideoObject(動画)
- Review/AggregateRating(レビュー・評価)
- Event(イベント)
- Organization(組織・企業情報)
- LocalBusiness(地域ビジネス)
実装方法には、手動でHTMLに記述する方法、WordPressプラグインを使う方法、マークアップ支援ツールを使う方法などがあります。
自社のサイト規模や技術的なリソースに応じて、適切な方法を選択することが重要です。
実装後は、リッチリザルトテストやGoogle Search Consoleで必ず検証し、エラーがないことを確認しましょう。
構造化データ実装時の注意点としては、以下の4つが特に重要です。
- ページ内容と一致した情報を記述する
- ユーザーに見えない情報は記述しない
- Googleガイドラインを遵守する
- 実装してもリッチリザルトが必ず表示されるわけではないと理解する
構造化データは、一度実装すれば終わりではなく、継続的に管理・更新していく必要がある施策です。
ページ内容の変更に応じて構造化データも更新し、定期的にエラーチェックを行うことで、長期的な効果を維持できます。
構造化データは、現代のSEO対策において、もはや必須の施策と言えるでしょう。
特に、ECサイト、飲食店、イベント運営、コンテンツメディアなど、具体的な商品やサービス、情報を提供するサイトでは、大きな効果が期待できます。
名古屋を拠点とする企業様で、「構造化データを実装したいが、何から始めればいいか分からない」「実装したけど効果が出ているか不安」といったお悩みをお持ちの方は、ぜひ株式会社エッコにご相談ください。
SEO対策の専門家が、貴社のWebサイトに最適な構造化データの設計から実装、効果測定まで、トータルでサポートいたします。
構造化データを正しく活用して、検索結果での視認性を高め、より多くのユーザーに貴社の情報を届けましょう。
