構造化データの入れ方｜JSON-LDの作成・検証・公開後確認

先に答え：画面にある事実だけを、対応する種類で記述する

構造化データは、ページの内容を決められた形式で説明するコードです。Googleはページの意味を理解する手がかりとして利用し、対応する種類ではリッチリザルトの対象になる可能性があります。ただし、検証に合格しても検索結果での表示や順位上昇は保証されません。

GoogleはJSON-LD、Microdata、RDFaをサポートし、可能ならJSON-LDを推奨しています。この記事では、HTMLの script type="application/ld+json" 内へ記述するJSON-LDを使います。

最初に、ページの主目的と対応する種類を照合する

「SEOに良さそうな種類を全部入れる」のではなく、実際のページ内容とGoogleがサポートする検索機能を照合します。会社概要ならOrganization、店舗情報なら該当するLocalBusinessの具体的な種類、記事ならArticle系など、ページの主題に合うものを選びます。

画像を拡大 ↗

会社情報、店舗、記事、階層リンクを対応する構造化データの種類へ結ぶ図。閉じる ×

Googleが対応する種類別ガイドで必須・推奨項目を確認します。

種類ごとに必須・推奨プロパティや追加ルールが異なります。schema.orgに存在する型でも、Googleのリッチリザルトが対応するとは限りません。Google検索での動作はSearch Centralの種類別ガイドを基準に確認します。

架空のOrganization例を作る

次は架空サイト https://example.com/ の最小限の説明例です。実在する会社・住所・連絡先ではありません。

<script type="application/ld+json">
{
  "@context": "https://schema.org",
  "@type": "Organization",
  "name": "Example Guide",
  "url": "https://example.com/",
  "logo": "https://example.com/images/logo.png"
}
</script>

GoogleのOrganization資料では、ホームまたは組織を説明する一つのページへの設置を推奨し、全ページへの重複設置は不要としています。2026年9月8日更新の同資料では必須プロパティはなく、ページに当てはまる推奨項目を追加する形です。

画像を拡大 ↗

example.comを使ったOrganizationのJSON-LD架空例。名称、URL、ロゴだけを記述。閉じる ×

コードは構造説明用です。実サイトの値へ置き換えて検証します。

ロゴURLは実際に取得でき、クロール可能な画像を指定します。本文にない所在地、評価、価格、架空の受賞歴などをコードにだけ追加しません。Googleの一般ガイドラインは、読者に見えない内容をマークアップしないよう求めています。

作成・検証・公開を分ける

1. 対象ページのURLと主題を決める。
2. Googleの対応一覧から種類を選び、その種類別ガイドを読む。
3. 本文に見える事実から値を作る。
4. JSONとして構文が正しいか確認する。
5. リッチリザルトテストでコードまたは検証環境URLを確認する。
6. エラーを直し、警告は推奨項目として内容に合うものを判断する。
7. 少数ページへ公開し、公開URLでも再テストする。
8. Search ConsoleのURL検査で、Googleが取得したページを確認する。
9. 対応レポートがある種類は、公開後もSearch Consoleで監視する。

画像を拡大 ↗

本文確認、コード検証、少数ページへの公開、URL検査と監視の流れ。閉じる ×

コード入力テストだけで完了にしません。

開発中のコード入力テストに通っても、本番テンプレートで削除されたり、JavaScript生成に失敗したり、ログインやnoindexでGoogleが取得できない場合があります。公開後は必ずURLで再確認します。

エラー・警告・表示されない場合を分ける

Googleは、リッチリザルトテストに合格しても表示を保証せず、内容との不一致、非表示情報、ガイドライン違反等で対象外になり得ると説明しています。検索結果に出ないからといって、同じJSON-LDを重複追加しません。

更新時に本文とコードを同時に直す

構造化データは初回設置だけでなく、本文変更時の保守が必要です。社名、ロゴ、URL、営業時間、記事公開日等が変わったときにコードだけ古いままだと、ページと説明が不一致になります。

画像を拡大 ↗

ページの名称やURL等を変更したとき、JSON-LDと公開後検証も同時に更新する図。閉じる ×

CMSやプラグインの重複出力も確認します。

更新担当者向けチェック表：

• 画面の名称と name が一致している。
• 正規URLと url が一致している。
• logo や画像URLを直接開ける。
• 削除したページや古いサブドメインを参照していない。
• 同じ対象を複数プラグイン・テーマが重複出力していない。
• 更新後の公開URLをリッチリザルトテストで再確認した。

制作担当者への依頼文

対象ページ：https://example.com/about
ページの主題：組織の公式情報
検討する型：Organization
本文に表示している項目：名称、URL、ロゴ
使用形式：JSON-LD
設置場所：ホームまたは会社案内のどちらか一つ
検証：コード入力、本番URL、Search Console URL検査
確認日：2026-10-12
注意：本文にない住所・評価・実績は追加しない

構造化データは本文の代用品ではありません。まず利用者が読める内容を整え、その内容を正確に説明するコードとして管理します。

SITE PORTを検討するときの確認ポイント

サイト制作を依頼する場合は、画面の見た目だけでなく、この記事で扱った設定を誰が担当するか、公開後に何を自分で変更できるかを確認します。SITE PORTの完成例と編集デモでは、完成イメージと日常的な編集の流れを確認できます。サーバー設定・検索向けコード・WordPress保守が通常の本文編集と同じ範囲で扱えるとは限らないため、必要な作業を具体的に伝えて対応範囲を確認してください。

関連記事

[Search ConsoleのURL検査](/articles/search-console-url-inspection)・[サイトマップの作成と送信](/articles/sitemap-create-submit-check)