実践的な構造化データガイド

実践的なSEOのためのJSON-LDスキーママークアップガイド

JSON-LDは検索エンジンにページ内容、発行者、サイト内の位置、利用価値のある事実を理解させます。

有用な目的はすべてのスキーマタイプを追加することではなく、表示内容に合致し、正しく検証でき、コンテンツ変更時に同期する正確な構造化データを作ることです。

便利なショートバージョン

タイトル、説明、著者、公開日、パンくず、商品詳細、動画データ、明確なQ&Aなど、正直で見える事実を記述できる場合にJSON-LDを使いましょう。Googleが表示しなくなった機能やユーザーが見られない内容のマークアップは避けてください。

最適なスキーマ選択 ほとんどのガイドページにArticle、WebPage、BreadcrumbListを使用。
最適なワークフロー タイトル、説明、正規URL、Open Graphを生成する同じページメタデータからスキーマを生成します。
最良の現実確認 FAQPageやWebSiteマークアップは内容を記述できますが、廃止されたGoogle表示に依存した戦略は避けてください。

JSON-LDの実際の役割

JSON-LDは機械可読の構造化データで、通常headやbodyのscriptタグ内にあり、schema.orgの語彙でエンティティを記述します。検索エンジンは表示内容の理解補助に使います。

パーサーの明確さ

意味

ページの事実をArticle、author、datePublished、BreadcrumbList、SoftwareApplicationなどの名前付きエンティティとプロパティに変換します。

検索機能

適格性

対応するリッチリザルトの対象にはなりますが、表示内容はGoogleが品質、ポリシー、検索クエリ、機能の可用性に基づき決定します。

サイトグラフ

一貫性

CMSやBlazorアプリに、正規URL、言語、タイトル、日付、画像、発行者データを一元管理できる構造化場所を提供します。

近道ではない

制限

弱いコンテンツ、偽レビュー、隠されたFAQ回答、古い日付、構造化データと一致しないページは修正しません。

重要: 構造化データはページを補助するものであり、有用なコンテンツの代わりではありません。表示内容が薄い、混乱している、古い、誤解を招く場合、スキーママークアップは強力な検索結果にはなりません。

ページの役割に応じてスキーマを選ぶ

スパム的または重複した構造化データを避ける最も簡単な方法は、ページの目的を明確にし、その役割を正確に表す最小限のスキーマセットを追加することです。

コンテンツ

Article / BlogPosting

利用用途
ガイド、チュートリアル、レビュー、ニュース風投稿、長文解説。
追加するタイミング
ページには明確な見出し、著者または発行者、公開日、更新日、正規URL、画像があります。
避けるべき場合
ページは主にツールのUI、商品一覧、カテゴリーページ、または薄いランディングページです。

ナビゲーション

BreadcrumbList

利用用途
ホームページ以下のほぼすべてのページ。
追加するタイミング
ユーザーはページがサイト階層のどこにあるか理解できます。
避けるべき場合
パンくずリストのパスが内部リンク、正規URL、表示ナビゲーションと一致しません。

サイトの識別情報

WebPage / WebSite / Organization

利用用途
ホームページ、ハブ、会社概要ページ、発行者情報が重要なページ。
追加するタイミング
ページ、サイト、発行者、言語をつなぐ安定したエンティティグラフが必要です。
避けるべき場合
古いサイトリンク検索ボックス表示を狙ってWebSiteマークアップを追加しています。

商品またはアプリ

Product / SoftwareApplication

利用用途
ツール、アプリ、SaaSページ、拡張機能、ダウンロード可能なソフトウェア、実際の商品ページ。
追加するタイミング
マークアップ時は、名前、説明、OSやカテゴリ、価格、オファー、評価がページ上で見える必要があります。
避けるべき場合
評価、価格、在庫状況、レビューがページ上でユーザーに見えません。

質問

FAQPage

利用用途
ユーザーがトピックを理解するのに役立つ見える質問と回答のセクション。
追加するタイミング
GoogleがFAQリッチリザルトを表示しなくても、Q&Aコンテンツはページ上で有用です。
避けるべき場合
検索スペースを埋めるためや多くのページで同じ回答を繰り返すために一般的なQ&Aを追加しています。

メディア

VideoObject / ImageObject

利用用途
重要な埋め込み動画、チュートリアル動画、クロール可能な画像資産を含むページ。
追加するタイミング
メディアはページの中心であり、タイトル、説明、サムネイル、アップロード日、安定したURLを持っています。
避けるべき場合
メディアは装飾的、非表示、ブロックされている、またはページの主目的に関連しません。

ミスを防ぐ実装チェックリスト

良いJSON-LDは地味ですが、信頼できるフィールドから一貫して生成され、検証が簡単で、ページ変更時に忘れにくいものです。

01

メインのページエンティティを1つ選ぶ

ページが主に記事、商品、アプリ、動画、FAQ、コレクション、一般的なウェブページのどれかを判断し、二次スキーマは主エンティティを補完します。

02

表示内容と一致させる

マークアップされた情報はすべてページ上で見えるか明確に推測できる必要があります:タイトル、著者、日付、価格、評価、Q&A、パンくずリスト、画像。

03

安定した@id値を使う

重要なエンティティには、正規URLに#article、#webpage、#organization、#faqなどの安定したIDを付けて、パーサーがグラフをつなげやすくします。

04

共通メタデータから生成

タイトルタグ、メタディスクリプション、正規URL、Open Graph画像、言語タグ、最終更新日を生成する同じソースフィールドを再利用します。

05

日付は正確に保つ

意味のあるコンテンツ変更があった場合のみdateModifiedを変更し、検索結果で新しく見せるためだけの自動更新は避けてください。

06

画像をクロール可能にする

絶対URLの画像、適切なサイズ、ロボット制御、認証、遅延読み込みのみでブロックされないファイルを使用してください。

07

早期レンダリング

Blazorや他のJavaScriptアプリでは、プリレンダリングまたはサーバーレンダリングされたJSON-LDを使い、クローラーが初期HTMLで見られるようにしましょう。

08

検証と監視

公開前にリッチリザルトテストを実行し、スキーママークアップバリデーターで構文を確認し、インデックス後はSearch Consoleを監視しましょう。

Blazorページ向けのシンプルなJSON-LDパターン

Blazorでは、初期化やプリレンダリング時にページメタデータからスキーマを作成し、一度シリアライズして、クローラーが初期HTMLで見られる場所にapplication/ld+jsonスクリプトを出力するのが安全です。

HTMLArticleのJSON-LD例
<script type="application/ld+json">
{
  "@context": "https://schema.org",
  "@type": "Article",
  "@id": "https://example.com/en/json-ld-schema-guide/#article",
  "headline": "JSON-LD Schema Markup Guide for Practical SEO",
  "description": "A practical guide to choosing, generating, and validating structured data.",
  "image": "https://example.com/images/json-ld-guide.png",
  "datePublished": "2026-03-28T10:00:00+00:00",
  "dateModified": "2026-05-31T10:00:00+00:00",
  "author": {
    "@type": "Organization",
    "name": "Example Publisher"
  },
  "publisher": {
    "@type": "Organization",
    "name": "Example Publisher",
    "logo": {
      "@type": "ImageObject",
      "url": "https://example.com/logo.png"
    }
  },
  "mainEntityOfPage": {
    "@type": "WebPage",
    "@id": "https://example.com/en/json-ld-schema-guide/"
  }
}
</script>
C#C#ヘルパーパターン
private MarkupString BuildJsonLd(PageMetaData meta)
{
    var pageUrl = BuildPageUrl(meta);

    var schema = new Dictionary<string, object?>
    {
        ["@context"] = "https://schema.org",
        ["@type"] = "Article",
        ["@id"] = $"{pageUrl}#article",
        ["headline"] = meta.Title,
        ["description"] = meta.Description,
        ["url"] = pageUrl,
        ["datePublished"] = meta.Published?.ToString("O"),
        ["dateModified"] = meta.Modified?.ToString("O"),
        ["inLanguage"] = CS.Culture
    };

    var json = JsonSerializer.Serialize(schema, new JsonSerializerOptions
    {
        DefaultIgnoreCondition = JsonIgnoreCondition.WhenWritingNull
    });

    return new MarkupString($"<script type=\"application/ld+json\">{json}</script>");
}
実践的ルール: urlと@idには安定したURLを使い、すべて同じ正規URLにします。同じページが複数言語URLにある場合は言語別メタデータを生成し、hreflang/正規設定を一貫させてください。

JSON-LDを使う前に検証する

検証には2つの役割があります。スキーママークアップバリデーターは語彙とJSON-LD構文の理解可能性をチェックし、Googleのリッチリザルトテストはページが対応リッチリザルトの対象かを判定します。

Googleの適格性

リッチリザルトテスト

Googleがページを読み取れるか、検出された構造化データがリッチリザルトの対象かを確認します。

リッチリザルトテストを開く

信頼を損なう一般的なJSON-LDの誤り

多くのスキーマ問題は複雑な技術的バグではなく、マークアップ内容とユーザーやクローラーがページで確認できる内容の不一致です。

隠れたまたは欠落したコンテンツのマークアップ

ユーザーが回答、レビュー、オファー、画像、著者情報を見られない場合は構造化データに含めないでください。信頼を失う最速の方法です。

すべてにFAQPageを追加すること

FAQスキーマは見えるQ&Aを記述できますが、すべての記事にコピペするのは避け、Q&Aがページを改善する場合のみ使いましょう。

競合する重複スクリプト

異なる見出し、日付、URLの複数のArticleブロックはページの解釈を難しくします。1つの明確なグラフが3つの部分的なものより優れています。

誤った正規URLまたは@id

スキーマのURLは正規ページ、文化圏URL、hreflang設定と一致させてください。言語混在URLは重複コンテンツやエンティティの混乱を招きます。

偽の新鮮さ

テンプレート編集や追跡変更、スキーマのみの更新でdateModifiedを更新しないでください。実際のコンテンツ変更時に使用します。

クライアントのみの遅延レンダリング

JSON-LDが遅延したクライアントレンダリング後にのみ表示されると、クローラーが見逃す可能性があります。重要なページはサーバーレンダリングやプリレンダリングを推奨します。

ページタイプ別の実用的スキーマ例

巨大なグラフはほとんど必要ありません。これらの組み合わせは、小規模サイト、ブログ、ツール、レビューサイトの多くのページをカバーします。

ガイド記事

Article + BreadcrumbList + WebPage

  • 見出し、著者、発行者、画像、日付、セクション名にはArticleを使います。
  • 表示されるサイトパスにはBreadcrumbListを使います。
  • WebPageや@id参照を使い、ページと記事エンティティをつなげます。

ツールページ

SoftwareApplication + WebPage + BreadcrumbList

  • 実際のアプリやツールのページの場合のみSoftwareApplicationを使います。
  • OS、カテゴリ、価格、オファーの詳細は表示されている場合のみ含めてください。
  • 実際のレビューが表示されていない限り、レビューや評価のマークアップは避けてください。

レビューページ

ページが対応している場合のみレビュー/商品をマークアップ

  • レビュー対象、著者、日付、評価はページに明確に表示されている場合のみマークアップしてください。
  • アフィリエイトリンクや商用情報は透明性を保ちましょう。
  • スキーマと表示内容で同じスコアを使う

質問ページ

FAQPageは有用な見えるQ&Aのみで使用

  • 各回答はキーワードのバリエーションだけでなく、それ自体で役立つ内容にしましょう。
  • クローラーがアクセスできないブロックされたUIの背後に回答を隠さないでください。
  • FAQのリッチリザルトを主なSEO効果と期待しないでください。

参照元確認済み

上記の指針はGoogle Search Centralとschema.orgの公式ドキュメントに基づき、実践的なJSON-LDチェックリストにまとめたものです。

01 Google構造化データの概要 developers.google.com 02 Google構造化データのポリシー developers.google.com 03 GoogleのArticle構造化データ developers.google.com 04 GoogleのBreadcrumb構造化データ developers.google.com 05 GoogleのFAQ構造化データ developers.google.com 06 Googleサイトリンク検索ボックスの更新 developers.google.com 07 Schema.orgの始め方 schema.org 08 Googleリッチリザルトテスト search.google.com 09 スキーママークアップバリデーター validator.schema.org

よくある質問

JSON-LDスキーママークアップはランキング要因ですか?

JSON-LD自体は魔法のランキングスイッチではありません。適格なコンテンツ理解とリッチリザルトの対象化を助けますが、ランキングは品質、関連性、クロール可能性、リンクなど多くの要因に依存します。

JSON-LDはページのどこに置くべき?

head内のscriptタグが管理しやすいですが、Googleはbody内のJSON-LDも読み取れます。重要なのは、マークアップがレンダリングされたページに存在し、表示内容と一致していることです。

FAQPageスキーマはまだ使うべき?

FAQPageは本当に有用な見える質問と回答がある場合のみ使い、Googleの追加表示スペースを期待して多用しないでください。多くの通常サイトでFAQリッチリザルトは大幅に縮小・廃止されています。

1ページに複数のJSON-LDブロックを設置できますか?

はい。通常の記事ページはArticle、BreadcrumbList、WebPageデータを持てます。ブロックは一貫させ、重複や矛盾するエンティティを避け、安定した@idで関連部分をつなぎましょう。

JSON-LDはMicrodataより優れていますか?

ほとんどの最新サイトではJSON-LDが推奨されます。GoogleはJSON-LD、Microdata、RDFaをサポートしますが、JSON-LDはHTMLテンプレート内に属性を入れずに済むため管理が容易です。

構造化データはどのくらいの頻度で検証すべきですか?

テンプレート、メタデータ、スキーマヘルパー、URL、言語ルーティング、画像生成、レビュー、FAQを変更したら必ず検証し、重要ページのインデックス後はSearch Consoleも確認してください。