JSON-LDチェック完全手順｜エラー確認ツールと見落とし7項目

JSON-LDチェックとは、構造化データの構文に誤りがないか、Googleのリッチリザルトに対応した形式で書けているかを検証する作業です。結論として、Google固有の検証にはリッチリザルト テストを使い、schema.org全体の汎用検証にはスキーマ マークアップ検証ツールを使うという役割分担が基本になります。本記事では、URLとコード両方でのチェック手順、頻出するエラーメッセージの意味と直し方、公開前に潰しておきたい見落とし7項目、そしてチェック合格後もリッチリザルトが出ない理由とSearch Consoleでの継続監視まで、実務でそのまま使える流れをまとめて解説します。

JSON-LDチェックとは？まず結論：3つのツールを役割で使い分ける

JSON-LDチェックとは、構造化データの記述がJSONとして文法的に正しいかという構文の観点と、Googleのリッチリザルトに必要なプロパティを満たしているかという対応状況の観点を検証する作業です。結論として、確認したい対象がすでに公開されているページなのか、まだ実装前のコードなのかによって、入力する情報とツールの組み合わせを変える必要があります。

構造化データの記述形式にはJSON-LD、Microdata、RDFaの3種類がありますが、Googleが推奨しているのはJSON-LD形式です。HTMLの<script type="application/ld+json">内にJSON形式で記述するため、本文のマークアップと独立して管理でき保守がしやすいという特徴があります（出典）。この特徴を理解しておくと、後述する各ツールの使い分けもスムーズに理解できます。

TechSuite株式会社の「AI検索パートナーズ」は、生成AIが構造化データを引用・推薦する仕組みを構文の正しさだけでなく意味的文脈やエンティティ認識まで技術的に捉え、LLMO/GEO/AEOの観点から一次情報設計に落とし込む支援を行っています。構文が正しいだけでは不十分で、検索エンジンやAIがどのように内容を解釈するかまで踏み込んで設計することが、今後のチェック体制の質を左右します。

JSON-LDチェックで確認すべき2軸とは？

JSON-LDチェックには、JSONとして文法的に正しいかという構文エラーの軸と、Googleが定めるリッチリザルトの必須プロパティを満たしているかという対応状況の軸の2つがあります。この2軸を分けて確認しないと、構文は通っているのに肝心のリッチリザルトが表示されないという事態に気づきにくくなります。まずは構文エラーがないかを確認し、そのうえで対象タイプごとの必須プロパティを満たしているかを見ていく順序が効率的です。

主要なスキーマタイプごとの必須プロパティは、あらかじめ一覧にしておくとチェック漏れを防ぎやすくなります。

スキーマタイプ	必須プロパティ	備考
Article	headline / image / datePublished / author	記事系のリッチリザルト向け
Product	name / image / offers（price, priceCurrency）	価格や在庫情報を含む
FAQPage	mainEntity（Question＋acceptedAnswer）	1問1答形式で記述する
BreadcrumbList	itemListElement（position, name, item）	パンくずリスト表示用
Recipe	name / image / recipeIngredient / recipeInstructions	レシピのリッチリザルト向け

URL単位とコード単位、どちらで確認する？

公開済みのページを確認したいならURL入力、実装前や下書き段階のコードを確認したいならコードスニペットの貼り付けを使うのが基本的な判断基準です。すでに本番環境に反映されているものはURLで検証すれば実際のクロール結果に近い判定が得られ、まだ公開していないコードはスニペット入力で事前に問題を潰しておけます。

公開前のチェックと公開後のチェックは目的が異なるため、どちらか一方だけで満足せず、両方のタイミングで確認する運用が望ましいと言えます。構造化データの基礎については、LLMOとは何かを先に押さえておくと、なぜ構造化データが重要視されるのかという背景も理解しやすくなります。

JSON-LDチェックに使う主要ツールと使い分け方

JSON-LDチェックの主軸は「リッチリザルト テスト」と「スキーマ マークアップ検証ツール」の2つです。旧「構造化データ テストツール」は2020年12月にGoogle固有の検証機能を終了し、機能はこの2つに引き継がれています（出典）。目的に合わせてこの2つを組み合わせることが、チェックの質と速度を両立させる結論です。

それぞれのツールがどこまでを検証してくれるのかを理解しておくと、エラーが出たときにどのツールに戻って確認すればよいかが判断しやすくなります。

リッチリザルト テストは何を検証してくれる？

リッチリザルト テストは、JSON-LD・Microdata・RDFaの3形式に対応し、URL入力とコードスニペットの貼り付けの両方に対応するGoogle固有の検証ツールです。スマートフォンとPCのユーザーエージェントを選んでテストできるため、表示端末ごとの差異も確認できます（出典）。対応するリッチリザルトタイプには記事、パンくずリスト、FAQ、求人情報、レシピ、レビュー抜粋などがあります。

スキーマ マークアップ検証ツールとの違いは？

スキーマ マークアップ検証ツール（validator.schema.org）は、schema.orgが運営する汎用検証ツールで、Google固有のリッチリザルト検証や警告は行いません。Googleはまずリッチリザルト テストでGoogle向けの表示を確認し、より広範なschema.org準拠の確認にはこちらを併用するよう案内しています（出典）。用途が違うため、どちらか一方だけで十分と考えないことが大切です。

旧ツールが廃止された経緯とは？

旧「構造化データ テストツール」は、以前はGoogle固有の検証も含めて一括で確認できていましたが、2020年12月にGoogle固有の検証機能を削除し、schema.org運営のスキーマ マークアップ検証ツールへ機能を移行しました。現在この旧ツールへアクセスしても案内ページに転送されるため、ブックマークが古い場合は更新しておく必要があります。

どのツールをいつ使う？使い分け早見表

目的別にツールを整理すると、次のように使い分けるのがわかりやすくなります。

目的	使うツール	入力形式	備考
公開済みページのGoogle対応を確認したい	リッチリザルト テスト	URL	スマホ/PCの切替可
実装前のコードを事前確認したい	リッチリザルト テスト	コードスニペット	結果は約90日保存
schema.org全体の構文を広く確認したい	スキーマ マークアップ検証ツール	URL / コード	Google固有の警告なし
WordPress実装を手軽に行いたい	構造化データ マークアップ支援ツール等	GUI操作	手動記述の下書き作成に便利

TechSuite株式会社の「AI検索パートナーズ」は、自社サイトにおいてAI Share of Voiceを高水準で維持しており、支援先でも複数ツールを組み合わせた継続的な検証によってAI Overviewの引用率が改善した実績があります。ツール単体の合否だけでなく、どのツールで何を見るかという運用設計まで含めて support する点が特徴です。

JSON-LDチェックの完全手順

JSON-LDチェックの手順は、URLまたはコードを入力し、ユーザーエージェントを選んでテストを実行し、検出項目とエラーを確認し、必要に応じて結果を保存・共有するという流れで進めます。この順序を踏めば、初めてでも迷わずチェックを完了できます。

各ステップで見るべきポイントを事前に知っておくと、テスト結果の読み違いを防げます。

何を入力すればいい？URLとコードスニペット

リッチリザルト テストでは、公開済みのページを確認したい場合はURLを入力し、未公開のコードを確認したい場合はコードスニペットを貼り付けます。どちらの方法でも、対象がJSON-LD・Microdata・RDFaのいずれの形式であっても検証可能です（出典）。入力を誤ると意図しない旧バージョンのコードを検証してしまうことがあるため、貼り付ける前に最新のコードであることを確認しておく必要があります。

スマホ用とPC用、どちらを選ぶべき？

リッチリザルト テストではスマートフォンとPCのユーザーエージェントを選んでテストを実行できます。表示端末によって認識結果が変わることもあるため、実際の主要な流入端末に合わせて選ぶのが安全です。多くのサイトはモバイル経由の流入が中心となるため、まずスマートフォン用で確認し、その後PC用でも同様の結果になるかを確認する進め方が実務的です。

検出項目・エラー・警告はどこを見る？

テストを実行すると、検出された構造化データの項目が一覧表示され、その下にエラーと警告が分けて表示されます。URLステータスには「クロールできません」や「構文にエラーがある構造化データが検出されました」などがあり、robots.txtやnoindexでクロールを禁止しているページはそもそもテストできません（出典）。リッチリザルト テストはユーザーの認証情報ではなくGoogle-InspectionToolとしてページへアクセスするため、robots.txtでのブロック状況も事前に確認しておく必要があります。

結果を共有・保存するにはどうする？

リッチリザルト テストのテスト履歴、および結果の共有リンクは、いずれも有効期間が約90日となっています（出典）。チームで結果を確認したい場合は共有リンクを発行できますが、90日を過ぎると閲覧できなくなるため、恒久的な記録として残したい場合はスクリーンショットや別ドキュメントへの転記を併用すると安心です。

TechSuite株式会社の「AI検索パートナーズ」は、コンサルティングという性質上、業種や商材、既存の実装状況に合わせて構造化データの設計とチェック体制をそれぞれ個別に組み立て、ボトルネックとなっている項目を特定してから解決策の実行まで伴走しています。手順そのものは共通でも、どこを重点的に見るべきかは案件ごとに異なるため、テンプレート的な運用だけでは拾いきれない課題にも対応できます。

エラー・警告メッセージの意味と直し方

JSON-LDチェックで頻出するのは「無効なJSONドキュメントです」のような構文エラーと、必須プロパティ不足の警告です。原因の多くはカンマや引用符の付け忘れ、全角文字の混入、@typeの表記ミスにあります。エラーメッセージの原文を理解しておくと、修正すべき箇所を素早く特定できます。

Googleが示す代表的な構文エラーには、次のようなものがあります（出典）。

エラーメッセージ	主な原因	対処法
無効なJSONドキュメントです	末尾カンマ、引用符の閉じ忘れ、全角文字の混入	JSON構文を半角に統一し、フォーマッタで整形する
値の型が正しくありません	数値を文字列で入れるなどの型ミスマッチ	各プロパティの型仕様を公式ドキュメントで確認する
解析エラー「コロンがありません」	キーと値の間のコロン抜け	エディタでコロンの有無を1行ずつ確認する
「カンマ」または「閉じ括弧」がありません	括弧やカンマの数が対応していない	JSONフォーマッタで自動整形し対応関係を確認する
一意のプロパティが重複しています	@contextを2つ記述するなどの重複	重複したプロパティを1つに統一する
最上位の要素が無効です	@typeやスキーマ全体の構造誤り	公式スキーマのサンプルと構造を突き合わせる

『無効なJSONドキュメントです』はなぜ出る？

このエラーは、JSONとしての文法そのものが崩れている場合に表示されます。末尾のトレイリングカンマ、引用符の閉じ忘れ、コピー時に紛れ込んだ全角のカンマや引用符が典型的な原因です。エディタの全角半角チェック機能や外部のJSONフォーマッタを併用すると、目視だけでは見つけにくい記号ミスを検出しやすくなります。

『値の型が正しくありません』はどう直す？

このエラーや「一意のプロパティが重複しています」という警告は、価格を文字列で記述してしまう、@contextを誤って2回記述してしまうなど、値の種類や記述回数のルール違反が原因です。公式スキーマの記述例を見ながら、該当プロパティの型と個数を1つずつ照らし合わせて修正します。

必須プロパティ不足の警告はどう補う？

必須プロパティ不足の警告は、そのスキーマタイプで求められる項目が記述されていない場合に表示されます。前述のArticleやProductなどの必須プロパティ一覧と実際のコードを照らし合わせ、不足している項目を本文の内容に基づいて追記することで解消できます。

クロールできないと表示されるときは？

「クロールできません」という表示は、robots.txtでの禁止設定やnoindex指定によってページ自体にアクセスできない場合に出ます。リッチリザルト テストはGoogle-InspectionToolとしてアクセスするため、通常のブラウザで見えていてもクロール制限があれば検証できません。robots.txtの記述とページのメタタグを合わせて確認する必要があります。

TechSuite株式会社の「AI検索パートナーズ」は、技術的な検証を担う人材とコンテンツを制作する人材が同じチームで連携し、エラーの検知から修正方針の策定、公開後の確認までを一気通貫で支援しています。エラーメッセージの原文を読み解く工程と、内容面の修正を切り離さずに進められる点が、対応スピードにつながっています。

公開前に潰す！JSON-LDの見落とし7項目チェックリスト

公開前に見落としやすいのは、必須プロパティ不足、@typeの表記ミス、相対URL、記号や全角文字の混入、ネストされたオブジェクトの@type抜け、実際のページ内容との不一致、コメントの残存という7項目です。この7つを1つずつ確認するだけで、公開後に発覚する手戻りをかなり減らせます。

7項目の内容と対処法を一覧にまとめました。

項目	内容	対処法
必須プロパティの過不足	ArticleやProductなど各タイプの必須項目が不足している	各スキーマの必須プロパティ一覧と照合する
@typeのスペル・大文字小文字ミス	faqpageのような誤記が残っている	公式ドキュメントの正しい表記（FAQPage等）に統一する
URLが絶対パスかどうか	相対パスは正しく解釈されない場合がある	https://から始まる絶対URLに修正する
末尾カンマ・引用符・全角文字	JSON構文エラーの主な原因になる	半角に統一しフォーマッタで整形する
ネストされたオブジェクトの@type抜け	authorやofferなど入れ子部分の型指定漏れ	入れ子ごとに@typeと必須項目を確認する
ページに表示されていない内容のマークアップ	本文にない情報を構造化データにだけ記述している	実際の掲載内容と一致させる
JSON-LDブロック内のコメントの残存	テストでは無視されるが標準非対応で実運用時にエラーの恐れがある	公開前に必ず削除する

記述ミス系の3項目とは？

必須プロパティの不足、@typeの表記ミス、相対URLの3つは、いずれも「そのスキーマタイプとして正しく認識されるか」に直結する項目です。構造化データ内のURL（image・url・@id等）はhttps://から始まる絶対URLで記述することが基本で、相対パスは正しく解釈されない場合があります（出典）。

構文・ネスト系の項目はどう見る？

記号や全角文字の混入はJSON構文エラーの主な原因であり、ネストされたオブジェクトの@type抜けは一見エラーにならなくても認識精度を下げる要因になります。authorやofferのように入れ子構造を持つプロパティは、親だけでなく子の@typeと必須項目まで確認する必要があります。

運用ルール系の項目はなぜ重要？

ページに実際に表示されていない内容をマークアップすることは、Googleのガイドライン上望ましくないとされています。技術的には記述できても実際の掲載内容と一致させることが前提です。また、JSON-LDブロック内のコメントはリッチリザルト テストでは無視されますが、JSON-LD標準ではサポートされないため、公開前には必ず削除しておく必要があります（出典）。この点はLLMO対策のチェックリストと合わせて運用すると、コンテンツ全体の整合性も保ちやすくなります。

TechSuite株式会社の「AI検索パートナーズ」は、AIを活用した記事制作サービス「バクヤスAI記事代行」で培った制作エンジンとノウハウをLLMO対策に転用しており、想定質問の分解に沿ったコンテンツ設計と合わせて、必須プロパティなど構造化データの必須項目もあらかじめ制作段階で組み込むことで見落としを防いでいます。

チェック後も安心して運用するにはどうすればいい？

チェックに合格しても必ずリッチリザルトが表示されるわけではなく、公開後はSearch Consoleの拡張レポートで表示状況を継続的に監視し、AI検索時代を見据えて構造化データの一貫性を保つことが重要です。構文チェックはあくまで入口であり、その後の運用まで含めて考える必要があります。

「チェック合格」と「実際の表示」は別物であることを踏まえ、公開後の見方を整理しておきます。

実装しても表示されない理由は？

構造化データを正しく実装しても、リッチリザルトの表示はGoogleのアルゴリズムによる判断であり、必ず表示されるとは限りません。対象のリッチリザルトタイプに該当していない、あるいは品質やコンテンツポリシーに合致していないと判断された場合は表示が見送られることがあります（出典）。表示状況はSearch Consoleの「拡張」レポートで確認できます。

『拡張』レポートで何を確認する？

Search Consoleの拡張レポートでは、構造化データがどのくらいのページで検出され、有効・警告・エラーがどう分布しているかを継続的に確認できます。日次のグラフでエラーが急増していないかを定期的に見ておくと、テンプレート変更などによる不具合の早期発見につながります。

確認項目	内容	対応の目安
ステータス	有効/警告/エラーの件数	エラーが増えていないか定期確認する
対象URL数	構造化データが検出されたページ数	想定するページ数と一致しているか確認する
詳細タイプ	FAQ/記事/商品等の分類	意図したタイプで認識されているか確認する
トレンド推移	日次のグラフ変化	急な増減があれば実装変更を疑う

AI検索時代にJSON-LDチェックが重要な理由は？

構造化データは、検索エンジンだけでなく生成AIがページの内容を理解する際の手がかりにもなります。スペルミスや構文ミスがあると、AIが内容を正しく認識できず、AI検索の回答やAI Overviewでの引用機会を逃す可能性があると考えられます。AI検索対策の進め方やGEOとは何かを合わせて理解しておくと、構造化データの整備がAI検索対応全体のどこに位置づくかが見えやすくなります。

TechSuite株式会社の「AI検索パートナーズ」は、構造化データの整備を含むAI検索対応の支援先において、AI検索経由の受注率が従来のSEO経由の約3倍に達した実績があり、露出や順位だけでなく受注という成果につながる施策設計を重視しています。

よくある質問

リッチリザルト テストとスキーマ マークアップ検証ツールの違いは？

リッチリザルト テストはGoogle固有のリッチリザルト対応を検証するツールで、スキーマ マークアップ検証ツールはschema.org全体の構文を検証する汎用ツールです。Googleはまずリッチリザルト テストで確認し、より広範な検証にはスキーマ マークアップ検証ツールを併用することを案内しています。

JSON-LDとMicrodataはどちらを使うべきですか？

Googleが推奨する記述形式はJSON-LDです。本文のHTMLと構造化データを分離して管理できるため保守性が高く、多くのCMSやプラグインもJSON-LD形式を前提に実装機能を提供しています。

構造化データはSEO（ランキング）に効果がありますか？

構造化データ自体は直接的なランキング要因ではないとされていますが、リッチリザルト表示によるクリック率向上や検索エンジンの内容理解の促進を通じて間接的にSEOへ寄与すると言われています。

テスト結果はいつまで確認できますか？

テスト履歴の保存期間、および結果の共有リンクの有効期間はいずれも約90日です。90日を過ぎると履歴や共有リンクからは確認できなくなるため、必要に応じて再テストを実施してください。

まとめ

JSON-LDチェックは、構文エラーの有無とリッチリザルトへの対応状況という2軸を、リッチリザルト テストとスキーマ マークアップ検証ツールで役割分担しながら確認する作業です。手順に沿って検出項目とエラーを確認し、公開前には見落とし7項目を潰しておくことで、手戻りを大きく減らせます。

チェックに合格してもリッチリザルトの表示は保証されないため、公開後はSearch Consoleの拡張レポートで継続的に監視することが欠かせません。AI検索時代においても、構造化データの正確さは検索エンジンやAIがページ内容を理解するための重要な手がかりになると考えられます。

参考にした情報源

• リッチリザルト テストについて（Google検索セントラル）
• 構造化データのマークアップと管理（Google for Developers）
• 構造化データチェッカーの解説記事（in-site.jp）
• JSON-LDの書き方に関する解説記事（GIGラボ）