構造化データ別ハンドブック｜SEOで使うべき主要スキーマと実装例を解説

まず結論からお伝えします。

• 構造化データは、検索エンジンにページ内容の「意味」を伝えるための補助情報です
• ただし、入れれば必ずリッチリザルトが出るわけではありません
• 大切なのは、Google検索が実際にサポートしているタイプだけを正しく使うことです

構造化データは、ウェブページのコンテンツを検索エンジンに明確に伝えるための仕組みです。

ページの見出しや本文をそのまま読むだけではなく、「これは記事」「これはパンくず」「これは商品情報」「これは動画情報」といった意味を機械可読な形で補足できます。

SEOでは、構造化データを入れることで検索エンジンがページを理解しやすくなり、条件を満たせばリッチリザルトの対象になることがあります。

ただし、構造化データは順位を直接上げる裏技ではありません。まずはページ自体の内容が有益で、構造化データの内容がページ上の見える情報と一致していることが前提です。

この記事では、Google検索で実際に使いやすい代表的な構造化データを体系的に整理し、コピーして使いやすいJSON-LDのサンプルとともに、実装時の注意点まで解説します。

SEO日報内のパンくずリストのSEO効果や関連記事の画像SEO完全ガイドと組み合わせることで、サイト全体のSEOを強化しやすくなります。
導線設計は『内部リンクの設計図』で体系化、基礎は『SEOとは？』へ。

構造化データとは？SEOでの役割

構造化データは、HTMLに追加するメタデータで、ページ内容を「何の情報か」として検索エンジンに伝えるためのものです。

主な形式には JSON-LD、Microdata、RDFa がありますが、Googleは JSON-LD を推奨しています。

SEOの基礎全体を復習したい方は、先に「SEOの基本」をご覧いただくと理解がスムーズです。

検索エンジンに意味を伝える技術

通常のHTMLは人間向けに書かれていますが、構造化データを使うと「これは記事タイトル」「これは著者」「これはパンくず」「これは価格」といった意味を検索エンジンに伝えやすくなります。

つまり、構造化データはページ内容の理解を補助するための技術です。

リッチリザルトとの関係

構造化データを実装すると、Google検索でリッチリザルトの対象になることがあります。

たとえば、パンくず、商品情報、レビュー評価、動画情報などは、条件を満たせば検索結果の見え方に反映される可能性があります。

ただし、構造化データを入れても表示は保証されません。Googleのアルゴリズム、検索クエリ、端末、ページ品質など、複数の条件で表示有無は決まります。

構造化データでできること / できないこと

• できること：検索エンジンにページ内容を分かりやすく伝える、リッチリザルトの対象になりうる状態を作る
• できないこと：順位上昇の保証、リッチリザルト表示の保証、薄いコンテンツの補強

まず優先したい代表的な構造化データ

schema.org には数多くのタイプがありますが、Google検索で実務的に使いやすいものから優先するのがおすすめです。

このハンドブックでは、特に次のタイプを中心に扱います。

• BreadcrumbList（パンくず）
• Article / NewsArticle（記事）
• Product（商品）
• Review snippet（レビュー）
• VideoObject（動画）
• Organization / WebSite（組織情報・サイト名）
• Image metadata（画像メタデータ）

一方で、FAQやHowToは以前と前提が変わっているため、後半で注意点として整理します。

代表的なスキーマとその実装例

BreadcrumbList（パンくずリスト）

パンくずの構造化データは、ページの階層を検索エンジンへ伝えるのに役立ちます。検索結果上でパンくずが反映されることもあり、ユーザーにも文脈が伝わりやすくなります。

「パンくずリストのSEO効果」でより詳しくご紹介しています。

<script type="application/ld+json">
{
  "@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": "現在のページ"
    }
  ]
}
</script>

構造化データはもちろん重要ですが、内部リンク構造の最適化もSEO評価に直結します。詳細は「内部リンクの設計図：テーマクラスターとアンカーテキストの実務」をご覧ください。

Article / NewsArticle（記事・メディア用）

記事のタイトル、著者、公開日、画像、発行元などを整理して伝えるのに向いています。

ニュース記事であれば NewsArticle、一般的なブログやコラムなら Article を使う考え方で問題ありません。

<script type="application/ld+json">
{
  "@context": "https://schema.org",
  "@type": "Article",
  "headline": "記事タイトル",
  "image": [
    "https://example.com/image.jpg"
  ],
  "author": {
    "@type": "Person",
    "name": "著者名"
  },
  "publisher": {
    "@type": "Organization",
    "name": "サイト名",
    "logo": {
      "@type": "ImageObject",
      "url": "https://example.com/logo.png"
    }
  },
  "datePublished": "2026-04-22",
  "dateModified": "2026-04-22"
}
</script>

NewsArticle を使う場合は "@type": "NewsArticle" に変更します。

Product（商品ページ用）

商品ページでは、価格、在庫、評価などを構造化データで伝えることで、Google検索やGoogle画像検索などで商品情報が豊かに見える可能性があります。

<script type="application/ld+json">
{
  "@context": "https://schema.org",
  "@type": "Product",
  "name": "商品名",
  "image": [
    "https://example.com/product.jpg"
  ],
  "description": "商品の説明文",
  "sku": "ABC-123",
  "brand": {
    "@type": "Brand",
    "name": "ブランド名"
  },
  "offers": {
    "@type": "Offer",
    "url": "https://example.com/product/",
    "priceCurrency": "JPY",
    "price": "9800",
    "availability": "https://schema.org/InStock"
  }
}
</script>

商品情報は、価格や在庫などの実際の表示内容と一致させることが重要です。

Review snippet（レビュー）

レビュー構造化データは、条件を満たせば星評価などの対象になり得ますが、使い方には注意が必要です。

特に、自社サイト上で自社ビジネスを自分で高評価表示させるような self-serving reviews は前提が厳しいため、乱用は避けるべきです。

<script type="application/ld+json">
{
  "@context": "https://schema.org",
  "@type": "Product",
  "name": "商品名",
  "aggregateRating": {
    "@type": "AggregateRating",
    "ratingValue": "4.4",
    "reviewCount": "37"
  }
}
</script>

レビュー系は、ページ上でユーザーに見えている内容と一致していることが特に重要です。

VideoObject（動画SEO用）

動画ページや動画埋め込みページでは、VideoObject を使うことで、動画情報を検索エンジンへ伝えやすくなります。
「動画SEO実践ガイド」で詳しくご紹介しています。

<script type="application/ld+json">
{
  "@context": "https://schema.org",
  "@type": "VideoObject",
  "name": "動画タイトル",
  "description": "動画の説明",
  "thumbnailUrl": [
    "https://example.com/thumbnail.jpg"
  ],
  "uploadDate": "2026-04-22",
  "contentUrl": "https://example.com/video.mp4",
  "embedUrl": "https://www.youtube.com/embed/xxxx"
}
</script>

動画SEOでは、構造化データだけでなく、動画がページ内で主目的として見つけやすいかも重要です。

Organization / WebSite（組織情報・サイト名）

サイト名や組織情報を整理して伝える用途では、Organization や WebSite が役立ちます。

特にホームページでのサイト名や基本情報の補足には実務上使いやすいタイプです。

<script type="application/ld+json">
{
  "@context": "https://schema.org",
  "@type": "WebSite",
  "name": "サイト名",
  "url": "https://example.com/"
}
</script>

組織情報を詳しく出したい場合は Organization を追加で使います。

Image metadata（画像メタデータ）

画像SEOの文脈では、まず本文との関連性、ファイル名、altテキスト、画像周辺の説明が重要です。

そのうえで、画像のクレジットやライセンス情報を伝えたい場合は、Google Images 向けの画像メタデータが役立つことがあります。

つまり、ImageObject を一般的な画像SEOの中心施策と考えるより、画像の詳細情報を補足する用途として捉える方が実務的です。

関連記事「画像SEO完全ガイド」もあわせてご覧ください。

FAQ / HowTo は以前と前提が違う

FAQPage

FAQPage の構造化データ自体は今も存在しますが、Google検索でFAQリッチリザルトが広く表示される前提ではありません。

現在は、主に well-known で authoritative な政府系・医療系サイトを中心に表示される扱いです。

そのため、一般企業サイトやブログでは、FAQを入れる目的を「検索結果で目立つため」だけに置かない方が安全です。FAQは、まずユーザーの不安や疑問を整理するためのコンテンツと考えるのがおすすめです。

HowTo

HowTo リッチリザルトは、現在は検索結果での扱いが大きく変わっており、従来のような前提で広く使うテーマではありません。

昔の「HowToを入れれば目立つ」という感覚で親記事に含めると、今はズレやすいため、本記事では主要な実装対象としては推していません。

実装テンプレート集（コピー可）

以下は JSON-LD の基本形です。
<head>内または本文内の適切な位置に設置できますが、テーマやCMSの仕様に合わせて管理しやすい方法を選びましょう。
あくまでテンプレートなので、自社サイトにあわせて値を差し替えてください。

複数スキーマを併用する例

<script type="application/ld+json">
[
  { "...Breadcrumb..." : "..." },
  { "...Article..." : "..." }
]
</script>

はてなブログ / WordPress の埋め込み例

• はてなブログ：記事編集画面の「HTML編集」から <script> を直接貼り付け
• WordPress：テーマ、プラグイン、またはカスタムHTMLブロックで管理

<!-- WordPress例: functions.phpに追加 -->
add_action('wp_head', function() {
  echo '<script type="application/ld+json"> {...コード...} </script>';
});

構造化データのテストとエラー修正

実装後は、必ず検証してください。構文が正しくても、Google検索で使われるとは限らないため、検証ツールの使い分けが重要です。

Rich Results Test の使い方

1. Rich Results Test にURLまたはコードを入力
2. 「検出されたアイテム」でGoogle検索向けのリッチリザルト適格性を確認
3. エラーや警告を修正

Rich Results Test は、Google検索が現在サポートしているタイプを前提にチェックするツールです。

Schema Markup Validator との違い

Schema Markup Validator は、Schema.org としての構文確認向けです。

一方、Rich Results Test は、Google検索での利用可能性確認向けです。

• Schema Markup Validator：構文の妥当性確認
• Rich Results Test：Google検索向けの適格性確認

Search Console での確認

Search Console では、実際にクロールされた後の認識状況を確認できます。

ただし、2026年以降は構造化データタイプに関する一部レポートの扱いが変わっているため、旧来の「拡張」レポート前提だけで運用しない方が安全です。実務では、Rich Results Test と URL検査を併用する考え方が使いやすいです。

よくある失敗と注意点

• ページに見えていない情報をマークアップする：見える内容と一致させる
• Google非対応タイプに過度な期待をする：Schema.org と Google検索は同義ではない
• FAQやHowToを旧前提で量産する：現在の表示条件を確認する
• リッチリザルト＝順位上昇と考える：構造化データは補助要素
• 検証せず公開する：最低限、Rich Results Test で確認する

まとめ：正しい構造化で検索結果の理解を助ける

構造化データは、「意味を明確に伝える」ことが本質です。

特に実務で優先しやすいのは、

• BreadcrumbList で階層を伝える
• Article / NewsArticle で記事情報を整理する
• Product や VideoObject で対象ページの主要情報を補足する
• Organization / WebSite でサイトの基本情報を整える

といった、Google検索で現在も使いやすいタイプです。

一方で、FAQやHowToのように前提が変わったタイプもあります。親記事では「何でも入れる」のではなく、今のGoogle検索で意味があるものを優先する方が実務的です。

まずは、パンくず、記事、商品、動画など、自サイトに関係する主要タイプから実装し、Rich Results Test で確認してみてください。

お悩みやご不明点がある方は、お気軽にコメント、お問い合わせください。

参照

• Google Search Central：Structured data markup that Google Search supports
• Google Search Central：General structured data guidelines
• Google Search Central：Introduction to structured data markup in Google Search
• Google Search Central Blog：Changes to HowTo and FAQ rich results
• Google Search Central：Article structured data
• Google Search Central：Product structured data
• Google Search Central：Review snippet structured data
• Google Search Central：Video best practices
• Google Search Central：Image metadata in Google Images
• Google Search Central Blog：Update on our efforts to simplify the search results page