構造化データ（Schema.org）の実装でSEOと検索表示を強化する方法

Googleの検索結果を眺めていると、星評価や価格情報、FAQ形式の展開など、通常のテキストリンクとは異なる見た目のリストを目にしたことがあるはずです。あれがリッチリザルトです。そしてその裏側で使われているのが、構造化データ（Schema.org）です。

構造化データは、Googleなどの検索エンジンに対して「このページは何について書かれているか」を機械が理解しやすい形式で伝える仕組みです。実装することでリッチリザルトの表示対象になりやすくなり、クリック率（CTR）の改善や検索での視認性向上につながる可能性があります。

この記事では、中小企業のサイト担当者でも実践できる構造化データの基本から実装手順、よくある失敗まで具体的に解説します。

構造化データとは何か、なぜ今必要なのか

Webページの中身は、人間が読むと「これは飲食店の情報だ」「ここに営業時間が書いてある」とすぐわかります。しかし検索エンジンのクローラーにとって、HTMLの中に書かれたテキストを意味として理解することは必ずしも簡単ではありません。

構造化データは、その「意味の橋渡し」をするためのものです。Schema.org（スキーマ・ドット・オーグ）はGoogleやMicrosoft、Yahoo!などの主要検索エンジンが共同で策定した語彙の標準規格で、この規格に沿ったマークアップを行うことで、検索エンジンがページの内容をより正確に把握できるようになります。

現在のSEO環境において構造化データが重要な理由は主に2つあります。

① リッチリザルトの対象になれる レシピのカロリー情報、商品の価格・在庫状況、イベントの日程、FAQの展開表示など、視覚的に目立つ表示形式への対応が可能になります。同じ検索順位でも、見た目のリッチさでクリックされやすさが変わることがあります。

② AIによる検索への対応 Google SGE（AI Overview）をはじめ、AIが検索結果を生成する動きが加速しています。構造化データで情報を明示的に提供しておくことは、AIが情報を正確に拾いやすくする手がかりになります。AIO対策の観点からも、今後ますます重要な要素になってくるでしょう。

JSON-LDが推奨される理由と基本の書き方

構造化データの実装形式には「JSON-LD」「Microdata」「RDFa」の3種類がありますが、Googleが公式に推奨しているのはJSON-LDです。

JSON-LDが選ばれる主な理由：

HTMLのコンテンツ部分とは分離して記述できるため、既存のページへの影響が少ない
<script>タグ内に記述するので、コードの追加・修正がしやすい
CMSやGoogleタグマネージャーとの連携が比較的容易

基本的な書き方は以下のような構造です（ローカルビジネスの例）。

<script type="application/ld+json">
{
  "@context": "https://schema.org",
  "@type": "LocalBusiness",
  "name": "〇〇株式会社",
  "address": {
    "@type": "PostalAddress",
    "streetAddress": "〇〇町1-2-3",
    "addressLocality": "大阪市",
    "addressRegion": "大阪府",
    "postalCode": "530-0000",
    "addressCountry": "JP"
  },
  "telephone": "06-XXXX-XXXX",
  "openingHours": "Mo-Fr 09:00-18:00"
}
</script>

このコードを<head>タグ内か<body>タグ内に配置します。どちらでもGoogleは認識しますが、管理のしやすさから<head>タグ内に置くことが多いです。

業種・ページ種別ごとの主要スキーマタイプ

Schema.orgには数百種類のスキーマが定義されています。自社サイトのページ種別に合ったものを選ぶことが大切です。

LocalBusiness（地域ビジネス） 店舗や事務所を持つ中小企業にとって、最も基本的なスキーマです。営業時間・住所・電話番号・マップ情報などを構造化して渡すことで、ローカル検索やMEOとの連携が強くなります。

FAQPage よくある質問ページやブログ記事内のQ&Aセクションに適用できます。適切に実装できると、検索結果でFAQが展開表示される場合があります（ただしGoogleの判断による）。実装コストが低い割に視認性への影響が期待できるため、特に優先度の高いスキーマのひとつです。

Article / BlogPosting ブログ記事や読み物コンテンツに使います。記事の著者・公開日・更新日・サムネイル画像などを明示できます。EEATの観点から、著者情報の構造化は今後さらに重視される方向性です。

Product ECサイトや製品ページ向け。価格・在庫状況・評価（AggregateRating）を組み合わせることで、商品情報のリッチリザルト表示を狙えます。

BreadcrumbList パンくずリストの構造化です。検索結果のURL表示がパンくず形式になることがあり、ページ構造をGoogleに正確に伝えられます。多くのページに横断的に適用できるので、サイト全体への効果が期待できます。

実装後に必ず行うべき検証ステップ

構造化データは「追加して終わり」ではありません。正しく記述されているか、Googleが認識できているかの確認が不可欠です。

① Googleのリッチリザルトテストを使う https://search.google.com/test/rich-results URLまたはコードを貼り付けると、エラーや警告を一覧で確認できます。エラーがあるスキーマはリッチリザルトの対象外になることが多いので、すべて解消することを目指してください。

② Schema.org バリデーターでの確認 https://validator.schema.org/ よりSchema.org側の仕様に沿ったチェックができます。リッチリザルトテストと両方使うと安心です。

③ Google Search Consoleの「拡張機能」レポートを確認する サーチコンソールの左メニューに「拡張機能」という項目があり、FAQやパンくずなど各スキーマタイプのステータスを確認できます。エラー・警告・有効の3段階で管理されているため、定期的なチェックを習慣にしてください。

実装時のよくある失敗：

実際のページ内容と構造化データの情報が食い違っている（Googleはスパム扱いする場合があります）
必須プロパティが不足している（警告ではなくエラーになる）
コピーしたコードの記号や括弧が壊れている（JSON構文エラー）

WordPress・CMSでの実装を効率化するには

フルスクラッチでHTMLを管理しているサイトなら直接コードを書けばよいですが、WordPressを使っている場合はプラグインを活用するのが現実的です。

Yoast SEO（有料版）やRank Mathは、記事投稿画面から構造化データを設定できる機能を持っています。Rank Mathは無料版でもスキーマ設定が充実しており、使い勝手が良いと評判です。ただし、細かいカスタマイズや複数スキーマの組み合わせが必要な場合は、手動でJSON-LDを追加するほうが正確に実装できることがあります。

Googleタグマネージャー（GTM）経由でJSON-LDを注入する方法もあります。CMSに直接手を入れたくない場合や、複数ページへの一括適用に便利ですが、Googleがタグマネージャー経由の構造化データを確実にクロールできるかどうか、挙動を慎重に確認してください。

まとめ：構造化データは「検索エンジンとの対話」を整える作業

構造化データの実装は、即座に検索順位が上がる魔法の施策ではありません。しかし、正確に実装することで検索エンジンがサイトの内容をより深く理解し、リッチリザルトの表示機会が増え、ユーザーの目に止まりやすくなる可能性が高まります。

取り組む優先順位としては、以下の順がおすすめです。

BreadcrumbList：ほぼすべてのページに適用可、影響範囲が広い
LocalBusiness：地域密着型のビジネスなら最優先
FAQPage：コンテンツ内にQ&Aがある場合に積極的に追加
Article/BlogPosting：ブログ運用中のサイト向け
Product：製品・サービスページがあれば検討

構造化データはSEO対策の「基盤整備」に近い作業です。一度きちんと設計して実装しておけば、コンテンツSEOや被リンク施策の効果をより高めるベースになります。

株式会社サイプレスでは、構造化データの設計・実装から、実装後のサーチコンソールを使った効果検証まで対応しています。「自社サイトに何を入れればいいかわからない」「実装したけれどエラーが出てしまった」という段階からでもご相談いただけます。SEO対策やAIO対策とあわせて、サイト全体の検索パフォーマンスを見直したい方はお気軽にお問い合わせください。