構造化マークアップとは？JSON-LDの書き方と自サイト検証で見つけた落とし穴

この記事でわかること

構造化マークアップとは？構造化データとの違い

構造化マークアップとは、Webページの情報が「何を意味しているのか」を検索エンジンが機械的に理解できるよう、schema.orgなどの決められた語彙と書式でデータを書き添えることです。Google検索セントラルは、構造化データを「ページに関する情報を提供し、ページのコンテンツを分類するための標準化されたデータ形式」と説明しています（構造化データ マークアップの概要）。

たとえばページに「鈴木太郎」という文字列があるとき、人間は前後の文脈から「この記事の著者だ」と判断できます。クローラーにとってはただの文字列ですが、構造化データで「この鈴木太郎はArticleのauthorである」と書き添えれば、意味を取り違えずに受け取れます。

なお、ここでいう構造化データは検索エンジン向けのマークアップの話で、データ分析やデータベースの分野でいう「構造化データ／非構造化データ」（表形式で整理されたデータかどうか）とは別の概念です。

構造化データと構造化マークアップの違い

構造化データは「意味づけされた情報そのもの」、構造化マークアップは「それをHTMLに書き込む作業や記法」を指します。実務ではほぼ同じ意味で使われ、Google自身も「構造化データ マークアップ」という言い方をします。「構造化データをマークアップする」と捉えると、両者の関係がいちばん正確に整理できます。

通常のHTMLマークアップとの違い

通常のマークアップは、HTMLタグで見出し・段落・リンクといった「文書の構造」を表します。構造化マークアップは、その中身が会社名なのか、住所なのか、価格なのかという「情報の意味」を表します。違いをコードで比べてみましょう。

<!-- 通常のマークアップ：文字列としてしか伝わらない -->
<p>株式会社サンプル</p>

<!-- 構造化マークアップ（JSON-LD）：「組織の名前」だと伝わる -->
<script type="application/ld+json">
{
  "@context": "https://schema.org",
  "@type": "Organization",
  "name": "株式会社サンプル",
  "url": "https://example.com/"
}
</script>

見た目は変わりませんが、後者は「株式会社サンプルという名前の組織で、公式URLはこれ」という情報を検索エンジンへ渡しています。構造化データは画面の表示には影響せず、検索エンジンが読むための補足情報として働きます。見出しやtitleなど通常のタグの使い方はSEO対策に必須のHTMLタグ一覧にまとめています。

仕組み：schema.orgの語彙とJSON-LDなどの書式

構造化マークアップは、「何を書くか」を決めるボキャブラリー（schema.org）と、「どう書くか」を決めるシンタックス（JSON-LD・Microdata・RDFa）の組み合わせでできています。どちらか一方だけでは成り立たず、語彙で決めた意味を、書式に従ってHTMLへ埋め込みます。

ボキャブラリー（schema.org）

ボキャブラリーとして最も広く使われているのがschema.orgです。主要な検索エンジンが共同で立ち上げた共通の語彙で、Article（記事）やProduct（商品）といった「タイプ」と、headline（見出し）やprice（価格）といった「プロパティ」が定義されています。

注意したいのは、schema.orgに定義があることと、Google検索で使われることは別だという点です。Googleは概要ページで、Google検索での扱いはschema.orgではなく検索セントラルのドキュメントを基準にするよう案内しています。schema.orgには、Google検索では使われないタイプやプロパティも多く含まれます。また、かつて使われたdata-vocabulary.orgのマークアップは、現在はリッチリザルトの対象外です。

シンタックス（JSON-LD／Microdata／RDFa）

Googleが対応する書式はJSON-LD・Microdata・RDFaの3種類で、サイトの構成が許すならJSON-LDを使うよう推奨しています。理由は、実装と大規模な保守が最も容易だからです。

書式	書く場所	特徴	Googleの扱い
JSON-LD	<script type=”application/ld+json”>の中（headでもbodyでも可）	表示用のHTMLと分離でき、入れ子の情報も書きやすい。JavaScriptで動的に挿入したものもGoogleは読み取れる	推奨
Microdata	表示用HTMLタグの属性（itemscope・itemtype・itemprop）	表示テキストと一致させやすいが、HTMLが煩雑になり保守しにくい	対応
RDFa	表示用HTMLタグの属性（vocab・typeof・property）	HTML5の拡張機能。Microdataと同様にHTMLへ埋め込む	対応

なお、Googleは「マークアップが有効で、各機能のドキュメントどおりに実装されていれば、3形式ともGoogleにとって同等に問題ない」としています。JSON-LDを勧めるのは、多くの場合それが最も実装・保守しやすいからです。

同じ組織情報をMicrodataとRDFaで書くと次のようになります。表示用のタグに属性が混ざるため、デザインを変えるたびにマークアップも壊れやすくなるのがわかります。

<!-- Microdata -->
<div itemscope itemtype="https://schema.org/Organization">
  <span itemprop="name">株式会社サンプル</span>
  <a itemprop="url" href="https://example.com/">公式サイト</a>
</div>

<!-- RDFa -->
<div vocab="https://schema.org/" typeof="Organization">
  <span property="name">株式会社サンプル</span>
  <a property="url" href="https://example.com/">公式サイト</a>
</div>

SEO効果とデメリット

構造化マークアップは、それ自体が直接的なランキング要因として順位が上がる施策ではありません。効果は「ページの意味が検索エンジンに正確に伝わること」と「リッチリザルトの表示資格を得ること」の2つで、その結果としてクリック率の改善が期待できる、という順番で考えます。

検索順位は直接は上がらない（Google公式の立場）

Googleの概要ページは、構造化データをリッチリザルトの表示に使う情報として説明しており、掲載順位を上げる仕組みとしては説明していません。また一般ガイドラインでは、構造化データの問題で手動による対策を受けても、失うのはリッチリザルトの表示資格であり、ウェブ検索での掲載順位には影響しないとしています。

リッチリザルトでクリックされやすくなる

リッチリザルトとは、通常のタイトルとスニペットに加えて、画像・評価・価格・日付・パンくずなどを含めて表示される検索結果です。構造化データは表示の前提条件ですが、Googleは「正しくマークアップしても、検索結果に表示されることは保証しない」と一般ガイドラインで明言しています。

表示されれば検索結果で目立ちやすくなり、クリック率の改善が期待できます。ただ効果の大きさはページや検索クエリによって違います。Googleが勧める測り方は、構造化データを入れていないページで数か月分のSearch Consoleデータを取り、追加後の数か月と比べるビフォー＆アフターの比較です。

AI Overviews・AIモード時代の位置づけ

AI Overviews（AIによる概要）やAIモードに表示されるために、特別な構造化データは必要ありません。GoogleはAI機能とウェブサイトに関するドキュメントで、AI機能に表示されるための追加要件や特別な最適化はなく、「追加する必要のある特別なschema.orgの構造化データもない」と書いています。

一方で同じドキュメントは、基本のベストプラクティスとして「構造化データがページ上の表示テキストと一致していること」を挙げています。つまり、構造化データはAI向けの裏技ではなく、従来どおり正確に書くべき基礎の一部という位置づけです。Googleが公開した生成AI検索の最適化ガイドでも、llms.txtやチャンク化は不要とされています。AI検索全体の考え方はLLMOの解説とAIO対策の解説で扱っています。

デメリット：工数・保守・誤実装のリスク

構造化マークアップのデメリットは、書式と仕様の知識が必要で、実装後も保守し続ける工数がかかることです。

• 実装しても、リッチリザルトの表示は保証されない
• Googleの対応機能は変わる。FAQやHowToのように、かつて代表的だったリッチリザルトも終了している
• テーマとSEOプラグインを併用すると、同じタイプが重複して出力されやすい（当サイトの実例は後述）
• 一般論として、テーマやプラグインの更新で出力内容が変わることもあるため、更新後の確認が必要になる
• ページに表示していない内容をマークアップすると、ガイドライン違反として手動による対策の対象になり得る

主な構造化データの種類と検索結果での見え方

よく使われる構造化データは、パンくずリストのBreadcrumbList、記事のArticle（BlogPosting・NewsArticle）、商品のProduct、組織のOrganizationです。下の表は、GoogleのGoogle検索がサポートする構造化データの一覧（2026年10月11日確認）から、多くのサイトに関係するものを抜き出したものです。

種類（Googleでの名称）	schema.orgタイプ	検索結果での見え方・用途	向いているサイト・ページ
パンくずリスト	BreadcrumbList	URL部分をサイト階層で表示（パソコンのみ）	階層のあるすべてのサイト
記事	Article／BlogPosting／NewsArticle	タイトル・画像・日付を適切に表示	ブログ・ニュース・コラム
組織	Organization	ロゴ・名称・連絡先などの管理情報を伝える	企業・団体のトップページ
商品	Product	価格・在庫・評価の表示	ECサイトの商品ページ、商品レビュー
ローカル ビジネス	LocalBusiness（Restaurantなどのサブタイプ）	営業時間・所在地などの詳細	店舗・拠点のページ
クチコミ抜粋	Review／AggregateRating	評価の星と件数	レビューを掲載するページ
イベント	Event	日時・会場の一覧表示	イベント告知ページ
求人情報	JobPosting	Googleの求人検索への掲載	個々の求人の詳細ページ（求人一覧ページではなく1件ごとのページ）
レシピ	Recipe	画像・評価・調理時間の表示	料理レシピ
動画	VideoObject	動画のサムネイルや再生時間	動画を主役にしたページ
プロフィール ページ	ProfilePage	サイトに関係する1人の人物・1つの組織の情報	著者・人物の紹介ページ
Q&A	QAPage	1つの質問とそれに付いた回答	ユーザーが回答を投稿するQ&Aサイト

Q&A（QAPage）は「1つの質問に対して回答が並ぶページ」向けで、サイト運営者が自分で書いた「よくある質問」には当てはまりません。また、データセット（Dataset）はGoogle検索ではなく、Googleデータセット検索に表示されるものとして一覧に載っています。パンくずリストの設計そのものはパンくずリストの設置方法とSEO効果で詳しく解説しています。

FAQ・HowToのリッチリザルトは終了（2026年時点の仕様）

FAQPageとHowToの構造化データは、2026年10月時点でGoogle検索のリッチリザルトとしては表示されません。上位の解説記事にはFAQを推奨例として紹介しているものもありますが、Googleの公式ドキュメントで確認できる経緯は次のとおりです。

機能	構造化データ	Google公式で確認できる経緯
よくある質問（FAQ）	FAQPage	2023年8月に、表示を著名で権威のある政府・医療サイトに限定。2026年5月8日のドキュメント更新で「2026年5月7日からGoogle検索に表示されなくなる」と告知し、2026年6月15日にドキュメントを削除
How-to	HowTo	2023年8月にパソコンのみに限定し、2023年9月13日からパソコンでも表示終了（廃止）
サイトリンク検索ボックス	WebSite＋SearchAction	2024年11月21日から表示を終了。順位には影響しないと説明
コース情報・ClaimReview・給与推定額・学習用動画・特別なお知らせ・車両リスティングなど	各タイプ	2025年6月12日に段階的な終了を発表し、2025年9月9日からSearch Consoleのレポートとリッチリザルトテストの対象外に
パンくずリスト（表示範囲の縮小）	BreadcrumbList	2025年1月のドキュメント更新で、表示はパソコンの検索結果のみ（モバイルでは表示しない）と明記

出典は、Google検索セントラル ブログ「HowTo とよくある質問のリッチリザルトにおける変更」（2023年8月8日、同年9月14日追記）、「サイトリンク検索ボックスの終了」（2024年10月21日）と、検索セントラルのドキュメント更新履歴です。

すでに入っているFAQPageを急いで消す必要はありません。Googleは2023年のブログで「使われていない構造化データが検索で問題を起こすことはない」と説明しています。ただし、リッチリザルト目的で新しくFAQPageやHowToを追加する理由はなくなりました。当サイトが出力しているFAQPageで見つかった不具合は「よくある失敗と注意点」で紹介します。

JSON-LDの書き方（コード例つき）

JSON-LDは、<script type=”application/ld+json”>のタグの中に、@contextで語彙（https://schema.org）を、@typeでタイプを宣言し、そのタイプのプロパティに値を入れる形で書きます。タグはheadにもbodyにも置けます。ここでは多くのサイトで最初に入れるArticleとBreadcrumbListを例にします。

基本形（Article）

<script type="application/ld+json">
{
  "@context": "https://schema.org",
  "@type": "BlogPosting",
  "headline": "構造化マークアップとは？JSON-LDの書き方",
  "image": [
    "https://example.com/photos/1x1/photo.jpg",
    "https://example.com/photos/4x3/photo.jpg",
    "https://example.com/photos/16x9/photo.jpg"
  ],
  "datePublished": "2026-07-23T09:00:00+09:00",
  "dateModified": "2026-10-11T09:00:00+09:00",
  "author": [
    {
      "@type": "Person",
      "name": "鈴木太郎",
      "url": "https://example.com/author/suzuki/"
    }
  ]
}
</script>

scriptタグのtypeを”application/ld+json”にすると、ブラウザはスクリプトとして実行せず、検索エンジンは構造化データとして読み取ります。authorのように、値として別のタイプ（Person）を入れ子にできるのがJSON-LDの強みです。Articleの公式ドキュメントによると、画像は幅×高さが5万ピクセル以上で、16×9・4×3・1×1の比率を複数用意するのが推奨です。

パンくずリスト（BreadcrumbList）

<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": "Web制作・コーディング",
      "item": "https://example.com/category/web/"
    },
    {
      "@type": "ListItem",
      "position": 3,
      "name": "構造化マークアップとは？"
    }
  ]
}
</script>

BreadcrumbListには、ListItemを2つ以上含めます。positionは1から始まる階層の順番で、最後の要素（現在のページ）はitemを省略できます。BreadcrumbListはArticleなどと同じページに併記できますが、同じページで2回出さないことが大切です。当サイトでは、まさにこの二重出力が起きていました（後述）。

必須プロパティと推奨プロパティの見方

何を書くべきかは、schema.orgではなく、Googleの各機能のドキュメントにある「必須プロパティ」と「推奨プロパティ」の表で判断します。必須が欠けるとリッチリザルトの対象外になります。推奨プロパティについてGoogleは、不完全・不正確なデータで推奨プロパティを網羅しようとするより、数は少なくても完全で正確な推奨プロパティを記述するほうが重要だとしています。

• Article・Organizationのように、必須プロパティがなく「当てはまる推奨プロパティをできるだけ追加する」とされている機能もある
• BreadcrumbListは、ListItemのposition・nameなどが必須
• JSONの文法は厳格。キーと文字列はダブルクォーテーションで囲み、最後のプロパティの後にカンマを付けず、コメントは書けない
• @typeは正式名称を大文字小文字まで正確に書く（articleではなくArticle）
• 日付はISO 8601形式で、タイムゾーンも付ける（例: 2026-10-11T09:00:00+09:00）

1ページに複数の構造化データを置くときは、タイプごとにscriptを分ける方法と、1つのscript内で@graphにまとめる方法があります。当サイトが使っているSEOプラグインは後者の@graph形式で出力しています。

実装方法：手書き・WordPressプラグイン・生成AI

構造化マークアップの実装方法は、テンプレートへの手書き、WordPressなどのCMSのプラグイン、生成AIでの下書き作成の3つが中心です。どの方法でも、最後に「本番のHTMLに何が出ているか」を確かめるところまでが実装です。

手書き（テンプレートに直接書く）

静的サイトや少数のページなら、前章のJSON-LDをテンプレートに直接書くのが確実です。ページの種類ごとにテンプレートを分け、値の部分だけをページのデータから差し込む形にすると、記述ミスと表記ゆれを減らせます。Googleタグマネージャーで挿入する方法もありますが、GoogleはJavaScriptで構造化データを生成する方法の中で、Productを動的に生成するとショッピングのクロールの頻度と信頼性が下がる可能性があると注意しています。

WordPressプラグイン（CMSの機能）

GoogleはWix・WordPress・ShopifyなどのCMSでHTMLを直接編集できない場合、CMSの設定画面や構造化データ用のプラグインを使う方法を案内しています。WordPressでは、SEOプラグインとテーマの両方が構造化データを出力することが多く、どちらが何を出しているかを把握しておかないと重複が起きます。

代表的なSEOプラグインでは、構造化データの設定は次の場所にあります（2026年10月11日に各プラグインの英語版公式ドキュメントを開いて確認）。メニュー名は英語版の公式ドキュメントに基づきます。日本語版では表示が異なる場合があります。

プラグイン	サイト全体の設定	記事ごとの設定
All in One SEO（AIOSEO）	All in One SEO → Search Appearance（検索の外観）→ Content Types（コンテンツタイプ）タブ → 投稿・固定ページなどの種類ごとの Schema Markup（スキーママークアップ）タブでスキーマの種類を選ぶ。AIOSEO ProのBasicプラン以上が必要	個々の投稿・ページの編集画面で設定。AIOSEO ProのBasicプラン以上が必要
Yoast SEO	Yoast SEO → Settings（設定）→ Site representation（サイトの表現）で、サイトが組織か個人かを選び、名称・ロゴ・SNSアカウントを登録（この情報が構造化データとして出力される）	本記事では未確認（参照した公式ヘルプは、サイト全体の設定のみを扱っている）
Rank Math	Rank Math SEO → Titles and Meta（タイトルとメタ）→ Posts などの投稿タイプ → Schema Type（スキーマタイプ）で既定のスキーマを選ぶ	投稿編集画面のRank Mathパネルの Schema（スキーマ）タブ → Schema Generator（スキーマジェネレーター）

プラグインが対応していないタイプを足したい場合は、テーマのfunctions.phpなどからwp_headフックでJSON-LDを出力する方法があります。次は、特定の固定ページにだけOrganizationを出す最小の例です（値はサンプルです）。

add_action('wp_head', function () {
    if (!is_page('about-us')) {
        return; // 対象ページ以外では出さない
    }
    $data = [
        '@context' => 'https://schema.org',
        '@type'    => 'Organization',
        'name'     => '株式会社サンプル',
        'url'      => home_url('/'),
    ];
    echo '<script type="application/ld+json">'
        . wp_json_encode($data, JSON_UNESCAPED_UNICODE | JSON_HEX_TAG)
        . '</script>' . "\n";
});

wp_json_encodeを使うと、引用符や改行のエスケープ漏れでJSONが壊れるのを防げます。JSON_HEX_TAGを付けておくと、値に「</script>」のような文字列が含まれていても、scriptタグが途中で閉じられることを防げます。また、テーマのfunctions.phpはテーマの更新で上書きされるため、子テーマのfunctions.phpか、コードスニペット系のプラグインに書いてください。ただし、SEOプラグインがすでに同じタイプを出していないかを、追加する前に本番HTMLで必ず確認してください。この確認を省くと、後述する当サイトの不具合と同じ重複が起きます。制作工程への組み込み方はWeb制作にSEOを組み込む方法で解説しています。

生成AIで下書きを作る

ChatGPTなどの生成AIにページの内容を渡してJSON-LDの下書きを作らせる方法も広がっています。早く書ける一方で、存在しないプロパティや、FAQPage・HowToのようにGoogle検索では表示が終わったタイプを提案することがあります。次の3ステップで使うと、誤りを持ち込みにくくなります。

1. 種類を選ぶ：Googleの「サポートされる構造化データの一覧」を見て、ページに合うタイプを人が決める（AIに丸投げしない）
2. 生成する：タイプと、ページに実際に書かれている情報だけをAIに渡してJSON-LDを作らせる
3. 照合する：出力をGoogleの各機能のドキュメントの必須・推奨プロパティと突き合わせ、リッチリザルトテストとSchema Markup Validatorに通す

ステップ2のプロンプトは、たとえば次のように書きます。

次の記事ページの情報だけを使って、schema.org の BlogPosting を JSON-LD で書いてください。
- 条件1：ページに書かれていない情報（評価・価格・肩書きなど）は追加しない
- 条件2：Google検索セントラルの「記事（Article）」ドキュメントの推奨プロパティの範囲で書く
- 条件3：日付は ISO 8601 形式（タイムゾーン +09:00 付き）にする
- 条件4：script タグで囲み、そのまま貼り付けられる形で出力する

【ページ情報】
タイトル：（記事タイトル）
公開日：（公開日時）／更新日：（更新日時）
著者：（著者名）／著者ページ：（URL）
アイキャッチ画像：（画像URL）

AIの出力は下書きとして扱い、ステップ3の照合を省かないことが前提です。

当サイトの実装例（AIOSEOとテーマで何を出しているか）

当サイト（scale-basics）はWordPressで運営しており、構造化データはSEOプラグインのAIOSEO（All in One SEO）と自作テーマの2か所から出力しています。2026年10月11日に、この記事の本番HTMLを取得してJSON-LDを確認した結果が次の表です。

出力元	scriptタグ	含まれるタイプ
AIOSEO（SEOプラグイン）	class=”aioseo-schema”のscript 1つ（@graph形式）	BlogPosting／BreadcrumbList／Organization／Person／WebPage／WebSite
テーマ	独立したscript	FAQPage（本文の「よくある質問」の見出しから自動生成）
テーマ（修正前のみ）	独立したscript	BreadcrumbList（AIOSEOと重複していたため、修正後は出力停止）

記事の情報はBlogPosting、著者はPerson、運営者はOrganizationとして、AIOSEOが1つの@graphにまとめて出しています。テーマ側は、AIOSEOが出さないFAQPageを担当する分担です。表の3行目が、次に紹介する不具合の正体でした。

構造化データ マークアップ支援ツール・データハイライターの現状

Googleの構造化データ マークアップ支援ツールは、2026年10月11日時点でも公開されています。ページのURLかHTMLを入力し、記事・イベント・商品・地域のお店・レストラン・Q&Aページなどのタイプを選んで、画面上の文字をマウスでタグ付けするとコードを生成するツールです。ヘルプによると出力形式の既定はJSON-LDで、Microdataも選べます。

データハイライターは、Search Console上でサイトのページをマウスでタグ付けし、構造化データのパターンをGoogleに伝えるツールです。ヘルプページは2026年10月11日時点で公開されており、対象は記事・イベント・地域のお店・レストラン・商品・ソフトウェア・映画・テレビ番組のエピソード・書籍です。ただし、Search Console内のツール本体が現在も使えるかはログインが必要なため確認できていません。また、Googleの構造化データの概要ページは両ツールに触れておらず、JSON-LDの実装と検証ツールでの確認を案内しています。新しく実装するなら、テンプレートかプラグインでJSON-LDを出す方法を基本にするのが無難です。

確認・検証方法

構造化マークアップを確認する方法は、公開前のリッチリザルトテストとSchema Markup Validator、公開後のSearch Consoleの3つです。Googleは開発中はリッチリザルトテスト、公開後はリッチリザルトのステータスレポートで確認するよう案内しています。

ツール	確認できること	向いている場面
リッチリザルトテスト	Google検索のリッチリザルトの対象になるか。URLかコードを入れて検証	公開前・Google向けの判定
Schema Markup Validator	schema.orgの仕様に沿っているか。Googleが使わないタイプも含めて構文と語彙を検証	公開前後・構文の総点検
Search ConsoleのURL検査	Googleがページを取得でき、構造化データを検出しているか	公開直後
Search Consoleのリッチリザルト ステータス レポート（拡張）	サイト全体の有効なアイテム数とエラー・警告の推移	公開後の継続監視

リッチリザルトテスト

リッチリザルトテストは、ページがGoogle検索のリッチリザルトの対象になるかを判定する公式ツールです。URLを入れるか、コードを直接貼り付けて実行し、検出された構造化データの種類と、重大なエラー・警告を確認します。重大なエラーは必ず直します。警告は直すと情報が充実しますが、リッチリザルトの対象になるために必須ではありません。なお、HowToは2023年にリッチリザルトテストの対象から外れています。

本記事の執筆にあたっては、リッチリザルトテストはGoogleアカウントへのログインが必要なため実行しておらず、当サイトの確認は次のSchema Markup Validatorで行いました。

スキーママークアップ検証ツール（旧構造化データテストツールの後継）

かつての「構造化データテストツール」は、Googleが2020年12月に方針を発表し、schema.orgコミュニティ向けのSchema Markup Validatorとして移管されました（Google検索セントラル ブログ）。2021年8月以降、旧ツールのURLはツールを選ぶ案内ページへ転送されます。Schema Markup Validatorはschema.orgへの準拠をチェックするツールで、Googleのリッチリザルトの判定はしません。

当サイトでは2026年10月11日、後述するパンくずとFAQの修正のあとに、この記事のURLをSchema Markup Validatorで検証しました。検証したのはリライト前の旧本文（よくある質問5問）の時点のページです。結果は「2件のアイテムを検出、エラーなし・警告なし」で、内訳はBlogPostingとFAQPageです。BreadcrumbList・Organization・Person・WebPage・WebSiteはBlogPostingと同じ@graphの中にあるため、トップレベルのアイテムとしては2件にまとめて表示されました。

Search Consoleの拡張レポートで監視

公開後は、Search Console（サーチコンソール）の「拡張」にあるリッチリザルトのステータスレポートで、有効なアイテム数とエラー・警告の推移を定期的に確認します。テンプレートやプラグインの更新で、公開後に壊れることがあるためです。個別のページはURL検査で、Googleが構造化データを検出しているかを確かめます。基本操作はサーチコンソールの使い方完全ガイドを参照してください。

なお、Search Consoleの生成AIパフォーマンスレポートは2026年8月に全世界へ展開され、AI OverviewsやAIモードでの表示回数も確認できるようになりました。構造化データを整えたページがAI検索でどう扱われているかを追う手がかりになります。

よくある失敗と注意点

構造化マークアップで最も避けたい失敗は、ページに表示していない内容をマークアップしてガイドライン違反になることです。次に多いのが、「出力の重複」や「値の混入」です。どちらも構文エラーにはならないため、検証ツールでは見落としやすい不具合です。当サイトで実際に見つかった3つの例で解説します。

ページに無い内容をマークアップしない（ガイドラインと手動による対策）

Googleの構造化データに関する一般的なガイドラインは、「ページの読者に表示されないコンテンツをマークアップしない」ことを求めています。守るべき主なルールは次のとおりです。

• JSON-LDに書いた内容は、本文にも書かれていること
• 虚偽のレビューや、ページと関係のない・誤解を招く内容をマークアップしない
• 最も具体的で適切なタイプとプロパティを使う（LocalBusinessよりRestaurantなど）
• 構造化データを載せたページを、robots.txtやnoindexでブロックしない

違反すると、Googleから手動による対策を受けることがあります。その場合リッチリザルトの表示資格を失いますが、ウェブ検索での掲載順位には影響しないとされています。状況はSearch Consoleの「手動による対策」レポートで確認し、修正後に再審査をリクエストします。レビューについては、2026年7月にやらせ・未開示の謝礼レビューを構造化データに含めない規定が明記され、手動による対策の条件も拡大されています。

プラグインとテーマの二重出力（当サイトで発見→修正）

当サイトでは、パンくずリストのBreadcrumbListが、AIOSEOとテーマの2系統から二重に出力されていました。この記事を含む5つのURL（記事2本・カテゴリページ・ニュース記事・固定ページ）を確認したところ、いずれもBreadcrumbListが2つありました。

原因は、テーマ実装時の確認漏れです。過去の保存HTMLとテーマのバックアップをさかのぼると、AIOSEOはテーマ側のパンくず出力関数が作られる前から、@graphの中でBreadcrumbListを出していました。テーマの関数には「AIOSEO等がBreadcrumbListを出していないことを確認済み」というコメントが付いていましたが、この前提は書かれた時点ですでに誤りでした。その後もAIOSEOのバージョンは変わっておらず、プラグインの更新で後から重複したわけではありません。

修正では、AIOSEOが有効なときはテーマ側の出力を止め、AIOSEOに一本化しました。AIOSEOを停止したときの予備として、テーマ側のコード自体は残しています。BreadcrumbListを出力する関数の先頭に追加したのは、次の条件分岐です（コメントは説明用に書き直しています）。

// AIOSEO が有効なら、テーマ側のパンくず構造化データは出さない
if (defined('AIOSEO_VERSION') || function_exists('aioseo')) {
    return;
}

修正後に同じ5つのURLの本番HTMLを確認し、BreadcrumbListがAIOSEOの1つだけになったことを確かめました。教訓は、構造化データを自前で足す前に、プラグインが何を出しているかを本番HTMLで確かめることです。ページのソースで「application/ld+json」を検索し、同じタイプが複数のscriptに出ていないかを見るだけで防げます。

FAQの見出し番号が質問名に混入（当サイトで発見→修正）

もう1つは、テーマが本文の「よくある質問」から自動生成しているFAQPageで、質問名（Question.name）に番号が混ざっていた不具合です。旧版の本記事は見出しを「Q1: 構造化マークアップと構造化データは同じものですか？」の形で書いており、構造化データには「1: 構造化マークアップと構造化データは同じものですか？」と出力されていました。

原因は、質問を取り出す正規表現が見出し先頭の「Q.」の形だけを想定していたことです。「Q1:」の形では「Q」だけが取り除かれ、「1: 」が質問名に残りました。「Q. 」「Q1: 」「Q1．」「Q2：」のどれでも番号ごと取り除くよう、次のように直しています（正規表現の行は実際の修正どおり、コメントは説明用です）。

// 修正前：先頭の「Q」と「.」しか除去しない
preg_match_all('/<h3[^>]*>\s*Q[\.\s]*(.+?)\s*<\/h3>\s*<p>(.+?)<\/p>/is', $faq_section, $matches, PREG_SET_ORDER);

// 修正後：「Q. 」「Q1: 」「Q1．」「Q2：」のいずれも番号ごと除去する
preg_match_all('/<h3[^>]*>\s*Q\s*\d*\s*[\.:：．]?\s*(.+?)\s*<\/h3>\s*<p>(.+?)<\/p>/isu', $faq_section, $matches, PREG_SET_ORDER);

修正後の本番HTMLでは、最初の質問名が「構造化マークアップと構造化データは同じものですか？」と番号なしで出力されていることを確認しました。ページ上の見出しをそのまま構造化データに流用する仕組みは便利ですが、見出しの書き方が変わると意図しない値が入ります。自動生成している場合は、出力されたJSON-LDの値を一度目で見て確かめることをおすすめします。

FAQのリッチリザルトはすでに表示されませんが、当サイトではFAQPageの出力を残すと編集部で判断しています。そのうえで、出す以上は正しい値にする、というのが今回の修正の考え方です。

Organizationの二重出力と名称の不一致（当サイトで発見→修正）

3つ目は、会社概要の固定ページ（/about-us/）で、組織情報のOrganizationがAIOSEOとテーマの両方から出力されていた不具合です。2つは同じ@id（https://scale-basics.com/#organization）を持っているのに、nameが「Scale Basics Blog」と「Scale Basics」で食い違い、ロゴも一致していませんでした。同じ実体に対して矛盾した情報を渡している状態です。

原因はパンくずと同じパターンで、テーマ側のコメントには「既存でOrganizationを出しているプラグインはなし（重複しない）」という、確認漏れの前提が書かれていました。こちらも、AIOSEOが有効なときはテーマ側のOrganization出力を止めて修正し、修正後の本番HTMLでOrganizationが1つになったことを確認しています。@idで同じ実体を指すときは、nameやlogoなどの値も1か所で管理して食い違いを防ぐのが原則です。

よくある質問

Q. 構造化マークアップを確認する方法は？

GoogleのリッチリザルトテストにページのURLかコードを入れて、リッチリザルトの対象になるかとエラーの有無を確認します。schema.orgの文法全体はSchema Markup Validatorで確かめ、公開後はSearch Consoleの「拡張」のレポートとURL検査で監視します。あわせて、ページのソースで「application/ld+json」を検索し、同じタイプが重複していないかも見ておくと安心です。

Q. 構造化データはどこに書けばいいですか？

JSON-LDなら、type属性を「application/ld+json」にしたscriptタグに書き、ページのheadかbodyのどちらかに置きます。その情報が当てはまるページ自身に書くのが原則で、ページに表示されている内容と一致させます。WordPressなどのCMSでは、テンプレートかSEOプラグインから出力するのが一般的です。

Q. 構造化マークアップはすべてのサイトに設定する必要がありますか？

必須ではありません。検索結果への表示そのものに、構造化データは必須ではありません。ただ、ページの意味を正確に伝えられるため、多くのサイトでは入れておく価値があります。何から始めるかはサイトの種類で決めます。ブログ・メディアならArticle（BlogPosting）とBreadcrumbList、企業サイトならトップページのOrganization、店舗ならLocalBusinessの具体的なサブタイプ、ECサイトなら商品ページのProductとBreadcrumbList、採用ページならJobPostingです。WordPressなら、まずSEOプラグインの設定で何が出ているかを確認してから、足りない分を追加します。

Q. 構造化データのデメリットは？

仕様の知識が必要で、実装と保守に工数がかかることです。実装してもリッチリザルトの表示は保証されず、Googleの対応機能も変わります。テーマとプラグインの併用で出力が重複したり、更新で出力が変わったりすることもあるため、公開後も定期的な確認が欠かせません。

Q. 構造化データマークアップ支援ツールとは？

Googleが提供する、マウス操作で構造化データのコードを作れる無料ツールです。ページのURLかHTMLを入れ、記事や商品などのタイプを選んで画面上の文字をタグ付けすると、JSON-LD（既定）またはMicrodataのコードが生成されます。2026年10月11日時点でツールのページは公開されています。

Q. 設定したのにリッチリザルトが出ないのはなぜ？

Googleは、正しくマークアップしても表示を保証していないためです。ほかに、必須プロパティが欠けている、ページに表示していない内容をマークアップしている、ガイドラインに違反している、FAQやHowToのように表示が終わった機能を使っている、といった原因が考えられます。リッチリザルトテストの判定と、Search Consoleの「手動による対策」レポートを確認してください。

まとめ

構造化マークアップは、schema.orgの語彙でページの意味を検索エンジンに伝え、リッチリザルトの表示資格を得るための技術です。順位を直接上げる施策ではなく、AI Overviews向けの特別な構造化データもありません。Googleが推奨するJSON-LDで、ページに見えている事実だけを正確に書くことが基本です。

何を書くかは、その時点のGoogleのドキュメントで判断します。FAQのリッチリザルトは2026年5月7日から表示されなくなり、HowToやサイトリンク検索ボックスも終了しました。記事サイトならArticleとBreadcrumbList、企業ならOrganization、ECならProductと、現在もサポートされているタイプから優先して実装しましょう。

そして、検証ツールに通すだけでなく、本番HTMLに何が出ているかを自分の目で確かめてください。当サイトでは、その確認でBreadcrumbListとOrganizationの二重出力、FAQの番号混入が見つかりました。いずれもテーマ実装時の確認漏れなどが原因で、修正後のSchema Markup Validatorではエラー0・警告0を確認しています（リライト前の旧本文で実行）。まずは自サイトのページのソースで「application/ld+json」を検索するところから始めてみてください。

本記事は2026年10月11日に調査・執筆しました。仕様は同日にGoogle検索セントラルの公式ドキュメント（構造化データ マークアップの概要、構造化データに関する一般的なガイドライン、Google検索がサポートする構造化データの一覧、記事・組織・パンくずリストの各ドキュメント、JavaScriptでの構造化データの生成、AI機能とウェブサイト、ドキュメント更新履歴）と検索セントラル ブログ（2020年12月15日・2023年8月8日・2024年10月21日・2025年6月12日）、Search Consoleヘルプ（構造化データ マークアップ支援ツール、データハイライター）で確認しています。当サイトの実装・不具合・修正・Schema Markup Validatorの結果は、2026年10月11日に本番HTMLを取得して確認した記録です（Schema Markup Validatorはリライト前の旧本文の時点で実行。リッチリザルトテストはログインが必要なため未実行）。WordPressプラグインの設定場所と有料プランの条件は、同日にAIOSEO・Yoast SEO・Rank Mathの英語版公式ドキュメントを開いて確認しました。リライト前の状況として、当サイトのこの記事自体はGoogle Search Consoleで「構造化マークアップ」の検索に対し平均35.7位・表示389回でした（集計期間: 2026年7月12日〜10月9日）。リッチリザルトの表示はGoogleの判断によるもので、実装しても表示が保証されるわけではありません。実装前に最新の公式ドキュメントをご確認ください。

無料ダウンロード資料

はじめてのSEO 完全ガイド

Web担当になった人が、90日で自走するための実務書

検索エンジンの仕組みから、キーワード選定・記事づくり・技術対応・効果測定、 そしてAI検索時代の打ち手まで。専門用語の知識ゼロの状態から読み始められるよう、用語はすべて本文中で説明しています。

体裁	PDF／A4縦・全109ページ
収録	図解21点、チェックリスト120項目、90日実行プラン、用語集56語

※フォーム送信後、ご入力のメールアドレス宛にダウンロードリンクをお送りいたします。

資料の詳細と目次を見る

こちらのフォームにご記入ください

入力は1分ほどで終わります。

Website

会社名必須

部署名任意

お名前必須

メールアドレス必須

電話番号必須

従業員規模必須 選択してください 1〜9名 10〜49名 50〜99名 100〜299名 300〜999名 1,000名以上

SEOの検討状況必須 選択してください 何から始めるべきか検討中 自社で運用しているが成果が出ていない 外部への委託を検討している 現在の委託先を見直したい 情報収集のみ

プライバシーポリシーに同意する必須

資料をダウンロードする

ご入力いただいた情報は、資料のご送付および当社サービスのご案内のために利用します。