BLOG

JSON-LDの書き方|ページの種類で選ぶ構造化データと実装の手順

JSON-LDの書き方そのものは、@context・@type・プロパティの3つを覚えれば足ります。手間がかかるのは、記事・商品・店舗などのページの種類ごとに型を選び、各プロパティに画面のどの値を入れるかを決める工程です。値の出どころを表にしてからテンプレートに書くと、画面とJSON-LDの値の食い違いを防げます。

Webページの画面の横にJSON-LDのコードが書かれた紙が並び、トップ・記事・店舗・商品のページの種類ごとに、違う型の名前の札が付いている図。

「JSON-LDは、サンプルのコードを貼り付けて値を書き換えれば終わりそう」。JSON-LDは本文のHTMLに手を入れず、scriptタグを1つ足すだけで書けるため、コードさえ用意すれば済むと思われがちです。ところが、Googleは画面に表示していない内容をマークアップしないよう求めていて、ページの内容と合わない構造化データは、文法が正しくてもリッチリザルトとして表示されないことがあります。JSON-LDは、ページの種類から型を選び、画面の値と対応させてから書きます。

本記事では、JSON-LDの基本の書き方から、ページの種類ごとの型の選び方、置き場所と確かめ方までを、企業サイトのSEO対策を支援する立場で順を追ってお伝えします。

この記事でわかること
  • JSON-LDは、scriptタグの中に@context、@type、プロパティを書く形式で、Googleが推奨している
  • 付ける型はページの種類で決まり、記事ならArticle、店舗ならLocalBusiness、商品ならProductを選ぶ
  • よくある質問のリッチリザルトは、2026年5月7日からGoogleの検索結果に表示されなくなった
  • プロパティごとに画面の表示とCMSの項目を表で対応させると、画面と違う値を書かずに済む

JSON-LDとは

JSON-LDは、JSONの書式で構造化データを書く形式です。schema.orgが定める型とプロパティを使い、記事の題名や著者、店の住所といったページの内容を、検索エンジンが読み取れる形で伝えます。

Googleは、構造化データの3つの形式のうち、多くの場合に実装と管理が最も容易なJSON-LDを推奨しています。ほかの2つの形式であるmicrodataとRDFaは、画面に表示する文章のHTMLタグに属性を書き足します。JSON-LDはscriptタグの中にまとめて書くので、表示用のHTMLに手を入れずに済みます。

画面に表示する記事の題名・著者名・公開日と、同じ値を書いたJSON-LDのコードを並べた図

3つの形式の書き方の違いは、schema.orgと3つの書き方を比べた記事で扱っています。

構造化データ マークアップとは | Google 検索セントラル | Documentation | Google for Developers
Google 検索がページの理解を高める「構造化データ マークアップとは」何か、解説します各機能のマークアップ例は「検索ギャラリー」から確認できます。
🌐 developers.google.com
外部リンク

※ 出典:Google検索セントラル「Google 検索における構造化データのマークアップの概要」

JSON-LDの基本の書き方

JSON-LDは、type属性に「application/ld+json」を指定したscriptタグの中に、@contextで語彙を、@typeで型を示し、続けてプロパティと値を書きます。ブログの記事ページなら、次のように書きます。

HTML
<script type="application/ld+json">
{
  "@context": "https://schema.org",
  "@type": "BlogPosting",
  "headline": "JSON-LDの書き方",
  "image": ["https://example.com/photos/16x9/photo.jpg"],
  "datePublished": "2026-10-17T09:00:00+09:00",
  "author": {
    "@type": "Person",
    "name": "山田太郎",
    "url": "https://example.com/profile/yamada"
  }
}
</script>

Googleに向けたJSON-LDで主に使う記述は、次の4つです。

記述

役割

書き方の例

@context

使う語彙を示す

"https://schema.org"

@type

何についてのデータかを示す

"BlogPosting"

プロパティ

型ごとに決まった項目に値を入れる

"headline": "記事の題名"

@id

ほかのデータから参照するための識別子を付ける

"https://example.com/#organization"

著者のように、値の中にさらに名前やURLを持つものは、authorの値を波括弧で囲み、中に@typeとプロパティを書きます。画像のように値が複数あるものは、角括弧で囲んで並べます。

ページの種類ごとに選ぶ構造化データ

付ける構造化データの型は、ページの主な内容で決まります。Googleは、schema.orgで定義された型のうち、最も具体的で適切な型を使うよう求めています。歯科医院のページなら、LocalBusinessではなく、下位の型のDentistを選びます。

サイトのページの種類ごとに、付ける構造化データの型を示した図

Googleの検索結果に使われる型

Googleがリッチリザルト(画像や評価などを添えて目立たせた検索結果)に使う型は、構造化データの検索ギャラリーに一覧があります。企業サイトで使うことの多い型と、Googleが定める必須プロパティは次のとおりです。

ページの種類

型

Googleの必須プロパティ

トップページ

WebSite

name、url

トップページか会社概要のページ

Organization

なし

ブログやニュースの記事

Article、BlogPosting、NewsArticle

なし

店舗や事業所のページ

Restaurant、DentistなどLocalBusinessの下位の型

address、name

買えない商品の紹介ページ

Product(商品スニペット)

name、review・aggregateRating・offersのいずれか1つ

商品を買えるページ

Product(販売者リスティング)

name、image、offers

イベントのページ

Event

location、name、startDate

求人のページ

JobPosting

datePosted、description、hiringOrganization、jobLocation、title

パンくずリストを表示するページ

BreadcrumbList

itemListElement

必須プロパティが無い型でも、Googleは推奨プロパティをできるだけ多く書くよう勧めています。ただし、不完全な値や不正確な値を多く書くより、少なくても完全で正確な値を書くほうが大切だとしています。必須と推奨の区別は機能ごとのGoogleのガイドに書かれていて、Googleは検索での扱いをschema.orgではなく検索セントラルのドキュメントで確かめるよう求めています。

検索結果に使われなくなった型

Googleが検索結果での表示をやめた型は、書いてもリッチリザルトになりません。とりわけ見落とされがちなのが、よくある質問のFAQPageです。Googleは、よくある質問のリッチリザルトが2026年5月7日からGoogle検索に表示されなくなると発表し、6月には説明のドキュメントも取り下げています。

手順を示すHowToのリッチリザルトも、2023年9月にパソコンとモバイルのどちらの検索結果にも表示されなくなっています。数年前のコード例には、FAQPageとHowToが残っていることがあります。コード例を写す前に、その型のガイドが今もGoogle検索セントラルにあるかを確かめます。

Google 検索セントラル ドキュメントの更新履歴・最新情報一覧 | What&apos;s new | Google for Developers
Google 検索セントラルに関するドキュメントの直近の更新履歴や最新情報を確認できます。
🌐 developers.google.com
外部リンク

※ 出典:Google検索セントラル「ドキュメントの最新の更新内容」

画面の表示とプロパティの対応表

JSON-LDの値を画面の表示と食い違わせないために、プロパティごとに、画面のどの表示とCMSのどの項目から値を入れるかを、表にしてから書きます。Googleは、ページの読者に表示されないコンテンツをマークアップしないよう求めているためです。対応表は、次の3つの手順で作ります。

1
STEP
ページの種類の洗い出し

サイトのページを、同じテンプレートで作られる単位に分けて一覧にします。

2
STEP
型と必須プロパティの書き出し

ページの種類ごとに型を選び、Googleの機能ごとのガイドから、必須プロパティと推奨プロパティを書き出します。

3
STEP
画面の表示とCMSの項目の書き込み

プロパティごとに、値を取る画面の表示と、値を差し込むCMSの項目を書きます。

記事ページなら、対応表は次のようになります。

プロパティ

画面の表示

CMSの項目

headline

記事の題名

タイトル

image

アイキャッチ画像

アイキャッチ

datePublished

公開日

公開日時

dateModified

更新日

更新日時

author.name

著者名

著者の氏名

author.url

著者のプロフィールページへのリンク

著者ページのURL

CMSの1つの項目から、画面の表示とJSON-LDの値の両方に同じ値が入る流れの図

対応表を作ると、画面に出ていない値が見つかります。更新日を画面に出していないサイトなら、更新日を表示するか、dateModifiedを書かないかを決めます。著者の書き方は、構造化データのauthorの書き方の記事で詳しく扱っています。

サイトのどのページから直すか、決めかねていませんか

ページの種類を洗い出すと、検索で見てほしいページが足りないと気づくことがあります。Writers-hubの「滋賀のSEO対策」は、1か月目に現状の分析と設計を行い、2か月目から実行に移ります。オンラインで全国に対応しています。

JSON-LDを置く場所と入れ方

JSON-LDは、HTMLのheadとbodyのどちらに置いても、Googleが読み取ります。入れ方は、HTMLのテンプレートを編集できるかで、次の4つから選びます。

入れ方

向いているサイト

気をつけること

テンプレートに直接書く

HTMLのテンプレートを編集できるサイト

値をCMSの項目から差し込む

CMSのプラグイン

WordPressなど、HTMLを直接編集しにくいサイト

テーマとプラグインの出力の重なり

Googleタグマネージャー

テンプレートを編集できないサイト

値をタグに書き写さず、変数でページから取る

JavaScriptでの生成

内容をJavaScriptで組み立てるサイト

商品のマークアップでは、Googleショッピングのクロールの頻度が下がることがある

Googleタグマネージャーで値をタグに書き写すと、ページの内容と構造化データが食い違うおそれが高まると、Googleは説明しています。価格や在庫がよく変わる商品ページは、サーバー側で出力するほうが確実です。

Web担当者Web担当者

サンプルのコードを貼って、値だけ手で書き換えれば足りますよね?

Writers-hub編集部Writers-hub
編集部

1ページだけなら、それでも書けます。ただ、手で書いた値は、記事の題名や商品の価格を直したときに、JSON-LDだけが古いまま残ります。テンプレートでCMSの項目から値を差し込めば、画面とJSON-LDが同じ項目から作られるので、値が食い違いません。

1ページに複数の型を書く方法

1ページに複数の型を書く方法は、メインの型の中に入れ子にする方法と、型ごとに並べる方法の2つです。Googleは、どちらの書き方でもページ上の複数のアイテムを認識します。

記事の著者のように記事の一部にあたるものは、入れ子にします。パンくずリストのように記事とは別のものは並べて書き、データどうしの関係を伝えるときは@idで参照します。JSON-LDの仕様にある@graphを使うと、@contextを1回書くだけで、複数のデータを1つのscriptタグに並べられます。

HTML
<script type="application/ld+json">
{
  "@context": "https://schema.org",
  "@graph": [
    {
      "@type": "Organization",
      "@id": "https://example.com/#organization",
      "name": "Example",
      "url": "https://example.com/"
    },
    {
      "@type": "BlogPosting",
      "headline": "JSON-LDの書き方",
      "publisher": { "@id": "https://example.com/#organization" }
    },
    {
      "@type": "BreadcrumbList",
      "itemListElement": [
        { "@type": "ListItem", "position": 1, "name": "ブログ", "item": "https://example.com/blog/" },
        { "@type": "ListItem", "position": 2, "name": "JSON-LDの書き方" }
      ]
    }
  ]
}
</script>

@graphの例では、BlogPostingのpublisherが、@idで同じページのOrganizationを指しています。BreadcrumbListは2つ以上のListItemで作り、最後の項目のitemを省くと、Googleはそのページ自身のURLを使います。

💡

Googleは、ページの主な目的を表す型を含めるよう求めています。記事ページでBreadcrumbListだけを書くと、ページが記事であることや題名・著者を、構造化データでGoogleに伝えられません。BlogPostingも書きます。

公開前と公開後の確かめ方

JSON-LDは、公開前に書き方の誤りを、公開後にGoogleが読み取れているかを確かめます。Googleは、テンプレートや配信の仕方が原因で公開後に問題が起きることがあるとして、公開後もレポートを見るよう勧めています。確かめ方は次の4つです。

確かめること

使うツール

時期

Googleのリッチリザルトの対象になるか

リッチリザルトテスト

公開前

schema.orgの型とプロパティの書き方

スキーママークアップ検証ツール

公開前

Googleがページの構造化データを検出したか

Search ConsoleのURL検査ツール

公開後

同じテンプレートのページ全体のエラーの数

Search Consoleのリッチリザルトのレポート

公開後

リッチリザルトテストとスキーママークアップ検証ツールは、どちらもURLかコードを入れて確かめます。Search Consoleのリッチリザルトのレポートは、記事や組織、店舗などの型には用意されていません。レポートが無い型は、テンプレートを変えるたびに、代表のページをリッチリザルトテストにかけ直します。

ℹ

リッチリザルトテストは、サイト名を伝えるWebSiteに対応していません。WebSiteのように、リッチリザルトテストが確かめない型は、スキーママークアップ検証ツールで書き方の誤りを見ます。

JSON-LDで避けたい書き間違い

JSON-LDの書き間違いには、ツールで見つかるものと見つからないものがあります。公開前に見直したい書き間違いは、次の6つです。

  • 画面に表示していない値を書く
  • 複数の著者を1つのauthor.nameにまとめて書く
  • 日付をISO 8601以外の形式で書く
  • JSON-LDの中にコメントを残す
  • 最後の項目の後ろにカンマを付ける
  • ダブルクォートを全角や“”で書く

最後のカンマとダブルクォートの誤りは、JSONとして読み取れなくなるため、リッチリザルトテストでエラーになります。一方で、JSON-LDの中のコメントは、リッチリザルトテストでは無視されます。コメントはJSON-LDの標準で認められていないので、公開前に消します。

複数の著者は、authorの中に1人ずつ分けて書き、author.nameには名前だけを入れます。日付はISO 8601の形式で書き、タイムゾーンも付けます。タイムゾーンが無いと、GoogleはGooglebotが使うタイムゾーンで日時を扱います。

画面と違う値をマークアップしていないかは、ツールでは確かめにくい誤りです。Googleは、品質に関するガイドラインは自動化ツールで簡単にテストできないとしています。テンプレートごとに1ページを開き、JSON-LDの値と画面の表示を見比べます。

Google 検索上の構造化データ ガイドライン | Google 検索セントラル | Documentation | Google for Developers
Google 検索上の構造化データに関する一般的なガイドラインです。ガイドラインに順守することは構造化データがリッチリザルトとして検索結果に表示されやすくなることに役立ちます。
🌐 developers.google.com
外部リンク

※ 出典:Google検索セントラル「構造化データに関する一般的なガイドライン」

JSON-LDのよくある質問

JSON-LDの実装で迷いやすい質問は、次の4つです。

JSON-LDは全ページに同じものを入れる?

入れる型はページの種類ごとに違い、全ページに同じJSON-LDを入れる必要はありません。サイト名を伝えるWebSiteは、トップページだけに置きます。Organizationも、Googleはトップページか会社概要のページに置くよう勧めていて、全ページに含める必要はないとしています。

FAQPageのJSON-LDは消したほうがいい?

Google検索のためにFAQPageを残す理由は、もうありません。2026年5月7日から、Google検索にはよくある質問のリッチリザルトが表示されていないためです。テンプレートから外しても、Googleの検索結果の表示は変わりません。外すかどうかは、Google以外の検索エンジンやサービスでFAQPageを使うかで決めます。

WordPressでもJSON-LDは入れられる?

WordPressでは、構造化データを出力するプラグインでJSON-LDを入れられます。Googleも、HTMLを直接編集できないCMSでは、プラグインを使うほうが簡単な場合があるとしています。テーマとプラグインの両方が同じ型を出力していないかは、公開後にページのHTMLで「application/ld+json」の数を数えて確かめます。

microdataの構造化データも書き換える?

正しく動いているmicrodataは、書き換えなくてもかまいません。Googleは、マークアップが有効で、機能のガイドどおりに実装されていれば、3つの形式のどれも有効としています。テンプレートを作り直すときに、管理しやすいJSON-LDへ移します。

まとめ|JSON-LDは書く前にページの種類で型を選ぶ

JSON-LDの書き方は、scriptタグの中に型とプロパティを書く形に決まっています。手間がかかるのは、ページの種類ごとに型を選び、各プロパティに画面のどの値を入れるかを決める工程です。ページの種類と型、画面の表示とCMSの項目を表で対応させてからテンプレートに書けば、公開後も画面とJSON-LDの値がそろいます。

私たち合同会社Writers-hubは、滋賀のSEO対策として、サイトの現状の分析と設計から実行、毎月の報告と見直しまでを行っています。オンラインで全国に対応しています。

分析と設計から、毎月の見直しまでを任せたいときは

滋賀のSEO対策は、月額20万円〜(税別・6か月〜)です。1か月目に現状の分析と設計を行い、2か月目から実行に移します。彦根市とその周辺は訪問もでき、オンラインで全国に対応しています。

この記事を書いた人

米山拓真

米山拓真

合同会社Writers-hub 代表社員

滋賀県立大学工学研究科の修士課程を修了後、大手制作会社の編集部を経て2019年にWebライターとして独立。2020年に記事制作を手順化した「ハブ式SEOライティングメソッド」を開発し、これまでに200人以上のライターを育成しました。2022年3月に合同会社Writers-hubを設立し、会社として累計8,000記事以上のSEO記事制作に携わっています。2024年にAIライティングシステム「一気通貫Pro」、2025年から書き手の文体を再現するAI編集者「Edico」を開発。このブログでは、クライアント案件と自社サイトで実際に試したことを書いています。

読んで終わりにしないために

記事の内容を自社に当てはめるとどうなるか、オンライン30分で一緒に整理します。費用はかかりません。