Schemaマークアップ：スパムのない構造化データ

有効なJSON-LDがリッチリザルトテストを通っても、リッチリザルトが表示されないことがあります。ツールの問題ではありません。構造化データは、構造化された言語で内容を説明するだけです。コンテンツの代わりにはならず、表示を保証せず、順位を上げるボタンでもありません。

よくある誤りは、「サイトにはどのschema型を追加すべきか」から始めることです。より適切なのは、このページがどのエンティティを扱い、ユーザーが実際に何を見ており、その内容についてGoogleが現在どの表示方法をサポートしているか、という問いです。

構造化データ、Schema.org、schemaマークアップ

構造化データは、機械が読める形式で整理したデータです。Schema.orgは、エンティティの型と属性を記述する語彙です。Schemaマークアップは、その語彙をJSON-LD、Microdata、RDFaでページへ組み込む方法です。

Google Searchは多くの機能で3形式すべてをサポートし、表示用HTMLと分離しやすく保守もしやすいJSON-LDを一般に推奨します。ただし、形式で誤データを救うことはできません。完璧なJSON-LDのProductでも、ページにない価格を宣言すれば一貫性の原則に反します。

Schemaは順位を上げますか？

Schemaを直接の順位向上要因として売り込むべきではありません。構造化データは、システムによるページ理解を助け、一部のリッチリザルトの対象条件を満たせる可能性があります。目立つ表示がCTRに影響する場合はありますが、マークアップが正しくてもGoogleは表示を保証しません。

結果は、次の条件にも左右されます。

• ページがクロール・インデックス登録されるか。
• 内容がSearchのポリシーと各機能の個別ポリシーを満たすか。
• データが正確、十分、最新で、ページに表示されているか。
• クエリ、デバイス、地域、Googleの表示判断。
• 最新ドキュメントで機能が引き続きサポートされているか。

リッチリザルトの一覧は変わるため、古いガイドやプラグインの一覧に頼らず、公式Search Galleryを確認してください。

主要コンテンツに基づいてschema型を選ぶ

関係がありそうなすべての型を、全ページに付けないでください。主要エンティティを特定します。

• ブログやニュース：Article、BlogPosting、または適切な具体的型。
• 購入可能な商品ページ：実際のオファー、価格、在庫状態を伴うProduct。
• 拠点のある事業：LocalBusinessまたは正確なサブタイプ。
• 料理レシピ：Recipe。
• 動画が主要コンテンツ：VideoObject。
• 組織の紹介：Organization。
• 階層の経路：BreadcrumbList。

商品一覧のカテゴリは、自動的に1つのProductになるわけではありません。ノートPCの選び方の記事は、多数の機種に言及するからといって、自分自身を商品として宣言するべきではありません。型は、ページが実際に提供するものを表す必要があります。

JSON文字列ではなく、元データから始める

持続可能なschemaは、ユーザー向け表示と同じデータソースから生成します。

画面ではデータベースの価格を表示し、JSON-LDにはCMSで手入力した数値を入れていると、最初のセール日に食い違います。構造化データは、同じ事実の別表現であるべきで、第2のコンテンツ保管庫ではありません。

最小限のBlogPostingの例

<script type="application/ld+json">
{
  "@context": "https://schema.org",
  "@type": "BlogPosting",
  "@id": "https://example.com/blog/image-seo#article",
  "mainEntityOfPage": {
    "@type": "WebPage",
    "@id": "https://example.com/blog/image-seo"
  },
  "headline": "Image SEO and alt text",
  "image": [
    "https://example.com/images/image-seo-1200x630.png"
  ],
  "datePublished": "2026-06-10T08:00:00+07:00",
  "dateModified": "2026-06-15T09:30:00+07:00",
  "author": {
    "@type": "Person",
    "@id": "https://example.com/authors/alex#person",
    "name": "Alex Nguyen",
    "url": "https://example.com/authors/alex"
  },
  "publisher": {
    "@type": "Organization",
    "@id": "https://example.com/#organization",
    "name": "Example",
    "url": "https://example.com/"
  }
}
</script>

この例は構造を示すだけです。実装時にはArticle専用ドキュメントの必須・推奨属性と照合してください。例の日付、URL、著者を本番へコピーしないでください。

@idでエンティティを安定して結び付ける

@idは、ユーザーが別途開くページである必要はありません。グラフ内の安定した識別子であり、通常、フラグメント付きの絶対URLを使います。

• https://example.com/#organization
• https://example.com/#website
• https://example.com/authors/alex#person
• https://example.com/products/a#product

記事内のpublisherとサイト全体のOrganizationが同じ@idを参照すれば、システムは、無関係で同名の2オブジェクトではなく、1つのエンティティと認識できます。

識別子はレンダリングをまたいで安定させる必要があります。リクエストごとに新しいランダムUUIDを作らないでください。また、組織とWebサイトのように異なる2つのエンティティへ、同じ@idを使わないようにします。

1ページに複数のアイテムを置く

1ページに、複数の有効な構造化データブロックを置くことができます。

• WebPageがページを説明します。
• BlogPostingが記事を説明します。
• BreadcrumbListが経路を説明します。
• OrganizationまたはPersonを発行者や著者として参照します。
• VideoObjectが埋め込まれた主要動画を説明します。

個別オブジェクトにするか、@graphで結べます。重要なのは、関係が正しく矛盾がないことです。動画が無関係な広告にすぎないのに、動画リッチリザルトを狙ってVideoObjectを追加するのは不適切です。

すべてのノードに長いOrganization全体を繰り返す必要はありません。正規のエンティティを1つ宣言し、@idで参照すれば、グラフを簡潔にできます。

必須属性と推奨属性

各機能のドキュメントは、属性を必須と推奨に分けています。必須が欠けると対象条件を満たしません。推奨は結果を充実させますが、実データがある場合にだけ宣言するべきです。

良い原則は、少なくても正確で十分であることです。次を追加しないでください。

• 実際の評価がないaggregateRating。
• 警告を消すために架空の値を入れたpriceValidUntil。
• プロフィールや編集責任がないのに、著者を「Admin」とすること。
• 無関係な内容の画像に汎用ロゴを使うこと。
• エンティティが所有しないプロフィールへのsameAsリンク。

テストの警告は、偽データを埋める命令ではありません。推奨属性が不足していると伝えているだけです。信頼できる情報源を使って追加できるかは、プロダクトチームが判断します。

マークアップの内容は表示され、一致している必要があります

Googleは、構造化データが主要コンテンツを正確に表し、読者に隠した情報を記述しないことを求めます。次のような例は危険です。

• JSON-LDでは$99なのに、ページは「お問い合わせ」と表示します。
• 購入できないのに、schemaはInStockとします。
• 表示していない5件の5つ星レビューを宣言します。
• FAQの回答がJSON-LDにしかありません。
• 期限切れ求人が未来のvalidThroughを保持しています。

「表示される」とは、すべての技術属性を生の文章にすることではありません。URL、ID、グラフの関係はメタデータで構いません。ただし、価格、評価、イベント、質問、著者といった、ユーザーに重要な主張は体験と対応する必要があります。

Product schema：データの不整合が最も早く現れる領域

価格と在庫は常に変化します。Productのマークアップは、画面と同じリクエストやパイプラインで生成する必要があります。次を統一してください。

• 適切なISO通貨。
• データ欄では、記号や解析しにくい書式を使わない価格数値。
• 正確なschema.orgのURLを使う在庫状態。
• 正しいバリエーションに属するオファー。
• バリエーションのcanonicalとProduct IDの一貫性。
• その商品自体の正当なレビューだけを集計する評価。

複数バリエーションの商品では、価格、色、SKUを任意に1オブジェクトへまとめず、商品バリエーションのドキュメントを読んでください。購入できない、または実際のオファーがないページに、エラーを消すためだけの偽オファーを作らないでください。

LocalBusiness：空のテンプレートで拠点を複製しない

各拠点には、実際の名称、住所、電話番号、営業時間、サービス地域、URLが必要です。支店ページにも、対応する有用な内容を用意する必要があります。同じ200の都市URLを作ってLocalBusinessを加えても、200の拠点にはなりません。

Schemaの情報は、問い合わせページ、ビジネスプロフィール、内部管理データと一致させるべきです。祝日の営業時間を変えたら、画面とJSON-LDの情報源の両方を更新します。

レビューと評価はスパムになりやすい領域です

次はマークアップしないでください。

• 事業者自身が書いたレビュー。
• 別の商品から流用した評価。
• 元レビューのない集計スコア。
• 全サービスの評価として使う、会社全般へのお客様の声。
• スクリプト内だけにある非表示データ。

品質違反によって、リッチリザルト表示の資格を失ったり、構造化データに関する手動による対策を受けたりする可能性があります。それがWeb全体の順位の自動的な消失を意味するわけではありませんが、星を数個得るために負う価値のあるリスクではありません。

FAQ schemaを全記事の標準にするべきではありません

本文のFAQは読者に役立ちますが、プラグインにチェック欄があるだけでマークアップを加えるべきではありません。各リッチリザルトの表示可能性と条件は、時期、分野、ポリシーで変わります。大規模に有効化する前に、次を確認してください。

1. 型がSearch Galleryに残っており、サイトに適用されるか確認します。
2. 機能専用ガイドラインをすべて読みます。
3. すべての質問と回答がページにあることを確認します。
4. 同一のFAQを数千URLで繰り返すのは避けます。
5. 「有効」を成功とみなさず、成果を測定します。

Schemaが編集構成を決めるべきではありません。内容にFAQが必要ならFAQを書き、その後で有効なマークアップを検討します。

3つの層でテストする

第1層：JSONとschemaの構文

パーサーがJSON-LDを読めるよう、カンマ、括弧、エスケープ、データ型を正確にします。商品名の引用符をエスケープしないだけで、ブロック全体が壊れる可能性があります。

第2層：Rich Results Test

このツールはGoogleがサポートする型を検査し、エラーと警告を表示します。エラーは修正し、警告は実データに応じて判断します。「有効」は、その時点で技術的な条件を満たすだけで、表示を保証しません。

第3層：本番ページとSearch Console

デプロイ済みURLをURL Inspectionで確認し、実際のHTMLを見て、リッチリザルトのレポートを監視します。ステージングのテストだけでは、キャッシュ、ロケール、機能フラグ、同意、本当の商品データの問題を検出できません。

SEO Checkerでページのシグナルを抽出確認し、無料SEO監査でメタデータやcanonicalの異常パターンを探してから、schemaを原因と判断してください。

不完全なデータと問題を起こす入力をテストする

テンプレートは、情報がそろったサンプル商品では正常でも、境界例で壊れがちです。

• 画像がありません。
• 価格が0、または未公開です。
• 通貨が2種類あります。
• 名前に引用符や改行が含まれます。
• 著者がいません。
• 移行によって更新日が公開日より前です。
• レビュー件数が0です。
• 商品が販売終了しています。
• 英語ページに、意図しないベトナム語の組織名が入ります。

これらのケースのフィクスチャを作成します。JSONを解析できること、絶対URLが正しいロケールを使うこと、対象条件を満たす場合にだけ必須属性が現れること、中核データがなければオブジェクトを省略することを検証してください。

よくある実装上の問題

2つのプラグインが同時にschemaを生成する

テーマがArticle、SEOプラグインがBlogPosting、レビュープラグインが別IDのProductを作る場合です。著者、画像、評価が矛盾する複数オブジェクトが生まれます。すべてのapplication/ld+jsonスクリプトを棚卸しし、各エンティティの所有元を1つ決めてください。

SchemaにステージングURLが入る

環境変数やキャッシュのため、@id、画像、canonicalがテスト用ドメインを指す場合があります。本番HTML内のすべての意図しないホスト名を検索してテストしてください。

ロケールのデータが混ざる

英語ページの見出しは英語でも、パンくずや組織名が誤ってベトナム語版から取得される場合です。共通部分と現地化部分を定義し、使う場合はinLanguageを確認してください。

JavaScriptによるマークアップ挿入が遅すぎる

GoogleはJavaScriptをレンダリングできますが、失敗や遮断のあるクライアントリクエストに依存すると、データが不安定になります。サーバーにすでにデータがあるなら、最初のHTMLにJSON-LDを出力する方が、通常は簡単で信頼できます。

弱いコンテンツをschemaで隠す

詳細なマークアップでも、情報不足の商品ページやコピー記事は補えません。構造化データは内容を説明するものであり、ページにない価値を作るものではありません。

デプロイ後に監視する

Schemaを契約としてリリース手順へ組み込みます。

• フィクスチャを使って生成処理を単体テストします。
• 主要テンプレートにスナップショットやschema検証を行います。
• ステージングと本番をクロールし、アイテム数とエラー数を数えます。
• マークアップのあるページ率が急減したら警告します。
• 拡張レポートと手動による対策を監視します。
• CTR、表示回数、エラーを比較できるよう、変更日を記録します。

Googleがあるリッチリザルトのサポートを変えても、慌てて有用なschema.orgをすべて削除する必要はありません。エンティティ理解を助けるマークアップと、特定の検索機能だけのためのものを区別してください。維持費と利点を評価してから、残すか外すかを決めます。

公開前チェックリスト

• Schema型は主要コンテンツを正しく表していますか？
• 最新ドキュメントでGoogleが引き続き機能をサポートしていますか？
• 実データから必須属性を十分に取得していますか？
• 重要な主張はユーザーに表示されていますか？
• URL、画像、@idは絶対指定で、クロール可能で、正しいドメインですか？
• CanonicalとmainEntityOfPageは同じ戦略的URLですか？
• 日付、価格、在庫、評価は自動更新されますか？
• 他プラグインによる重複オブジェクトはありませんか？
• Rich Results Testに通りましたか？
• データ不足でJSONが壊れませんか？
• 本番とSearch Consoleを確認しましたか？

まとめ

良いschemaマークアップは、表示中の内容を正直に構造化して説明します。JSON-LDのコピーではなく、データモデルと情報源の所有権から始まります。正しい型を選び、安定したIDを使い、実在する属性を十分に宣言し、境界例もテストし、デプロイ後に監視してください。

警告を消すために評価を捏造せず、非表示の内容をマークアップせず、リッチリザルトを確実な成果として約束しないでください。ページと構造化データが同じ事実を情報源とすれば、schemaは壊れやすい装飾ではなく、保守しやすい技術要素になります。

参考資料：Google Search Centralの構造化データ入門、一般的なガイドライン、Schema.org。