Search OS
用語集
SEO

スキーママークアップ

スキーママークアップは、schema.orgの語彙を使用してページ内容の意味(著者、評価、価格、イベントなど)を明確に示し、検索エンジンが理解できるようにする標準化された構造化データです。Googleはこのマークアップを読み取り、星評価、FAQ、パンくずリストなどのリッチリザルトを表示します。また、JSON-LD、Microdata、RDFaをサポートしていますが、実装と保守が最も簡単な形式であるため、JSON-LDを推奨しています。

  • Schema markup は標準化された構造化データであり、search engine にページの意味を明示するために schema.org の語彙を使用します。

  • マークアップが設定されていると、Google は星評価、FAQ、パンくずリストなどの rich results を表示でき、視認性とクリック率を向上させます。

  • JSON-LD、Microdata、RDFa はいずれもサポートされていますが、Google は実装と保守が最も簡単であるため、JSON-LDを推奨しています。

  • 強化表示(rich results)の対象になるには、該当する種類に必要な必須プロパティをすべて入力する必要があります。

  • ページ上で実際に表示されている内容とマークアップの値を一致させる必要があり、公開前に Rich Results Test で検証してください。

Google 検索のレシピ リッチ リザルト

Google のレシピ リッチ リザルトでは、星評価、画像、調理時間はいずれも各ページの Recipe スキーマ マークアップから取得されています。この視覚的な表示は、構造化データがもたらす成果です。

スキーマ マークアップとは

スキーマ マークアップは、ページ内に構造化データを埋め込み、検索エンジンに「このテキストが実際に何を意味するのか」を明示的に伝えるための標準的な方法です。Google 自身の説明を借りると、レシピページではどの値が材料なのか、調理時間なのか、温度なのか、カロリー数なのかを示します。人間から見れば文字はどちらも同じに見えますが、検索エンジンは「Avatar」が映画を指すのかプロフィール画像を指すのかを判別しづらいため、schema.org の語彙を使ってコンテンツに意味を付与します。

スキーマ マークアップが適用されると、Google はそれをリッチ スニペット(リッチ リザルト)の基盤として使用します。星評価、展開可能な FAQ、パンくずナビゲーション、価格と在庫状況、イベントのスケジュールなどの拡張表示がその例です。schema.org は Google、Microsoft(Bing)、Yandex、Yahoo が共同で使用する共通語彙であるため、1 つの実装を複数の検索エンジンや AI が参照できます。answer engineを一度に。

JSON-LDの例(Google推奨の形式)

JSON-LDはデータを<script type="application/ld+json">ブロック内にラップします。可視の本文コンテンツと混在しないため、最も扱いやすい形式です。以下はArticleタイプの有効なスニペットです。これは<head>または<body>のどちらにも配置できます。

<script type="application/ld+json">
{
  "@context": "https://schema.org",
  "@type": "Article",
  "headline": "スキーママークアップの完全ガイド",
  "image": "https://example.com/images/cover.jpg",
  "datePublished": "2026-01-05T08:00:00+09:00",
  "dateModified": "2026-02-05T09:20:00+09:00",
  "author": {
    "@type": "Person",
    "name": "Jane Doe",
    "url": "https://example.com/profile/jane"
  },
  "publisher": {
    "@type": "Organization",
    "name": "SearchOS",
    "logo": {
      "@type": "ImageObject",
      "url": "https://example.com/logo.png"
    }
  }
}
</script>

重要な要素は3つあります。@contextは語彙のソースを宣言し(https://schema.org)、@typeはオブジェクトの種類(Article、Product、FAQPage など)を宣言し、その下のプロパティはそのタイプが必須または推奨するフィールドです。Google は、「拡張表示の対象となるには、必須プロパティをすべて含める必要があります」と述べており、少ない数であっても不正確な値を無理に入れるより、少数でも正確で完全な値を優先しつつ、可能な限り多くの推奨プロパティを追加するよう勧めています。

JSON-LD、Microdata、RDFaの違い

Google は、(正しく実装されている限り)この3つのフォーマットを同等にサポートしており、多くの場合は JSON-LD を推奨しています。JSON-LD は、大規模に実装・管理しやすく、エラーが最も起こりにくい形式です。

ディメンション

JSON-LD(推奨)

Microdata

RDFa

フォーム

JSONとして分離され、<script>ブロック内に配置

HTMLタグ属性としてインラインで記述

HTMLタグ属性としてインラインで記述

本文との関係

本文と交差せずに配置される(スタンドアロンのブロック)

可視マークアップに直接付加

可視コンテンツに直接付加

標準の起源

JavaScript表記法(W3C勧告)

オープンコミュニティのHTML仕様

HTML5拡張

主な配置場所

<head>/<body>

主に<body>(headも可)

両方<head><body>

動的挿入

Googleは、JSで挿入された場合でも読み取ります

静的マークアップに基づく

静的マークアップに基づく

保守

簡単(データが1か所に集約される)

中程度(ネストが深くなるほど複雑になる)

中程度

同じデータを2つの形式で表現すると、その違いが明確になります。以下は、同一のBreadcrumbListをJSON-LDとMicrodataで記述した例です。

JSON-LD

<script type="application/ld+json">
{
  "@context": "https://schema.org",
  "@type": "BreadcrumbList",
  "itemListElement": [
    { "@type": "ListItem", "position": 1, "name": "Blog", "item": "https://example.com/blog" },
    { "@type": "ListItem", "position": 2, "name": "SEO", "item": "https://example.com/blog/seo" },
    { "@type": "ListItem", "position": 3, "name": "Schema Markup" }
  ]
}
</script>

Microdata

<ol itemscope itemtype="https://schema.org/BreadcrumbList">
  <li itemprop="itemListElement" itemscope itemtype="https://schema.org/ListItem">
    <a itemprop="item" href="https://example.com/blog">
      <span itemprop="name">Blog</span></a>
    <meta itemprop="position" content="1" />
  </li>
  <li itemprop="itemListElement" itemscope itemtype="https://schema.org/ListItem">
    <a itemprop="item" href="https://example.com/blog/seo">
      <span itemprop="name">SEO</span></a>
    <meta itemprop="position" content="2" />
  </li>
</ol>

Microdataでは、あちこちにitemscopeitemtype、そしてitemprop属性が表示中のマークアップ全体に散在するため、ネストが深くなるほど管理が煩雑になります。JSON-LDではデータが1つのブロックにまとまるため、テンプレート化や検証が容易です。

実際の効果(Googleのケーススタディ)

Google Search Centralが公開している導入事例は次のとおりです(出典: Googleのstructured dataドキュメントの紹介)。

  • Rotten Tomatoes: 100,000ページに構造化データを適用し、25% higherclick-through rate(CTR)を達成しました。構造化データなしのページと比較して。

  • Food Network:ページの80%を検索機能に対応させた結果、訪問数が35%増加しました。

  • Rakuten:構造化データのあるページでは、ユーザーの滞在時間が1.5倍長くなり、インタラクション率は3.6倍高くなりました(AMP上)。

  • Nestléリッチリザルトとして表示されたページは、非リッチリザルトページよりCTRが82%高くなりました。 than non-rich-result pages.

とはいえ、リッチリザルトが必ず表示されるわけではありません。Googleは、マークアップが有効であっても、表示するかどうかは自社のアルゴリズムが判断すると述べています。Googleはまた、次の2つのガイドラインを明示しています。ユーザーに見えない情報をマークアップしないこと、そして、マークアップのためだけに空のページを作成しないこと。

実装チェックリスト

  • 可能であればJSON-LDで記述する(Googleの推奨であり、管理しやすいため)。

  • schema.orgからタイプを選ぶ。ただし、Google Search Centralドキュメントを主な参照先として使用してください(Google が求める必須プロパティと推奨プロパティは、schema.org のものと異なる場合があります)。

  • 必須プロパティはすべて入力してください。1つでも欠けると、そのページは拡張表示の対象外になります。

  • マークアップの値は、ページ上で実際に見えている内容と一致させてください(不一致のある、または非表示のマークアップは不可)。

  • 公開前にRich Results Testで検証し、公開後は Search Console の Rich Results レポートで監視してください。

  • すべてのdata-vocabulary.orgマークアップは schema.org に移行してください。これらはもはやリッチリザルトの対象ではありません。

参考資料

関連コンテンツ

既存のウェブサイトを維持したまま、

検索とAIが情報を読み取れる状態を確認します。

SEOの基盤からAI検索での可視性まで、継続して運用します。

まずは製品資料で、Search OSの仕組みをご確認ください。