CreaTools LogoCreaTools
Tech Notes
Tips

構造化データ（JSON-LD）の書き方ガイド｜リッチリザルトが出る条件と出ない理由

2026-07-07

結論：構造化データは「ページの内容を機械が読める形で渡すラベル」

構造化データがやることは1つ。「このページは記事で、タイトルはこれで、書いたのはこの人」という情報を、検索エンジンが誤読しない形式で渡すだけ。

人間はページを見れば「これはレシピだ」「これはQ&Aだ」とわかる。Google もかなり理解するが、確実ではない。そこを補うのが構造化データ。

効果をはっきりさせておく。

  • やってくれること … 検索結果の見た目を強化する「リッチリザルト」の候補になる（星評価、FAQの展開、パンくず表示など）
  • やってくれないこと … 順位を直接上げること。構造化データはランキング要因ではない

つまり sitemap.xml と同じで「置けば順位が上がる」ものではない。ただしリッチリザルトが出れば検索結果で目立ち、クリック率が変わる。狙う価値は十分ある。

書き方は JSON-LD 一択でいい

構造化データの書き方は3種類あるが、選択肢は実質1つ。

形式書く場所現状
JSON-LD<script> タグ内にJSONで独立して書くGoogle 推奨。これを使う
microdataHTMLタグに属性を散りばめる既存HTMLに絡んで保守がつらい
RDFaHTMLタグに属性を散りばめる同上。新規で選ぶ理由がない

JSON-LD の強みはHTMLの構造と完全に分離できること。デザインを変更しても構造化データが壊れない。

最小構成はこれだけ

<head> か <body> のどこかに <script type="application/ld+json"> を置く。記事ページの例：

<script type="application/ld+json">
{
  "@context": "https://schema.org",
  "@type": "Article",
  "headline": "構造化データの書き方ガイド",
  "datePublished": "2026-07-07",
  "dateModified": "2026-07-07",
  "author": {
    "@type": "Person",
    "name": "山田太郎"
  }
}
</script>

押さえるのは3つだけ。

  • @context … https://schema.org 固定。語彙の定義元
  • @type … このデータが何か（Article、FAQPage、Product など）
  • 残り … タイプごとのプロパティ。何が使えるかは schema.org に全部載っている

中身はただのJSON。 カンマの付け忘れや閉じ括弧のミスが一番多い事故なので、書いたら JSON Formatter に貼って構文チェックしてから埋め込むと確実。

よく使うタイプ5つ

schema.org には800以上のタイプがあるが、実際に使うのはごく一部。リッチリザルトにつながるものから優先する。

タイプ用途リッチリザルトでの見え方
Article / BlogPostingブログ・記事見出し・日付・画像の強化表示
BreadcrumbListパンくずリストURLの代わりに階層を表示
FAQPageよくある質問検索結果でQ&Aが展開表示
Product商品ページ星評価・価格・在庫を表示
Organization / WebSiteサイト全体の情報ロゴ・サイト名の認識

FAQPage の例

検索結果での面積が大きく、効果を実感しやすいのが FAQ。

<script type="application/ld+json">
{
  "@context": "https://schema.org",
  "@type": "FAQPage",
  "mainEntity": [
    {
      "@type": "Question",
      "name": "構造化データを入れると順位は上がりますか？",
      "acceptedAnswer": {
        "@type": "Answer",
        "text": "いいえ。ランキング要因ではありません。リッチリザルトの候補になるだけです。"
      }
    },
    {
      "@type": "Question",
      "name": "JSON-LDはheadとbodyどちらに書くべきですか？",
      "acceptedAnswer": {
        "@type": "Answer",
        "text": "どちらでも認識されます。管理しやすい場所で構いません。"
      }
    }
  ]
}
</script>

ページに実際に表示されているQ&Aだけを書くこと。 ページにない内容を構造化データにだけ書くのはガイドライン違反で、手動対策（ペナルティ）の対象になる。

Next.js / WordPress での入れ方

Next.js（App Router）

コンポーネント内で <script> を出力するだけ。

export default function ArticlePage() {
  const jsonLd = {
    "@context": "https://schema.org",
    "@type": "Article",
    headline: "記事タイトル",
    datePublished: "2026-07-07",
  };

  return (
    <>
      <script
        type="application/ld+json"
        dangerouslySetInnerHTML={{ __html: JSON.stringify(jsonLd) }}
      />
      <article>...</article>
    </>
  );
}

記事データから動的に生成すれば、ページを増やすたびに手で書く必要はない。

WordPress

Yoast SEO / All in One SEO などの主要プラグインが Article や BreadcrumbList を自動出力している。まず今のページのソースで application/ld+json を検索して、すでに出ているか確認してから足すこと。同じタイプを二重に出すと矛盾のもと。

テスト方法：書いたら必ず検証する

構造化データは書き間違えても見た目に一切影響がないので、壊れていても気づけない。検証までがセット。

ツール用途
リッチリザルトテストGoogle がリッチリザルト対象として認識するかを確認
Schema Markup Validatorschema.org の文法として正しいかを確認
Search Console の「拡張」レポートサイト全体でのエラー・警告を継続監視

見るべきはリッチリザルトテスト。「有効なアイテムが検出されました」と出れば合格。 エラーは必須プロパティの欠落、警告は推奨プロパティの欠落を意味する。警告は残っていてもリッチリザルトは出る。

なお、title や meta description、OGP などページ側のメタ情報とセットで確認したい場合は Meta Checker でまとめて見られる。

リッチリザルトが出ない典型パターン

パターン1：JSONの構文エラー

一番多い。カンマ抜け・閉じ括弧不足・コメント混入。構文が壊れているとその <script> ブロックは丸ごと無視される。 エラーも出ない。だから気づかない。

パターン2：ページの内容と一致していない

ページに存在しないレビューや価格を構造化データにだけ書くパターン。認識されないだけでなく、悪質と判断されると手動対策の対象。 構造化データは「ページにあるものの説明」であって、盛る場所ではない。

パターン3：正しいのに出ない

実はこれが正常。構造化データが有効でも、リッチリザルトを出すかどうかは Google が決める。 サイトの信頼性やクエリとの関連性で判断されるため、「テストは合格したのに検索結果に出ない」は仕様の範囲内。数週間〜数ヶ月かかることも普通にある。

パターン4：そもそもインデックスされていない

リッチリザルト以前に、ページが Google に登録されていなければ何も始まらない。インデックスの土台は sitemap.xml と robots.txt の設定を先に確認する。

まとめ

  • 構造化データは「ページ内容を機械可読にするラベル」。順位を直接上げるものではなく、リッチリザルトの候補になる
  • 書き方は JSON-LD 一択。@context と @type を押さえれば中身はただのJSON
  • 優先するのは Article・BreadcrumbList・FAQPage・Product・Organization
  • ページに表示されていない内容を書くのはガイドライン違反。盛らない
  • 構文エラーはブロックごと無視されて気づけない。リッチリザルトテストでの検証までがセット
  • 「有効なのに出ない」は仕様。出すかどうかの最終判断は Google がする