構造化データ（JSON-LD）：コピーして使える2つの例とテスト方法

SEOgrinder 編集部 · 公開日 2026年11月4日 · 読了時間約15分

結論： 構造化データとは、ページの内容を検索エンジンに伝えるための記述です。Google が勧める形式が JSON-LD で、<script type="application/ld+json"> タグの中に置く JSON のブロックです。下の2つの例のどちらかをコピーし、example.com の値を、ページ上で見える事実に置き換えて、Google の Rich Results Test（リッチリザルトテスト）で結果を確認してください。正しいコードは、ページをリッチリザルトの対象にしますが、表示されることを Google は保証していません。

構造化データとは何か、Google は JSON-LD をどう扱うか

Google は、構造化データを “a standardized format for providing information about a page and classifying the page content”（ページに関する情報を提供し、ページのコンテンツを分類するための標準化された形式）と定義しています（Google）。語彙の大半は schema.org に由来します。JSON-LD は、それを書き表す3つの方法の1つです。ほかの2つ、Microdata と RDFa は、目に見える HTML に属性を足します。JSON-LD は、別の1つのブロックにまとめて置くので、レイアウトに触れずに追加も修正もできます。

マークアップが有効で、正しく実装されていれば、3つの形式のどれでも問題ない、と Google は述べています。それでも、環境が許すなら JSON-LD を勧めています。JSON-LD は “the easiest solution for website owners to implement and maintain at scale”（サイト運営者が導入し、大規模に維持するのにもっとも簡単な方法）だからです（Google）。

得られるものは、次のとおりです。構造化データは “can enable search results that are more engaging to users”（ユーザーにとってより魅力的な検索結果を可能にしうる）と Google は書き、それをリッチリザルトと呼んでいます。対応している機能は、サポートされている機能のギャラリーにまとまっていて、Article、Breadcrumb、Event、Organization、Product、Recipe などがあります。Google の導入ページには、もう1点あります。検索の動作については、schema.org ではなく Google 自身のドキュメントを頼りにしてください。schema.org には、Google 検索が必要とするより多くの属性とオブジェクトがあります。

コードを書く前に、Google の構造化データの一般的なガイドラインにある3つのルールが当てはまります。

マークアップを置くページについて、そしてそこで訪問者に見えることだけを、記述します。
構造化データのあるページを、robots.txt や noindex などで Googlebot からブロックしないでください。
使う種類の必須プロパティを、すべて埋めてください。1つでも欠けているアイテムは “are not eligible for rich results”（リッチリザルトの対象になりません）。

例1：トップページ用の Organization

Google は、Organization のマークアップを、トップページか、組織を説明する1ページ、たとえば「会社概要」のページに置くよう勧めています。すべてのページに置く必要はありません（Google）。この種類には必須プロパティがなく、Google は、当てはまる推奨プロパティを加えるよう勧めています。値はすべて置き換えてください。

<script type="application/ld+json">
{
  "@context": "https://schema.org",
  "@type": "Organization",
  "name": "サンプル自転車工房",
  "url": "https://www.example.com/",
  "logo": "https://www.example.com/images/logo.png",
  "description": "サンプル自転車工房は、体に合わせたオーダーメイドの自転車を製作しています。",
  "email": "contact@example.com"
}
</script>

Google のページによる、各プロパティの役割は次のとおりです。

name：サイト名として使っているのと同じ名前を使います。
url：Web サイトのアドレスです。Google が組織を一意に特定する助けになります。
logo：112 × 112 px 以上で、クロールとインデックスが可能なものです。検索結果やナレッジパネルにどのロゴを出すかを、Google が決める助けになりえます。
description と email：任意の情報です。address、contactPoint、sameAs（他のサイトにあるプロフィールページ）は、自分に当てはまる場合にだけ加えます。

より具体的なサブタイプが合うなら、Google はそちらを勧めています。たとえば、ショップなら OnlineStore、飲食店なら LocalBusiness のサブタイプです。

例2：ブログ記事用の Article とパンくずリスト

1ページに複数のアイテムがあっても、入れ子にしても別々に並べても、Google は理解します（Google）。この例は、2つのアイテムを JSON の配列に別々に並べ、それぞれに @context を付けています。Google が個別のアイテムについて示している形です。

<script type="application/ld+json">
[
  {
    "@context": "https://schema.org",
    "@type": "BlogPosting",
    "headline": "自転車用ヘルメットの選び方",
    "image": [
      "https://www.example.com/photos/helmet-16x9.jpg",
      "https://www.example.com/photos/helmet-4x3.jpg",
      "https://www.example.com/photos/helmet-1x1.jpg"
    ],
    "datePublished": "2026-10-12T08:00:00+02:00",
    "dateModified": "2026-11-04T09:20:00+01:00",
    "author": [
      {
        "@type": "Person",
        "name": "山田 花子",
        "url": "https://www.example.com/team/hanako-yamada"
      }
    ]
  },
  {
    "@context": "https://schema.org",
    "@type": "BreadcrumbList",
    "itemListElement": [
      { "@type": "ListItem", "position": 1, "name": "ブログ", "item": "https://www.example.com/blog" },
      { "@type": "ListItem", "position": 2, "name": "サイクリング", "item": "https://www.example.com/blog/cycling" },
      { "@type": "ListItem", "position": 3, "name": "自転車用ヘルメットの選び方" }
    ]
  }
]
</script>

Article。 Google は Article、NewsArticle、BlogPosting を受け付けます。必須プロパティは挙げておらず、author、datePublished、dateModified、headline、image を勧めています。Google が “show better title text, images, and date information”（より良いタイトルテキスト、画像、日付の情報を表示する）助けになるからです（Google）。日付は、タイムゾーンつきの ISO 8601 で書きます。タイムゾーンがなければ、Google は Googlebot のタイムゾーンを使います。著者は、種類、名前、URL を持つ別々のエントリとして並べます。見出しは短くしてください。“long titles may be truncated on some devices”（長いタイトルは、端末によっては切り詰められることがあります）。画像については、記事に関係のある高解像度のファイルを、16x9、4x3、1x1 の比率で複数用意するよう、Google は勧めています。ロゴではありません。

パンくずリスト。 ここでは、ルールが厳格です。BreadcrumbList には ListItem が2つ以上必要で、各エントリには通常 position、name、item（アドレス）が必要です。item を省けるのは最後のエントリだけで、その場合 Google はページ自体のアドレスを使います（Google）。URL 構造のコピーではなく、典型的なユーザーの経路を示すよう Google は勧めており、この機能はデスクトップで利用できるものとして挙げています。ガイドラインについての私たちの読み方は、こうです。ページ上にも同じ経路を表示してください。読者に見えないもののマークアップは、認められていないからです。

JSON-LD は公開の前後にどう確認するか

Rich Results Test（リッチリザルトテスト）（search.google.com/test/rich-results）。Google は、これを “the official Google tool for testing your structured data”（構造化データをテストする Google 公式のツール）と呼んでいます。ツールのページには、アドレスか、貼り付けたコードを入力できるので、公開前に例を試せます。まず重大なエラーを直してください。重大でない指摘は、対象になるために必須ではないと Google は述べています。
Schema Markup Validator（validator.schema.org）。Google のテストのページは、これを、schema.org に基づくすべてのマークアップを “without Google feature specific warnings”（Google の機能に固有の警告なしで）確認するものと説明しています。自分の種類に合う Google の機能がないときに使います。
URL 検査ツール（Search Console）。数ページを公開したあとに使います。ページが robots.txt、noindex、ログインでブロックされていないことを確認するよう、Google は求めています。新しいページがクロールされるまでには、数日かかることがあります。
リッチリザルトのレポート（Search Console）。公開後に、テンプレートや配信の問題でマークアップが壊れることがある、と Google は注意しています。テンプレートを変えるたびに、もう一度見てください（Google）。

2026年11月4日に、上の2つの例をこう確認しました。どちらのブロックも、有効な JSON として解析できました（Python の json モジュール）。プロパティは、Google の Organization、Article、Breadcrumb のページ（最終更新 2026年9月8日）に沿っています。Google のツールには貼り付けていないので、最初に貼り付けるときが本当のテストです。

構造化データにできないこと

リッチリザルトは保証されません。 Google は、“Google does not guarantee that your structured data will show up in search results”（構造化データが検索結果に表示されることを、Google は保証しません）と書いています（Google）。理由には、アルゴリズムがプレーンなテキストの結果のほうが合うと判断することがあること、テストでは見つけられない形でマークアップが誤っていることがあることが含まれます。
順位の約束ではありません。 読んだ Google のページには、構造化データが順位を上げるという記述は見つかりませんでした。Google は、メリットをリッチリザルトの対象になることとして説明しています。構造化データに関する手動対策は、その資格を取り除きますが、ページの順位には影響しない（“doesn't affect how the page ranks in Google web search”）と、Google は付け加えています。
AI の回答には要りません。 Google の生成 AI 機能のガイドには、こうあります。“Structured data isn't required for generative AI search, and there's no special schema.org markup you need to add”（構造化データは生成 AI 検索には必須ではなく、追加すべき特別な schema.org マークアップもありません）（Google）。それでも、リッチリザルトの対象になるためには、構造化データは良いことだとしています。SEOgrinder は、どの AI システムがあなたのサイトの名前を挙げるかを測りません。
FAQ マークアップには、Google の検索結果がもうありません。 Google の変更履歴には、こうあります。“This feature will no longer appear in Google Search starting May 7, 2026”（この機能は、2026年5月7日以降、Google 検索に表示されなくなります）（Google）。その目的で、FAQPage マークアップを加えないでください。

よくある間違い：JSON-LD の5つのつまずき

1. 誰にも見えないものをマークアップする

Google のガイドラインは、“Don't mark up content that is not visible to readers of the page.”（ページの読者に見えないコンテンツを、マークアップしないでください）です。Google 自身の例では、マークアップが演者を記述しているなら、ページの本文も同じ演者を記述していなければなりません。

2. 壊れた JSON

構文のミスが1つあると、ブロック全体が壊れます。Search Console にある Google の解析できない構造化データのレポート（英語名 “Unparsable structured data report”）には、エラーの種類が挙げられています。カンマや閉じ括弧の欠け、コロンの欠け、文字列の中の不正なエスケープシーケンス、たとえばテキスト値の中に紛れ込んだ \q のようなバックスラッシュなどです。見つけるための Google のヒントは、空のオブジェクトから始めて、自分のコードを少しずつ戻していくことです。

3. 必須プロパティの欠け

必須プロパティのないアイテムは、リッチリザルトの対象にならない、と Google は述べています。よくあるのは、position、name、item のないパンくずリストのエントリです。

4. ページに合わない種類

Google は、当てはまるもっとも具体的な種類を求めています。無関係なマークアップの例として、スポーツ配信サイトが放送を地域のイベントとしてマークアップする例と、木工サイトが作り方を料理のレシピとしてマークアップする例を挙げています。

5. ページや画像をブロックする

構造化データのあるページは Googlebot に開いておく必要があり、マークアップの中の画像のアドレスは、クロールとインデックスが可能でなければなりません。画像フォルダへの Disallow ルールは、丁寧に作ったマークアップを無駄にしかねません。

SEOgrinder は構造化データをどう確認するか

SEOgrinder は私たちのツールで、私たちが開発しています。ページをスキャンし、「Google 上のページ」を開いて、2つのカードを見てください。「構造化データ」は、JSON-LD と Microdata で見つかった種類を一覧にします。「項目チェック」は、エントリの件数を数え、そのうちいくつが「無効」（必須項目が欠けている）か、「不足あり」（推奨項目だけが欠けている）かを、欠けている項目名とともに示します。タスク一覧には、「構造化データに必須項目が欠けています」「構造化データが不完全です」「構造化データがありません」、そして、解析できないコードがあるときは「構造化データのブロックが 1 件壊れています」として出ます。修正したら、再チェック を押してください。

制限は4つあります。SEOgrinder が読むのは、サーバーが返す HTML です。ブラウザーでスクリプトが初めて加える JSON-LD は見えません。Google は、それを読めます。読むのは JSON-LD と Microdata で、RDFa は読みません。必須項目を知っているのは、よく使われる種類の一覧にあるものだけで、すべての種類ではありません。そして、Google がリッチリザルトを出すかどうかは判断しません。そのプレビューは、Rich Results Test が出します。

私たち自身のページも、2026年11月4日に同じように読みました。次のコマンドは、記事では 1 を、トップページでは 0 を出力します。このコマンドは、記事の英語版を対象にしています。

curl -sS https://seogrinder.com/en/blog/seo-audit-checklist | grep -c 'application/ld+json'

記事にある1つのブロックには、BlogPosting と、3つのエントリ（SEOgrinder、ブログ、その記事）を持つ BreadcrumbList が入っています。トップページには、構造化データがありません。

よくある質問

JSON-LD は Microdata より良いのですか？

マークアップが有効なら、Google にとって3つの形式は同等です。Google が JSON-LD を勧めるのは、もっとも導入しやすく、大規模に維持しやすいからです。

すべてのページに構造化データが要りますか？

いいえ。種類は、そのページに合うところにだけ加えます。トップページや会社概要のページには Organization、投稿には Article です。多くのページには合う種類がなく、それで問題ありません。

プラグインや JavaScript で JSON-LD を加えてもいいですか？

はい。CMS では構造化データ用の設定ページやプラグインが見つかることがあること、スクリプトで挿入された JSON-LD を Google が読めることを、Google は書いています（Google）。結果は Rich Results Test で確認してください。SEOgrinder が見るのは、サーバーが返すものだけであることも、覚えておいてください。

JSON-LD で順位は上がりますか？

Google のページが説明しているのは、リッチリザルトの対象になることで、順位が上がることではありません。順位は、誰にも約束できません。

次のステップ

いちばん大切なページを選びます。例1か例2を、自分の値にして Rich Results Test に貼り付け、指摘されたものを直してください。公開したら、そのページを SEOgrinder でスキャンし、「Google 上のページ」を開いて、「項目チェック」カードを読みます。ほかのチェックの中で構造化データがどこにあたるかは、SEOチェックリストで確認できます。