JSON-LDとは、会社や製品などの構造化データを、HTMLのscript要素にまとめて書く形式です。画面に載せた事実を選び、型と項目を決め、設置してから公開URLで確かめます。
制作担当へ渡すなら、対象URL、画面に出ている情報、現在の出力元を用意してください。構造化データそのものの役割やAI検索との関係は構造化データの役割で扱っています。ここではコードを書くところから進めます。
書く前に何を決める？
製造業のサイトなら、会社を説明するトップと、個別の製品を紹介するページを分けて考えます。会社名を表すOrganizationと、製品を表すProductでは、何について書くかが違うためです。
schema markupという言葉で依頼されても、専用の別ファイルを必ず作るという意味ではありません。schema.orgが定めた型や項目を使い、ページの内容に意味を付ける作業です。JSON-LDはその記述形式の一つです。
作業の順番を次のように決めます。
- 対象ページを開き、会社名や製品名などの事実を確認する
- HTMLとCMSの設定を調べ、すでにある構造化データを探す
- 型と項目を選び、本文と同じ内容でコードを書く
- 設置後の出力と画面を照合し、検証する
プラグインが会社情報を出しているところへ、別の社名表記を手書きで足さないでください。どの設定から出すかを決め、古い情報を修正・統合します。複数の型があること自体より、同じ会社や製品について矛盾した説明が残ることが問題です。
JSON-LDを使う理由は？
Googleの形式の公式説明は、JSON-LDを推奨しています。画面の本文のタグへ情報を混ぜずに記述でき、住所のような入れ子の情報も表しやすい形式です。多くのページへの実装や保守で、誤りを減らしやすいとも説明しています。
担当者にとっては、本文の見た目を作るHTMLと、機械へ渡すデータを分けて確認できます。ただし、管理する事実まで別々にすると更新漏れが起きます。CMSに製品名の欄があるなら、画面とJSON-LDの両方を同じ欄から出す設計にします。
JSON-LDは通常のJavaScript処理を書き込む場所ではありません。W3Cの仕様に沿ったJSON形式で記述します。キーと文字列は半角の二重引用符で囲み、項目の間を半角のカンマで区切ります。最後の項目の後ろへ余分なカンマを付けないようにします。
会社情報はどう書く？
以下は説明用の架空の会社です。【】の中は実際の情報へ置き換える欄で、このまま公開するコードではありません。型名や項目名は変更しません。
<script
type="application/ld+json"
>
{
"@context": "https://schema.org",
"@type": "Organization",
"name":
"【青葉精密工業株式会社】",
"url":
"【会社トップの完全なURL】",
"description":
"【精密金属部品を製造する会社】"
}
</script>
各項目の役割は次のとおりです。
| 項目 |
書く内容 |
| @context |
使う語彙。例ではschema.org |
| @type |
対象の型。例では会社・組織 |
| name |
画面にも載せた会社名 |
| url |
会社のサイトのURL |
| description |
公開済みの事業説明 |
項目の定義はschema.orgの会社情報の型で確認できます。事業説明は、実際の対応範囲を超える宣伝文句へ書き換えません。所在地やロゴを加えるときも、公開情報と参照先を確認してから記述します。
Googleの会社情報の仕様は、トップページへの設置を案内しています。必須項目はなく、自社に当てはまる情報を追加する方針です。仕様書の欄をすべて埋めるために、未確認の情報を補う必要はありません。
製品の例はどう書く？
個別の金属部品を紹介するページなら、その製品について記述します。会社情報をコピーして型名だけProductへ替えても、製品の説明にはなりません。
<script
type="application/ld+json"
>
{
"@context": "https://schema.org",
"@type": "Product",
"name": "【位置決め用ブッシュ】",
"model": "【AB型】",
"description":
"【治具に使用する金属部品】",
"manufacturer": {
"@type": "Organization",
"name":
"【青葉精密工業株式会社】"
}
}
</script>
これは型と項目の関係を示す短い例です。schema.orgの製品情報の型にあるmodelは型式など、manufacturerは製造元を表します。実際のページの製品名、型式、用途、製造元と照合してください。
この例だけでは、Googleの商品スニペットの要件を満たしません。商品の表示要件では、nameに加え、review・aggregateRating・offersのいずれかが必要です。schema.orgで製品を記述できることと、Googleの特定の表示形式へ対応することを分けます。
受注生産で価格を公開していないなら、テストを通すために価格を作らないでください。価格0は見積もり依頼の意味にはなりません。実在しない評価や口コミも足さず、公開できる事実でどこまで対応できるかを決めます。
scriptはどこに置く？
HTMLのhead内でもbody内でも置けます。上の例では、scriptのtypeにapplication/ld+jsonを指定しています。JSONだけを通常の本文欄へ貼り、読者の画面にそのまま表示する設置とは違います。
CMSで編集するなら、構造化データ用の設定欄や、HTMLを出すテンプレートを確認します。本文へ入力したscriptが保存時に取り除かれる仕組みもあるため、入力画面の内容だけでは設置済みと判断しません。配信されたHTMLで確認します。
配置を決めたら、同じ型の別ページも開いてください。製品共通のテンプレートへ固定の型式を書き込むと、別製品にも同じデータが出ます。共通にするのは書式で、製品名や説明は各ページの情報から出します。
データにだけ説明を追加しない
Googleの一般ガイドラインは、読者に見えない内容をマークアップしないよう求めています。仕様や対応条件を足すなら、先に画面へ正しい説明を載せます。
私たちも暦の自社メディアで、一覧のFAQを構造化データにだけ入れ、画面へ出していない失敗をしました。質問と答えを画面にも出す形に直しています。出典は自社メディアの運営記録です。コードが書けたことと、読者に情報を渡せたことを分けて確かめる必要がありました。
動的に追加してもよい？
Googleは、JavaScriptで生成し、レンダリング時にDOM内にある構造化データを処理できます。DOMとは、ブラウザが読み込み後に扱うページの構造です。最初のHTMLにコードがないときは、処理後に追加された内容を確認します。
動的生成の公式説明は、タグ管理の設定へ本文と同じ情報を二重に持つと、食い違う危険が増えると注意しています。画面や元データから値を取り、更新箇所を増やさないようにします。
同じ説明には、Productを動的生成すると、ショッピング向けの取得頻度や確実性が下がりうるという注意もあります。価格や在庫が頻繁に変わる製品では、最初に返すHTMLへ含められるかを制作担当と確認してください。
動的な出力の検査は、貼り付けたコードだけで済ませずURLを使います。Googleも、コード入力にはJavaScriptの制約があるためURL入力を推奨しています。取得後のHTMLに、意図した会社名や製品名が入っているかを見ます。
設置後は何を確かめる？
構文、Googleの表示要件、内容の正しさを順に確認します。スキーマの検証案内が扱うのは、ページへ埋め込まれたschema.orgのデータです。Googleの表示要件とは検査範囲が違います。
公開前はコードを検査し、公開後は実際のURLで再検査します。リッチリザルトテストのエラーと警告の読み方は検証ツールの使い方へ進んでください。Googleのテストのヘルプには、テストがコメントを無視しても、公開用のJSON-LDからは削除するよう案内があります。
最後に画面とデータを並べ、会社名、型式、用途が一致するかを人が読みます。テストが有効でも検索結果への表示は保証されません。制作担当からはコードだけでなく、変更した出力元と、検査したURLも受け取ってください。
サイト設計の点検として、会社トップと製品詳細を別々に確認します。次の製品更新でも同じ欄から正しいデータを出せるところまで決めると、貼り付けた直後だけの確認で終わらずに済みます。
仕様・出典の確認日：2026年10月23日。
