構造化データマークアップとは？ — 基本概念と仕組み
構造化データマークアップとは、Webページ上のコンテンツが「何を意味しているのか」を機械が理解できるように、あらかじめ定義された語彙（ボキャブラリー）と構文（シンタックス）で情報を記述する技術です。
たとえば、ページ上に「鈴木太郎」というテキストがあるとします。人間なら前後の文脈から「著者名だ」「会社の代表者だ」と判断できますが、クローラーはHTMLの文字列としてしか認識できません。構造化データを使えば、「この『鈴木太郎』はこのArticleのauthorである」という意味情報を機械可読な形式で付加できます。
検索エンジンがページの内容を正しく理解できれば、検索結果上でリッチリザルト（リッチスニペット）として目立つ表示がなされる可能性が高まります。リッチリザルトが表示されると、青いリンクだけの通常の検索結果と比べてクリック率（CTR）の向上が期待できます。Googleの公式ドキュメントでも、構造化データを適切に実装することでリッチリザルトの対象になり得ると明記されています。
構造化データの語彙として最も広く使われているのがSchema.orgです。Schema.orgはGoogle、Microsoft（Bing）、Yahoo!、Yandexが共同で策定したボキャブラリーで、数百種類のスキーマタイプ（Type）と数千のプロパティ（Property）が定義されています。SEOに強いWebサイトを実装するには、この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でも全ページに構造化データ（Article + BreadcrumbList）を適用し、Google Search Consoleの「拡張」レポートでリッチリザルトの対象を全ページに広げています。実際にどのリッチリザルトが表示されるかは、あくまでGoogleの判断に委ねられます。
主なリッチリザルトの種類には、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-07-23",
"dateModified": "2026-07-23"
}
</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構文のエラーです。最後のプロパティの後にカンマを付けてしまう「トレイリングカンマ」や、クォーテーションの閉じ忘れはよくあるミスです。次に、@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-07-23",
"dateModified": "2026-07-23",
"mainEntityOfPage": {
"@type": "WebPage",
"@id": "https://example.com/structured-data-markup/"
}
}
</script>ポイントは、headlineは110文字以内に収めること、imageには横幅1200px以上の画像URLを指定すること、datePublishedとdateModifiedはISO 8601形式で記述することです。mainEntityOfPageは、このArticleがそのWebページのメインコンテンツであることを示します。
FAQPage — よくある質問
FAQPageスキーマは、Q&A形式のコンテンツに使用します。正しく実装すると、検索結果でよくある質問がアコーディオン形式で展開表示されることがあります。
ただし2023年8月以降、GoogleはFAQリッチリザルトの表示を大幅に制限しました。現在、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を含めることも可能ですが、その場合はエスケープ処理が必要になるため、プレーンテキストで記述するほうがエラーを避けやすくなります。
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/structured-data/#step1",
"image": "https://example.com/images/step1.jpg"
},
{
"@type": "HowToStep",
"name": "JSON-LDコードの作成",
"text": "選定したスキーマタイプに基づき、JSON-LD形式でコードを作成します。@context、@type、必須プロパティを記述します。",
"url": "https://example.com/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/structured-data/#step3",
"image": "https://example.com/images/step3.jpg"
},
{
"@type": "HowToStep",
"name": "リッチリザルトテストで検証",
"text": "Googleのリッチリザルトテストツールでコードにエラーがないか検証します。エラーがあれば修正し、再度テストします。",
"url": "https://example.com/structured-data/#step4",
"image": "https://example.com/images/step4.jpg"
},
{
"@type": "HowToStep",
"name": "本番環境にデプロイ",
"text": "検証が完了したら本番環境にデプロイし、Google Search Consoleで構造化データの認識状況を確認します。",
"url": "https://example.com/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サイトの商品ページで使用します。価格、在庫状況、レビュー評価、商品画像などを構造化データとして記述することで、検索結果に商品のリッチな情報が表示されます。購入意思のあるユーザーの目を引くうえで重要なスキーマです。
Productスキーマでは、offers内のshippingDetails（配送情報）やhasMerchantReturnPolicy（返品ポリシー）といったフィールドも記述できます。これらは、AIエージェントが商品を比較・購入代行する「エージェント型商取引」の文脈でも重視されるようになっています。実際、上位小売がエージェント型商取引に「見えない」実態を分析した調査では、priceValidUntilやshippingDetails.deliveryTime、返品可能日数といったフィールドを欠いた商品ページが多く、AIエージェントの比較検討の対象にすら入らないケースが報告されています。ECサイトでは、これらのフィールドの整備が新たな可視性の条件になりつつあります。
<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スキーマは、サイトのナビゲーション階層を検索エンジンに伝えるために使用します。パンくずリストは多くのサイトに実装されていますが、HTMLだけでは「これがパンくずリストである」という意味を検索エンジンに明示できません。BreadcrumbListスキーマを使うと、検索結果のURL表示部分がパンくず形式になり、ユーザーにサイト構造が伝わりやすくなります。パンくずリスト自体の設計や設置方法はパンくずリストの正しい設置方法とSEO効果の解説で詳しく扱っています。
scale-basics.comでは全ページにBreadcrumbListスキーマを実装しています。実装後、Google Search Consoleの「パンくずリスト」レポートで全ページが「有効」と認識される状態を維持しています。
<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": "SEO",
"item": "https://example.com/category/seo/"
},
{
"@type": "ListItem",
"position": 3,
"name": "構造化データマークアップ完全ガイド",
"item": "https://example.com/structured-data-markup/"
}
]
}
</script>itemListElementは配列で、positionが1から始まる階層順序を示します。最後の要素（現在のページ）のitemプロパティは省略しても構いませんが、記述したほうが明確です。BreadcrumbListの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スキーマは、企業や団体の基本情報を記述するために使用します。主にコーポレートサイトのトップページや会社概要ページに実装し、ブランドのナレッジパネル（検索結果の右側に表示される組織情報パネル）への情報提供に寄与します。
公式サイトに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）を表示させられます。ブランド名で検索したときに検索結果に出る「サイト内検索」のテキストボックスのことです。
この実装は、一定以上のブランド認知度があるサイトで効果を発揮します。ユーザーがサイトに遷移することなく直接サイト内検索を実行できるため、ユーザー体験の向上と直接流入の増加が期待できます。
<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です。これはSchema.orgの仕様に基づいてバリデーションを行うツールで、Google固有の要件ではなく、Schema.orgの標準仕様に準拠しているかを確認できます。
scale-basics.comでは、次のワークフローで構造化データの品質を維持しています。まず、新しいページを作成したらリッチリザルトテストでプレビューを確認します。次に、Schema Markup Validatorでスキーマの整合性をチェックします。そして本番デプロイ後、Google Search Consoleの「拡張」レポートを定期的に見て、エラーや警告が出ていないかを確認します。
あわせて、AI検索での見え方も観測できるようになりました。Search Consoleの生成AIパフォーマンスレポートでは、AI OverviewsやAI Mode、Discoverの生成AI機能で自サイトのURLが表示された回数を確認できます。これは順位を変える機能ではなく、AI検索での露出状況を可視化する計測ツールですが、構造化データを整えたページがAI検索でどう扱われているかを追う手がかりになります。
よくあるエラーと対処法
構造化データマークアップでよく発生するエラーと対処法をまとめます。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-07-23」や「2026-07-23T09:00:00+09:00」形式に修正 |
| 「推奨フィールド “image” がありません」 | 推奨プロパティが未記述（警告） | リッチリザルト表示のために推奨プロパティもできるだけ記述する |
| 「ページに記載された内容と構造化データの内容が一致しません」 | 表示コンテンツとJSON-LDの情報に乖離がある | ページ上に表示されている情報と構造化データの値を一致させる |
特に初心者が陥りやすいのはJSON構文エラーです。JSON-LDはJavaScriptのオブジェクト記法に似ていますが、JSONの厳格な仕様に従う必要があります。プロパティ名は必ずダブルクォーテーションで囲む、末尾のカンマ（トレイリングカンマ）は許容されない、コメントは使えない、といった制約があります。VS Codeなどのエディタでは、JSON構文のエラーをリアルタイムでハイライトするプラグインを活用すると効率的です。
Before/After — 構造化データ実装で検索結果はどう変わるか
構造化データを実装する前と後で、検索結果の表示がどう変わるかを見てみましょう。以下は、表示イメージを模した比較です（実際の表示はGoogleの判断やサイトの権威度によって異なります）。
Before: 構造化データなしの検索結果表示
scale-basics.com › blog › structured-data
構造化データマークアップ完全ガイド｜JSON-LDコード例付き
構造化データマークアップの基礎から実装方法まで解説。
JSON-LDのコード例を豊富に掲載...構造化データなしの場合、検索結果にはタイトル、URL、メタディスクリプションの3行だけが表示されます。他のサイトの検索結果と視覚的に差別化する要素がなく、ユーザーの目に留まりにくい状態です。
After: 構造化データ実装後の検索結果表示
scale-basics.com › ブログ › 構造化データマークアップ完全ガイド
構造化データマークアップ完全ガイド｜JSON-LDコード例付き
scale-basics.com - 鈴木太郎 - 2026年7月23日
構造化データマークアップの基礎から実装方法まで解説。
JSON-LDのコード例を豊富に掲載...
よくある質問：
▸ 構造化データマークアップとは何ですか？
▸ JSON-LDとMicrodataの違いは何ですか？
▸ 構造化データを実装するとSEOに効果がありますか？構造化データ実装後は、URL部分がパンくずリスト形式（日本語表示）になり、著者名と公開日が表示され、権威度によってはFAQのアコーディオンが展開される可能性があります。検索結果の占有面積が広がり、視認性の向上が期待できます。
scale-basics.comで構造化データ（Article + BreadcrumbList）を全ページに導入した運用では、以下のような状態を維持しています。
- リッチリザルトの対象ページ: 0ページ → 全ページに拡大
- Google Search Console「拡張」レポート: エラーが出ない状態を維持
- パンくずリスト: 全ページが「有効」と認識される状態を維持
これらはコンテンツの品質改善やサイト速度の最適化とあわせて取り組んだ結果ですが、リッチリザルトの対象化やパンくず表示は構造化データの直接的な効果です。CTRの改善は複数要因が絡むため、構造化データ単体の寄与を切り出して数値で断定することは避けています。
構造化データとLLMO・AIO — AI検索時代の役割
2026年現在、検索は大きな転換期を迎えています。GoogleのAI OverviewsやAI Mode、BingのCopilot、PerplexityといったAI検索が台頭し、従来の「10本の青いリンク」だけでなく、AIが生成する回答が検索結果に表示されるようになりました。この環境で、構造化データマークアップは従来のSEO効果に加えた役割を持ち始めています。
LLMOとは大規模言語モデル最適化（Large Language Model Optimization）の略で、AIが情報を収集・理解・引用しやすいようにコンテンツを最適化する考え方です。構造化データは、このLLMOの文脈でも意味を持ちます。
AIモデルがWebページの情報を処理する際、構造化データは「機械可読なメタデータ」として機能します。HTMLの自由形式のテキストからは、「この文章は本文なのか、サイドバーの広告なのか」「この価格は商品の価格なのか、比較対象の価格なのか」の判別が難しいケースがあります。構造化データがあれば、これらを明確に区別でき、AIが回答を生成する際の材料になります。
ここで注意したいのは、Google自身の見解です。Googleは生成AI検索向けの公式最適化ガイドで、生成AI機能は既存の検索ランキング・品質システムに根ざしているため、AI向けの特別な最適化やllms.txtの設置、コンテンツのチャンク化は不要だと明言しています。つまり構造化データは「AIのための魔法の施策」ではなく、従来から推奨されてきた適切なマークアップの一部という位置づけです。ローカル・ショッピング・画像・動画のような構造化しやすいコンテンツに正しくマークアップを施すことが、そのまま生成AI機能での見え方にもつながる、という整理になります。
この前提のうえで、構造化データが具体的に効く場面を挙げます。AIO対策としての構造化データは、AI Overviewがページ内のエンティティ（人物、組織、商品など）の関係性を正確に理解する助けになります。FAQPageやHowToで記述した情報は、AI検索エンジンが質問応答やステップ回答を生成する際の構造化された情報源として参照されやすくなります。また前述のとおり、Productスキーマの整備はエージェント型商取引での可視性に直結します。Organizationやローカルビジネスの構造化データは、AIアシスタントが企業情報を回答する際の参照元になります。
2026年のSEO・AIO戦略において、構造化データは「派手な新テクニック」ではなく、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など）を段階的に追加していくのがベストプラクティスです。
構造化データマークアップの高度な実装テクニック
基本的なスキーマタイプの実装を理解したら、さらに効果を高める高度なテクニックも押さえておきましょう。
複数スキーマの同時実装（@graph）
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-07-23",
"dateModified": "2026-07-23",
"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": "SEO",
"item": "https://scale-basics.com/category/seo/"
},
{
"@type": "ListItem",
"position": 3,
"name": "構造化データマークアップ完全ガイド"
}
]
}
]
}
</script>@graphを使う方法はHTMLの記述量が少なくなり、エンティティ間の関連性も表現しやすくなりますが、JSONの構造が複雑になるためエラーが発生しやすいというデメリットもあります。チームの技術レベルや管理方針に応じて使い分けてください。
動的なJSON-LD生成と運用 — 当サイトの移行事例
CMSやフレームワークを使うサイトでは、JSON-LDを動的に生成するのが効率的です。WordPressならfunctions.phpやプラグイン、Next.jsならメタデータAPIやカスタムコンポーネントを使い、ページのメタ情報から自動的にJSON-LDを生成できます。手動管理では記事数の増加とともに管理コストが膨らみますが、自動生成の仕組みがあれば100ページでも1,000ページでも同じ品質を保てます。
scale-basics.comでは、この自動生成を運用の前提にしています。当サイトは2026年7月にNext.js（SSG）構成からWordPressへ全面移行しましたが、その際も記事データからArticleとBreadcrumbListのJSON-LDを自動生成する仕組みに載せ替えることで、全記事の構造化データを実装漏れなく引き継げました。移行では旧URL（/blog/xxx/）から新URL（/xxx/）への301リダイレクトでURLを継承し、インデックス上の問題は起きていません。移行の詳細や表示速度の実測データはSEOに強いコーディングの実装ガイドで公開しています。
ネストされたエンティティでE-E-A-Tを強化
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-07-23",
"dateModified": "2026-07-23"
}
</script>このようなネスト構造は、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構文エラー、必須プロパティの欠落、ページ内容との不一致が代表的なエラーパターンで、これらを事前に理解しておくと効率的に実装できます。
AI検索時代における構造化データは、「AI向けの特別施策」ではなく、従来から推奨されてきた適切なマークアップの延長線上にあります。Googleも生成AIのための特別な最適化は不要と述べており、良質なコンテンツと正しいマークアップの積み重ねが、検索とAIの双方に効く土台になります。一方でProductスキーマのように、エージェント型商取引での可視性を左右する具体的な場面も出てきています。
まだ構造化データを実装していないサイトは、まずBreadcrumbListとArticle（またはOrganization）から始めてみてください。構造化データは一度仕組みを構築すれば運用コストが低く、長期的なリターンが大きい施策です。本記事のコード例を土台に、今日から実装に取りかかってみてください。
本記事は、Schema.orgおよびGoogle Search Centralの公開ドキュメントと、scale-basics.comの運営で得た実体験（全記事へのArticle・BreadcrumbList実装、2026年7月のNext.js→WordPress移行と301リダイレクトによるURL継承）にもとづいて執筆しています。リッチリザルトの表示可否はGoogleの判断によるため、実装が表示を保証するものではありません。
