「構造化データって聞いたことはあるけど、何をすればいいかわからない。」
SEO対策を進めていくと、必ずぶつかるのがこの壁です。 構造化データは、検索エンジンにサイトの情報を"正確に"伝えるための仕組み。正しく実装すれば、検索結果にリッチリザルトが表示され、クリック率が大幅に向上します。
特に店舗ビジネスにおいては、営業時間、住所、口コミ、サービス内容などを検索エンジンが自動的に読み取れるようになるため、集客面でのインパクトは非常に大きいです。
しかし、実装方法がよくわからない。JSON-LDって何?そもそも本当に効果があるの?という疑問を持っている方も多いでしょう。
この記事では、構造化データの基本から、店舗サイトで実装すべき種類、JSON-LDの具体的な書き方、テスト方法まで、実務で使えるレベルで解説します。
SEO対策の全体像をまだ把握できていない方は、先にSEO対策とは?初心者でもわかる完全ガイドを読んでおくと、この記事の内容がより理解しやすくなります。
構造化データとは?SEOにおける役割
構造化データの定義 — 検索エンジンへの「翻訳装置」
構造化データとは、Webページの情報を検索エンジンが理解しやすい形式で記述したコードのことです。 HTMLだけでは、人間には読める情報でも、検索エンジンにはその意味まで正確に伝わりません。
たとえば、ページ上に「営業時間 9:00〜18:00」と書いてあったとします。 人間なら一目でわかりますが、Googleのクローラーにとっては「ただのテキストの一部」でしかないのです。
構造化データを使えば、「これは営業時間である」「このページはLocalBusinessの情報である」といった意味情報を、機械が読み取れる形で明示できます。
つまり構造化データは、人間が書いた情報を検索エンジンが正しく解釈するための「翻訳装置」のようなものです。
構造化データのフォーマット — JSON-LDが主流である理由
構造化データの記述形式には、主に3種類があります。
| フォーマット | 記述場所 | 特徴 |
|---|---|---|
| JSON-LD | <script>タグ内 | HTMLと分離して記述。管理しやすい |
| Microdata | HTML要素の属性 | HTMLに直接埋め込む。可読性が低い |
| RDFa | HTML要素の属性 | Microdataと似た方式。やや複雑 |
2026年現在、Googleが公式に推奨しているのはJSON-LD(JavaScript Object Notation for Linked Data)です。
JSON-LDが選ばれる理由は明快です。 HTMLのコンテンツとは完全に分離して記述できるため、既存のページ構造を一切変更せずに構造化データを追加できます。
MicrodataやRDFaは、HTML要素に直接属性を追加する形式のため、マークアップが複雑になりやすく、メンテナンスコストが高くなります。 特にCMSやテンプレートを使っているサイトでは、JSON-LDのほうが圧倒的に扱いやすいです。
構造化データがSEOに与える影響
よくある誤解として、「構造化データを実装すれば検索順位が上がる」というものがあります。 結論から言うと、構造化データは直接的なランキング要因ではありません。
ただし、間接的にSEOに大きな影響を与えます。
リッチリザルトによるクリック率の向上
構造化データを実装すると、検索結果にリッチリザルト(リッチスニペット)が表示される可能性があります。 星評価、価格、FAQ、営業時間などが検索結果に直接表示されるため、通常の検索結果よりも目立ちます。
Googleの公式データでは、リッチリザルトが表示されたページのクリック率は、通常の検索結果と比較して平均で20〜30%高いとされています。 クリック率が上がれば、結果的にトラフィックが増え、SEO全体にプラスの効果をもたらします。
検索エンジンの理解度向上
構造化データによって、Googleがページの内容をより正確に理解できるようになります。 これは、AI Overviewやナレッジパネルなど、従来の「10本の青いリンク」以外の検索結果表示でも重要です。
2026年現在、GoogleのAI OverviewはWebページの構造化データを参照して回答を生成するケースが増えています。 構造化データを実装しておくことは、AI時代の検索結果への対応としても欠かせません。
Google検索における表示パターンの拡大
構造化データを正しくマークアップすることで、以下のような検索結果の強化表示が期待できます。
- 星評価(レビュー)の表示
- FAQ(よくある質問)の展開表示
- パンくずリストの表示
- 営業時間・住所の直接表示
- イベント情報のカード表示
- 商品価格・在庫状況の表示
これらはすべて、ユーザーの目に留まりやすく、クリックにつながりやすい表示形式です。
店舗サイトに実装すべき構造化データの種類
店舗サイトの場合、すべての構造化データを片っ端から実装する必要はありません。 優先度の高いものから順に対応すれば十分です。
ここでは、店舗サイトで特に効果が高い構造化データを優先度順に解説します。
最優先 — LocalBusiness(店舗情報)
店舗ビジネスのサイトにとって、最も重要な構造化データがLocalBusinessです。 これは店舗の基本情報(名前、住所、電話番号、営業時間など)を検索エンジンに伝えるためのスキーマです。
LocalBusinessを実装すると、Google検索やGoogleマップで店舗情報が正確に表示されやすくなります。 MEO(マップエンジン最適化)との相乗効果も期待できるため、店舗サイトでは最優先で対応すべきマークアップです。
LocalBusinessには業種別の下位タイプが多数用意されています。 自社の業種に合ったタイプを選ぶことで、より正確な情報を伝えられます。
| 業種 | 推奨スキーマタイプ |
|---|---|
| 飲食店 | Restaurant |
| 美容室・サロン | BeautySalon / HairSalon |
| 歯科医院 | Dentist |
| 整骨院・整体院 | MedicalBusiness |
| 弁護士事務所 | Attorney / LegalService |
| スポーツジム | SportsActivityLocation |
| 小売店全般 | Store |
業種に該当する下位タイプがない場合は、LocalBusinessをそのまま使えば問題ありません。
高優先 — BreadcrumbList(パンくずリスト)
パンくずリストの構造化データは、サイトの階層構造をGoogleに明示的に伝えるものです。
実装すると、検索結果のURLの部分がパンくずリスト形式で表示されます。 「サイトTOP > カテゴリ > 記事名」のような階層が表示されるため、ユーザーにとってもわかりやすく、クリック率の向上につながります。
なお、パンくずリストはSEO内部対策の基本要素でもあります。 内部対策全般について確認したい方は、SEO内部対策チェックリスト|初心者が今すぐ確認すべき20項目も参考にしてください。
高優先 — FAQPage(よくある質問)
FAQPageは、ページ内のよくある質問とその回答を構造化データとしてマークアップするものです。
実装すると、検索結果にFAQがアコーディオン形式で展開表示される可能性があります。 検索結果の占有面積が大きくなるため、視認性が大幅に上がります。
2026年現在、GoogleはFAQリッチリザルトの表示基準を厳格化しています。 政府機関や医療機関などの権威あるサイトでは引き続き表示されやすいものの、一般的なサイトでは表示頻度が下がっています。
ただし、構造化データ自体を実装しておくことは、AI OverviewやGoogleアシスタントへの情報提供という観点でも意味があります。 表示されなくても、実装しておくデメリットはありません。
中優先 — Review / AggregateRating(レビュー・評価)
ReviewおよびAggregateRatingは、ユーザーのレビューや評価を構造化データとして記述するものです。
正しく実装すると、検索結果に星評価(例:4.5 / 5)が表示されます。 星評価は視覚的なインパクトが大きく、クリック率の向上に直結します。
ただし、Googleのガイドラインでは、自社サイトに自分で投稿した評価は構造化データとしてマークアップしてはいけないとされています。 第三者のレビューサイトや、ユーザーが投稿した口コミを掲載している場合にのみ使用してください。
ガイドラインに違反するマークアップを行うと、手動ペナルティの対象になる可能性があるため、慎重に対応しましょう。
中優先 — Organization / WebSite(組織・サイト情報)
Organizationは企業や組織の情報を、WebSiteはサイト全体の情報をGoogleに伝えるための構造化データです。
Organizationでは、企業名、ロゴ、公式SNSアカウント、連絡先などを記述します。 これにより、Googleのナレッジパネルに正確な企業情報が表示されやすくなります。
WebSiteでは、サイト名やサイト内検索の機能を記述できます。 特にサイト内検索の構造化データ(SearchAction)を実装すると、Google検索結果にサイト内検索ボックスが表示される場合があります。
どちらもトップページに1回だけ実装すれば十分です。
低優先だが有効 — Event / Product / Service
業種やビジネスモデルによっては、以下の構造化データも検討する価値があります。
Event(イベント情報) セミナー、ワークショップ、体験会などを定期的に開催している場合に有効です。 検索結果にイベントのカード表示が出やすくなります。
Product(商品情報) ECサイトや物販を行っている店舗では、商品の価格、在庫状況、レビューを検索結果に表示できます。
Service(サービス情報) 提供サービスの種類や価格帯を記述するスキーマです。 2026年時点ではリッチリザルトとしての表示は限定的ですが、AI Overviewでの参照が増えている傾向があります。
JSON-LDの書き方と実装手順
ここからは、実際のJSON-LDコードの書き方と、サイトへの実装手順を解説します。 コピー&ペーストで使えるテンプレートも用意しているので、すぐに実装に取りかかれます。
JSON-LDの基本構文
JSON-LDは、HTMLの<head>タグ内(または<body>タグ内)に<script>タグで記述します。
基本構文は以下の通りです。
<script type="application/ld+json">
{
"@context": "https://schema.org",
"@type": "スキーマタイプ",
"プロパティ名": "値"
}
</script>
@contextは常にhttps://schema.orgを指定します。
これは構造化データの語彙体系として、Googleが公式にサポートしている規格です。
@typeには、先述したLocalBusinessやFAQPageなどのスキーマタイプを指定します。
LocalBusinessのJSON-LDテンプレート
店舗サイトで最も使用頻度が高いLocalBusinessのテンプレートです。 自社の情報に書き換えてそのまま使えます。
{
"@context": "https://schema.org",
"@type": "LocalBusiness",
"name": "店舗名",
"image": "https://example.com/images/storefront.jpg",
"url": "https://example.com",
"telephone": "+81-3-1234-5678",
"priceRange": "$$",
"address": {
"@type": "PostalAddress",
"streetAddress": "渋谷1-2-3 ABCビル5F",
"addressLocality": "渋谷区",
"addressRegion": "東京都",
"postalCode": "150-0002",
"addressCountry": "JP"
},
"geo": {
"@type": "GeoCoordinates",
"latitude": 35.6595,
"longitude": 139.7004
},
"openingHoursSpecification": [
{
"@type": "OpeningHoursSpecification",
"dayOfWeek": ["Monday", "Tuesday", "Wednesday", "Thursday", "Friday"],
"opens": "09:00",
"closes": "18:00"
},
{
"@type": "OpeningHoursSpecification",
"dayOfWeek": ["Saturday"],
"opens": "10:00",
"closes": "15:00"
}
],
"sameAs": [
"https://www.instagram.com/example",
"https://twitter.com/example"
]
}
特に注意すべきポイントをいくつか補足します。
telephoneの記述 電話番号は国際形式(+81から始まる形式)で記述するのが推奨されています。 ただし、国内向けの店舗サイトであれば「03-1234-5678」のような通常の形式でも認識されます。
geoの記述 緯度・経度を正確に記述すると、Googleマップとの連携精度が上がります。 緯度・経度はGoogleマップで店舗の位置をクリックすれば確認できます。
openingHoursSpecificationの記述
曜日ごとに異なる営業時間がある場合は、複数のオブジェクトを配列で記述します。
定休日は記述しないか、opensとclosesを同じ値にする方法があります。
FAQPageのJSON-LDテンプレート
FAQ(よくある質問)ページ用のテンプレートです。
{
"@context": "https://schema.org",
"@type": "FAQPage",
"mainEntity": [
{
"@type": "Question",
"name": "質問文をここに記述",
"acceptedAnswer": {
"@type": "Answer",
"text": "回答文をここに記述。HTMLタグも使用可能です。"
}
},
{
"@type": "Question",
"name": "2つ目の質問文",
"acceptedAnswer": {
"@type": "Answer",
"text": "2つ目の回答文"
}
}
]
}
質問と回答のペアは、mainEntity配列にいくつでも追加できます。
回答文にはHTMLタグ(<a>や<strong>など)を含めることもできます。
BreadcrumbListのJSON-LDテンプレート
パンくずリスト用のテンプレートです。
{
"@context": "https://schema.org",
"@type": "BreadcrumbList",
"itemListElement": [
{
"@type": "ListItem",
"position": 1,
"name": "ホーム",
"item": "https://example.com/"
},
{
"@type": "ListItem",
"position": 2,
"name": "カテゴリ名",
"item": "https://example.com/category/"
},
{
"@type": "ListItem",
"position": 3,
"name": "記事タイトル"
}
]
}
最後の項目(現在のページ)にはitemプロパティを省略するのが一般的です。
positionは1から始まる連番で指定します。
実装場所と実装方法
JSON-LDの設置場所は、<head>タグ内が推奨されています。
ただし、<body>タグ内に設置しても問題なく認識されます。
WordPressの場合
WordPressサイトでは、以下の方法で実装できます。
- テーマの
header.phpに直接記述する - 「Insert Headers and Footers」などのプラグインを使う
- Yoast SEOやRank Mathなどのプラグインの構造化データ機能を使う
Yoast SEOを使用している場合、Organization、WebSite、BreadcrumbListは自動的に出力されます。 LocalBusinessやFAQPageは、手動で追加するか、専用のプラグインを使う必要があります。
Next.jsなどのフレームワークの場合
Next.js(App Router)であれば、<script>タグをコンポーネント内でレンダリングするのが一般的です。
export default function StorePage() {
const jsonLd = {
"@context": "https://schema.org",
"@type": "LocalBusiness",
"name": "店舗名",
// ...その他のプロパティ
};
return (
<>
<script
type="application/ld+json"
dangerouslySetInnerHTML={{ __html: JSON.stringify(jsonLd) }}
/>
{/* ページコンテンツ */}
</>
);
}
JavaScriptオブジェクトとして定義してからJSON.stringify()で文字列化するため、構文エラーが起きにくいメリットがあります。
複数の構造化データを同一ページに設置する方法
1つのページに複数の構造化データを設置することは可能です。 方法は2つあります。
方法1:個別の<script>タグで記述する
<script type="application/ld+json">
{ "@context": "https://schema.org", "@type": "LocalBusiness", ... }
</script>
<script type="application/ld+json">
{ "@context": "https://schema.org", "@type": "BreadcrumbList", ... }
</script>
方法2:@graphで1つにまとめる
{
"@context": "https://schema.org",
"@graph": [
{ "@type": "LocalBusiness", ... },
{ "@type": "BreadcrumbList", ... },
{ "@type": "FAQPage", ... }
]
}
どちらの方法でもGoogleは正しく認識します。
管理のしやすさを考えると、@graphで1つにまとめるほうがおすすめです。
構造化データのテスト・検証方法
構造化データは、書いただけでは正しく動作しているかわかりません。 実装後は必ずテストツールで検証してください。
リッチリザルトテスト(Google公式)
Googleが提供する公式テストツールです。
URL:https://search.google.com/test/rich-results
URLまたはコードを入力するだけで、以下の内容を確認できます。
- 構造化データが正しく認識されているか
- リッチリザルトとして表示される資格があるか
- エラーや警告がないか
テスト結果には「有効」「警告あり」「エラー」の3段階で表示されます。
エラーは必ず修正してください。エラーがあると、構造化データが完全に無視されます。 警告は推奨プロパティが不足している場合に表示されます。可能であれば対応しましょう。
Schema Markup Validator
Schema.orgが提供する検証ツールです。
URL:https://validator.schema.org/
リッチリザルトテストがGoogle固有の仕様をチェックするのに対して、Schema Markup Validatorはschema.org全体の仕様に基づいてチェックします。
Googleのリッチリザルトテストで問題がなくても、schema.orgの仕様に違反しているケースがあります。 両方のツールでチェックするのがベストプラクティスです。
Google Search Consoleでの確認
構造化データを本番サイトに実装したら、Google Search Consoleでも確認しましょう。
Search Consoleの左メニューにある「拡張」セクションで、以下の項目が確認できます。
- パンくずリスト
- FAQ
- よくある質問
- レビュースニペット
- ローカルビジネス
ここにエラーが表示されている場合は、実装に問題があります。 クリックすると、エラーの詳細と該当ページが確認できるので、1つずつ修正してください。
修正後は「修正を検証」ボタンを押すと、Googleが再クロールして結果を更新してくれます。
よくあるエラーと対処法
構造化データの実装でよくあるエラーをまとめます。
| エラー内容 | 原因 | 対処法 |
|---|---|---|
| JSON構文エラー | カンマの過不足、閉じ括弧の不足 | JSONバリデーターで構文チェック |
| 必須プロパティの不足 | nameやaddressが未記述 | 各スキーマの必須プロパティを確認 |
| 型の不一致 | 数値に文字列を入れているなど | schema.orgの仕様に従う |
| URLの不正 | 相対パスで記述している | 絶対URL(https://〜)を使用する |
| ページ内容との不一致 | 実際のページにない情報を記述 | ページに表示されている情報のみ記述 |
特に最後の「ページ内容との不一致」は、Googleのガイドライン違反にあたります。 構造化データに記述する情報は、必ずページ上に実際に表示されている内容と一致させてください。
FAQ
Q. 構造化データを実装すれば、必ずリッチリザルトが表示されますか?
いいえ、構造化データの実装はリッチリザルト表示の前提条件ですが、表示を保証するものではありません。 Googleは検索クエリやページの品質、ユーザーの状況などを総合的に判断して、リッチリザルトを表示するかどうかを決定します。 ただし、実装していなければ絶対に表示されないため、実装しておくこと自体は必須です。
Q. 構造化データは全ページに実装すべきですか?
ページの種類に応じて適切な構造化データを選んで実装するのが正しいアプローチです。 たとえば、LocalBusinessはトップページや店舗情報ページに、BreadcrumbListは全ページに、FAQPageはFAQが記載されているページにだけ実装します。 無関係な構造化データを入れるのは避けてください。
Q. WordPress向けの構造化データプラグインはどれがおすすめですか?
Yoast SEOまたはRank Math SEOが定番です。 どちらもOrganization、WebSite、BreadcrumbListを自動出力してくれます。 LocalBusinessやFAQPageなど、より細かい制御が必要な場合は「Schema Pro」や「WP Schema」などの専用プラグインを併用するのが効率的です。
Q. 構造化データを実装するとページの表示速度に影響しますか?
ほぼ影響しません。 JSON-LDのコードはファイルサイズが非常に小さく(通常1KB未満)、レンダリングにも関与しないため、表示速度への影響は無視できるレベルです。
Q. Googleビジネスプロフィールと構造化データのLocalBusinessは両方必要ですか?
はい、両方実装するのが推奨です。 Googleビジネスプロフィール(旧Googleマイビジネス)はGoogle検索やGoogleマップ上での表示に直接影響し、構造化データのLocalBusinessは自社サイトからの情報伝達を正確にします。 両方の情報が一致していると、Googleの信頼度が上がり、検索結果での表示精度が向上します。
まとめ
構造化データは、検索エンジンにサイトの情報を正確に伝えるためのマークアップです。 直接的なランキング要因ではないものの、リッチリザルトによるクリック率の向上や、AI Overviewへの情報提供など、間接的なSEO効果は非常に大きいです。
店舗サイトで優先的に実装すべき構造化データを改めてまとめます。
- LocalBusiness — 店舗の基本情報。最優先で対応
- BreadcrumbList — サイトの階層構造。全ページに実装
- FAQPage — よくある質問。該当ページに実装
- Review / AggregateRating — レビュー・評価。第三者レビューがある場合
- Organization / WebSite — 企業・サイト情報。トップページに実装
記述形式はJSON-LDを選んでください。 Googleが公式推奨しており、HTMLと分離して管理できるため、実装もメンテナンスも最も簡単です。
実装後は必ずリッチリザルトテストとSchema Markup Validatorでエラーがないか確認し、本番公開後はSearch Consoleで定期的にモニタリングしましょう。
構造化データの実装は、SEO内部対策の一部です。 タイトルタグ、メタディスクリプション、内部リンクなど、他の内部対策も合わせて最適化することで、サイト全体のSEO効果を最大化できます。
まだSEO対策全体の進め方が明確でない方は、SEO対策とは?初心者でもわかる完全ガイドで全体像を把握してから取り組んでみてください。
