Contact us

構造化データは「最小セット」から始めよう：FAQ・HowTo・製品・ローカルビジネスで実践する導入・運用ガイド

構造化データを最小セットで整理し、導入判断の全体像を示したミニマルなビジュアル

Contents

構造化データと聞くと、「専門的で難しそう」「すべてを完璧に実装しないと意味がないのでは？」「間違った実装はペナルティにつながるかもしれない」といった不安を感じるWeb担当者の方は少なくありません。確かに、Schema.orgには数百種類ものタイプが存在し、そのすべてを把握するのは困難です。

しかし、実務において最初からすべてを網羅する必要はありません。むしろ、事業への貢献度が高い特定のページタイプに絞り、必須プロパティのみで構成された「最小セット」から始めることが、最も安全かつ効果的なアプローチです。

本記事では、多くの中小企業のサイトで実装価値が高い「FAQ」「HowTo」「製品（Product）」「ローカルビジネス（LocalBusiness）」の4種類に焦点を当て、その最小要件、よくある落とし穴、そして導入後の検証・運用フローまでを実務的な視点で解説します。

必須プロパティだけで構成する

構造化データを必須プロパティのみに絞って設計する考え方を整理したビジュアル

構造化データの実装は、完璧を目指すよりも、まず必須項目を正しく記述することが重要です。ここでは、4つの主要なタイプについて、Googleが定める必須プロパティを中心とした最小構成を紹介します。

FAQ構造化データの最小要件

FAQPageは、よくある質問とその回答が記載されたページに適用します。ユーザーが検索結果画面で直接回答の一部を閲覧できるリッチリザルトが表示される可能性があります。

  • 必須プロパティ
    • mainEntity: 質問（Question）と回答（Answer）のペアを格納する配列です。
      • Question
        • name: 質問文そのもの。
        • acceptedAnswer:
          • Answer
            • text: 回答文そのもの。
  • 実装時の前提条件
    • ページに記載されている質問と回答のテキストと、構造化データの内容は完全に一致している必要があります。
    • ユーザーが自ら質問を投稿できるようなフォーラム形式のページではなく、サイト運営者が作成した静的なQ&Aページが対象です。

HowTo構造化データの最小要件

HowToは、ある目的を達成するための一連のステップを解説するコンテンツに適用します。手順が検索結果に表示されることがあります。

  • 適用できるコンテンツの条件
    • 料理のレシピ、修理の手順、特定の作業の進め方など、明確なステップが存在するコンテンツが対象です。
    • 各ステップがユーザーのアクションを記述している必要があります。広告や宣伝を目的としたコンテンツには使用できません。
  • 必須プロパティ
    • name: HowTo全体のタイトル（例：「ネクタイの結び方」）。
    • step: 手順の各ステップを HowToStep または HowToSection で記述します。
      • HowToStep
        • text または name: ステップの簡潔な説明。
        • url: （推奨）各ステップにアンカーリンクがある場合、そのURLを指定します。
        • image: （推奨）ステップを説明する画像。

製品（Product）構造化データの最小要件

Productは、特定の商品を販売するページで使用します。価格や在庫状況などが検索結果に表示される可能性があります。

  • 単一製品ページを前提とした考え方
    • このマークアップは、原則として「1つの商品」または「同じ商品の複数のバリエーション（色やサイズ違いなど）」を扱うページに適用します。カテゴリ一覧ページなど、複数の異なる商品が並ぶページには適していません。
  • 必須プロパティ
    • name: 製品名。
    • offers: 価格や販売状況に関する情報。
      • Offer
        • price: 価格（例: 1500）。
        • priceCurrency: 通貨コード（日本円なら JPY）。
        • availability: 在庫状況（例: https://schema.org/InStock ）。
    • review または aggregateRating: （推奨）レビューや評価がある場合は、どちらか一方または両方を含めます。これらが無い場合は必須ではありません。

ローカル（LocalBusiness）構造化データの最小要件

LocalBusinessは、実店舗を持つ企業や特定の地域でサービスを提供する事業の情報を記述します。店舗の場所、営業時間などがナレッジパネルやGoogleマップ上に表示されやすくなります。

  • NAP情報の一貫性
    • 構造化データに記述するName（名前）、Address（住所）、Phone（電話番号）は、Webサイト上の表記、Googleビジネスプロフィール、その他すべてのオンライン情報と完全に一致させることが極めて重要です。
  • 対象ページの考え方
    • 会社概要ページ、店舗情報ページ、またはサイトの全ページフッターなど、企業の公式な連絡先情報が記載されている場所に実装するのが一般的です。
  • 必須プロパティ
    • name: 企業・店舗名。
    • address: 住所。
      • PostalAddress
        • streetAddress: 市区町村以降の住所。
        • addressLocality: 市区町村。
        • addressRegion: 都道府県。
        • postalCode: 郵便番号。
        • addressCountry: 国コード（日本なら JP）。
    • telephone: 電話番号。

よくある落とし穴

構造化データとページ内容の不一致や多重定義といった落とし穴を示唆するビジュアル

構造化データの実装では、意図せずエラーやポリシー違反を犯してしまうケースがあります。ここでは、特に注意すべき3つのポイントを解説します。

ページ内容と一致しないマークアップ

最も多い間違いの一つが、構造化データの内容と、ユーザーが実際にページ上で見るコンテンツが一致していないケースです。

  • テンプレ流用時の注意点
    • 別のページからJSON-LDスニペットをコピーして使い回す際、内容を修正し忘れると、古い情報や無関係な情報がマークアップされてしまいます。特にFAQや製品情報で発生しがちです。必ずページ固有の情報に書き換えてください。

同一ページへの多重定義

1つのページに対して、同じタイプの構造化データが複数回出力されてしまう問題です。

  • プラグイン・テーマ併用時のリスク
    • 例えば、使用しているWordPressテーマが自動でLocalBusinessを出力し、さらにSEOプラグインでも同じ設定をしていると、LocalBusinessが二重に定義されることがあります。どちらか一方を無効にするか、設定を見直す必要があります。

非対応コンテンツへの適用

構造化データのタイプが、ページのコンテンツ内容と合っていないケースです。リッチリザルトを表示させたいがために、不適切なタイプを無理に適用することはスパムと見なされるリスクがあります。

  • FAQやHowToの誤用例
    • FAQ: ユーザーが質問を投稿できるフォーラムや、単一の質問と回答しかないページにFAQPageを使用するのは誤りです。
    • HowTo: 単なるヒント集やリスト形式の記事で、明確な時系列や手順が存在しないものにHowToを適用することはできません。

検証フローの基本

構造化データの検証フローと継続運用を整理するための基本構造を示したビジュアル

構造化データを実装した後は、必ず正しく認識されているかを確認する作業が必要です。

実装後に必ず行うチェック

Googleのテストツールを使って、実装したコードに技術的な問題がないかを確認します。

  • 構文エラーと警告の違い
    • エラー: 致命的な問題であり、構造化データがGoogleに認識されない原因となります。例えば、必須プロパティの欠落や、JSON-LDの構文ミス（カンマの抜けなど）が該当します。エラーは必ず修正が必要です。
    • 警告: 必須ではないが、推奨されるプロパティが欠けている場合に表示されます。例えば、製品のreviewがない場合などです。警告は必ずしも修正が必要ではありませんが、追加することでリッチリザルトの表示機会を高める可能性があります。

テストツールの使い分け

Googleは2つの主要なテストツールを提供しており、目的に応じて使い分けることが重要です。

  • 構造化データ検証の考え方
    • リッチリザルト テスト: 特定のページがGoogleのリッチリザルトの対象となるかを検証するためのツールです。FAQやHowToなど、リッチリザルトが表示されるタイプはこちらでテストします。「有効」と表示されれば、技術的な要件は満たされています。
    • スキーマ マークアップ検証ツール: Schema.orgの構文全体を検証するための、より汎用的なツールです。リッチリザルト対象外のタイプ（例: WebSite）や、より詳細なデバッグを行いたい場合に使用します。

Search Consoleでの確認ポイント

実装した構造化データがサイト全体でどのようにGoogleに認識されているかは、Google Search Consoleで確認します。

  • レポートの見方
    • Search Consoleの「拡張」セクションに、サイトで検出された構造化データのタイプ（FAQ、商品など）ごとのレポートが表示されます。
    • レポートでは、「有効」「有効（警告あり）」「無効」のステータス別に、対象となるURLの数を確認できます。
  • エラー対応の基本姿勢
    • 「無効」と判定されたURLがある場合、その詳細を確認し、原因を特定して修正します。修正後は、Search Consoleから「修正を検証」をリクエストすることで、再クロールを促すことができます。エラーは放置せず、一つずつ着実に対応していくことが重要です。

運用テンプレとして考える

構造化データは一度実装して終わりではありません。サイトの更新に合わせて継続的にメンテナンスしていくための仕組み作りが大切です。

ページ追加・修正時の運用ルール

新しいページを追加したり、既存のページを更新したりする際のルールを明確にしておきましょう。

  • 手動修正と自動生成の切り分け
    • 手動修正: FAQページや製品ページなど、ページごとに内容が大きく異なる場合は、都度JSON-LDスニペットを手動で作成・修正するのが確実です。
    • 自動生成: CMSのカスタムフィールドなどを利用して、製品名や価格、質問・回答などを入力すれば、自動的にJSON-LDが生成される仕組みを構築できると、運用負荷が大幅に下がります。

構造化データを増やす判断基準

基本の4種類に慣れてきたら、他のタイプを追加することも検討できます。しかし、その判断は慎重に行うべきです。

  • 「増やす前に確認すべきこと」
    • Googleがサポートしているか？: その構造化データが、Googleの検索結果に何らかの影響を与える（リッチリザルトが表示されるなど）ものかを確認します。
    • コンテンツと一致しているか？: サイト内に、その構造化データを適用するのにふさわしいコンテンツが十分にあるかを確認します。
    • 運用コストに見合うか？: 新しいタイプを追加・維持するための手間やコストが、得られるであろうメリットに見合うかを検討します。

すぐに使えるJSON-LDスニペット（最小構成）

この記事で解説した4種類の構造化データをすぐに試せるよう、最小構成のJSON-LDスニペットを用意しました。これらを「たたき台」として、ご自身のサイトの情報に合わせて書き換えてご活用ください。

<details> <summary><strong>FAQPage スニペット</strong></summary>
JSON
{
  "@context": "https://schema.org",
  "@type": "FAQPage",
  "mainEntity": [
    {
      "@type": "Question",
      "name": "質問1のテキストをここに入力します 。",
      "acceptedAnswer": {
        "@type": "Answer",
        "text": "回答1のテキストをここに入力します。"
      }
    },
    {
      "@type": "Question",
      "name": "質問2のテキストをここに入力します。",
      "acceptedAnswer": {
        "@type": "Answer",
        "text": "回答2のテキストをここに入力します。"
      }
    }
  ]
}
</details> <details> <summary><strong>HowTo スニペット</strong></summary>
JSON
{
  "@context": "https://schema.org",
  "@type": "HowTo",
  "name": "手順全体のタイトルをここに入力します 。",
  "step": [
    {
      "@type": "HowToStep",
      "name": "ステップ1の説明",
      "text": "ステップ1の詳しい手順をここに記述します。"
    },
    {
      "@type": "HowToStep",
      "name": "ステップ2の説明",
      "text": "ステップ2の詳しい手順をここに記述します。"
    }
  ]
}
</details> <details> <summary><strong>Product スニペット</strong></summary>
JSON
{
  "@context": "https://schema.org",
  "@type": "Product",
  "name": "製品名をここに入力します 。",
  "image": [
    "https://example.com/product-image.jpg"
   ],
  "description": "製品の簡単な説明をここに入力します 。",
  "sku": "製品SKUまたは型番",
  "mpn": "製品MPNまたは製造番号",
  "brand": {
    "@type": "Brand",
    "name": "ブランド名"
  },
  "offers": {
    "@type": "Offer",
    "url": "https://example.com/product-page.html",
    "priceCurrency": "JPY",
    "price": "1500",
    "availability": "https://schema.org/InStock",
    "itemCondition": "https://schema.org/NewCondition"
  }
}
</details> <details> <summary><strong>LocalBusiness スニペット</strong></summary>
JSON
{
  "@context": "https://schema.org",
  "@type": "LocalBusiness",
  "name": "企業名または店舗名をここに入力します 。",
  "image": "https://example.com/logo.png",
  "@id": "https://example.com/",
  "url": "https://example.com/",
  "telephone": "03-1234-5678",
  "address": {
    "@type": "PostalAddress",
    "streetAddress": "丸の内1-1-1",
    "addressLocality": "千代田区",
    "addressRegion": "東京都",
    "postalCode": "100-0005",
    "addressCountry": "JP"
  }
}
</details>
Share the Post:

Related Posts