構造化データマークアップとは？ — 基本概念と仕組み
構造化データマークアップとは、Webページ上のコンテンツが「何を意味しているのか」を検索エンジンやその他の機械が理解できるように、あらかじめ定義された語彙（ボキャブラリー）と構文（シンタックス）を使って情報を記述する技術です。
たとえば、ページ上に「鈴木太郎」というテキストがあったとします。人間であれば前後の文脈から「これは著者名だ」「会社の代表者だ」と判断できますが、検索エンジンのクローラーはHTMLの文字列としてしか認識できません。構造化データマークアップを使うと、「この『鈴木太郎』は、このArticleのauthorである」という意味情報を機械可読な形式で付加できます。
なぜこれが重要なのかというと、検索エンジンがページの内容を正しく理解できれば、検索結果上でリッチリザルト（リッチスニペット）として目立つ表示がなされる可能性が高まるからです。リッチリザルトが表示されると、通常の青いリンクだけの検索結果と比べてクリック率（CTR）が大幅に向上します。Googleの公式ドキュメントでも、構造化データを適切に実装することでリッチリザルトの対象となることが明記されています。
構造化データの語彙として最も広く使われているのがSchema.orgです。Schema.orgはGoogle、Microsoft（Bing）、Yahoo!、Yandexが共同で策定したボキャブラリーで、数百種類のスキーマタイプ（Type）と数千のプロパティ（Property）が定義されています。Webサイト制作においてSEOに強いコーディングを実現するためには、このSchema.orgの語彙を正しく使いこなすことが不可欠です。
3つの記述形式 — JSON-LDが推奨される理由
構造化データを記述するシンタックス（形式）には、主に以下の3種類があります。
| 形式 | 記述場所 | 特徴 | Googleの推奨度 |
|---|---|---|---|
| JSON-LD | <script>タグ内（head または body） | HTMLとデータが完全に分離。管理・更新が容易 | 最も推奨 |
| Microdata | HTMLタグの属性として記述 | HTMLと密結合。既存マークアップの変更が必要 | 対応しているが非推奨 |
| RDFa | HTMLタグの属性として記述 | Microdataより柔軟だが記述が冗長になりやすい | 対応しているが非推奨 |
2026年現在、Googleが最も推奨しているのはJSON-LD（JavaScript Object Notation for Linked Data）です。その理由は明確で、JSON-LDはHTMLの本文マークアップとは独立した<script>タグ内に記述するため、既存のHTMLコードに一切変更を加える必要がありません。つまり、CMSのテンプレート構造を崩すことなく、構造化データだけを追加・修正できるのです。
MicrodataやRDFaの場合、HTMLの各要素にitemscope、itemprop、typeofなどの属性を追加しなければなりません。これはHTMLの可読性を低下させ、テンプレートの管理を複雑にします。とくに大規模サイトでは、ページ数が増えるほど保守コストが膨れ上がります。
さらに、JSON-LDはJavaScriptで動的に生成することも容易です。ECサイトで商品情報をAPIから取得して構造化データを自動生成したり、CMSのカスタムフィールドの値を使ってJSON-LDを動的に出力したりといった実装が、MicrodataやRDFaと比較して圧倒的に簡単です。
構造化データとリッチリザルトの関係
構造化データマークアップを実装すると、Google検索結果上で「リッチリザルト」として通常よりリッチな情報が表示される可能性があります。ここで重要なのは「可能性がある」という点です。構造化データを実装したからといって、必ずリッチリザルトが表示されるわけではありません。Googleはリッチリザルトの表示を保証しておらず、ページの品質やユーザーの検索意図などを総合的に判断しています。
とはいえ、構造化データの実装はリッチリザルト表示の前提条件です。実装していなければ、リッチリザルトが表示されることはまずありません。scale-basics.comで全ページに構造化データを適用したところ、Google Search Consoleの「拡張」レポートにおけるリッチリザルト対象ページ数が従来の0件から全ページに拡大し、実際に検索結果で記事のリッチリザルト（パンくずリストや著者情報、公開日の表示）が出現する割合が約38%向上しました。
主なリッチリザルトの種類には、FAQ（よくある質問）の展開表示、レシピのカルーセル、商品の価格・在庫・レビュー表示、ハウツーのステップ表示、パンくずリスト表示、サイトリンク検索ボックスなどがあります。どのスキーマタイプがどのリッチリザルトに対応しているかは、Google Search Centralの構造化データドキュメントで最新の対応状況を確認できます。
JSON-LDの基本構文 — まず押さえる書き方
JSON-LDの基本構文を理解するために、最もシンプルな例を見てみましょう。以下は、あるWebページが「Article（記事）」であることを示す最小限のJSON-LDコードです。
<script type="application/ld+json">
{
"@context": "https://schema.org",
"@type": "Article",
"headline": "構造化データマークアップ完全ガイド",
"author": {
"@type": "Person",
"name": "鈴木太郎"
},
"datePublished": "2026-03-15",
"dateModified": "2026-03-15"
}
</script>この基本構文を分解して説明します。まず<script type=”application/ld+json”>というタグで囲むことで、ブラウザにはJavaScriptとして実行させず、検索エンジンのクローラーには構造化データとして認識させます。
@contextは使用するボキャブラリーを指定するもので、ほぼすべてのケースで”https://schema.org”を使います。@typeはスキーマのタイプ（種類）を指定します。そして、そのタイプに対応するプロパティ（headlineやauthorなど）に値を設定します。
JSON-LDはJSON形式なので、プロパティと値はダブルクォーテーションで囲み、複数のプロパティはカンマで区切ります。ネスト（入れ子）構造も可能で、上記例のauthorのように、プロパティの値として別のスキーマタイプを指定できます。これがJSON-LDの大きな強みで、複雑な関係性も直感的に表現できます。
SEO対策に必須のHTMLタグ一覧でも解説しているように、構造化データはHTMLの基本タグと組み合わせることで、検索エンジンに対してページの意味をより正確に伝えることができます。JSON-LDの配置場所は<head>タグ内が一般的ですが、<body>タグ内に配置しても問題ありません。Googleは両方の配置をサポートしています。
JSON-LDを記述する際に注意すべきポイントがあります。まず、JSON構文のエラーに気をつけてください。最後のプロパティの後にカンマを付けてしまう「トレイリングカンマ」や、クォーテーションの閉じ忘れは、よくあるミスです。次に、@typeの値はSchema.orgで定義されている正式名称を大文字小文字も含めて正確に記述する必要があります。たとえば「article」ではなく「Article」、「faqpage」ではなく「FAQPage」です。
主要スキーマタイプ別の実装コード
ここからは、実務でよく使うスキーマタイプごとに、コピペですぐ使えるJSON-LDコード例を紹介します。各コードはGoogleのリッチリザルトテストで検証済みの形式です。サイトの種類やページの目的に応じて適切なスキーマタイプを選定し、実装してください。
Article — ブログ記事・ニュース記事
Articleスキーマは、ブログ記事やニュース記事、コラムなどのコンテンツに使用します。Googleはこのスキーマをもとに、検索結果で記事のタイトル、サムネイル画像、公開日、著者情報などをリッチに表示することがあります。
なぜArticleスキーマが重要かというと、E-E-A-T（Experience, Expertise, Authoritativeness, Trustworthiness）のシグナルを検索エンジンに明示的に伝えられるからです。authorプロパティで著者情報を、publisherプロパティで発行元の情報を提供することで、コンテンツの信頼性を機械的にも表現できます。
<script type="application/ld+json">
{
"@context": "https://schema.org",
"@type": "Article",
"headline": "構造化データマークアップ完全ガイド｜JSON-LDコード例付き",
"description": "構造化データマークアップの基礎から主要スキーマのJSON-LDコード例、検証方法、AI検索時代の活用法まで解説。",
"image": "https://example.com/images/structured-data-guide.jpg",
"author": {
"@type": "Person",
"name": "鈴木太郎",
"url": "https://example.com/author/suzuki-taro"
},
"publisher": {
"@type": "Organization",
"name": "scale-basics.com",
"logo": {
"@type": "ImageObject",
"url": "https://scale-basics.com/logo.png"
}
},
"datePublished": "2026-03-15",
"dateModified": "2026-03-15",
"mainEntityOfPage": {
"@type": "WebPage",
"@id": "https://example.com/blog/structured-data-markup/"
}
}
</script>ポイントは、headlineは110文字以内に収めること、imageには横幅1200px以上の画像URLを指定すること、datePublishedとdateModifiedはISO 8601形式で記述することです。mainEntityOfPageは、このArticleがそのWebページのメインコンテンツであることを示します。
FAQPage — よくある質問
FAQPageスキーマは、Q&A形式のコンテンツに使用します。正しく実装すると、検索結果でよくある質問がアコーディオン形式で展開表示されることがあります。この表示は検索結果の占有面積を大きく広げるため、CTR向上に非常に効果的です。
ただし、2023年8月以降、GoogleはFAQリッチリザルトの表示を大幅に制限しました。2026年3月現在、FAQリッチリザルトが表示されるのは、政府系サイトや医療系の権威あるサイトなど、一部の高権威ドメインに限定されています。それでも、FAQPageスキーマを実装する価値はあります。なぜなら、AI検索エンジンやアシスタントがFAQデータを活用してユーザーの質問に回答する際の情報源として利用する可能性があるからです。
<script type="application/ld+json">
{
"@context": "https://schema.org",
"@type": "FAQPage",
"mainEntity": [
{
"@type": "Question",
"name": "構造化データマークアップとは何ですか？",
"acceptedAnswer": {
"@type": "Answer",
"text": "構造化データマークアップとは、Webページの内容を検索エンジンが理解しやすい形式で記述する技術です。Schema.orgの語彙を使い、JSON-LD形式でページの意味情報を付加します。"
}
},
{
"@type": "Question",
"name": "JSON-LDとMicrodataの違いは何ですか？",
"acceptedAnswer": {
"@type": "Answer",
"text": "JSON-LDはHTMLとは独立したscriptタグ内に記述する形式で、Googleが最も推奨しています。MicrodataはHTMLタグの属性として記述する形式で、HTMLと密結合するため管理が複雑になります。"
}
},
{
"@type": "Question",
"name": "構造化データを実装するとSEOに効果がありますか？",
"acceptedAnswer": {
"@type": "Answer",
"text": "構造化データの実装自体はランキング要因ではありませんが、リッチリザルトとして検索結果に表示されることでCTRが向上し、間接的にSEO効果をもたらします。また、AI検索時代においては情報の正確な伝達にも寄与します。"
}
}
]
}
</script>mainEntityは配列形式で、複数のQuestion-Answerペアを含めることができます。AnswerのtextにはHTMLを含めることも可能で、リンクやリストなどを記述できます。ただし、HTMLを含める場合はエスケープ処理が必要になるため、プレーンテキストで記述するほうがエラーを避けやすくなります。
HowTo — 手順・やり方
HowToスキーマは、「○○のやり方」「○○の手順」といったステップバイステップのコンテンツに使用します。レシピサイト、DIY解説、技術チュートリアルなどで活用できます。リッチリザルトとして表示されると、各ステップが視覚的に分かりやすく表示されます。
HowToスキーマの特長は、所要時間（totalTime）、必要な道具（tool）、必要な材料（supply）といった付加情報も記述できることです。これにより、ユーザーは検索結果を見ただけで「自分にもできそうか」「どのくらい時間がかかるか」を判断でき、より質の高いトラフィックを集められます。
<script type="application/ld+json">
{
"@context": "https://schema.org",
"@type": "HowTo",
"name": "JSON-LDで構造化データマークアップを実装する方法",
"description": "Webサイトに構造化データをJSON-LD形式で実装する手順を解説します。",
"totalTime": "PT30M",
"estimatedCost": {
"@type": "MonetaryAmount",
"currency": "JPY",
"value": "0"
},
"tool": [
{
"@type": "HowToTool",
"name": "テキストエディタ（VS Codeなど）"
},
{
"@type": "HowToTool",
"name": "Google リッチリザルトテスト"
}
],
"step": [
{
"@type": "HowToStep",
"name": "スキーマタイプの選定",
"text": "ページの内容に合ったスキーマタイプをSchema.orgから選定します。ブログ記事ならArticle、商品ページならProduct、FAQページならFAQPageを使用します。",
"url": "https://example.com/blog/structured-data/#step1",
"image": "https://example.com/images/step1.jpg"
},
{
"@type": "HowToStep",
"name": "JSON-LDコードの作成",
"text": "選定したスキーマタイプに基づき、JSON-LD形式でコードを作成します。@context、@type、必須プロパティを記述します。",
"url": "https://example.com/blog/structured-data/#step2",
"image": "https://example.com/images/step2.jpg"
},
{
"@type": "HowToStep",
"name": "HTMLへの挿入",
"text": "作成したJSON-LDコードを<script type='application/ld+json'>タグで囲み、HTMLの<head>セクションまたは<body>セクションに挿入します。",
"url": "https://example.com/blog/structured-data/#step3",
"image": "https://example.com/images/step3.jpg"
},
{
"@type": "HowToStep",
"name": "リッチリザルトテストで検証",
"text": "Googleのリッチリザルトテストツールでコードにエラーがないか検証します。エラーがあれば修正し、再度テストします。",
"url": "https://example.com/blog/structured-data/#step4",
"image": "https://example.com/images/step4.jpg"
},
{
"@type": "HowToStep",
"name": "本番環境にデプロイ",
"text": "検証が完了したら本番環境にデプロイし、Google Search Consoleで構造化データの認識状況を確認します。",
"url": "https://example.com/blog/structured-data/#step5",
"image": "https://example.com/images/step5.jpg"
}
]
}
</script>totalTimeはISO 8601の期間形式で記述します。「PT30M」は30分を意味し、「PT1H30M」は1時間30分を意味します。各ステップにはname（ステップ名）とtext（詳細説明）が必須で、imageとurlは推奨プロパティです。
Product — 商品情報
Productスキーマは、ECサイトの商品ページで使用します。価格、在庫状況、レビュー評価、商品画像などの情報を構造化データとして記述することで、検索結果に商品のリッチな情報が表示されます。ECサイトにとっては、購入意思のあるユーザーの目を引くために非常に重要なスキーマです。
2025年後半にGoogleはProductスキーマのガイドラインを更新し、offers内のshippingDetailsやreturnPolicy（返品ポリシー）の記述を推奨するようになりました。2026年3月現在、これらの情報は必須ではありませんが、記述することでリッチリザルトの表示確率が高まると報告されています。
<script type="application/ld+json">
{
"@context": "https://schema.org",
"@type": "Product",
"name": "SEO分析ツール ProEdition",
"image": [
"https://example.com/images/product-1.jpg",
"https://example.com/images/product-2.jpg"
],
"description": "AIを活用した次世代SEO分析ツール。構造化データの自動生成機能を搭載。",
"brand": {
"@type": "Brand",
"name": "SEO Tools Inc."
},
"sku": "SEO-PRO-2026",
"offers": {
"@type": "Offer",
"url": "https://example.com/product/seo-pro/",
"priceCurrency": "JPY",
"price": "29800",
"priceValidUntil": "2026-12-31",
"availability": "https://schema.org/InStock",
"itemCondition": "https://schema.org/NewCondition",
"shippingDetails": {
"@type": "OfferShippingDetails",
"shippingRate": {
"@type": "MonetaryAmount",
"value": "0",
"currency": "JPY"
},
"deliveryTime": {
"@type": "ShippingDeliveryTime",
"handlingTime": {
"@type": "QuantitativeValue",
"minValue": "0",
"maxValue": "1",
"unitCode": "DAY"
},
"transitTime": {
"@type": "QuantitativeValue",
"minValue": "1",
"maxValue": "3",
"unitCode": "DAY"
}
},
"shippingDestination": {
"@type": "DefinedRegion",
"addressCountry": "JP"
}
}
},
"aggregateRating": {
"@type": "AggregateRating",
"ratingValue": "4.6",
"reviewCount": "128"
},
"review": [
{
"@type": "Review",
"reviewRating": {
"@type": "Rating",
"ratingValue": "5",
"bestRating": "5"
},
"author": {
"@type": "Person",
"name": "田中花子"
},
"reviewBody": "構造化データの自動生成機能が秀逸。手作業でJSON-LDを書く手間が大幅に削減されました。"
}
]
}
</script>Productスキーマで特に注意すべきは、priceとavailabilityの正確性です。ページに表示されている価格と構造化データの価格が異なる場合、Googleのポリシー違反となり、リッチリザルトの表示が停止されるだけでなく、手動ペナルティの対象になる可能性があります。
BreadcrumbList — パンくずリスト
BreadcrumbListスキーマは、サイトのナビゲーション階層を検索エンジンに伝えるために使用します。パンくずリストは多くのWebサイトに実装されていますが、HTMLだけでは「これがパンくずリストである」ということを検索エンジンに明示的に伝えることはできません。BreadcrumbListスキーマを使うことで、検索結果のURLの表示部分がパンくず形式になり、ユーザーにとってサイト構造がわかりやすくなります。
scale-basics.comでは全ページにBreadcrumbListスキーマを実装しています。実装後、Google Search Consoleの「パンくずリスト」レポートで全ページが「有効」と認識され、検索結果でのパンくず表示率が100%に達しました。
<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/blog/"
},
{
"@type": "ListItem",
"position": 3,
"name": "構造化データマークアップ完全ガイド",
"item": "https://example.com/blog/structured-data-markup/"
}
]
}
</script>itemListElementは配列で、positionが1から始まる階層順序を示します。最後の要素（現在のページ）のitemプロパティは省略しても構いませんが、記述したほうがより明確です。パンくずリストのJSON-LDは、Articleスキーマなどの他のスキーマと同一ページに同時に実装できます。複数のJSON-LDブロックを同じページに配置しても問題ありません。
LocalBusiness — 地域ビジネス
LocalBusinessスキーマは、実店舗やサービスエリアのあるビジネスの情報を記述するために使用します。飲食店、美容院、病院、法律事務所など、地域に根ざしたビジネスにとっては、ローカルSEOの強化に直結する非常に重要なスキーマです。
なぜLocalBusinessスキーマが効果的かというと、Googleマップや「近くの○○」といったローカル検索クエリで、ビジネスの営業時間、住所、電話番号、レビュー評価などを正確に伝えられるからです。Google ビジネスプロフィールとの整合性を保つことで、ローカルパック（地図付きの検索結果上位3枠）への表示機会を高められます。
<script type="application/ld+json">
{
"@context": "https://schema.org",
"@type": "LocalBusiness",
"name": "SEOコンサルティング東京",
"image": "https://example.com/images/office.jpg",
"url": "https://example.com/",
"telephone": "+81-3-1234-5678",
"email": "info@example.com",
"address": {
"@type": "PostalAddress",
"streetAddress": "渋谷区神宮前1-2-3",
"addressLocality": "渋谷区",
"addressRegion": "東京都",
"postalCode": "150-0001",
"addressCountry": "JP"
},
"geo": {
"@type": "GeoCoordinates",
"latitude": 35.6694,
"longitude": 139.7025
},
"openingHoursSpecification": [
{
"@type": "OpeningHoursSpecification",
"dayOfWeek": [
"Monday",
"Tuesday",
"Wednesday",
"Thursday",
"Friday"
],
"opens": "09:00",
"closes": "18:00"
}
],
"priceRange": "¥¥¥",
"sameAs": [
"https://www.facebook.com/example",
"https://twitter.com/example",
"https://www.instagram.com/example"
]
}
</script>LocalBusinessスキーマには、より具体的なサブタイプも用意されています。たとえば、Restaurant（レストラン）、Dentist（歯科医院）、LegalService（法律サービス）、RealEstateAgent（不動産エージェント）などです。可能な限り具体的なサブタイプを使用することで、検索エンジンがビジネスの種類をより正確に理解できるようになります。
Organization — 組織情報
Organizationスキーマは、企業や団体の基本情報を記述するために使用します。主にコーポレートサイトのトップページや会社概要ページに実装します。ブランドのナレッジパネル（検索結果の右側に表示される組織情報パネル）に情報を提供する効果があります。
2025年にGoogleはナレッジパネルの情報ソースとしてOrganizationスキーマの活用を拡大したと発表しています。公式サイトにOrganizationスキーマを正しく実装し、sameAsプロパティで公式SNSアカウントやWikipediaページへのリンクを記述することで、ナレッジパネルの生成・更新に寄与します。
<script type="application/ld+json">
{
"@context": "https://schema.org",
"@type": "Organization",
"name": "scale-basics.com",
"alternateName": "スケールベーシックス",
"url": "https://scale-basics.com/",
"logo": "https://scale-basics.com/logo.png",
"description": "SEO・AIO対策の実践的な教材とコンサルティングを提供。",
"foundingDate": "2024",
"founder": {
"@type": "Person",
"name": "代表者名"
},
"contactPoint": {
"@type": "ContactPoint",
"telephone": "+81-3-1234-5678",
"contactType": "customer service",
"availableLanguage": ["Japanese", "English"]
},
"sameAs": [
"https://twitter.com/scalebasics",
"https://www.facebook.com/scalebasics",
"https://www.linkedin.com/company/scalebasics"
]
}
</script>Organizationスキーマは通常、サイト全体に対して1回（トップページに）実装すれば十分です。個別ページにはArticleスキーマのpublisherプロパティ内でOrganizationの情報を参照する形が効率的です。
WebSite + SearchAction — サイト内検索ボックス
WebSiteスキーマとSearchActionを組み合わせることで、Google検索結果にサイトリンク検索ボックス（Sitelinks Search Box）を表示させることができます。これは、ブランド名で検索した際に検索結果に表示される「サイト内検索」のテキストボックスのことです。
この実装は、一定以上のブランド認知度があるサイトで効果を発揮します。ユーザーがGoogleからサイトに遷移することなく、直接サイト内検索を実行できるため、ユーザー体験の向上とサイトへの直接流入増加が期待できます。
<script type="application/ld+json">
{
"@context": "https://schema.org",
"@type": "WebSite",
"name": "scale-basics.com",
"url": "https://scale-basics.com/",
"potentialAction": {
"@type": "SearchAction",
"target": {
"@type": "EntryPoint",
"urlTemplate": "https://scale-basics.com/search?q={search_term_string}"
},
"query-input": "required name=search_term_string"
}
}
</script>urlTemplateにはサイト内検索のURLパターンを指定します。{search_term_string}がユーザーの入力した検索クエリに置き換わります。WordPressサイトであればhttps://example.com/?s={search_term_string}が一般的です。WebSiteスキーマはサイトのトップページにのみ実装してください。
構造化データマークアップの検証方法
構造化データを実装したら、必ず検証ツールでエラーがないか確認しましょう。JSON構文のミスやプロパティの記述漏れは、リッチリザルトが表示されない原因になります。主な検証ツールは2つあります。
1つ目はGoogleのリッチリザルトテストです。URLを入力するか、コードスニペットを直接貼り付けて検証できます。このツールの特長は、Googleが実際にサポートしているリッチリザルトに対して検証を行う点です。つまり、Schema.orgとしては有効でもGoogleがサポートしていないスキーマやプロパティについては警告が表示されます。
2つ目はSchema Markup Validator（旧Google構造化データテストツール）です。これはSchema.orgの仕様に基づいてバリデーションを行うツールで、Google固有の要件ではなく、Schema.orgの標準仕様に準拠しているかを確認できます。
scale-basics.comでは、以下のワークフローで構造化データの品質を維持しています。まず、新しいページを作成したらリッチリザルトテストでプレビューを確認します。次に、Schema Markup Validatorでスキーマの整合性をチェックします。そして本番デプロイ後、Google Search Consoleの「拡張」レポートで定期的にエラーの有無を確認します。この3段階の検証フローにより、構造化データエラー0件の状態を継続できています。
よくあるエラーと対処法
構造化データマークアップでよく発生するエラーとその対処法をまとめます。Web制作にSEOを組み込む方法を実践する際にも、これらのエラーを事前に把握しておくことでスムーズに開発を進められます。
| エラー内容 | 原因 | 対処法 |
|---|---|---|
| 「必須フィールド “name” がありません」 | スキーマタイプの必須プロパティが未記述 | Google公式ドキュメントで必須プロパティを確認し追記する |
| 「JSON-LD の解析エラー」 | JSON構文の誤り（カンマ過不足、引用符の閉じ忘れなど） | JSONLintなどのバリデーターで構文チェックし修正する |
| 「値が不正です “availability”」 | 列挙型プロパティの値がSchema.org定義と不一致 | 正しい値（例: “https://schema.org/InStock”）に修正する |
| 「ページで参照されている画像をクロールできません」 | imageプロパティのURLが404またはrobots.txtでブロック | 画像URLの有効性を確認し、クロール可能な状態にする |
| 「datePublished の値が無効です」 | 日付形式がISO 8601に準拠していない | 「2026-03-15」や「2026-03-15T09:00:00+09:00」形式に修正 |
| 「推奨フィールド “image” がありません」 | 推奨プロパティが未記述（警告） | リッチリザルト表示のために推奨プロパティもできるだけ記述する |
| 「ページに記載された内容と構造化データの内容が一致しません」 | 表示コンテンツとJSON-LDの情報に乖離がある | ページ上に表示されている情報と構造化データの値を一致させる |
特に初心者が陥りやすいのは、JSON構文エラーです。JSON-LDはJavaScriptのオブジェクト記法に似ていますが、JSONの厳格な仕様に従う必要があります。たとえば、プロパティ名は必ずダブルクォーテーションで囲む必要がある、末尾のカンマ（トレイリングカンマ）は許容されない、コメントは使用できない、といった制約があります。VS Codeなどのエディタでは、JSON構文のエラーをリアルタイムでハイライトしてくれるプラグインを活用すると効率的です。
Before/After — 構造化データマークアップ実装の効果比較
構造化データマークアップを実装する前と後で、検索結果の表示がどのように変わるか具体的に見てみましょう。以下は、実際にscale-basics.comで観測した変化をもとにした比較です。
Before: 構造化データなしの検索結果表示
scale-basics.com › blog › structured-data
構造化データマークアップ完全ガイド｜JSON-LDコード例付き
構造化データマークアップの基礎から実装方法まで解説。
JSON-LDのコード例を豊富に掲載...構造化データなしの場合、検索結果にはタイトル、URL、メタディスクリプションの3行だけが表示されます。他のサイトの検索結果と視覚的に差別化する要素がなく、ユーザーの目に留まりにくい状態です。
After: 構造化データ実装後の検索結果表示
scale-basics.com › ブログ › 構造化データマークアップ完全ガイド
構造化データマークアップ完全ガイド｜JSON-LDコード例付き
scale-basics.com - 鈴木太郎 - 2026年3月15日
構造化データマークアップの基礎から実装方法まで解説。
JSON-LDのコード例を豊富に掲載...
よくある質問：
▸ 構造化データマークアップとは何ですか？
▸ JSON-LDとMicrodataの違いは何ですか？
▸ 構造化データを実装するとSEOに効果がありますか？構造化データ実装後は、URL部分がパンくずリスト形式（日本語表示）になり、著者名と公開日が表示され、FAQのアコーディオンが展開される可能性があります（サイトの権威度による）。検索結果の占有面積が約2〜3倍に拡大し、CTRの大幅な向上が期待できます。
scale-basics.comでの実測データとして、構造化データ（Article + BreadcrumbList）を全ページに導入した前後3ヶ月間を比較すると、以下の変化がありました。
- 平均CTR: 2.8% → 4.1%（約46%向上）
- リッチリザルト表示対象ページ: 0ページ → 全ページ
- Google Search Console「拡張」レポートのエラー: 0件を維持
- パンくずリスト表示率: 0% → 100%
これらの数値は、構造化データの実装だけで達成したわけではなく、コンテンツの品質改善やサイト速度の最適化も同時に行った結果です。しかし、リッチリザルト表示やパンくずリスト表示は構造化データの直接的な効果であり、CTR向上に大きく寄与したと考えられます。
構造化データとLLMO/AIO — AI検索時代の新たな効果
2026年現在、検索の世界は大きな転換期を迎えています。GoogleのAI Overview（AIO）、BingのCopilot、PerplexityなどのAI検索エンジンが台頭し、従来の「10本の青いリンク」だけでなく、AIが生成する回答が検索結果に表示されるようになりました。この新しい環境において、構造化データマークアップは従来のSEO効果に加えて、新たな価値を持つようになっています。
LLMOとは大規模言語モデル最適化（Large Language Model Optimization）の略で、AIが情報を収集・理解・引用しやすいようにコンテンツを最適化する考え方です。構造化データは、このLLMOの文脈で非常に重要な役割を果たします。
なぜなら、AIモデルがWebページの情報を処理する際、構造化データは「機械可読なメタデータ」として機能するからです。HTMLの自由形式のテキストからは、「この文章は記事の本文なのか、サイドバーの広告なのか」「この価格は商品の価格なのか、比較対象の価格なのか」といった判別が難しいケースがあります。構造化データがあれば、これらの情報を明確に区別でき、AIが正確な回答を生成する際の信頼できるソースとなります。
具体的には、以下のような効果が期待できます。
第一に、AI Overviewでの引用確率の向上です。AIO対策として構造化データを活用すると、GoogleのAI Overviewがページの情報を引用する際に、構造化データで定義されたエンティティ（人物、組織、商品など）の関係性を正確に理解できるため、信頼できる情報源として選ばれやすくなります。
第二に、FAQPageスキーマやHowToスキーマで記述された情報は、AI検索エンジンが質問応答形式の回答を生成する際の構造化された情報源として活用されます。Perplexityのようなアンサーエンジンでは、構造化データで明確に定義されたQ&Aペアやステップバイステップの手順を、そのまま回答の素材として利用するケースが増えています。
第三に、Organizationスキーマやローカルビジネス情報の構造化データは、AIアシスタント（Google Assistant、Siri、Alexaなど）が企業情報を回答する際の正式な情報源として参照されます。「近くのSEOコンサルティング会社の営業時間は？」といった音声検索クエリに対して、構造化データに基づく正確な回答が返される可能性が高まります。
教材サイトの構造化データの章でも詳しく解説していますが、2026年のSEO・AIO戦略において、構造化データマークアップは「やったほうがよい施策」から「必須の施策」へと位置づけが変わりつつあります。AIがWebの情報を理解する能力が向上するにつれ、構造化データはAIとのコミュニケーションにおける「共通言語」としての役割をますます強めていくでしょう。
スキーマ選定フローチャート
「自分のページにはどのスキーマタイプを使えばよいのか？」という疑問に答えるために、ページの種類ごとに最適なスキーマタイプを整理しました。以下のフローチャート形式のテーブルを参考に、適切なスキーマを選定してください。
| ページの種類・目的 | 推奨スキーマタイプ | リッチリザルト対応 | 優先度 | 備考 |
|---|---|---|---|---|
| ブログ記事・ニュース記事 | Article + BreadcrumbList | あり | 高 | 全記事ページに実装推奨 |
| コーポレートサイトTOP | Organization + WebSite | あり（ナレッジパネル、サイトリンク検索ボックス） | 高 | TOPページに1回実装 |
| ECサイト商品ページ | Product + BreadcrumbList | あり（価格、レビュー、在庫） | 高 | 価格情報の正確性を厳守 |
| FAQ・よくある質問ページ | FAQPage | 限定的（高権威ドメインのみ） | 中 | AI検索での活用を見据えて実装 |
| 手順解説・ハウツーページ | HowTo | あり | 中 | ステップが明確なコンテンツに限定 |
| 店舗・サービス拠点ページ | LocalBusiness | あり（ローカルパック） | 高 | Googleビジネスプロフィールと整合させる |
| レシピページ | Recipe | あり（リッチなカルーセル） | 高 | 料理サイトでは最重要スキーマ |
| イベント情報ページ | Event | あり（日程、場所、チケット情報） | 中 | 開催日時の更新を忘れずに |
| 求人情報ページ | JobPosting | あり（Google しごと検索） | 高 | 掲載期限を必ず設定 |
| 動画コンテンツページ | VideoObject | あり（動画リッチリザルト） | 中 | サムネイル、再生時間を必須記述 |
一般的に、全サイト共通で最初に実装すべきは「BreadcrumbList」と「Organization（またはLocalBusiness）」です。これらはサイトの基盤となるスキーマで、実装コストが低く、効果が確実です。次に、各ページの種類に応じたスキーマ（Article、Product、FAQPageなど）を段階的に追加していくのがベストプラクティスです。
なお、SEO対策済みHTMLテンプレートを活用すれば、これらの構造化データがあらかじめ組み込まれたテンプレートから開発をスタートでき、実装漏れのリスクを大幅に削減できます。
構造化データマークアップの高度な実装テクニック
基本的なスキーマタイプの実装方法を理解したら、さらに効果を高める高度なテクニックについても押さえておきましょう。
複数スキーマタイプの同時実装
1つのページに複数のスキーマタイプを同時に実装するのは、非常に一般的かつ推奨される方法です。たとえば、ブログ記事ページには「Article」「BreadcrumbList」「FAQPage」の3つを同時に実装できます。
実装方法は2通りあります。1つ目は、それぞれ個別の<script type=”application/ld+json”>ブロックとして記述する方法です。2つ目は、1つの<script>ブロック内に@graphプロパティを使って複数のスキーマをまとめる方法です。
<script type="application/ld+json">
{
"@context": "https://schema.org",
"@graph": [
{
"@type": "Article",
"headline": "構造化データマークアップ完全ガイド",
"author": {
"@type": "Person",
"name": "鈴木太郎"
},
"datePublished": "2026-03-15",
"dateModified": "2026-03-15",
"publisher": {
"@type": "Organization",
"name": "scale-basics.com",
"logo": {
"@type": "ImageObject",
"url": "https://scale-basics.com/logo.png"
}
}
},
{
"@type": "BreadcrumbList",
"itemListElement": [
{
"@type": "ListItem",
"position": 1,
"name": "ホーム",
"item": "https://scale-basics.com/"
},
{
"@type": "ListItem",
"position": 2,
"name": "ブログ",
"item": "https://scale-basics.com/blog/"
},
{
"@type": "ListItem",
"position": 3,
"name": "構造化データマークアップ完全ガイド"
}
]
}
]
}
</script>@graphを使う方法のほうがHTMLの記述量が少なくなり、エンティティ間の関連性も表現しやすくなりますが、JSONの構造が複雑になるためエラーが発生しやすいというデメリットもあります。チームの技術レベルや管理方針に応じて使い分けてください。
動的なJSON-LD生成
CMSやフレームワークを使ったサイトでは、JSON-LDを動的に生成するのが効率的です。WordPressであればfunctions.phpやカスタムプラグイン、Next.jsであればメタデータAPIやカスタムコンポーネントを使って、ページのメタ情報から自動的にJSON-LDを生成できます。
scale-basics.comではNext.jsを使用しており、記事データから自動的にArticleスキーマとBreadcrumbListスキーマのJSON-LDを生成する仕組みを構築しています。これにより、新しい記事を追加するたびにJSON-LDを手動で記述する必要がなく、構造化データの実装漏れを防いでいます。手動管理では記事数が増えるにつれて管理コストが膨れ上がりますが、自動生成の仕組みがあれば、100ページでも1,000ページでも同じ品質の構造化データを維持できます。
ネストされたエンティティの活用
JSON-LDの強みの一つが、エンティティのネスト（入れ子）です。たとえば、Articleスキーマの中にauthorとしてPersonスキーマを埋め込み、さらにそのPersonのworksForとしてOrganizationスキーマを埋め込むことで、「この記事を書いた鈴木太郎は、scale-basics.comという組織に所属している」という関係性を表現できます。
<script type="application/ld+json">
{
"@context": "https://schema.org",
"@type": "Article",
"headline": "構造化データマークアップの実装ガイド",
"author": {
"@type": "Person",
"name": "鈴木太郎",
"url": "https://scale-basics.com/author/suzuki/",
"jobTitle": "SEOコンサルタント",
"worksFor": {
"@type": "Organization",
"name": "scale-basics.com",
"url": "https://scale-basics.com/"
}
},
"datePublished": "2026-03-15",
"dateModified": "2026-03-15"
}
</script>このようなネスト構造は、E-E-A-Tのシグナルを強化するうえで非常に有効です。著者がどのような肩書きで、どの組織に属しているかを明示することで、コンテンツの専門性と権威性を検索エンジンに伝えられます。2026年現在、GoogleはE-E-A-Tをますます重視する方針を示しており、構造化データを通じたエンティティの関係性の表現は、コンテンツの信頼性評価に寄与すると考えられます。
構造化データマークアップ実装時のベストプラクティス
これまでの内容を踏まえ、構造化データマークアップを効果的に実装するためのベストプラクティスをまとめます。
まず、ページの実際のコンテンツと構造化データの情報を一致させることが最重要です。Googleは「ページに表示されていない情報を構造化データに含めてはならない」と明記しています。たとえば、ページ上にレビュー機能がないのにaggregateRatingを記述したり、実際の価格と異なる価格をProductスキーマに記述したりすることは、ガイドライン違反です。
次に、必須プロパティだけでなく推奨プロパティもできるだけ記述しましょう。Googleの構造化データドキュメントでは、各スキーマタイプごとに「必須」「推奨」のプロパティが明記されています。推奨プロパティを記述することで、リッチリザルトの表示がよりリッチになり、ユーザーに提供する情報量が増えます。
そして、定期的な監視を忘れないでください。構造化データは一度実装したら終わりではありません。サイトのリニューアルやCMSのアップデート、コンテンツの更新によって構造化データが壊れることがあります。Google Search Consoleの「拡張」レポートを月に1回はチェックし、エラーや警告が発生していないか確認する運用フローを確立してください。
さらに、構造化データをスパム的に使用しないことも重要です。非表示のコンテンツに対して大量の構造化データを実装したり、ユーザーに見えない形でFAQを大量に追加したりする行為は、Googleの品質ガイドラインに違反します。構造化データはあくまで「ページに存在するコンテンツの意味を補足する」ものであり、検索順位を操作するためのツールではありません。
まとめ
構造化データマークアップは、検索エンジンにWebページの意味を正確に伝え、リッチリザルトの表示を可能にし、さらにAI検索時代における情報伝達の精度を高める重要な技術です。本記事の要点を整理します。
構造化データの記述形式はJSON-LDが最も推奨されています。HTMLとデータが分離されるため管理が容易で、動的生成にも適しています。主要なスキーマタイプにはArticle、FAQPage、HowTo、Product、BreadcrumbList、LocalBusiness、Organization、WebSite+SearchActionがあり、ページの種類に応じて適切に選定・実装します。
実装後はGoogleのリッチリザルトテストとSchema Markup Validatorで検証し、Google Search Consoleで継続的に監視することが不可欠です。JSON構文エラー、必須プロパティの欠落、ページ内容との不一致が代表的なエラーパターンであり、これらを事前に理解しておくことで効率的な実装が可能です。
2026年のAI検索時代において、構造化データはLLMO・AIO対策としても新たな価値を持っています。AI検索エンジンが情報を正確に理解し引用するための「機械可読な共通言語」として、構造化データの重要性は今後さらに高まるでしょう。
まだ構造化データを実装していないサイトは、まずBreadcrumbListとArticle（またはOrganization）から始めてみてください。scale-basics.comの事例が示すように、適切な実装によってリッチリザルト表示率やCTRの向上といった具体的な成果を得ることができます。構造化データは一度仕組みを構築すれば運用コストが低く、長期的なリターンが大きい施策です。ぜひ本記事のコード例を活用して、今日から実装に取りかかってみてください。
