構造化データとは？中小企業サイトで優先したい種類と実装時の注意点

構造化データは「検索順位を上げるコード」ではない

SEOについて調べていると、

「構造化データを入れるとSEOに強くなる」
「schemaを入れれば検索順位が上がる」

という説明を見ることがあります。

しかし、構造化データを、

「検索順位を直接上げるための裏技」

と考えるのは適切ではありません。

Googleは構造化データを、ページに関する情報を標準化された形式で提供し、ページの内容を分類するための仕組みとして説明しています。

適切な構造化データを設定することで、Googleがページ内容を理解する手掛かりになり、対応するコンテンツでは通常の検索結果より情報量の多い「リッチリザルト」の対象になる可能性があります。

ただし、正しく設定したからといって、必ずリッチリザルトが表示されるわけではありません。Googleも、構造化データがガイドラインに沿って実装されていても、検索結果での表示を保証するものではないと明記しています。

つまり構造化データは、

検索順位を操作する施策ではなく、Googleへページの意味を正確に伝えるための技術施策

と考えるのが基本です。

まず結論：すべて入れるのではなく“ページの役割に合うものだけ”設定する

schema.orgには非常に多くの構造化データタイプがあります。

だからといって、

「設定できるものは全部設定しよう」

と考える必要はありません。

例えば一般的な中小企業サイトであれば、優先順位は次のように考えられます。

ほぼすべての企業サイト

• Organization
• BreadcrumbList

実店舗・地域サービス

• LocalBusiness

ブログ・オウンドメディア

• Article／BlogPosting

採用活動を行っている

• JobPosting

商品販売・EC

• Product

イベント・セミナーを開催している

• Event

重要なのは、

「どんなリッチリザルトが欲しいか」から考えるのではなく、「このページは何を表しているのか」から選ぶこと

です。

Google検索が現在サポートしている構造化データは限定されており、対応する機能も随時変更されます。実装前にはGoogle Search Centralの最新一覧を確認することが重要です。

構造化データとは？初心者向けに簡単に解説

人には分かる情報を検索エンジンにも明確に伝える

例えば、会社概要ページに次の情報があったとします。

• 株式会社〇〇
• 神奈川県相模原市
• 042-000-0000
• Web制作会社

人が見れば、

「これは会社名」
「これは住所」
「これは電話番号」

と分かります。

しかし、検索エンジンに対して、

これは会社名です
これは所在地です
これは電話番号です

と、より明確な形式で伝えるのが構造化データです。

例えばOrganizationというタイプを使って、

• name
• address
• telephone
• url
• logo

などを記述します。

GoogleはOrganizationの構造化データについて、組織の詳細を理解し、検索結果上で他の組織と区別するために利用できると説明しています。

schema.orgとGoogle検索の関係

構造化データでは一般的にschema.orgで定義された語彙が使われます。

ただし、

schema.orgに存在するタイプ＝Google検索で特別表示される

という意味ではありません。

Google検索には、Googleがサポートしている構造化データと、それぞれの検索機能があります。

そのため実務では、

schema.orgに存在するか

だけではなく、

Google検索が現在その機能をサポートしているか

まで確認する必要があります。

構造化データとリッチリザルトの違い

この2つは混同されやすいので整理します。

構造化データ
→ ページの意味を機械が理解しやすい形式で伝えるデータ

リッチリザルト
→ 構造化データなどを利用して検索結果が通常より豊かに表示される仕組み

例えば商品ページなら、

• 価格
• 在庫状況
• レビュー情報

などが検索結果上で追加表示される場合があります。

GoogleはProductマークアップにより、対象となる商品ページが価格・在庫などの追加情報を含む商品スニペットの対象になり得ると説明しています。

ただし、

構造化データを設定する＝リッチリザルト表示確定

ではありません。

あくまで表示対象になるための条件を整える施策です。

中小企業サイトで優先したい構造化データ7種類

Organization｜会社情報をGoogleへ伝える

企業サイトなら、まず検討したいのがOrganizationです。

主に、

• 会社名
• URL
• ロゴ
• 所在地
• 電話番号
• 企業識別情報

などをGoogleへ伝えられます。

Googleは、Organizationの情報をホームページ、または会社について説明する代表的なページに配置することを推奨しており、全ページへ設定する必要はないと説明しています。

おすすめページ

• トップページ
• 会社概要ページ

特に優先したいサイト

• コーポレートサイト
• BtoBサイト
• ブランドサイト
• EC運営企業

Googleは、会社名やロゴ、実世界での所在地・電話番号など、ユーザーに役立つ情報を中心に設定することを推奨しています。

BreadcrumbList｜サイト内の階層を伝える

パンくずリストがあるサイトなら、BreadcrumbListも優先度が高い構造化データです。

例えば、

トップ ＞ SEO対策 ＞ 構造化データとは

という階層をGoogleへ伝えます。

パンくずリストは、

• サイト階層を理解しやすくする
• ユーザーが上位階層へ移動しやすくなる
• Googleへページの位置関係を伝える

という役割があります。

Googleも、Breadcrumbの構造化データによってページがサイト階層のどこに位置するかを示せると説明しています。

おすすめページ

基本的にはトップページを除く、

• サービス詳細
• ブログ記事
• 事例詳細
• 商品詳細
• 採用情報

などです。

LocalBusiness｜店舗・地域ビジネス向け

実店舗や地域密着型サービスならLocalBusinessを検討します。

例えば、

• 飲食店
• 美容室
• 歯科医院
• 整骨院
• 不動産会社
• 工務店
• 地域密着型サービス会社

などです。

GoogleはLocalBusinessにより、

• 営業時間
• 所在地
• 電話番号
• ビジネスの種類
• 部門情報

などをGoogleへ伝えられると説明しています。

また、できるだけ具体的なサブタイプを利用することも推奨されています。

例えば飲食店なら、

LocalBusiness

だけでなく、

Restaurant

など、より実態に近いタイプを選びます。

なお、ローカル集客では構造化データだけでなく、Googleビジネスプロフィールの登録・管理も重要です。

Googleも、地域ビジネスの所在地や営業時間などを検索・Googleマップへ反映させる手段としてBusiness Profileの管理を案内しています。

Article・BlogPosting｜ブログ・コラム向け

オウンドメディアを運営しているなら、

• Article
• BlogPosting
• NewsArticle

などが候補になります。

GoogleはArticle構造化データによって、

• 記事タイトル
• 画像
• 公開日
• 更新日
• 執筆者

などの記事情報をより明確に伝えられると説明しています。

おすすめページ

• SEO記事
• コラム
• ブログ
• ニュース記事
• 解説コンテンツ

特にE-E-A-Tを意識するなら、

誰が書いたのか

がページ上でも構造化データ上でも分かるように整理しておくとよいでしょう。

JobPosting｜採用ページ向け

求人情報を自社サイトに掲載している企業なら、JobPostingも重要です。

対象は、

会社の採用トップページ

というより、

1つ1つの具体的な求人ページ

です。

例えば、

• Webデザイナー募集
• 営業職募集
• エンジニア募集

などの求人詳細です。

Googleは、適切なJobPosting構造化データを求人ページへ追加することで、Google検索の求人検索体験の対象になれると説明しています。

求人では特に、

• 投稿日
• 職務内容
• 雇用主
• 勤務地

など、必須項目を正確に設定する必要があります。

募集終了後も古い求人情報を残し続けないよう、運用面まで含めて設計しましょう。

Product｜商品販売・ECサイト向け

商品を販売しているサイトなら、Productを検討します。

Googleが対応する商品情報には、

• 商品名
• 価格
• 在庫
• レビュー情報
• Offer情報

などがあります。

適切な商品マークアップによって、対象ページが価格や在庫などを含む商品スニペットの候補になります。

優先したいサイト

• ECサイト
• メーカーの商品詳細
• 通販サイト
• 自社商品販売サイト

価格や在庫は変更されるため、ページ上に表示している情報と構造化データの内容を常に一致させることが重要です。

Event｜セミナー・イベントページ向け

セミナーやリアルイベントを開催している企業ならEventがあります。

例えば、

• 展示会
• セミナー
• 講演会
• 音楽イベント
• 地域イベント

などです。

GoogleはEvent構造化データを適切に実装することで、イベントがGoogle検索やGoogleマップなどのイベント体験の対象になり得ると案内しています。

ただし、

「毎週開催しています」だけの一覧ページ

ではなく、各イベントの、

• 日時
• 会場
• イベント名
• 開催情報

を明確にしたページを作ることが基本です。

FAQ・HowToは優先すべき？現在のGoogle検索での扱い

以前は、

• FAQPage
• HowTo

がSEO施策として頻繁に紹介されていました。

しかし、現在は注意が必要です。

Googleは2023年にFAQリッチリザルトの表示を大幅に縮小し、現在はよく知られた信頼性の高い政府サイト・医療サイトを中心に表示するとしています。

一般企業サイトでは、FAQPageを設定しても検索結果上でFAQリッチリザルトが通常表示されるものではありません。

さらにHowToについては、Google検索でのリッチリザルト表示自体が終了しています。

そのため一般的な中小企業サイトでは、

「FAQを構造化データにすること」よりも、「ユーザーが抱える疑問へページ上で分かりやすく回答すること」

を優先しましょう。

FAQコンテンツ自体が不要になったわけではありません。

• 料金
• 契約
• 納期
• 対応範囲
• 初めて利用する際の不安

などを解消するFAQは、問い合わせ導線として引き続き重要です。

構造化データを入れるべきページ・入れなくていいページ

構造化データは、ページの内容に合わせて設定します。

例えば、

ページ	優先候補
トップ・会社概要	Organization
サービス一覧・詳細	BreadcrumbList
店舗ページ	LocalBusiness＋BreadcrumbList
ブログ記事	Article／BlogPosting＋BreadcrumbList
求人詳細	JobPosting＋BreadcrumbList
商品詳細	Product＋BreadcrumbList
イベント詳細	Event＋BreadcrumbList

重要なのは、存在しない情報を構造化データだけで追加しないことです。

Googleの一般ガイドラインでは、構造化データで示す内容はページの主要コンテンツを正しく表している必要があり、ユーザーから見えない情報や誤解を招く情報をマークアップすることは認められていません。

実装するならJSON-LDがおすすめ

Googleがサポートしている主な記述形式は、

• JSON-LD
• Microdata
• RDFa

です。

その中でもGoogleはJSON-LDを推奨しています。

例えばOrganizationなら、イメージは次のようになります。

<script type="application/ld+json">
{
  "@context": "https://schema.org",
  "@type": "Organization",
  "name": "株式会社〇〇",
  "url": "https://example.com/",
  "logo": "https://example.com/logo.png",
  "telephone": "00-0000-0000"
}
</script>

実際には、

• 業種
• サイト構成
• 拠点数
• Googleが推奨する最新プロパティ

などを確認したうえで設定します。

Web上のコード例をコピーして、そのまま使うのはおすすめできません。

構造化データの仕様やGoogle側のサポート内容は変更されることがあるため、実装時点の公式ドキュメントを確認してください。

WordPressなどCMSで実装するときの注意点

SEOプラグインとテーマの二重出力に注意する

WordPressでは、

• SEOプラグイン
• テーマ
• 構造化データ専用プラグイン
• 独自実装

など、複数箇所からschemaが出力されることがあります。

例えば、

Organizationが2つ
BreadcrumbListが複数

など、意図しない重複が起きるケースがあります。

そのため、

「プラグインを入れたから完了」

ではなく、実際に出力されているコードを確認することが重要です。

ページ内容と構造化データを一致させる

例えばページ上では、

料金：100,000円

なのに、構造化データでは、

80,000円

となっていたら情報が一致していません。

Googleは、構造化データで参照する内容がユーザーから見えるページ内容と一致し、誤解を招かないことを求めています。

特に、

• 商品価格
• 在庫
• 営業時間
• 求人情報
• イベント日時

は更新漏れに注意します。

自動生成された情報を放置しない

CMSで自動生成すると便利ですが、

• 著者が存在しない
• 古い会社情報が残る
• 募集終了求人が残る
• ロゴURLが切れている

といった問題が起きます。

構造化データもサイトコンテンツと同じく、公開後の保守が必要です。

構造化データ実装の7ステップ

サイト内のページ種類を整理する

まずコードを書くのではなく、ページを分類します。

例えば、

• 会社情報
• サービス
• 店舗
• 記事
• 商品
• 求人
• イベント

です。

Googleが現在サポートしている種類を確認する

Google Search Centralの「Google検索がサポートしている構造化データ」を確認します。

2026年6月時点の公式一覧には、Article・Breadcrumb・Event・JobPosting・LocalBusiness・Organization・Productなど多数の対応機能が掲載されています。

過去の記事だけを参考にすると、すでにサポート終了している機能を実装してしまう可能性があります。

必須・推奨プロパティを確認する

構造化データごとに、

必須項目

と

推奨項目

があります。

例えばJobPostingでは、Google検索上で求人機能の対象になるために必須プロパティが設定されています。

一方、Organizationには必須プロパティがなく、該当する推奨項目を追加する形になっています。

タイプによって条件は異なるため、個別ガイドを確認します。

まず数ページで実装する

いきなりサイト全体へ反映するより、

代表的な数ページ

から導入します。

特にテンプレートを変更する場合は、設定ミスがサイト全体へ広がる可能性があります。

リッチリザルトテストで確認する

Googleは構造化データ実装時に、まずリッチリザルトテストで確認することを推奨しています。

確認するのは、

• 検出されているタイプ
• エラー
• 警告
• 必須項目
• リッチリザルト対象

などです。

なお、

テストでエラーがない＝検索結果で必ず表示される

ではありません。

URL検査でGoogleからの見え方を確認する

公開後はSearch ConsoleのURL検査で、

• Googleがアクセスできているか
• noindexになっていないか
• robots.txtでブロックされていないか

などを確認します。

Googleも構造化データの実装フローとして、テスト後に数ページへ公開し、URL検査でGoogleからどのように見えているか確認する方法を案内しています。

Search Consoleで継続監視する

公開して終わりではありません。

構造化データに対応するリッチリザルトレポートが利用できる場合は、

• 有効な項目
• 無効な項目
• 新しく発生したエラー

を確認します。

Googleも、新規実装後・テンプレート変更後・定期的なトラフィック分析時にSearch Consoleを確認することを推奨しています。

構造化データでよくある7つの失敗

とにかく種類を増やす

構造化データの数が多いほどSEOが強くなるわけではありません。

ページ内容に合うものだけ設定します。

ページ上にない情報をマークアップする

構造化データには、

実際にページ上でユーザーが確認できる情報

を使います。

隠された情報や誤解を招く情報はガイドライン違反になる可能性があります。

古いSEO記事を参考にFAQ・HowToを大量実装する

Google検索の仕様は変わります。

FAQリッチリザルトは一般サイトでは通常表示されず、HowToリッチリザルトのサポートも終了しています。

実装前に必ず現在の公式情報を確認します。

プラグインを入れて確認しない

WordPressのプラグインは便利ですが、

正しく設定されている保証ではありません。

リッチリザルトテストで確認します。

構造化データだけ更新してページを更新しない

商品価格・求人・営業時間などは、

画面表示と構造化データを同時に更新

します。

リッチリザルトが出ない＝実装失敗だと思う

正しく実装しても、Googleがリッチリザルトを表示するとは限りません。

Googleは検索履歴・場所・デバイスなど複数要素を考慮して検索結果を決定するため、構造化データは表示を保証するものではありません。

構造化データだけでSEOを改善しようとする

構造化データ以前に、

• 検索意図
• コンテンツ品質
• 内部リンク
• ページ速度
• クロール・インデックス
• サービス内容
• 実績・一次情報

などを整える必要があります。

構造化データは、良いページの意味をより明確に伝える補助施策として使います。

このまま使えるチェックリスト｜構造化データ実装前後の確認項目

実装前

• ページの種類を分類した
• Googleが現在サポートしているタイプを確認した
• ページ内容に合ったschemaを選んだ
• 必須プロパティを確認した
• 推奨プロパティを確認した
• 構造化データに使用する情報がページ上にも存在する
• 古いGoogle仕様を参考にしていない

企業サイト

• Organizationを確認した
• 会社名が正しい
• URLが正しい
• ロゴが正しい
• 所在地・電話番号が最新
• 必要に応じてLocalBusinessを検討した

コンテンツ

• パンくずにBreadcrumbListを検討した
• 記事にArticle／BlogPostingを検討した
• 著者情報が正しい
• 公開日・更新日が正しい

用途別

• 求人詳細にはJobPostingを検討した
• 商品詳細にはProductを検討した
• イベント詳細にはEventを検討した
• 一般企業サイトでFAQリッチリザルトを前提にしていない
• HowToリッチリザルトを目的に実装していない

技術確認

• JSON-LDなど適切な形式で実装した
• CMS・プラグインによる二重出力がない
• リッチリザルトテストを実施した
• エラーを修正した
• URL検査を実施した
• Googlebotをブロックしていない
• noindexになっていない

公開後

• Search Consoleを確認している
• テンプレート変更後にも再確認した
• 料金・在庫・営業時間などの更新と連動している
• Google公式仕様の変更を定期的に確認している

まとめ：構造化データは“検索エンジンへの説明書”として設計する

構造化データは、

「入れれば検索順位が上がるSEOテクニック」

ではありません。

役割は、

ページに書かれている情報が何を意味しているのか、検索エンジンへ明確に伝えること

です。

中小企業サイトなら、まず、

Organization
↓
BreadcrumbList
↓
LocalBusiness（店舗型なら）
↓
Article／BlogPosting（記事があるなら）
↓
JobPosting・Product・Event（必要なサイトのみ）

という順番で検討すると整理しやすくなります。

そして重要なのは、

ページ内容に合う種類を選ぶ
↓
Googleの最新公式仕様を確認する
↓
ページ上の情報と一致させる
↓
リッチリザルトテストで検証する
↓
Search Consoleで公開後も監視する

という運用です。

Google検索がサポートする構造化データやリッチリザルトは変更されることがあります。

一度設定して終わりではなく、Webサイトのコンテンツと同じように定期的に点検する技術要素として管理していきましょう。

構造化データ・SEO設定の確認ならRefuへ

Refuでは、ホームページ制作時のSEO設計だけでなく、

「どのページにどの構造化データが必要か」
「WordPressから正しく出力されているか」
「Search Console上で技術的な問題が起きていないか」

まで含めたサイト構造・SEO改善を行っています。

「構造化データを設定できているか分からない」
「昔入れたschemaが現在も有効か確認したい」
「SEOの技術面をまとめて点検したい」

など、お気軽にご相談ください。

▶ 無料相談はこちらから

その他おすすめ記事はこちら

成果を出す企業が必ずやっているアクセス解析の活用法

コンバージョン率を上げるための改善ポイント5選｜成果が伸びるUX改善と導線設計

Web集客に必要なKPIとは？成果を数値で管理する方法｜中小企業が“改善できるサイト”を作る基礎知識

お問い合わせが増えるCTA設計｜ボタン文言・配置・タイミングの鉄則

GA4で“集客のムダ”を見つける方法｜チャネル別に成果を伸ばす分析手順

検索意図から逆算するキーワード設計｜中小企業のためのKWマップ作成法