構造化データとは？
小規模事業者のホームページで使う場面
構造化データとは、 ホームページに掲載している店舗名、住所、営業時間、 記事タイトル、著者、パンくずリストなどの情報を、 検索エンジンが項目ごとに理解しやすい形式で記述したデータです。 見た目を変更する文章ではなく、 HTML内へ追加する検索エンジン向けの補助情報として使われます。 適切な構造化データを設定すると、 Googleがページや事業者の情報を理解する手掛かりになり、 対応する検索機能では通常より情報量の多い リッチリザルトへ表示される資格を得られる場合があります。 ただし、正しく設定してもリッチリザルトの表示は保証されず、 構造化データだけで検索順位が上がるわけでもありません。 ページ上に見えていない情報、古い営業時間、 実在しない口コミなどを記述すると、 ガイドライン違反になる可能性があります。 本記事では、構造化データの意味、 schema.orgとGoogle対応機能の違い、 小規模事業者が使いやすいOrganization・LocalBusiness・Breadcrumb・Article、 WordPressでの導入方法、 リッチリザルトテストとSearch Consoleでの確認方法まで解説します。
項目別に伝える
店舗、組織、記事、階層などの意味を、決められた語彙と形式で検索エンジンへ示します。
情報だけを設定
トップ、店舗情報、記事、パンくずなど、ページの主題に合う種類を選びます。
Search Console
公開前に文法を検証し、公開後はGoogleが取得したデータとエラーを継続確認します。
構造化データは ページの意味を決まった項目で伝えるデータ
人が読める本文に加えて、検索エンジンが分類しやすい情報をHTML内へ記述します。
関係を明示
通常のページには、 店舗名、住所、電話番号、営業時間などが文章として掲載されています。 人は見出しや配置から意味を理解できますが、 検索エンジンにとっては、 どの文字列が正式名称で、 どれが住所や営業時間なのかを判断する手掛かりが必要です。
構造化データでは、 「このページは店舗について説明している」 「この文字列は店舗名」 「この値は電話番号」 「この日時は記事の公開日」 といった意味を、 標準化された種類とプロパティで記述します。
多くの構造化データでは、 共通語彙としてschema.orgが使われます。 schema.orgには非常に多くの種類と項目がありますが、 Google検索で特別な表示に利用される種類や必須項目は限られています。 Google検索での使い方は、 Google検索セントラルの各機能の公式資料を基準に確認します。
構造化データは検索結果の候補を広げるが 表示と順位を保証するものではない
正しく設定することは「リッチリザルトへ表示される資格」を得るための条件です。
Googleへ事業者、記事、パンくず、 商品、イベントなどの種類と詳細を伝えます。
構造化データがなくてもGoogleはページを理解しますが、明示的な手掛かりを追加できます。Googleが対応する種類で、 必須項目とガイドラインを満たすと、 拡張表示の対象になる場合があります。
実際に表示するかは、検索内容・端末・地域などを含めGoogleが判断します。営業時間、価格、公開日、 店舗情報などが変わったときに、 見える情報とデータを同時更新します。
古い情報を残すと、正しく記述されていても品質上の問題になります。サイトの業種ではなく 各ページが実際に説明する対象で種類を選ぶ
小規模事業者では、組織・店舗・パンくず・記事から確認すると整理しやすくなります。
会社・団体・事業者の正式名称、 ロゴ、URL、連絡先などをGoogleへ伝えるために使います。 通常はトップページへの設定を検討します。
実店舗や営業拠点の名称、住所、 電話番号、営業時間などを表します。 業種に合う具体的な下位タイプを選びます。
トップ、カテゴリ、現在ページなど、 サイト内での位置関係を表します。 実際のパンくずと同じ階層を記述します。
ブログ・コラム・ニュース記事の タイトル、画像、公開日、更新日、著者などを表します。
個別の商品ページで、 商品名、画像、価格、在庫、評価などを表します。 サービス紹介へ無理に商品データを使いません。
日時・会場・参加方法が明確な セミナー、催事、講座などのイベントページで使います。
ページ上で確認できる正確な情報を 必要な範囲で完全に記述する
文法の正しさだけでなく、表示内容との一致・最新性・関連性が必要です。
店舗、記事、商品、イベントなど、 ページが主に説明する対象を確認します。
必須プロパティ、推奨プロパティ、 画像や日付の要件、個別ガイドラインを確認します。
店名、価格、営業時間、公開日など、 利用者が画面上で確認できる内容と一致させます。
リッチリザルトの対象に必要な項目を満たし、 推奨項目は正確に管理できるものから追加します。
構造化データで指定した画像やページが、 robots.txt・noindex・認証で遮断されていないか確認します。
営業時間、住所、料金、公開日などを、 片方だけ古い状態で残さないようにします。
非表示の価格、存在しないサービス、 ページに掲載していない評価などを追加しません。
実際に収集していない口コミや、 ガイドライン対象外の自己評価を記述しません。
各ページの主題を無視して同じデータを大量出力せず、 店舗を説明する適切なページへ設定します。
不明な値を推測するより、 公式資料を確認し、正しい情報を用意してから公開します。
HTML本文を更新した際に、 プラグインやJSON-LDの値も更新します。
文法上正しくても、 内容が誤っている・誤解を招く場合は問題になります。
WordPressでは既存の自動出力を確認し 一つの管理方法へ整理する
テーマ・SEOプラグイン・専用プラグイン・独自コードの重複に注意します。
3形式へ対応
Google検索は、 JSON-LD、Microdata、RDFaの3形式をサポートしています。 どの形式でも正しく実装されていれば利用できますが、 Googleは一般的にJSON-LDを推奨しています。 JSON-LDはページ本文のHTMLタグへ直接属性を埋め込まず、 独立したデータとして管理しやすい形式です。
WordPressでは、 テーマやSEOプラグインがOrganization、WebSite、 Article、BreadcrumbListなどを自動出力していることがあります。 専用プラグインや独自コードを追加する前に、 公開ページのソースとリッチリザルトテストで 既に何が出力されているか確認します。
複数の機能から同じ種類が出力されても、 必ずエラーになるとは限りません。 しかし、名称・URL・ロゴ・住所などの値が食い違うと、 Googleがどの情報を信頼すべきか分かりにくくなります。 管理元を一つに寄せ、更新場所を明確にしましょう。
新しく導入する前に、 現在検出されている種類とエラーを確認します。
テーマ、SEOプラグイン、専用プラグイン、 headerコード、タグ管理を確認します。
事業者、店舗、パンくず、記事など、 実際のページ構成に合う範囲へ絞ります。
正式名称、ロゴ、住所、電話番号、 URLなどを公式情報へ統一します。
トップ、店舗情報、記事、 サービスなど、テンプレートごとに確認します。
設定変更が公開ページへ反映され、 古いデータや二重出力が残っていないか確認します。
公開前はテストツール 公開後はURL検査と拡張レポートで確認する
文法、Google対応、クロール後の認識を別々の道具で調べます。
ページまたはコードを入力し、 Google検索のどのリッチリザルトへ対応できるか、 重大なエラーがあるかを確認します。
検出されても実際の検索結果への表示を保証するものではありません。Googleのリッチリザルト対象外を含め、 schema.orgに基づく構造と文法を幅広く検証します。
Google検索での表示要件は、Google公式資料を別途確認します。Googleが取得したページ、 検出された構造化データ、 サイト全体の有効・無効項目を確認します。
拡張レポートは、Googleが対応データを検出した種類だけ表示されます。公開前はコード入力、 公開後は実際のURLでリッチリザルトテストを実行します。
必須項目不足、型の違い、 無効なURL・日時など、対象外になる問題を修正します。
推奨項目の不足は必ずしも無効ではありません。 正確に管理できる項目を追加します。
Googleがアクセスでき、 noindex・robots.txt・認証で遮断されていないか確認します。
パンくずなど対応する拡張レポートと、 解析不能な構造化データの問題を確認します。
修正後は検証を開始し、 Googleの再クロール・再インデックス後に状態を追跡します。
小さく導入して検証し 本文更新と同じ流れで保守する
まずトップ・店舗情報・記事などの代表ページから始めます。
事業者情報の理解、店舗情報、 パンくず、記事情報など、必要な対象を整理します。
Google検索が現在サポートする種類と、 個別の必須・推奨項目を確認します。
正式名称、住所、営業時間、 著者、公開日などを利用者にも分かるよう掲載します。
テーマ・プラグインの重複を避け、 管理元を決めて正確な値を設定します。
リッチリザルトテスト、 Schema Markup Validator、URL検査を使います。
Search Consoleと公式資料を定期確認し、 本文変更時にデータも更新します。
検索向けのデータだけを作らず 利用者に見える事業情報を先に整える
正式名称、住所、電話番号、営業時間、記事情報を一貫して管理しましょう。
合わせて確認したい内容
- Organizationと事業者情報
- LocalBusinessと店舗情報
- BreadcrumbListとサイト階層
- Articleとブログ・コラム
- JSON-LDとWordPressの出力
- リッチリザルトテスト
- URL検査とSearch Console
- 営業時間・住所・料金の更新管理
※構造化データを設定しても、 リッチリザルトの表示、検索順位、アクセス数、 問い合わせ数が必ず向上することを保証するものではありません。 ページ内容の正確さと利用者にとっての分かりやすさを優先してください。
LocalBusinessの設定項目を見る →ページの主題に合う正確なデータを設定しよう
構造化データは、 ホームページに掲載している事業者・店舗・記事・階層などの情報を、 検索エンジンへ決まった項目で伝える補助データです。 小規模事業者ではOrganization、LocalBusiness、 BreadcrumbList、Articleなどから必要なものを選びます。 本文と同じ正確な情報を設定し、 WordPressの重複出力を確認したうえで、 リッチリザルトテスト、URL検査、Search Consoleで継続確認しましょう。
本記事は、2026年7月時点で公開されている Google検索セントラル、Search Console、 schema.orgの公式情報を参考に作成しています。 Googleがサポートする構造化データの種類、 必須・推奨プロパティ、リッチリザルト、 Search Consoleのレポートは変更される場合があります。 導入時には最新の公式情報を確認してください。
- Google検索セントラル：構造化データの仕組み
- Google検索セントラル：Google検索がサポートする構造化データ
- Google検索セントラル：構造化データに関する一般的なガイドライン
- Google検索セントラル：構造化データのテストツール
- Google検索セントラル：Organizationの構造化データ
- Google検索セントラル：LocalBusinessの構造化データ
- Google検索セントラル：Articleの構造化データ
- Search Console ヘルプ：リッチリザルトレポート
- Search Console ヘルプ：解析不能な構造化データ
- Schema.org：構造化データの共通語彙
