# SEOのための構造化データ:その正体とスキーママークアップの実装方法 **構造化データ** とは、ページの内容が何を意味するのかを検索エンジンに正確に伝えるために、ページへ追加するコードです。この文字列は価格、こちらは著者、このブロックはレシピ、といった具合です。ほとんどの人はこれを **スキーママークアップ** と呼びます。記述にほぼ誰もが使う共通の語彙(スキーマ)にちなんだ呼び名です。 もしあなたが「スキーマを追加すればランキングは動くのか?」と思ってここに来たのなら、正直に言うと **それ自体では効果はありません。** 構造化データは機能が表示される「可能性」を生み出すだけで、表示を保証するものではなく、リッチリザルトが最良の体験かどうかはクエリごとにGoogleが判断します。 とはいえ、 **リッチリザルトを獲得したページはより多くのクリックを得る傾向があり、** [Google自身の事例研究](https://developers.google.com/search/docs/appearance/structured-data/intro-structured-data) もそれを裏付けています。Nestléはリッチリザルトとして表示されたページでクリック率が82%高いことを測定し、Rotten Tomatoesは構造化データのあるページはないページに比べてCTRが25%高いと報告しました。 ## 構造化データ(スキーママークアップ)とは何か 「スキーママークアップ」と「構造化データ」は、厳密には同じものではないものの、しばしば同じ意味で使われます。 構造化データとは、 **コンテンツを機械が読み取れる形でラベル付けする一般的な手法** です。Schema.orgは、そのためにほぼ誰もが使う共通の語彙であり、Google、Microsoft、Yahoo、Yandexが支える共同プロジェクトです。つまり「スキーマを追加する」と言うとき、人々は「Schema.orgの構造化データを追加する」ことを意味しています。 構造化データは、ページ上の価格・評価・著者にラベルを付け、検索エンジンが読み取れるようにする 形式は3つあります。JSON-LD、Microdata、RDFaです。Googleは **JSON-LD** を推奨しており、以下のすべての例でもこの形式を使います。 ## スキーマが今、以前より重要な理由 構造化データはかつてないほど重要です。理由は3つあり、判断にどれだけ影響すべきかの順に並べます。 1. **リッチリザルト。** これは青いリンクを超えた拡張リスティングです。星評価、商品価格、パンくず、サイトリンク、レシピカードなど。より多くのスペースを取り、より多くの注目を集めます。これは最も直接的で測定可能なメリットです。 2. **エンティティの理解。** スキーマはGoogleに、ページ上にどんな単語があるかだけでなく、あなたが _何者か_ を伝えます。LinkedIn、X、Wikipediaのプロフィールへの`sameAs`リンクを含むOrganizationマークアップは、Googleがあなたのサイトをナレッジグラフ上の既知のエンティティと結びつけるのを助けます。 3. **AIとAIによる概要。** スキーマそれ自体がAIの引用を解き放つわけではありませんが、ページ上の事実を明示的かつ一貫したものにします。これは人間であれモデルであれ、あらゆるシステムがそれらを正しく解析するのに役立ちます。 リッチリザルトは星・価格・パンくずを加え、プレーンな青いリンクよりも多くのスペースを取り、注目を集める ## 2026年でもリッチリザルトを獲得できるスキーマの種類 ここでは主力となる種類を、それぞれ **コピー&ペーストできるJSON-LD** とともに紹介します。実際の値に差し替え、すべてのフィールドを訪問者がページで実際に目にする内容と一致させてください。 ### Article / BlogPosting ブログ記事、ニュース、編集コンテンツ向け。 ```json { "@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) 商品を販売するページ向け。 ```json { "@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 商品、書籍、映画、サービスの編集レビュー向け。 ```json { "@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." } ``` ### BreadcrumbList 階層構造の中にあるあらゆるページ向け。現在のページは最後の項目で、`item`を省略します。 ```json { "@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`配列がエンティティを明確にするための要となる仕組みです。 ```json { "@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など)がある場合はそちらを使いましょう。 ```json { "@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機能を期待してスキーマを追加するのはやめましょう。** ```json { "@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](/content/ja/blog/google-search-console/index.html) の拡張レポートでリッチリザルトの状態を継続的に監視すること。 ## SEOcrawl AIですべてのページの構造化データを検証する 2つのGoogleツールを手作業で実行するのはスポットチェックには十分ですが、スケールしませんし、デプロイがテンプレート全体のマークアップをひそかに壊したときには教えてくれません。 素早い単一ページのチェックには、 [SEOcrawl AIの無料スキーマバリデーター](/content/ja/free-seo-tools/schema-validator/index.html) が、URLのJSON-LDをSchema.org仕様とGoogleのリッチリザルトポリシーの両方に照らして監査します。ページ上のすべてのブロックを抽出し、 **資格を妨げるエラーと、単に弱めるだけの警告を切り分ける** ので、まず何を直すべきかが正確に分かります。 そしてマークアップのリグレッションはたいていリッチリザルトのカバレッジの低下として現れるため、 [SEOcrawl AI](/content/ja/index.html) は拡張の側面も追跡します。Search Consoleのカバレッジとクエリのデータを——手動で、自動ルールで、あるいはClaudeやChatGPTから直接 [SEOcrawl MCPサーバー](/content/ja/mcp/index.html) を通じて——引き出せるので、スキーマを取り除くテンプレート変更が、謎ではなく測定可能な変化として表れます。 ## よくある質問 ### スキーママークアップはランキングを上げますか、それとも迷信ですか? スキーマはランキング要因ではありません。ページをリッチリザルトの対象にし、検索エンジンがコンテンツを理解する助けにはなりますが、 **それ自体が順位を押し上げることはありません。** メリットは間接的です。リッチリザルトを獲得したページは、クリック率が高くなる傾向があります。 ### FAQのリッチリザルトは廃止されましたが、FAQPageスキーマは削除すべきですか? いいえ。Googleは **FAQPageが引き続き有効な種類であり、ページを理解するために今でもマークアップを解析する** ことを確認しています。ただ、開閉できるパネルが表示されなくなっただけです。その時間はFAQの _コンテンツ_ に費やしましょう。今でもロングテールのトラフィックを獲得し、AIシステムが回答を抽出するのにも役立ちます。 ### スキーマを追加してからリッチリザルトが表示されるまで、どれくらいかかりますか? 決まった期間はありません。Googleはまずページを再クロールして再処理する必要があり、サイトのクロール頻度によって数日から数週間かかることがあります。しかも**有効なマークアップがあっても得られるのは資格だけで、**確約された枠ではありません。 ### ChatGPTやAIによる概要に引用されるにはスキーマが必要ですか? 特に必要ではありません。GoogleはAIによる概要やAIモードに特別なスキーマは不要だと明言しています。重要なのは、構造化データが表示コンテンツと一致していること、そしてそのコンテンツが本当に質問に答えていることです。スキーマはモデルにとっての曖昧さを減らすので役立ちますが、引用を強制するものではありません。 ### JSON-LDを追加するとページが遅くなりますか? いいえ。JSON-LDのブロックは **ページソース内の小さなテキスト** にすぎず、視覚的に何かをレンダリングしたりブロックしたりすることはありません。唯一の実質的なコストはメンテナンスです。内容を正確に保ち、もう対象にしていない機能のブロックは削除しましょう。 ## 著者: [David Kaufmann](/content/ja/author/david-kaufmann/index.html) 私はこの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インテリジェンスプラットフォームです。まさに、ずっと存在してほしいと願っていたプラットフォームです。 **著者の他の記事:** - [Google Discover とは何か、その仕組みと掲載される方法](/content/ja/blog/google-discover/index.html) - [Google Search Console でregexを使う方法](/content/ja/blog/google-search-console-regex/index.html) など.