構造化マークアップとは？LLMO・AIO時代の実装方法【2026年版】

「構造化マークアップって何?」「LLMOやAIOって聞いたことはあるけど、SEOとどう違うの?」と疑問に感じていませんか?

2026年現在、Google検索ではAI Overviewsが標準表示されるようになり、ChatGPTやPerplexityなどのAI検索ツールも急速に普及しています。従来のSEO対策だけでは、AI時代の検索流入を十分に確保できない状況が生まれつつあります。

結論から言うと、構造化マークアップはSEOとLLMO・AIO双方の基盤となる重要な施策です。検索エンジンだけでなくAIにも情報を正確に伝えられる構造化マークアップは、これからのWeb戦略に欠かせません。

この記事では、構造化マークアップの基礎知識から実装方法、そしてLLMO・AIO時代に対応した最新戦略まで、初心者にもわかりやすく解説します。Web担当者やマーケターの方は、ぜひ最後までお読みください。

この記事は「SEO対策の完全ガイド」の個別テーマ解説です。SEOの全体像はガイドからご覧ください。

構造化マークアップとは?SEOへの影響を初心者向けに解説

構造化マークアップの基本概念

構造化マークアップとは、Webページ内のテキスト情報に「意味」を持たせ、検索エンジンやAIが正確に理解できるようにするための記述方法です。

通常のHTMLでは、テキストが「どのように表示されるか」を指定するだけですが、構造化マークアップを使うと「このテキストは何を意味するのか」まで明示できます。たとえば、「株式会社○○」という文字列に対して「これは会社名である」、「1,980円」という数字に対して「これは商品価格である」といった情報を付加できるのです。

HTMLとの違い

項目	通常のHTML	構造化マークアップ
役割	表示方法の指定	意味・構造の明示
検索エンジンの理解	文字列としてのみ認識	意味を含めて認識
記述場所	HTML全体	headタグ内またはHTML要素内

具体例として、通常のHTMLでは<div>株式会社InnoMark</div>と記述しますが、構造化マークアップでは企業名であることを明示的に示せます。これにより、検索エンジンのクローラーが「InnoMark」を単なる文字列ではなく、「企業名」として正確に認識できるようになります。

SEOにおける構造化マークアップの重要性

構造化マークアップは、SEOにおいて間接的に大きな効果をもたらします。主なメリットは次の3つです。

1. リッチスニペット表示によるCTR向上

検索結果に星評価、FAQ、レシピの調理時間などが表示されるリッチスニペットは、視覚的にユーザーの目を引きます。これにより、クリック率(CTR)が大幅に向上する可能性があります。実際、リッチスニペットが表示されたページは、通常の検索結果と比べてCTRが30%以上向上するケースも報告されています。

2. 検索エンジンのインデックス精度向上

構造化データを実装することで、Googleのクローラーがページの内容をより正確に理解できます。これにより、適切な検索クエリに対してページが表示されやすくなり、検索意図とのマッチング精度が高まります。

3. ナレッジグラフへの反映可能性

企業情報や著名人の情報を構造化マークアップすることで、Googleのナレッジグラフ(検索結果右側に表示される情報ボックス)に反映される可能性が高まります。これはブランド認知度の向上にも貢献します。

【誤解注意】構造化マークアップで順位は上がる?

ここで重要な点を明確にしておきます。構造化マークアップ自体は、検索順位に直接的な影響を与えません。

Googleも公式に「構造化データの追加によってリッチリザルトが表示される可能性は高まりますが、検索順位が保証されるわけではありません」と述べています。つまり、構造化マークアップは「順位を上げる魔法のツール」ではないのです。

しかし、間接的なSEO効果は確実に存在します。

リッチスニペット表示によるCTR向上→アクセス数増加
ユーザー体験の改善→サイト滞在時間の延長
検索意図とのマッチング精度向上→適切なユーザーへのリーチ

これらの要素が複合的に作用し、結果的にSEO成果の向上につながります。構造化マークアップは「すぐに順位が上がる施策」ではなく、「中長期的にサイトの価値を高める施策」と理解することが大切です。

構造化マークアップの3つの形式と選び方

JSON-LD(Google推奨形式)

JSON-LD(JavaScript Object Notation for Linked Data)は、Googleが最も推奨している構造化データの形式です。

特徴と実装の容易さ

JSON-LDの最大の利点は、HTMLの構造に影響を与えずにデータを記述できる点です。<script type="application/ld+json">タグ内にJSON形式でデータを記述するため、既存のHTMLを変更する必要がありません。これにより、サイトの表示やデザインを崩すリスクが極めて低くなります。

headタグ内での記述方法

JSON-LDは通常、HTML文書の<head>セクション内に記述します。以下は記事(Article)の基本的な実装例です。

<script type="application/ld+json">
{
  "@context": "https://schema.org",
  "@type": "Article",
  "headline": "SEO構造化マークアップとは?",
  "author": {
    "@type": "Person",
    "name": "川谷厚志"
  },
  "datePublished": "2026-01-15",
  "image": "https://example.com/article-image.jpg"
}
</script>

WordPressでの実装例

WordPressでは、プラグインを使うことで簡単にJSON-LDを実装できます。

Yoast SEO: 自動的にArticle、Organization、Personなどの構造化データを生成
Schema Pro: より詳細な構造化データをGUIで設定可能

手動で実装する場合は、テーマのheader.phpまたはカスタムフィールドを使って追加します。

Microdata

Microdataは、HTML要素に直接属性を追加する形式です。itemscope、itemtype、itempropなどの属性を使用してデータを構造化します。

HTML要素に直接記述する方式

<div itemscope itemtype="https://schema.org/Organization">
  <span itemprop="name">株式会社InnoMark</span>
  <span itemprop="address">大阪市</span>
</div>

この方式は、HTMLとデータが一体化するため視覚的にわかりやすい反面、コードが複雑になりやすいデメリットがあります。

JSON-LDとの使い分け

Microdata: 既存のHTMLマークアップを活用したい場合
JSON-LD: 新規実装やメンテナンス性を重視する場合

現在はJSON-LDが主流となっており、新規でサイトを構築する場合はJSON-LDの採用を強く推奨します。

RDFa

RDFa(Resource Description Framework in Attributes)は、HTMLやXMLに埋め込む形式の構造化データです。

特徴と利用シーン

RDFaはMicrodataと同様にHTML要素に属性を追加しますが、より柔軟な表現が可能です。ただし、記述が複雑になりやすく、現在はあまり使用されていません。主に学術論文のメタデータや、既存のRDFaが実装されているサイトのメンテナンスで使用されます。

どの形式を選ぶべきか?

Googleの推奨とその理由

Googleは明確にJSON-LDを推奨しています。理由は以下の通りです。

HTMLと分離されているため実装・メンテナンスが容易
エラーが発生してもサイト表示に影響しない
複数の構造化データを一箇所にまとめて記述できる
プログラムで動的に生成しやすい

実装難易度の比較表

形式	実装難易度	メンテナンス性	Google推奨度	主な用途
JSON-LD	★☆☆(易)	★★★(高)	★★★	すべてのケース
Microdata	★★☆(中)	★★☆(中)	★☆☆	既存HTMLの活用
RDFa	★★★(難)	★☆☆(低)	☆☆☆	特殊なケースのみ

結論: 特別な理由がない限り、JSON-LDを選択しましょう。

Schema.orgの主要な語彙(ボキャブラリー)タイプ

Article(記事)タイプ

Article型は、ブログ記事やニュース記事に使用する最も基本的な構造化データです。

ブログ記事での活用法

記事の見出し、著者、公開日、更新日、画像などを明示的に指定できます。これにより、Googleがコンテンツの鮮度や信頼性を適切に評価できるようになります。

必須プロパティと推奨プロパティ

必須プロパティ:

headline: 記事のタイトル(110文字以下推奨)
image: 記事の代表画像
datePublished: 公開日時

推奨プロパティ:

author: 著者情報
dateModified: 更新日時
publisher: 発行者情報

これらを適切に設定することで、検索結果に公開日や著者名が表示されやすくなります。

Product(商品)タイプ

Product型は、ECサイトや商品紹介ページで使用します。

ECサイトでの実装例

{
  "@context": "https://schema.org",
  "@type": "Product",
  "name": "DataPush離脱防止ツール",
  "offers": {
    "@type": "Offer",
    "price": "9800",
    "priceCurrency": "JPY",
    "availability": "https://schema.org/InStock"
  },
  "aggregateRating": {
    "@type": "AggregateRating",
    "ratingValue": "4.8",
    "reviewCount": "127"
  }
}

価格・在庫情報の記述

価格情報を正確に記述することで、Google検索結果に商品価格が表示されます。また、在庫状況(InStock、OutOfStockなど)を示すことで、ユーザーに有益な情報を提供できます。

Organization(企業・組織)タイプ

Organization型は、企業情報をGoogleに伝えるための構造化データです。

コーポレートサイトでの活用

企業名、ロゴ、所在地、SNSアカウントなどを構造化することで、ナレッジグラフへの表示やブランド検索時の情報充実が期待できます。

ロゴ・SNSアカウントの設定

{
  "@context": "https://schema.org",
  "@type": "Organization",
  "name": "合同会社InnoMark",
  "url": "https://inno-mark.jp/",
  "logo": "https://inno-mark.jp/logo.png",
  "sameAs": [
    "https://twitter.com/innomark",
    "https://www.facebook.com/innomark"
  ]
}

SNSアカウントをsameAsプロパティで指定することで、Googleが企業の公式アカウントを認識しやすくなります。

FAQ・HowTo・Recipeなど

よく使われるタイプ一覧

FAQPage: よくある質問ページ
HowTo: 手順説明ページ
Recipe: レシピページ
Event: イベント情報
JobPosting: 求人情報
LocalBusiness: 店舗・施設情報

各タイプの実装目的

タイプ	主な用途	リッチリザルト表示例
FAQPage	サポートページ、Q&Aコンテンツ	検索結果に質問と回答を展開表示
HowTo	チュートリアル、手順説明	ステップごとの手順を表示
Recipe	料理レシピ	調理時間、カロリー、評価を表示
Event	セミナー、イベント告知	開催日時、場所を表示

用途に応じた適切なタイプを選択することが、効果的な構造化マークアップの鍵となります。

構造化マークアップの実装方法【実例付き】

JSON-LDでの基本的な記述方法

ここでは、実際に使えるJSON-LDのコード例を紹介します。

Article(記事)の実装コード

<script type="application/ld+json">
{
  "@context": "https://schema.org",
  "@type": "Article",
  "headline": "SEO構造化マークアップとは?LLMOとAIO時代の実装方法",
  "description": "構造化マークアップの基礎からLLMO・AIO対応まで徹底解説",
  "image": "https://example.com/images/structured-data.jpg",
  "author": {
    "@type": "Person",
    "name": "川谷厚志",
    "url": "https://inno-mark.jp/"
  },
  "publisher": {
    "@type": "Organization",
    "name": "合同会社InnoMark",
    "logo": {
      "@type": "ImageObject",
      "url": "https://inno-mark.jp/logo.png"
    }
  },
  "datePublished": "2026-01-19",
  "dateModified": "2026-01-19"
}
</script>

このコードをHTML文書の<head>セクション内に貼り付けるだけで実装完了です。

WordPressでの実装手順

プラグイン活用(Yoast SEO、Schema Pro)

Yoast SEOの場合:
- プラグインをインストール・有効化
- 設定 > 一般 > 組織または個人から、サイトタイプを選択
- 自動的にOrganization/Person、Article型が生成される
Schema Proの場合:
- より詳細な構造化データを設定可能
- Product、Event、Recipeなど多様なタイプに対応
- 条件分岐で異なるページに異なるスキーマを適用可能

手動実装の方法

テーマのfunctions.phpまたはプラグインを使って、headセクションにコードを挿入します。

function add_structured_data() {
  if (is_single()) {
    // 記事ページのみ構造化データを出力
    $schema = array(
      '@context' => 'https://schema.org',
      '@type' => 'Article',
      // ... プロパティを追加
    );
    echo '<script type="application/ld+json">' . json_encode($schema) . '</script>';
  }
}
add_action('wp_head', 'add_structured_data');

Shopify・EC-CUBEでの実装

プラットフォーム別の対応

Shopify: テーマファイル(theme.liquid)を編集してJSON-LDを追加。または、構造化データアプリを使用
EC-CUBE: 管理画面からHTMLヘッダー出力設定で追加、またはプラグインを使用

ECプラットフォームでは、Product型とOfferの実装が特に重要です。

実装後の検証方法

実装後は必ず検証ツールでチェックしましょう。

Googleリッチリザルトテスト

URL: https://search.google.com/test/rich-results

検証したいページのURLを入力し、「URLをテスト」をクリックします。エラーや警告が表示されたら、該当箇所を修正します。

Structured Data Testing Tool(廃止予定)

後継として、リッチリザルトテストまたはスキーママークアップ検証ツールを使用してください。

Search Consoleでの確認

実装から数日~数週間後、Google Search Consoleの「拡張」セクションで構造化データの状況を確認できます。エラーが表示された場合は、早急に対処しましょう。

リッチスニペットの種類とCTR改善効果

星評価(レビュー)スニペット

星評価のリッチスニペットは、商品やサービスのレビュー評価を検索結果に表示する機能です。

実装方法と表示例

AggregateRating型を使用して、平均評価とレビュー数を記述します。

{
  "@type": "Product",
  "aggregateRating": {
    "@type": "AggregateRating",
    "ratingValue": "4.7",
    "bestRating": "5",
    "worstRating": "1",
    "ratingCount": "215"
  }
}

CTR向上データ

BrightEdgeの調査によると、星評価が表示されたページは、表示されないページと比べてCTRが約35%向上すると報告されています。視覚的なインパクトが大きく、ユーザーの信頼獲得にも貢献します。

FAQリッチリザルト

FAQリッチリザルトは、よくある質問とその回答を検索結果に直接表示します。

質問と回答の構造化

{
  "@context": "https://schema.org",
  "@type": "FAQPage",
  "mainEntity": [{
    "@type": "Question",
    "name": "構造化マークアップとは何ですか?",
    "acceptedAnswer": {
      "@type": "Answer",
      "text": "構造化マークアップとは、Webページのコンテンツに意味を持たせる技術です..."
    }
  }]
}

表示条件とガイドライン

【2026年5月更新】FAQリッチリザルトはGoogle検索から完全に姿を消しました。経緯を整理すると次のとおりです。

2023年8月〜9月: 一般サイトでの表示が停止され、政府機関・医療機関のサイトに限定された
2026年5月7日: FAQリッチリザルトがGoogle検索に表示されなくなった（限定表示も終了）
2026年6月: Search Consoleの「FAQ」レポートとリッチリザルトテストのサポートが終了
2026年8月: 関連APIのサポートが終了

Googleはこの変更をブログ記事では告知せず、構造化データのドキュメントに注記を追加する形で周知しました。ドキュメントには「FAQ構造化データはそのまま残して構わない。マークアップが問題を起こすことはないが、Google検索で目に見える結果を生むこともない」という趣旨の記載があります（Google検索セントラル・2026年8月時点）。

つまり2026年現在、FAQPageは「消しても害はないが、入れても検索結果上の成果はゼロ」という位置づけです。同じく手順系の HowTo も2023年8月（モバイル）・9月（デスクトップ）に廃止され、すでに全面的に姿を消しています。にもかかわらず「FAQ構造化データでCTRを改善しよう」と説明している記事は今も多く残っています。実装の優先順位を決めるときは、その型が現在も可視的な成果を生むのかを必ず確認してください。

パンくずリスト

パンくずリストは、サイト内の現在位置を示すナビゲーションです。

サイト構造の明示化

{
  "@context": "https://schema.org",
  "@type": "BreadcrumbList",
  "itemListElement": [{
    "@type": "ListItem",
    "position": 1,
    "name": "ホーム",
    "item": "https://inno-mark.jp/"
  },{
    "@type": "ListItem",
    "position": 2,
    "name": "ブログ",
    "item": "https://inno-mark.jp/blog/"
  }]
}

ユーザビリティ向上

パンくずリストの構造化により、検索結果にサイト階層が表示され、ユーザーがサイト構造を理解しやすくなります。これは直帰率の低下にもつながります。

その他のリッチスニペット

イベント、求人、商品、レシピなど

リッチスニペット	主な表示情報	業界
Event	開催日時、場所、チケット価格	イベント運営、セミナー
JobPosting	職種、給与、勤務地	人材採用
Recipe	調理時間、カロリー、材料	料理・グルメ
VideoObject	動画時間、アップロード日	動画コンテンツ

業界や用途に応じて、適切なリッチスニペットを実装することで、検索結果での差別化が図れます。

【2026年最新】LLMO・AIO時代の構造化マークアップ戦略

LLMO(Large Language Model Optimization)とは

LLMOとは、ChatGPTやPerplexityなどの大規模言語モデル(LLM)が生成する回答において、自社のコンテンツやサービスが引用・参照されやすくなるように最適化する施策です。

AI検索エンジンの台頭

2026年現在、AI検索の利用が急速に拡大しています。ナイル株式会社の2025年調査では、「生成AIで調べものをする」と回答した人が43.5%に達しており、従来の検索エンジンと並ぶ情報収集手段となっています。

ChatGPT Search、Perplexityへの対応

ChatGPTは2024年11月に検索機能(ChatGPT Search)を一般公開し、Perplexityも情報源の引用を重視したAI検索エンジンとして人気を集めています。これらのAI検索ツールに自社情報が引用されるためには、LLMO対策が不可欠です。

AIO(AI Overviews)とは

AIOは2つの意味で使われますが、本記事ではGoogleの「AI Overviews(AIによる概要)」と、広義の「AI Optimization(AI検索最適化)」の両方を含む文脈で使用します。

GoogleのAI検索結果

Google AI Overviewsは、検索結果の最上部にAIが生成した要約を表示する機能です。2024年8月から日本でも提供開始され、2025年3月のコアアップデート以降、表示頻度が急増しています。

Ahrefsの2025年調査によると、AI Overviewsが表示されると上位ページのクリック率が平均34.5%減少することが明らかになっています。つまり、従来のSEO対策だけでは流入確保が難しくなっているのです。

従来のSEOとの違い

項目	従来のSEO	AIO/LLMO
目的	検索順位の向上	AI引用・参照の獲得
成果指標	検索順位、クリック数	AI引用率、ブランド露出
主な対策	キーワード最適化、被リンク	情報の正確性、引用価値
クリック	サイト訪問が前提	AI回答で完結する場合も

AI検索時代に求められる構造化データ

AI検索では、より詳細で正確な構造化データが求められます。

より詳細なエンティティ情報

AIは、単なる情報の羅列ではなく、エンティティ(実体)とその関係性を理解します。そのため、著者情報、組織情報、引用元など、詳細なエンティティ情報を構造化データで提供することが重要です。

ファクトチェック可能なデータ構造

AIは情報の信頼性を判断する際、ファクトチェック可能な情報を優先します。以下の要素を構造化データに含めましょう。

著者の専門性(credentials)
情報の出典(citation)
更新日時(dateModified)
レビュー者情報(reviewer)

引用元としての最適化

AIに引用されやすくするためには、以下のポイントを押さえた構造化データを実装します。

簡潔で明確な定義文
一次情報であることの明示
統計データやファクトの提供
専門性・信頼性の証明

構造化マークアップとLLMO/AIOの関係性

構造化マークアップは、LLMO/AIO対策の基盤となる重要な施策です。

AI検索での構造化データ活用

ChatGPTやPerplexityなどのAI検索ツールは、Web上の情報を収集する際に構造化データを参照します。特にJSON-LD形式のデータは、AIが解析しやすい形式であるため、引用率の向上につながります。

ただし、ここは慎重に扱うべき論点です。Googleは2026年8月時点で、AI Overviews や AI Mode 向けの専用スキーマ仕様を公開していません。公式の立場は「構造化データはリッチリザルトのために引き続き有用だが、AIの応答のために特別なマークアップが必要なわけではない」というものです。

「構造化データがあるページはAI Overviewsでの引用率が高い」という調査は複数ありますが、いずれも第三者による観測であり相関であって因果ではありません。構造化データが整っているサイトは、そもそも情報設計・E-E-A-T・技術的な健全性も整っている傾向があるためです。「構造化データを入れればAIに引用される」と断定する説明を見かけたら、その根拠が公式情報か第三者の相関データかを確かめてください。

今後の実装トレンド予測

2026年以降、以下のトレンドが予測されます。

専門性の証明: AuthorやReviewerの詳細情報がより重要に
一次情報の明示: オリジナルデータであることを示す構造化データ
マルチモーダル対応: 画像、動画、音声への構造化データ拡張
リアルタイム性: 情報の鮮度を示すタイムスタンプの重要性向上

従来のSEO対策に加えて、AI時代に対応した構造化マークアップを実装することが、これからのWeb戦略の鍵となります。

【一次データ】自社メディア124記事を実測したら、「実装したつもり」と「実際の出力」が一致していなかった

ここからは、InnoMarkが自社で運用しているオウンドメディア（本ブログ）の公開HTMLを全記事分そのまま取得して計測した一次データをお見せします。一般論ではなく、実際に運用されているWordPressサイトで何が起きているかの記録です。

計測方法（3ステップ・どなたでも再現できます）

対象の確定: 記事台帳から「現役の公開記事」だけを抽出する（301で転送している退役記事を混ぜると数字が狂います）。今回の対象は124記事
公開HTMLの取得: 管理画面の本文ではなく、実際に配信されている公開URLのHTMLを取得する
抽出: <script type="application/ld+json"> ブロックを取り出し、@type を数える

ポイントは2番です。管理画面やプラグインの設定画面ではなく、配信されているHTMLを見ること。この一手間が、後述する「26本の取りこぼし」を発見できるかどうかを分けました。

計測結果（2026年8月21日時点・現役124記事）

出力されている `@type`	該当記事数	出力率
BreadcrumbList / ListItem	124本	100%
SiteNavigationElement	124本	100%
ItemList	7本	6%
FAQPage / Question / Answer	1本	1%
Article / BlogPosting	0本	0%
Organization	0本	0%
WebSite / WebPage	0本	0%

InnoMark調べ。inno-mark.jp/blog の現役公開記事124本の公開HTMLを2026年8月21日に取得し、JSON-LDブロックの @type を集計。

発見1: FAQブロックが27本あるのに、FAQPageが出ていたのは1本だけだった

本文にFAQ用のブロック（構造化データ出力プラグインが提供するFAQブロック）を持つ記事は27本ありました。ところが、公開HTMLに FAQPage が出力されていたのは1本だけ。残る26本は、編集画面上はFAQとしてマークアップしたつもりでも、実際には何も出力されていなかったことになります。

原因は単純ではなく、プラグイン側の出力設定・テーマとの競合・キャッシュなど複数が絡みます。重要なのは原因の特定より、「出力されているつもりで、実際には出ていなかった」状態が気づかれないまま続いていたという事実のほうです。定期的に公開HTMLを確認する運用がなければ、この26本はこれからも発見されませんでした。

発見2: Article も Organization も1本も出ていなかった

より深刻だったのはこちらです。ブログ記事であれば当然入っているべき Article（または BlogPosting）が0本。企業サイトのエンティティを示す Organization も0本でした。実際に出力されていたのは、パンくずリストとグローバルナビゲーションだけです。

SEOプラグインは導入済みで、メタディスクリプションもOGPも正常に出力されています。それでもスキーマグラフの出力だけが機能していませんでした。「有名なSEOプラグインを入れているから構造化データは大丈夫」という前提が、そのまま成立していなかったわけです。

InnoMarkのスタンス: 構造化マークアップは「実装したか」ではなく「出力されているか」で管理する

この結果から、私たちは構造化マークアップの管理方針を次のように置いています。

設定画面を信用しない。チェックが入っていることと、HTMLに出ていることは別の話です
1ページだけ見て安心しない。テンプレートや記事タイプごとに出力が変わります。全記事を機械的に走査してはじめて分布が見えます
定点観測する。プラグイン更新・テーマ変更・キャッシュ設定の変更で、ある日突然出力が止まります。今回の26本がまさにそれです
「壊れていないか」は単独では判定できない。変更していない記事と比べて初めて、それが元からの状態なのか今回壊れたのかが分かります

実装ガイドは世の中に大量にありますが、実装後に出力が生き続けているかを見張る運用の話はほとんど語られていません。構造化データは「作って終わり」の成果物ではなく、監視対象のインフラとして扱うべきです。

なお、この計測自体は特別なツールを必要としません。公開URLのHTMLを取得して ld+json を数えるだけです。記事数が多い場合はスクリプト化すれば数分で終わります。サーチコンソールでの確認方法とあわせて、「Search Console(サーチコンソール)の使い方完全ガイド」も参考にしてください。

よくある実装エラーと解決方法

Googleペナルティにつながる誤実装

構造化マークアップの誤実装は、Googleペナルティの対象となる可能性があります。

スパム的なマークアップ

以下のような実装は、Googleのガイドライン違反となります。

実際には存在しない高評価レビューを記述する
他サイトからコピーした内容を自社コンテンツとして構造化する
ユーザーに見えない隠しテキストを構造化データに含める

これらは検索結果からの除外やランキング低下のペナルティを受ける可能性があります。

実際のコンテンツと異なる情報

構造化データは、ページに表示されているコンテンツと一致している必要があります。例えば、ページに表示されていない価格情報を構造化データに記述したり、実際の著者と異なる人物を著者として記載したりすることは禁止されています。

エラーメッセージの読み解き方

Google Search Consoleでエラーが表示された場合の対処法を解説します。

Search Console警告への対処

よくあるエラーと対処法:

エラーメッセージ	原因	対処法
「必須プロパティがありません」	必須項目の未記入	該当プロパティを追加
「値が無効です」	形式の間違い	正しい形式に修正
「推奨プロパティがありません」	推奨項目の未記入	可能な限り追加

必須プロパティ不足の解消

例えば、Article型ではheadline、image、datePublishedが必須です。これらが欠けていると、リッチリザルトが表示されません。リッチリザルトテストで「必須プロパティ」をすべて確認しましょう。

実装したのにリッチリザルトが表示されない原因

構造化データを正しく実装しても、すぐにリッチリザルトが表示されるとは限りません。

Googleのガイドライン違反チェック

まず、Googleのガイドラインに違反していないか確認します。

コンテンツとマークアップの一致
スパム的な内容でないか
ユーザーに価値を提供しているか

インデックス待ち期間

構造化データを実装してからGoogleに認識されるまで、通常2週間~1ヶ月程度かかります。Search Consoleの「URL検査ツール」で「インデックス登録をリクエスト」することで、処理を早めることができます。

また、リッチリザルトはすべてのクエリで表示されるわけではありません。Googleが「このクエリにはリッチリザルトが有益」と判断した場合にのみ表示されます。

【2026年版・判断マトリクス】投資すべき型と、もう追いかけなくてよい型

FAQとHowToが姿を消したことで、構造化データの費用対効果は2023年以前とはっきり変わりました。限られた工数をどこに割くかを、可視的な成果・エンティティとしての価値・実装コストの3軸で整理します。

型	Google検索での可視的な成果	エンティティ伝達としての価値	実装コスト	InnoMarkの推奨
`Article` / `BlogPosting`	あり（記事系の表示）	高	低（プラグインで自動）	最優先で出力を確認
`Organization`	あり（ロゴ・企業情報）	非常に高	低（サイトに1つ）	最優先で出力を確認
`BreadcrumbList`	あり（階層表示）	中	低	維持（多くのテーマが自動出力）
`Product` / `Review`	あり（価格・星評価）	高	中	EC・商品ページがあるなら投資
`VideoObject`	あり（動画枠）	中	中	動画を持つなら投資
`Event` / `LocalBusiness`	あり	高	中	該当事業なら投資
`FAQPage`	なし（2026年5月7日に廃止）	低〜中	低	新規の工数投下は不要（既存は放置で可）
`HowTo`	なし（2023年に廃止）	低〜中	中	撤退

InnoMark作成。Google検索セントラルの構造化データギャラリー（2026年8月時点）と自社メディアでの運用実績をもとに整理。

この表の読み方: 「地味な型を確実に出す」ほうが効く

表を眺めると、ひとつの傾向が見えてきます。派手なリッチリザルトを狙う型ほど廃止・縮小のリスクが高く、地味にエンティティを伝える型ほど長く生き残っているということです。FAQとHowToは短期間で消えましたが、Article・Organization・BreadcrumbListは一貫して残り続けています。

私たちのスタンスは明確です。「まだ実装していない新しい型を探す」より先に、「当然入っているはずの型が本当に出力されているか」を確認してください。先ほどの実測が示すとおり、後者のほうがはるかに大きな穴が空いていることがあります。ArticleとOrganizationが0本という状態は、どれだけ新しい型を追加しても埋まりません。

そのうえで補足すると、AI検索を意識する場合も結論は変わりません。AIが必要としているのは「このページは誰が書いた何の記事で、どの組織のものか」という基本情報です。それを担うのはFAQではなくArticleとOrganizationです。LLMO全体の考え方は「LLMO対策とは？ChatGPT・Geminiに選ばれるサイト作りの完全ガイド」で整理しています。

構造化マークアップのSEO効果測定方法

Search Consoleでの効果確認

Google Search Consoleは、構造化マークアップの効果測定に不可欠なツールです。

リッチリザルトレポートの見方

Search Consoleにログイン
左メニューから「拡張」セクションを選択
該当する構造化データタイプ(FAQ、パンくずリストなど)をクリック
エラー、警告、有効なアイテム数を確認

有効なアイテムが増えていれば、正しく実装できています。エラーや警告がある場合は、早急に修正しましょう。

クリック率の変化追跡

「検索パフォーマンス」レポートで、構造化データ実装前後のCTRを比較します。特定のページやクエリでCTRが向上していれば、リッチスニペットの効果が出ていると判断できます。

GA4での効果測定

Google Analytics 4(GA4)では、より詳細な流入分析が可能です。

流入元別の分析

GA4の「集客」>「トラフィック獲得」レポートで、Organic Searchからの流入を分析します。構造化データ実装後に以下の指標をチェックしましょう。

セッション数の変化
エンゲージメント率
コンバージョン率

コンバージョン貢献度

GA4の「探索」機能を使って、構造化データを実装したページからのコンバージョンを追跡します。リッチスニペット経由の訪問者がコンバージョンに至りやすいかを分析することで、ROIを測定できます。

【実測】効果測定をGoogleだけで行うと判断を誤る — 検索クリックの82%がBingだった話

効果測定でもうひとつ、実務上きわめて重要な落とし穴があります。構造化データの効果をGoogle Search Consoleだけで判断してしまうことです。

私たちが自社メディアの流入をエンジン別に分解したところ、検索クリックの約82%はBing経由でした（28日間の実測・2026年8月時点）。Googleは残りの2割弱です。さらに記事単位で見ると、Bingでは3〜8位に入っているのにGoogleでは20〜60位台、という記事が大半でした。最大の流入を集めている記事は、Bingで2.5位・Googleでは71位です。

この構成比を知らずにGoogle Search Consoleだけを見ていると、次のような誤判定が起きます。

実際には流入の8割を支えている施策を「効果なし」と結論づけてしまう
Googleのリッチリザルト仕様変更（FAQ廃止など）の影響を、サイト全体の影響として過大に見積もってしまう
逆に、Google側だけで改善した数字を全体の成果と取り違えてしまう

実際、私たちが実施したあるリライトは、Googleでは順位が9ポイント下がって「失敗」に見えたのに、Bingでは同期間のサイト全体が3割減るなかで逆にクリックが4割増えていました。片方だけを見ていたら、有効な施策を打ち切っていたことになります。

だからInnoMarkでは、施策の成否を必ず両エンジンで判定します。Bing Webmaster Tools は無料で登録でき、APIも公開されています。自社の構成比を一度も測ったことがないなら、構造化データの実装より先にそちらを確認することをおすすめします。どのエンジンから来ているかを知らないまま行う効果測定は、結論が偶然に左右されます。

なお、Bingの管理画面は週次でデータが更新される仕様のため、実装直後に数字を見に行っても変化は出ません。判定は最短でも2〜3週間後に、確定した週次データ同士で比較してください。

実装前後の順位変動チェック

構造化マークアップ自体は順位に直接影響しませんが、間接的な効果を測定することが重要です。

ランキングツールでのモニタリング

以下のツールで検索順位を継続的にモニタリングします。

GRC(日本語対応)
Ahrefs
Semrush
Rank Tracker

構造化データ実装後、数ヶ月単位で以下の変化を観察しましょう。

順位の変動
表示回数(インプレッション)の増加
CTRの向上

これらの指標が改善していれば、構造化マークアップが成功していると言えます。

まとめ:構造化マークアップは2026年のSEO必須施策

構造化マークアップは、従来のSEOとAI検索時代のLLMO/AIO対策、両方の基盤となる重要な施策です。

実装ステップのチェックリスト

☑ 1. サイトタイプに合ったSchema.org語彙を選択

ブログ: Article型
ECサイト: Product型
コーポレートサイト: Organization型
サービスサイト: Service型

☑ 2. JSON-LDで実装

Google推奨形式を使用
headタグ内に記述
必須プロパティをすべて含める

☑ 3. 検証ツールでチェック

リッチリザルトテスト
Search Console
構造化データマークアップ検証ツール

☑ 4. Search Consoleでの効果測定

リッチリザルトレポートの確認
CTRの変化を追跡
エラーの早期発見・修正

☑ 5. 公開HTMLで出力を確認する（最重要）

設定画面ではなく配信されているHTMLを見る
全記事を走査して @type の分布を出す
プラグイン更新・テーマ変更のたびに再確認する

☑ 6. LLMO/AIO対応の最適化

著者情報・専門性の明示
一次情報であることの構造化
引用されやすいデータ形式の採用

AI検索時代のWeb戦略

2026年現在、Google AI OverviewsやChatGPT Searchの普及により、検索体験は大きく変化しています。従来のSEO対策だけでは不十分であり、AIに「引用される」「推薦される」ための対策が必須となっています。

構造化マークアップは、検索エンジンとAI双方に正確な情報を伝える唯一の標準化された手法です。早期に実装することで、競合との差別化と長期的な集客力の向上が期待できます。

最後に、本記事でお伝えしたかった最も重要なことを繰り返します。構造化マークアップの現場で実際に起きている問題は、「まだ知らない型がある」ことではなく、「入れたはずの型が出ていない」ことです。私たちが自社メディア124記事を実測したときも、ArticleとOrganizationは1本も出力されておらず、FAQブロックを持つ27本のうち実際に出ていたのは1本だけでした。

新しい型を追加する前に、まず公開HTMLを開いて ld+json を確認してください。そして効果を判定するときは、自社の流入がどの検索エンジンから来ているかを先に把握してください。この2つを飛ばした構造化データ施策は、成果が出ているかどうかすら分からないまま工数だけを消費します。

InnoMarkはデータ可視化とGA4/GTMの計測設計を本業とする会社です。本記事の数値も、すべて自社で運用しているメディアを実際に計測して得たものです。構造化データの棚卸し、計測環境の設計、エンジン別の効果測定の仕組みづくりまで、お困りの際はお気軽にご相談ください。

よくある質問(FAQ)

Q1: 構造化マークアップを実装すると、必ず検索順位が上がりますか?

いいえ、構造化マークアップ自体は検索順位に直接的な影響を与えません。Googleも公式に「構造化データは検索順位を保証するものではない」と述べています。

ただし、間接的なSEO効果は確実に存在します。リッチスニペットが表示されることでクリック率(CTR)が向上し、より多くのユーザーがサイトを訪問するようになります。また、検索エンジンがページの内容を正確に理解できるようになるため、適切な検索クエリに対して表示されやすくなります。

結果として、アクセス数の増加、ユーザーエンゲージメントの向上につながり、中長期的にSEO成果の改善が期待できます。構造化マークアップは「順位を上げる魔法のツール」ではなく、「サイトの価値を高める基盤技術」と理解することが大切です。

Q2: JSON-LD、Microdata、RDFaのどれを使うべきですか?

特別な理由がない限り、JSON-LDの使用を強く推奨します。理由は以下の通りです。

まず、GoogleがJSON-LDを公式に推奨しています。JSON-LDはHTMLと分離されているため、実装が容易で、既存のコードを変更する必要がありません。また、エラーが発生してもサイトの表示に影響しないため、安全性が高いというメリットがあります。

Microdataは既存のHTMLマークアップを活用したい場合には有効ですが、コードが複雑になりやすく、メンテナンスが困難です。RDFaは現在ほとんど使用されておらず、特殊なケース以外での採用は推奨されません。

新規でサイトを構築する場合も、既存サイトに追加する場合も、JSON-LDを第一選択肢としてください。WordPressなどのCMSを使用している場合は、Yoast SEOやSchema Proなどのプラグインを活用することで、コーディングなしでJSON-LDを実装できます。

Q3: 構造化マークアップを実装したのに、リッチスニペットが表示されません。なぜですか?

リッチスニペットが表示されない主な理由は以下の4つです。

1. インデックスに時間がかかっている 構造化データを実装してからGoogleに認識されるまで、通常2週間~1ヶ月程度かかります。Search Consoleの「URL検査ツール」で「インデックス登録をリクエスト」することで、処理を早めることができます。

2. Googleのガイドライン違反 実際のページコンテンツと構造化データの内容が一致していない場合や、スパム的なマークアップをしている場合、リッチスニペットは表示されません。Googleのガイドラインを再確認してください。

3. 必須プロパティの不足 各構造化データタイプには必須プロパティがあります。リッチリザルトテストで「必須」と表示されているプロパティがすべて含まれているか確認しましょう。

4. Googleの判断 すべてのクエリでリッチスニペットが表示されるわけではありません。Googleが「このクエリにはリッチスニペットが有益」と判断した場合にのみ表示されます。正しく実装しても表示されない場合があることを理解しておきましょう。

Search Consoleの「拡張」>「リッチリザルト」レポートで、実装状況とエラーの有無を定期的にチェックすることをお勧めします。

Q4: LLMO対策とSEO対策は別々に行う必要がありますか?

いいえ、LLMO対策とSEO対策は別物ではなく、相互に補完し合う関係にあります。

実際、AI Overviewに引用されるページの約52%は、通常のオーガニック検索でも上位10位にランクインしています。つまり、従来のSEOで高く評価されているページは、AI検索でも引用されやすい傾向があるのです。

両者に共通する重要な要素:

高品質で正確なコンテンツ
E-E-A-T(専門性・権威性・信頼性)の強化
構造化マークアップの実装
ユーザーニーズへの的確な回答

ただし、LLMO特有の施策も存在します。

著者の専門性・経歴の明示
一次情報であることの明確化
AIが引用しやすい簡潔な定義文
ファクトチェック可能なデータ提供

効果的なアプローチは、従来のSEO対策をしっかり行いつつ、AI時代に対応した要素を段階的に追加していくことです。既存のSEO施策を放棄するのではなく、その延長線上にLLMO対策を位置づけることで、検索エンジンとAI検索の両方で成果を上げることができます。

Q5: AI Overviewsが表示されると、サイトへのアクセスは減りますか?

はい、AI Overviewsが表示されるクエリでは、従来の検索結果と比べてクリック率が低下する傾向があります。

Ahrefsの2025年調査によると、AI Overviewsが表示されると上位ページのクリック率は平均で約34.5%減少しています。これは「ゼロクリック検索」と呼ばれる現象で、ユーザーが検索結果ページ上でAIの要約を読むだけで満足し、Webサイトをクリックしない傾向が強まっているためです。

ただし、すべてのケースでアクセスが減るわけではありません。以下のようなポジティブな側面もあります。

AI Overviewsに引用されるメリット:

ブランド認知度の向上
専門性・信頼性のアピール
引用元リンクからの高品質な流入

実際、Googleの調査では、AI Overviewsに含まれるリンクは、通常の検索結果よりも多くクリックされるケースもあることが報告されています。

今後のWeb戦略としては、単なるアクセス数だけでなく、「AIに引用される」「情報源として認識される」という新しい指標も重視する必要があります。構造化マークアップやE-E-A-Tの強化により、AI Overviewsでの露出を高めつつ、深掘りしたい読者のための詳細コンテンツも用意することが、AI検索時代のバランスの取れた戦略と言えるでしょう。

SEO対策を体系的に学びたい方は「SEO完全ガイド｜Google上位表示の手法を総まとめ」をご覧ください。

参考URL・引用元まとめ

Q6: すでに実装済みのFAQ構造化データは削除すべきですか?

削除する必要はありません。Googleは「FAQ構造化データはそのまま残して構わない。マークアップが問題を起こすことはない」としています。ただしGoogle検索での可視的な成果はゼロなので、これから工数をかけて新規に実装する優先度は最も低い部類です。削除作業自体にも工数とリスクがあるため、既存分は放置し、新しく作る記事では他の型に工数を回す、という運用が現実的です。

Q7: 構造化データが実際に出力されているか、どうやって確認すればよいですか?

公開URLのHTMLを直接確認するのが最も確実です。ブラウザでページのソースを表示し、application/ld+json で検索して、期待している @type が入っているかを見てください。管理画面やプラグインの設定画面は「出力するつもり」を示しているだけで、実際の出力を保証しません。記事数が多い場合は、公開URLを順に取得して @type を集計するスクリプトを組めば数分で全記事を棚卸しできます。私たちが自社メディア124記事を計測したところ、FAQブロックを持つ27本のうち実際に出力されていたのは1本だけでした。

＼検索トレンドの変化に対応できていますか？／

SEO・データ活用の相談はInnoMarkへ

SEO/コンテンツ戦略の設計・GA4/Search Consoleでの効果測定・データに基づく改善提案

InnoMarkに無料で相談する

※初回相談・お見積もりは無料

LLMO対策とは？ChatGPT・Geminiに選ばれるサイト作りの完全ガイド

【初心者必見】Google Search Console（サーチコンソール）9つの分析方法と活用法

＼データを可視化するマーケティング会社／

まずは無料でInnoMarkに相談する

SEO・データ活用 / Web制作 / 広告運用 / DX支援

✓ 初回相談無料✓ オンライン対応✓ 無理な営業なし