WEB MARKETING DICTIONARY

構造化データとは？
企業サイトの選び方と検証手順

会社情報・記事・商品のどれから整えるか。現在のGoogle検索の仕様を踏まえ、実装する対象と確認の順番を整理します。

SEO ／ 最終更新・情報確認：2026-10-09

構造化データは、ページに書かれた情報が「会社名」「記事の著者」「商品の価格」など、何を意味するかを決められた形式で伝える仕組みです。見出しや本文を読みやすくすることと併せて、検索エンジンへ情報の関係を示します。

最初に選ぶのは種類の数ではなく、自社サイトで正確に伝えたい情報です。会社を識別してほしいなら会社情報、商品を比較してほしいなら商品情報という順に、担当者が更新を続けられる範囲から始めましょう。

会社・記事・商品ページの情報を項目ごとに整理し、つながりを示すイラスト
ページの内容と、情報の意味・つながりを対応させて整理します。

検索結果でできることと、期待しすぎないこと

Googleは構造化データをページの理解に利用し、対応する種類ではリッチリザルトなどの検索表示の対象になります。ただし、正しく記述しても表示は保証されません。schema.orgに種類があることと、Google検索で専用の表示が用意されていることも別です。

種類を増やすだけで検索流入やAIからの引用が増えるとは判断できません。商品の条件が本文で分からない、会社情報が古いといった問題があれば、まず読者に見える情報を直し、その内容を構造化データへ反映します。

編集：株式会社イノベイド。WEB制作・運用、EC支援、AI/IT導入支援を行っています。運営者情報・編集方針もご確認ください。

FAQの検索表示が終了しても、役立つ質問と回答は残す

Googleの公式更新履歴では、FAQリッチリザルトは2026年5月7日からGoogle検索に表示されなくなったと説明されています。6月15日には専用ドキュメントも削除されました。FAQPageを追加して検索結果に質問の展開表示を出す、という目的では計画しないでください。

一方、schema.orgのFAQPageという種類は存在します。機能終了を理由に、送料・納期・申込条件など読者に役立つFAQ本文まで消す必要はありません。

  • 質問と回答が役立つ：本文は残し、回答が最新で分かりやすいかを確認します。
  • FAQPageを既に出力している：他の仕組みで利用しているか、回答とデータが一致しているかを確認してから、維持・削除を判断します。
  • これから検索表示を改善したい：FAQ表示を目当てに実装する工数より、現在対応する種類と、読者が知りたい情報の整備を優先します。

削除する場合は、FAQ本文や記事・パンくずの出力まで止めないよう、テーマやプラグインの設定範囲を確かめます。残す場合も、古い回答を自動出力し続けないことが大切です。

企業サイトでは、ページの役割から種類を選ぶ

次は着手順を決めるための目安です。すべてを一度に入れるのではなく、相談や購入につながる主要ページから選び、各種類の公式要件に照らします。

ページ・目的確認する種類先に整える情報
会社を正しく識別してもらうOrganization正式社名、公式URL、ロゴ、連絡先など。会社概要や実際の事業と食い違わないことを優先。
下層ページの位置を伝えるBreadcrumbList利用者がたどれる階層と名称。Googleのパンくず検索表示は現在デスクトップが対象。
解説記事の情報を伝えるArticle／BlogPosting見出し、著者、記事画像、分かっている公開日・実際の更新日。実在しない監修者は補わない。
商品情報を比較してもらうProduct商品名、価格、通貨、在庫など。購入できるページとレビュー記事では対応する機能・要件を分けて確認。

たとえば、法人向けノベルティを販売する会社なら

まず、会社の正式な連絡先を一本化します。次に、相談の多い商品詳細ページで価格・注文条件とデータが一致するかを点検し、記事は著者・更新日・画像をそろえます。価格が個別見積もりなら、検索結果に価格を出したいからといって固定価格を作らず、実際の販売方法と対象機能の要件を確認します。

資料請求が目的の企業なら会社・サービス情報の整合性、商品購入が目的なら価格・在庫の更新漏れを先に見る、と事業の目的で順序を変えます。検索順位の見込みだけで選ぶより、誤認を減らす効果と維持できる範囲から決めると管理しやすくなります。

既存の出力を調べ、小さく実装して検証する

GoogleはJSON-LD、Microdata、RDFaに対応し、多くの場合JSON-LDを推奨しています。JSON-LDはHTML内のscript type="application/ld+json"で情報を記述する形式です。既に正しく動いている形式を、形式の違いだけで作り直す必要はありません。

  1. 代表ページを選ぶ。会社情報、主要記事、主力商品などから、更新担当者が正誤を判断できるページを選びます。
  2. 現在の出力元を調べる。CMSのテーマ・プラグイン・独自コードのどれが出しているかを確認します。同じ会社や記事について異なる値が出ていれば、追加する前に整合させます。
  3. 本文と値を照合する。名前、URL、価格、在庫、日付、画像を一つずつ確認。推奨項目を埋めるために、分からない値や存在しない評価を作らないようにします。
  4. 対象機能の要件とテスト結果を照合する。Googleのリッチリザルトテストで対象の種類と重大なエラーを確認します。推奨項目の指摘は、実際に用意できる情報から改善します。
  5. 反映後のURLを検査する。Search ConsoleのURL検査でGoogleから見える状態を確認し、更新後のクロールを待ちます。変更したページ以外にも影響した場合は、同じテンプレートの代表ページを再点検します。

CMSの設定を変える前に、元の設定と対象ページを控えましょう。テーマとプラグインの両方が出力している場合も、同じ情報を複数箇所から出すこと自体を一律にエラーとせず、異なる値や古い情報が混ざっていないかを調べ、更新元を管理しやすい形へ整理します。

テストが通ったら、次に何を見るか

結果次の確認・判断
重大なエラーがある該当する種類の要件と入力値を確認。テンプレート全体の変更なら、同じ原因が他ページにもないかを調べる。
対象のリッチリザルトが検出されないGoogleが対応する種類か、データがテストしたページにあるかを確認。schema.orgの構文確認だけで検索表示の対象とは判断しない。
エラーはないが検索表示が変わらないクロール後の状態、インデックス、本文との一致、機能の提供条件を確認。テスト合格は実際の表示の保証ではない。
更新後も古い価格・日付が出るCMSの保存値、キャッシュ、別の出力元、Googleの再クロール状況を確認。本文とデータを一緒に点検する。

Schema.orgのバリデーターは一般的なマークアップの構文や抽出を確認する道具、GoogleのリッチリザルトテストはGoogleが扱う検索機能を確認する道具として使い分けます。どちらも、価格の正しさや架空のレビューまで自動で保証してくれるわけではありません。

効果は、エラー解消と読者の行動を分けて確かめる

実装した日、対象URL、変更した項目、修正前のエラーを記録しておきます。まず対象のエラーが解消し、価格・連絡先などの更新漏れがないかを確認。そのうえで、Googleの再クロール後に検索の表示回数・クリック数・CTRと、相談や購入につながった行動を見ます。

検索での変化は、ページ・クエリ・端末をできるだけそろえ、季節性や広告施策、同時に変えた本文の影響も考慮します。短期間に数回クリックされた程度では、構造化データだけの効果と結論づけないでください。表示されなかったからと、説明に合わない種類や評価を追加するのも避けます。

  • エラーは減ったがクリックは変わらない：本文が検索意図に答えているか、見出しや商品条件が十分かを見直します。
  • クリックは増えたが相談・購入が増えない：検索結果で期待した内容と本文が合っているか、次に進む導線が分かるかを確認します。
  • 更新のたびに値がずれる：出力元と担当者の作業を整理し、継続して一致させられる仕組みを優先します。

計測の整理には、記事・メディアのKPIと効果測定も参考にしてください。

仕様と確認に役立つ一次資料

情報確認日：2026-10-09。以下はGoogle検索とschema.orgの資料です。Googleの表示条件を、他の検索サービスの仕様として扱わないようにしてください。

関連する用語

自社サイトの出力と更新手順を点検したい方へ

株式会社イノベイドでは、WEB制作・運用のご相談を受け付けています。利用しているCMS、点検したいページ、現在のテスト結果をお知らせください。ページの情報と更新方法を確認し、対応範囲をご案内します。

WEB制作・運用を見る編集方針を見る構造化データの点検を相談する