JSON-LD構造化データとは？SEOでの役割・書き方・検証方法を初心者向けに解説

JSON-LD 構造化データは、SEOまわりでよく出てくるけれど、最初はかなり分かりにくい言葉です。

ただ、実務で見るポイントはそこまで複雑ではありません。ページの本文とは別に、「このページは記事です」「この名前がタイトルです」「公開日はこれです」「パンくずはこの順番です」と、検索エンジンが読み取りやすい形で補足するものです。

先に要点

JSON-LD は、JSON形式で意味づけ情報を書くための形式です。
構造化データは、ページ内の情報が何を意味するのかを検索エンジンへ伝えやすくする記述です。
SEOでは、記事、パンくず、商品、FAQなどを schema.org の語彙で整理して伝える用途が多いです。
入れれば必ず順位が上がるものではありません。本文と矛盾しない、正しいマークアップにすることが大前提です。

JSON-LD 構造化データとは何か

JSON-LD 構造化データは、かなりざっくり言うと、ページの意味を検索エンジンに分かりやすく渡すためのJSON形式の補足情報 です。

たとえば記事ページなら、画面上にはタイトル、本文、公開日、更新日、カテゴリ、著者などが表示されています。
人間は見ればなんとなく分かりますが、検索エンジンや機械にとっては、どれが記事タイトルで、どれが公開日で、どれが著者なのかを正確に判断する必要があります。

そこで JSON-LD を使って、次のように補足します。

<script type="application/ld+json">
{
  "@context": "https://schema.org",
  "@type": "BlogPosting",
  "headline": "JSON-LD構造化データとは？",
  "datePublished": "2026-04-17T00:00:00+09:00",
  "dateModified": "2026-04-17T00:00:00+09:00",
  "author": {
    "@type": "Organization",
    "name": "技術記録帖"
  }
}
</script>

これは画面には表示されません。
でも検索エンジンはこの記述を読んで、ページの意味を理解する助けにできます。

JSON-LDと構造化データの違い

ここは混乱しやすいところです。

言葉	ざっくりした意味
構造化データ	ページ内の情報が何なのかを機械に伝えるための記述全般
JSON-LD	構造化データを書く形式のひとつ
schema.org	構造化データで使う共通語彙

つまり、構造化データ = 目的、JSON-LD = 書き方、schema.org = 辞書 と考えると分かりやすいです。

たとえば「この記事はBlogPostingです」「この文字列はheadlineです」「このURLはimageです」という意味づけをしたいとします。
そのとき、schema.org の語彙を使い、JSON-LD形式で書く、という流れです。

Google Search Central の構造化データ導入ガイドでも、Google検索がページを理解しやすくするために標準化された形式で情報を提供するものとして構造化データが説明されています。
また、GoogleはJSON-LD、Microdata、RDFaをサポートしていますが、可能ならJSON-LDを推奨しています。

なぜSEOで使われるのか

JSON-LD構造化データがSEOで話題になる理由は、大きく2つあります。

1つ目は、検索エンジンがページ内容を理解しやすくなることです。
ページが記事なのか、商品なのか、パンくずなのか、FAQなのか、レビューなのかを、機械が読み取りやすい形で渡せます。

2つ目は、条件を満たすとリッチリザルトの対象になる可能性があることです。
リッチリザルトは、通常の青いリンクだけでなく、検索結果上で追加情報が表示される検索結果の見え方です。

ただし、ここで誤解してはいけないのは、JSON-LDを入れたら必ず順位が上がるわけでも、必ずリッチリザルトになるわけでもない ことです。
Googleのドキュメントでも、構造化データは検索結果で特別な機能を有効にする対象になり得ますが、品質ガイドラインや技術要件を満たす必要があります。

構造化データは、本文の品質を上げる魔法ではありません。
本文にない内容をJSON-LDだけで盛るのは危険です。検索エンジンにとっても、読者にとっても、不自然な情報になります。

実務でよく入れるJSON-LD

実務で最初に見ることが多いのは、次のあたりです。

種類	主な用途
WebSite	サイト全体の情報
Organization	運営者や会社情報
BlogPosting / Article	記事ページ
BreadcrumbList	パンくずリスト
FAQPage	FAQページ
Product	商品ページ
LocalBusiness	店舗や地域ビジネス

このサイトのような技術ブログなら、まず見るべきは WebSite、Organization、BlogPosting、BreadcrumbList です。
記事ページごとにタイトル、説明、公開日、更新日、画像、著者、URLを出し、パンくずがあるならBreadcrumbListも出します。

ECサイトならProduct、価格、在庫、レビューなどが候補になります。
ただし、商品構造化データは実際の表示内容や販売条件とズレると問題になりやすいので、かなり慎重に扱います。

FAQPageも便利そうに見えますが、FAQ形式の本文が本当にページ上にある場合に使うべきです。
本文にないQ&Aを構造化データだけで入れるのは避けます。

JSON-LDはどこに書くのか

JSON-LDは、HTML内に次のようなscriptタグで書きます。

<script type="application/ld+json">
{
  "@context": "https://schema.org",
  "@type": "WebSite",
  "name": "技術記録帖",
  "url": "https://engineer-notes.net/"
}
</script>

一般的には <head> 内に出すことが多いですが、Googleの案内ではページ内のどこに置いてもよいとされています。
ただ、実務ではテンプレート管理のしやすさを考えて、headにまとめることが多いです。

Laravelのようなサーバーサイドテンプレートなら、記事詳細ページのBladeで次のように作るのが分かりやすいです。

@php
    $articleSchema = [
        '@context' => 'https://schema.org',
        '@type' => 'BlogPosting',
        'headline' => $article->title,
        'description' => $article->meta_description,
        'datePublished' => optional($article->published_at)?->toIso8601String(),
        'dateModified' => optional($article->updated_at)?->toIso8601String(),
        'mainEntityOfPage' => route('articles.show', $article),
    ];
@endphp

<script type="application/ld+json">
    @json($articleSchema, JSON_UNESCAPED_UNICODE | JSON_UNESCAPED_SLASHES)
</script>

ポイントは、手書きの文字列連結でJSONを作らないことです。
エスケープ漏れやカンマのミスが起きやすいので、PHP配列から @json で出す方が安全です。

記事ページで入れるなら何を書くか

記事ページのJSON-LDでは、最低限次のような情報を検討します。

@context
@type
headline
description
datePublished
dateModified
author
publisher
mainEntityOfPage
image

この中で特に大事なのは、画面上の情報と一致していることです。

たとえば、JSON-LDでは公開日が2026年4月17日なのに、本文や画面では2026年4月10日になっていると不自然です。
タイトルも、画面のH1やtitleタグと大きくズレていると、何を正として見ればよいのか分かりにくくなります。

構造化データは、読者に見えない裏側の情報です。
だからこそ、表に出ている本文やメタ情報と矛盾させないことが大事です。

パンくずのJSON-LD

記事ページでは、BreadcrumbListもよく使います。

<script type="application/ld+json">
{
  "@context": "https://schema.org",
  "@type": "BreadcrumbList",
  "itemListElement": [
    {
      "@type": "ListItem",
      "position": 1,
      "name": "ホーム",
      "item": "https://engineer-notes.net/"
    },
    {
      "@type": "ListItem",
      "position": 2,
      "name": "記事一覧",
      "item": "https://engineer-notes.net/articles"
    }
  ]
}
</script>

パンくずのJSON-LDで気をつけたいのは、画面上のパンくずとズレないことです。
画面では「ホーム / ソフトウェア / 記事名」なのに、JSON-LDでは「ホーム / ネットワーク / 記事名」になっていると、カテゴリ整理としても不自然です。

このサイトのように複数カテゴリを持つ記事では、主カテゴリをどう扱うかを決めておくとブレにくいです。

よくある失敗

JSON-LD構造化データでよくある失敗は、だいたい次のようなものです。

1. 本文にない情報を書く

構造化データは、ページ内容の補足です。
本文や画面にない評価、価格、FAQ、著者情報などをJSON-LDだけに入れるのは避けます。

特にFAQやレビューは、検索結果で目立ちそうだからと入れたくなります。
でも、ページ上に実際のQ&Aやレビューがないなら、構造化データとしても不自然です。

2. 型を何でも入れすぎる

Article、FAQPage、Product、HowTo、Reviewなどを、とにかくたくさん入れれば強くなるわけではありません。
ページの実態に合う型だけを使います。

技術記事なら、まずBlogPostingとBreadcrumbListで十分なことも多いです。
FAQ形式の記事ならFAQPageを検討する、商品販売ページならProductを検討する、という順番で見ます。

3. 日付やURLが古い

JSON-LDはテンプレートで自動出力することが多いので、日付やURLのズレに気づきにくいです。
公開日、更新日、canonical URL、画像URL、著者名、組織名は、リリース後にも確認します。

4. JSONとして壊れている

カンマ忘れ、クォート漏れ、HTMLエスケープ、全角記号の混入などで、JSONとして壊れることがあります。
手書きで長いJSON-LDを書くほど壊れやすいです。

実務では、CMSやテンプレート側でデータから生成し、検証ツールで確認する流れにした方が安全です。

検証方法

JSON-LDを入れたら、必ず検証します。

代表的には次のツールを使います。

Google Rich Results Test
Schema Markup Validator
Search Console の拡張レポート

Googleのリッチリザルトテストは、Google検索のリッチリザルト対象として解釈できるかを見るのに便利です。
Schema Markup Validatorは、schema.orgとして構文や構造を見るのに使いやすいです。

ただし、テストでエラーがないからといって、検索結果に必ず特別表示されるわけではありません。
あくまで「壊れていないか」「対象になり得るか」を確認するものです。

このサイトのような技術ブログなら何から入れるか

技術ブログなら、最初に入れるなら次の順番が現実的です。

サイト全体のWebSite
運営者のOrganization
記事ページのBlogPosting
パンくずのBreadcrumbList
必要なページだけFAQPage

すべてのページに無理やりFAQPageを入れる必要はありません。
むしろ、記事本文がFAQ形式ではないのにFAQPageを出すと不自然です。

JSON-LDは、サイト全体の情報設計とセットで考えると効果が出やすいです。
記事タイトル、H1、メタディスクリプション、パンくず、カテゴリ、用語リンク、JSON-LDが同じ方向を向いていると、検索エンジンにも読者にも分かりやすくなります。

AI時代にも意味があるのか

JSON-LD構造化データは、AI検索やLLM時代でも意味があります。
ただし、JSON-LDを入れればAIに引用される という話ではありません。

価値があるのは、ページの意味が整理されることです。

これは記事なのか
誰が公開しているのか
いつ公開・更新されたのか
どのページが正規URLなのか
どのカテゴリに属するのか
どの情報がFAQや商品情報なのか

こうした情報が整理されていると、機械がページを解釈しやすくなります。
ただし、最終的には本文の分かりやすさ、根拠、一次情報、内部リンク、更新性が大事です。

JSON-LDは、良い本文を補強するものです。
薄い本文を強く見せるためのものではありません。

まとめ

JSON-LD構造化データは、ページの意味を検索エンジンに伝えやすくするための記述です。
構造化データという目的に対して、JSON-LDはその書き方のひとつであり、schema.orgは使う語彙です。

実務では、まず次を意識すると扱いやすいです。

画面に出ている内容と一致させる
ページの実態に合う型だけを使う
手書きではなくテンプレートから生成する
公開後に検証ツールで確認する
リッチリザルトや順位上昇を保証するものだと思わない

SEOで大事なのは、本文、タイトル、内部リンク、ページ体験、情報の信頼性です。
JSON-LDはその土台を機械にも伝わりやすくする補助として使うと、実務ではかなり自然です。

参考リンク

Google Search Central: Understand how structured data works
Google Search Central: General structured data guidelines
Google Search Central: Rich Results Test
Schema.org: Schema.org
Schema.org: JSON-LD