SEOのための構造化データ:その正体とスキーママークアップの実装方法

SEOのための構造化データ:その正体とスキーママークアップの実装方法

構造化データとは、ページの内容が何を意味するのかを検索エンジンに正確に伝えるために、ページへ追加するコードです。この文字列は価格、こちらは著者、このブロックはレシピ、といった具合です。ほとんどの人はこれをスキーママークアップと呼びます。記述にほぼ誰もが使う共通の語彙(スキーマ)にちなんだ呼び名です。

もしあなたが「スキーマを追加すればランキングは動くのか?」と思ってここに来たのなら、正直に言うとそれ自体では効果はありません。 構造化データは機能が表示される「可能性」を生み出すだけで、表示を保証するものではなく、リッチリザルトが最良の体験かどうかはクエリごとにGoogleが判断します。

とはいえ、リッチリザルトを獲得したページはより多くのクリックを得る傾向があり、Google自身の事例研究もそれを裏付けています。Nestléはリッチリザルトとして表示されたページでクリック率が82%高いことを測定し、Rotten Tomatoesは構造化データのあるページはないページに比べてCTRが25%高いと報告しました。

構造化データ(スキーママークアップ)とは何か

「スキーママークアップ」と「構造化データ」は、厳密には同じものではないものの、しばしば同じ意味で使われます。

構造化データとは、コンテンツを機械が読み取れる形でラベル付けする一般的な手法です。Schema.orgは、そのためにほぼ誰もが使う共通の語彙であり、Google、Microsoft、Yahoo、Yandexが支える共同プロジェクトです。つまり「スキーマを追加する」と言うとき、人々は「Schema.orgの構造化データを追加する」ことを意味しています。

同じ商品ページを2つ並べた図。左は訪問者が見るもの——タイトル、星評価、価格、著者。右は検索エンジンが読むJSON-LDで、ページ上の価格・評価・著者をマークアップ内の対応するフィールドとコーラル色のラベルでつないでいる
構造化データは、ページ上の価格・評価・著者にラベルを付け、検索エンジンが読み取れるようにする

形式は3つあります。JSON-LD、Microdata、RDFaです。GoogleはJSON-LDを推奨しており、以下のすべての例でもこの形式を使います。

JSON-LDは単一の<script>ブロックに収まり、通常は<head>内に、表示用のHTMLとは分離して置かれます。だからこそ、実際のページ要素に属性を巻き付けるMicrodataやRDFaよりも、追加・保守・デバッグが容易です。Microdataを使うサイトを引き継いだ場合でも動作はしますが、新しいマークアップはJSON-LDにすべきです。

スキーマが今、以前より重要な理由

構造化データはかつてないほど重要です。理由は3つあり、判断にどれだけ影響すべきかの順に並べます。

  1. リッチリザルト。 これは青いリンクを超えた拡張リスティングです。星評価、商品価格、パンくず、サイトリンク、レシピカードなど。より多くのスペースを取り、より多くの注目を集めます。これは最も直接的で測定可能なメリットです。
  2. エンティティの理解。 スキーマはGoogleに、ページ上にどんな単語があるかだけでなく、あなたが何者かを伝えます。LinkedIn、X、WikipediaのプロフィールへのsameAsリンクを含むOrganizationマークアップは、Googleがあなたのサイトをナレッジグラフ上の既知のエンティティと結びつけるのを助けます。
  3. AIとAIによる概要。 スキーマそれ自体がAIの引用を解き放つわけではありませんが、ページ上の事実を明示的かつ一貫したものにします。これは人間であれモデルであれ、あらゆるシステムがそれらを正しく解析するのに役立ちます。
Google検索での同じ結果の比較。左はマークアップのないプレーンな青いリンクのリスティング、右はパンくず・星評価・レビュー数・価格・サムネイルを備えたリッチリザルトで、ページ上でより多くのスペースを占めている
リッチリザルトは星・価格・パンくずを加え、プレーンな青いリンクよりも多くのスペースを取り、注目を集める

2026年でもリッチリザルトを獲得できるスキーマの種類

ここでは主力となる種類を、それぞれコピー&ペーストできるJSON-LDとともに紹介します。実際の値に差し替え、すべてのフィールドを訪問者がページで実際に目にする内容と一致させてください。

Article / BlogPosting

ブログ記事、ニュース、編集コンテンツ向け。

{
  "@context": "https://schema.org",
  "@type": "BlogPosting",
  "headline": "Structured Data for SEO: What It Is and How to Add Schema Markup",
  "image": "https://example.com/images/structured-data.png",
  "datePublished": "2026-07-07",
  "dateModified": "2026-07-07",
  "author": {
    "@type": "Person",
    "name": "Jane Doe",
    "url": "https://example.com/author/jane-doe"
  },
  "publisher": {
    "@type": "Organization",
    "name": "Example",
    "logo": {
      "@type": "ImageObject",
      "url": "https://example.com/logo.png"
    }
  }
}

Product(OfferとratingつきのProduct)

商品を販売するページ向け。

{
  "@context": "https://schema.org",
  "@type": "Product",
  "name": "Trail Running Shoe X",
  "image": "https://example.com/shoe.jpg",
  "description": "Lightweight trail shoe with a grippy outsole.",
  "brand": { "@type": "Brand", "name": "Acme" },
  "sku": "ACME-TRX-42",
  "offers": {
    "@type": "Offer",
    "url": "https://example.com/shoe",
    "price": "129.00",
    "priceCurrency": "USD",
    "availability": "https://schema.org/InStock"
  },
  "aggregateRating": {
    "@type": "AggregateRating",
    "ratingValue": "4.6",
    "reviewCount": "218"
  }
}

Review

商品、書籍、映画、サービスの編集レビュー向け。

{
  "@context": "https://schema.org",
  "@type": "Review",
  "itemReviewed": { "@type": "Product", "name": "Trail Running Shoe X" },
  "reviewRating": {
    "@type": "Rating",
    "ratingValue": "4",
    "bestRating": "5"
  },
  "author": { "@type": "Person", "name": "Jane Doe" },
  "reviewBody": "Comfortable over long distances, though sizing runs small."
}

階層構造の中にあるあらゆるページ向け。現在のページは最後の項目で、itemを省略します。

{
  "@context": "https://schema.org",
  "@type": "BreadcrumbList",
  "itemListElement": [
    { "@type": "ListItem", "position": 1, "name": "Home", "item": "https://example.com" },
    { "@type": "ListItem", "position": 2, "name": "Blog", "item": "https://example.com/blog" },
    { "@type": "ListItem", "position": 3, "name": "Structured Data" }
  ]
}

Organization(sameAsつきのOrganization)

これはサイト全体で一度だけ(トップページまたはグローバルテンプレートに)配置します。sameAs配列がエンティティを明確にするための要となる仕組みです。

{
  "@context": "https://schema.org",
  "@type": "Organization",
  "name": "Example",
  "url": "https://example.com",
  "logo": "https://example.com/logo.png",
  "sameAs": [
    "https://www.linkedin.com/company/example",
    "https://x.com/example",
    "https://en.wikipedia.org/wiki/Example"
  ]
}

LocalBusiness

物理的な所在地を持つビジネス向け。汎用のLocalBusinessではなく、利用できる最も具体的なサブタイプ(Restaurant、Dentistなど)がある場合はそちらを使いましょう。

{
  "@context": "https://schema.org",
  "@type": "LocalBusiness",
  "name": "Example Coffee",
  "image": "https://example.com/store.jpg",
  "@id": "https://example.com",
  "url": "https://example.com",
  "telephone": "+1-555-0100",
  "address": {
    "@type": "PostalAddress",
    "streetAddress": "123 Main St",
    "addressLocality": "Austin",
    "addressRegion": "TX",
    "postalCode": "78701",
    "addressCountry": "US"
  },
  "geo": {
    "@type": "GeoCoordinates",
    "latitude": 30.2672,
    "longitude": -97.7431
  },
  "openingHours": "Mo-Fr 07:00-18:00"
}

FAQPageとHowTo

Googleは**2026年5月7日にFAQのリッチリザルトを廃止し、**2023年8月に権威ある政府・医療サイトに限定して始めた縮小を完了させました。HowToのリッチリザルトは、さらに前の2023年9月にデスクトップで廃止されています。

Googleはページを理解するために今でもFAQPageを解析します。 ただ、検索で開閉できるQ&Aパネルが表示されなくなっただけです。ですからFAQコンテンツはページに残しましょう。実際の質問に答え、機械があなたを読み取るのを助けるからです。ただし、目に見えるSERP機能を期待してスキーマを追加するのはやめましょう。

{
  "@context": "https://schema.org",
  "@type": "FAQPage",
  "mainEntity": [{
    "@type": "Question",
    "name": "Does schema markup guarantee rich results?",
    "acceptedAnswer": {
      "@type": "Answer",
      "text": "No. Valid markup makes a page eligible, but Google decides whether to show a rich result."
    }
  }]
}

どのページにどのスキーマを使うか

最もよくある間違いは、ページに間違った種類を貼り付けること、あるいは当てはまらない種類を重ねてしまうことです。最も具体的な種類を、そのページが実際に何であるかに合わせ、それが今でもリッチリザルトを生成するかを確認しましょう。

ページスキーマ2026年のリッチリザルト
ブログ記事、ニュース、ガイドArticle / BlogPostingあり
商品ページProduct + Offerあり
編集レビューProduct + Reviewあり
階層内のあらゆるページBreadcrumbListあり
トップページ / 会社概要Organizationエンティティのみ
物理的な所在地LocalBusinessあり(ローカル)
レシピRecipeあり
動画VideoObjectあり
FAQブロックFAQPageなし(廃止)
手順の説明HowToなし(廃止)

Googleのガイドラインは、適用できる最も具体的な種類を使い、構造化データはそれが説明するページに置くことです。

スキーマをテストして検証する方法

確認していないスキーマを公開してはいけません。公式ツールは2つ、それぞれ役割が1つずつあります。

  • リッチリザルトテストは、ページがGoogleのリッチリザルトの対象になるかどうかを教え、どのように表示され得るかをプレビューします。「これは機能を獲得できるか?」に答えるために使いましょう。
  • スキーママークアップ検証ツールは、Google固有の機能チェックなしに、あらゆるSchema.orgマークアップを汎用的に検証します。「構文的に正しいか?」に答えるために使います。これは旧・構造化データテストツールの後継です。

スキーマは静かに壊れます。テーマの更新やプラグインの競合が、目に見えるエラーなしに何百ものページからJSON-LDを取り除くことがあります。だからこそ本当のワークフローはこうです。公開前に検証し、テンプレートの変更やデプロイのたびに再確認し、Search Consoleの拡張レポートでリッチリザルトの状態を継続的に監視すること。

4段階の検証ループ。scriptブロックにJSON-LDを書き、リッチリザルトテストとスキーママークアップ検証ツールで検証し、公開ページに反映し、Search Consoleの拡張レポートを監視する。テンプレート変更やデプロイのたびに再確認へと戻る矢印がついている
公開前に検証し、その後もテンプレートの変更やデプロイのたびに再確認する

SEOcrawl AIですべてのページの構造化データを検証する

2つのGoogleツールを手作業で実行するのはスポットチェックには十分ですが、スケールしませんし、デプロイがテンプレート全体のマークアップをひそかに壊したときには教えてくれません。

素早い単一ページのチェックには、SEOcrawl AIの無料スキーマバリデーターが、URLのJSON-LDをSchema.org仕様とGoogleのリッチリザルトポリシーの両方に照らして監査します。ページ上のすべてのブロックを抽出し、資格を妨げるエラーと、単に弱めるだけの警告を切り分けるので、まず何を直すべきかが正確に分かります。

そしてマークアップのリグレッションはたいていリッチリザルトのカバレッジの低下として現れるため、SEOcrawl AIは拡張の側面も追跡します。Search Consoleのカバレッジとクエリのデータを——手動で、自動ルールで、あるいはClaudeやChatGPTから直接SEOcrawl MCPサーバーを通じて——引き出せるので、スキーマを取り除くテンプレート変更が、謎ではなく測定可能な変化として表れます。

よくある質問

スキーママークアップはランキングを上げますか、それとも迷信ですか?

スキーマはランキング要因ではありません。ページをリッチリザルトの対象にし、検索エンジンがコンテンツを理解する助けにはなりますが、それ自体が順位を押し上げることはありません。 メリットは間接的です。リッチリザルトを獲得したページは、クリック率が高くなる傾向があります。

FAQのリッチリザルトは廃止されましたが、FAQPageスキーマは削除すべきですか?

いいえ。GoogleはFAQPageが引き続き有効な種類であり、ページを理解するために今でもマークアップを解析することを確認しています。ただ、開閉できるパネルが表示されなくなっただけです。その時間はFAQのコンテンツに費やしましょう。今でもロングテールのトラフィックを獲得し、AIシステムが回答を抽出するのにも役立ちます。

スキーマを追加してからリッチリザルトが表示されるまで、どれくらいかかりますか?

決まった期間はありません。Googleはまずページを再クロールして再処理する必要があり、サイトのクロール頻度によって数日から数週間かかることがあります。しかも**有効なマークアップがあっても得られるのは資格だけで、**確約された枠ではありません。

ChatGPTやAIによる概要に引用されるにはスキーマが必要ですか?

特に必要ではありません。GoogleはAIによる概要やAIモードに特別なスキーマは不要だと明言しています。重要なのは、構造化データが表示コンテンツと一致していること、そしてそのコンテンツが本当に質問に答えていることです。スキーマはモデルにとっての曖昧さを減らすので役立ちますが、引用を強制するものではありません。

JSON-LDを追加するとページが遅くなりますか?

いいえ。JSON-LDのブロックはページソース内の小さなテキストにすぎず、視覚的に何かをレンダリングしたりブロックしたりすることはありません。唯一の実質的なコストはメンテナンスです。内容を正確に保ち、もう対象にしていない機能のブロックは削除しましょう。

著者: David Kaufmann

David Kaufmann

私はこの10年以上、SEOに完全に夢中になって過ごしてきました。正直なところ、他の生き方は考えられません。

私のキャリアが新たな次元に到達したのは、Chess.com でシニアSEOスペシャリストとして働いたときでした。Chess.com はインターネット全体で最も訪問数の多い上位100サイトの1つです。数百万ページ、数十言語、そして最も競争の激しい SERPs の1つという規模で仕事をした経験は、どんなコースや資格でも得られないことを教えてくれました。あの経験は、本当に優れたSEOとは何かという私の視点を一変させ、それ以降に私が築いてきたすべての土台となりました。

その経験から、私は SEO Alive を創業しました。オーガニック成長に本気で取り組むブランドのためのエージェンシーです。私たちは dashboards や月次レポートを売るためにここにいるのではありません。本当に成果を動かす戦略を構築するためにここにいます。クラシカルなSEOの最良の部分と、Generative Engine Optimization (GEO) というエキサイティングな新しい世界を組み合わせ、あなたのブランドが Google の青いリンクだけでなく、ChatGPT、Perplexity、Google AI Overviews が毎日何百万人もの人々に届けている AI 生成の回答の中にも確実に表示されるようにします。

そして、この両方の世界をきちんと扱えるツールが見つからなかったので、自分で作りました。それが SEOcrawl です。rankings、テクニカル監査、backlinks モニタリング、crawl ヘルス、そして AI ブランド可視性トラッキングを1つの場所に統合した、エンタープライズ向けのSEOインテリジェンスプラットフォームです。まさに、ずっと存在してほしいと願っていたプラットフォームです。

→ David のすべての記事を読む
著者の他の記事: David Kaufmann

この著者の他のコンテンツをご覧ください