「解析不能な構造化データ」とは？サーチコンソールに出たときの原因の見つけ方

Search Console を開いたら、左のメニューに見慣れない「解析不能な構造化データ」という項目が増えていて、赤いエラーが並んでいる。構造化データを自分で書いた覚えはあまりない。何が壊れているのか、どこを直せばいいのか、放っておくと順位に響くのか。そんな人に向けて書いています。

先に答えを書くと、このレポートに出ているのは「書き方の文法が崩れていて、Google が中身を読めなかった構造化データ」です。読み終えるころには、レポートの行から壊れている箇所までたどり着き、テストで確かめてから直す順番が分かるはずです。

結論: 構文が読めなかった構造化データの一覧

構造化データは、ページの内容(記事のタイトル、公開日、パンくずの階層など)を、検索エンジンが読みやすい決まった形で書き添えたものです。ブログでは、ページの HTML の中に JSON-LD という形式で書かれていることが多く、テーマや SEO プラグインが自動で出していることもよくあります。

Search Console ヘルプの解析できない構造化データのレポートは、レポートの中身をこう説明しています。

このレポートには、重大な構文エラーが原因で解析できなかった、サイト内の構造化データの一覧が表示されます。解析エラーがあると、構造化データの意図するタイプ（ジョブ、イベントなど）を判別できなくなります。

ヘルプのページの題は「解析できない構造化データのレポート」ですが、同じページの中で「解析不能な構造化データ」とも書かれていて、指しているものは同じです。続けて「このレポートは、Google がサイトで解析不能な構造化データを検出した場合にのみ、プロパティで利用できます。」とあるので、このメニューが見えていること自体が、読めない構造化データが見つかったという知らせです。ずっと見えていなかったのに急に増えたように見えるのは、そのためだと考えられます。

また、ヘルプには「このレポートに記載されている項目はすべて構造化データの重大なエラーです。警告や有効な項目はありません。」とあります。ほかの構造化データのレポートのように、有効・警告・エラーの3段に分かれてはいません。並んでいるのは全部エラーです。

パンくずなど、種類ごとのレポートに出てこない理由

構造化データを入れているサイトでは、Search Console の「拡張機能」の下に、パンくずリストや動画など、種類ごとのレポートが出ます。その見方と、エラー・警告・有効の意味はサーチコンソールの拡張レポートとは、構造化データのエラーは順位ではないに書きました。

「解析不能な構造化データ」に出ているものは、そうした種類ごとのレポートには出てこない、と私は考えています。理由は、上の引用の2文目です。種類ごとのレポートに振り分けるには、それがパンくずなのか動画なのかが分からないといけません。ところが構文が崩れていると、Google はそこまで読み進められず、どの種類の構造化データのつもりだったのかが分からない。だから、種類を問わずこの1つのレポートにまとめて出てくる、という読み方です。ヘルプに「種類ごとのレポートには出ない」と書いた一文があるわけではないので、ここは私の読みとして書いています。

この読み方を裏づける一文も、同じヘルプにあります。

こうした解析エラーを修正すると、項目をまったく解析できなかったことが原因でそれまで見つからなかった警告やエラーが新たに検出されることがあります。

構文を直すと、Google はようやく中身を読めるようになり、そこで初めて「パンくずの項目が足りない」といった、種類ごとの問題が見つかることがある、ということです。解析不能のエラーを直したあとに、別のレポートに新しいエラーが出ても、直し方が悪かったとは限りません。読めるようになったので、次の段階の問題が見えた、と受け取ってください。

エラーの種類は、3つに分けて読む

ヘルプには、このレポートに出るエラーの種類が表で17個並んでいます。名前は難しく見えますが、何がおかしいかで分けると3つにまとまります。下の表の左の列は、ヘルプの表に書かれている名前そのままです。真ん中の「分け方」は、私が読みやすくするために付けたものです。

いちばん大づかみなのが「無効な JSON ドキュメントです」で、ヘルプの説明は「JSON に最上位構文エラーがあります。」です。ブログで JSON-LD を使っているなら、1つ目の行の名前が出ていれば、括弧やカンマを数えるところから始めます。

3つ目の行の「一意のプロパティが重複しています」には、ヘルプに「@context 値が 2 つあります。」という例が付いています。JSON-LD の書き出しにある「@context」が、1つのまとまりの中に2回書かれている、ということです。最後の「存在しない項目を参照しています」の説明は「itemref 属性が存在しない識別子を参照しています。」で、これは JSON-LD ではなく、HTML のタグに属性として書く microdata という形式で出るものです。構造化データの形式には JSON-LD・microdata・RDFa の3つがあり、Google 検索セントラルの構造化データに関する一般的なガイドラインでは JSON-LD が「推奨」とされています。

壊れている JSON-LD を見つけて、テストで確かめる手順

エラーの名前が分かったら、実際に壊れている箇所を探します。私は次の順で進めています。

1. レポートのエラーの行を押して、該当するページの URL を見る。ヘルプには「エラーの行をクリックすると、該当するページ、エラーの詳細、デバッグツールへのリンクが表示されます。」とあります。並んでいる URL が、記事のページばかりか、トップページだけか、カテゴリーのページだけか、をまず見ます。
2. そのページをブラウザで開き、ページのソースを表示して「ld+json」で探す。JSON-LD は、ソースの中でこの手順の下に示した形の行から始まります。1ページに複数あることもあるので、見つかった数も数えておきます。
3. リッチリザルト テストに URL を入れて、どの構造化データが読めていないかを見る。読めない構造化データがあると、結果のステータスに「構文にエラーがある構造化データが検出されました」と出ることがあります。
4. 怪しい JSON-LD の部分をコピーして、リッチリザルト テストの「コード」に貼り、直しながらテストし直す。
5. 直したら、公開しているページをもう一度テストし、Search Console で「修正を検証」を押す。

<script type="application/ld+json">
{ ……ここに構造化データ…… }
</script>

手順3と4で使うリッチリザルト テストのヘルプには、URL のほかにコードを直接試す使い方も書かれています(「ツールのランディング ページで、テストの対象として URL の代わりに [コード] を選択し、テストするコードを貼り付けます。」)。結果の「検出された項目」の欄については「構造化データが見つかったにもかかわらず解析できない場合は、ここに表示されます。」とあります。

どこが崩れているか見つけにくいときのやり方も、解析不能のレポートのヘルプに書かれています。

リッチリザルト テストを使用して、構造化データの構文を修正、テストします。エラーが見つからない場合は、空のオブジェクトから開始し、エラーが見つかるまで、問題があるコードの一部を順に追加しながら確認します。

日本語版は「エラーが見つからない場合は」ですが、英語版は "If you are having problems finding the error" で、「エラーの場所を見つけにくいときは」(私の訳)という意味です。空の {} から始めて、元のコードを少しずつ戻し、テストがエラーを出した時点で、直前に戻した部分が怪しいと分かる、というやり方です。

ページのソースで見つからないのにテストでは構造化データが出てくる場合は、JavaScript があとから書き足している可能性があります。テストのコード エクスプローラについて、ヘルプは「エクスプローラでは、レンダリングされたソースコードが使用されます。」と書いています。そのときは、ソース表示ではなくテストの画面のコードで探します。Google から見たページの状態を Search Console 側で確かめる URL 検査の読み方はサーチコンソールでインデックスを確認する方法に書きました。

ブログで、私がまず疑うところ

ここから先は、公式の記述ではなく私の当たりの付け方です(1つだけ公式に書かれているものは、そう断ります)。最初に見るのは、手順1で見た URL の並び方です。

解析不能のヘルプには「1 つのエラーが複数のページにわたって見られる場合の原因として最もよくあるのは、使用しているテンプレートのエラーです。」とあります。ブログでいうテンプレートは、テーマや SEO プラグインが全記事に同じ形で出している部分です。記事のページがまとめて出ているならテーマかプラグイン、1本の記事だけならその記事に自分で貼ったもの、と私は分けて考えています。

• 自分で貼った JSON-LD の書き損じ。記事のカスタム HTML の欄や、テーマの設定にある head へコードを足す欄に、どこかの見本を写して貼ったもの。閉じ括弧が1つ足りない、最後の項目のあとにカンマが残っている、引用符やコロンが全角(“ ” や ：)になっている、といったものを私はまず探します。日本語で書いた文章の中にそのまま「"」を入れてしまい、そこで文字列が切れていることもあります
• JSON-LD の中のコメント。これは公式に書かれています。リッチリザルト テストのヘルプは「リッチリザルト テストツールでは、JSON-LD ブロック内のコメントは無視されます。ただし、この動作は JSON-LD 標準ではサポートされていないため、実際の使用状況ではエラーが発生する可能性があります。最終的にページを公開する前には、JSON-LD からコメントを必ず削除してください。」と書いています。テストで通っても、コメントが残っていれば消す、と覚えておくと安全です
• テーマとプラグインの二重出力を、手で直したあと。テーマとプラグインが同じような構造化データを別々に出していること自体は、それぞれの JSON-LD が正しく書けていれば、構文の誤りにはならないはずだと私は考えています。私が疑うのは、二重になっているのに気づいて、片方を手で消したり、2つを1つにまとめ直したりしたあとです。括弧の対応が崩れたり、「@context」が2回残ったりしやすいからです。二重出力の確かめ方と、同じ種類が2つ出たときの扱いについて Google が書いていること・書いていないことはWordPressのSEOプラグインは必要？二重出力をソースで確かめるにまとめました
• テーマやプラグインを更新した直後から出始めた。自分では何も触っていないのに記事のページがまとめて出ているなら、更新で出力が変わった可能性を考えます。直すのは自分ではなく作者の側になることが多いと思うので、テストの結果を添えて問い合わせるか、その出力を止めて別の出し方にするかを決めます

どれに当たるかは、手順2で見つけた JSON-LD の数と、どれがどこから出ているか(テーマの名前やプラグインの名前が近くのコメントや属性に入っていることがあります)で、ある程度しぼれます。

直したあと: 修正を検証と、新しく出るエラー

公開しているページで直ったことをリッチリザルト テストで確かめたら、Search Console のエラーの詳細ページで「修正を検証」を押します。解析不能のレポートのヘルプは、検証にかかる時間を「検証は通常 2 週間ほどで完了しますが、それより長くかかる場合もあります。」と書いています。英語版は "Validation typically takes up to about two weeks, but in some cases can take much longer" です。拡張レポートの記事で引いた、Search Console の別のヘルプには「検証には、クロール頻度に応じて2週間以上かかる場合があります」とあり、2週間を過ぎることも珍しくない、と私は受け取っています。押した翌日に数字が減っていなくても、それだけで直っていないとは言えません。検証の流れ全体と、問題が表から消えるまでの扱いは、前に挙げたサーチコンソールの拡張レポートとは、構造化データのエラーは順位ではないの後半に書いています。

前に書いたとおり、構文を直すと、それまで読めなかった中身が読まれて、種類ごとのレポートに新しい警告やエラーが出ることがあります。そのときは、解析不能のレポートではなく、そちらのレポートでそれぞれの問題を見ていきます。

順位への影響は、このレポートのヘルプには書かれていない

いちばん気になるのは、放っておくと順位が下がるのか、だと思います。解析不能のレポートのヘルプには、日本語版にも英語版にも、順位への影響は書かれていませんでした。

構造化データと順位の関係で公式に書かれているのは、私が読んだ範囲では、構造化データに関する一般的なガイドラインの次の文です。

構造化データに関する手動による対策が実施されると、ページがリッチリザルトとして表示されなくなります。ただし、Google ウェブ検索でのページの掲載順位には影響しません。

ただし、これは「手動による対策」(Google の担当者がポリシー違反として処置したとき)についての文で、構文の誤りで読めなかった場合の話ではありません。サーチコンソールの拡張レポートとは、構造化データのエラーは順位ではないでは、いちばん重い手動対策ですら順位に影響しないことから、拡張レポートのエラーも順位の問題ではない、と読みました。解析エラーにも同じ読み方はできますが、公式が解析エラーについて書いた文ではないので、ここでは「順位に関係ない」とは断定しません。言えるのは、読めなかった構造化データは種類も分からないので、そのままではリッチリザルト(検索結果で星や階層などが付く見え方)の材料にならないだろう、というところまでです。

私は、順位のためというより、入れたつもりの構造化データが読まれていない状態を放っておかないために直しています。そして、記事が検索でどれだけ表示され、押されているかは、構造化データとは別に Search Console の検索パフォーマンスで見ます。そこから直す記事を選ぶ話は、記事の最後に書きました。

よくある質問

「解析不能な構造化データ」とは、何のことですか

ページに書かれた構造化データのうち、構文の誤り(括弧やカンマの不足、文字列の中の記号の崩れなど)のせいで、Google が読み取れなかったものです。Search Console では、それを集めたレポートの名前として出てきます。ヘルプによると、このレポートは読めない構造化データが見つかったときにだけ表示され、並ぶ項目はすべて重大なエラーです。

構造化データを入れた覚えがないのに出ています

ブログでは、テーマや SEO プラグインが自動で構造化データを出していることが多いので、入れた覚えがなくても出ることがあります。該当するページのソースで「ld+json」を探すと、何がいくつ出ているかが分かります。記事のページがまとめて出ているなら、ヘルプのとおりテンプレート(テーマやプラグインの出力)を先に疑います。

放っておくと、検索順位は下がりますか

解析不能のレポートのヘルプには、順位への影響は書かれていません。一般的なガイドラインにある「掲載順位には影響しません」は手動による対策についての文なので、解析エラーにそのまま当てはめることはできません。私は、構造化データが読まれていない状態を直す、という目的で対応しています。

直したのに、レポートのエラーが減りません

まず、公開しているページをリッチリザルト テストにかけて、本当に直っているかを確かめます。キャッシュのせいで古いページが返っていることもあるので、私はキャッシュを消してから試します。直っていれば、あとは Google がページを読み直すのを待つ段階です。解析不能のレポートのヘルプには「修正の検証を明示的にリクエストしたかどうかにかかわらず、Google は既知の問題のあるページをクロールするたびにインスタンス数を更新します。」とあります。

構造化データを外してしまっても、いいですか

外せば、その構造化データについての解析エラーは出なくなりますが、何のために入れていたかによります。ブログで何を入れておく価値があるかは構造化データのSEO効果は順位ではない、個人ブログがJSON-LDを入れる順番に書きました。外す前に、それがテーマの出力なのかプラグインの出力なのかを確かめておくと、あとで戻すときに迷いません。

まとめ

• 「解析不能な構造化データ」は、構文の誤りで Google が読めなかった構造化データの一覧。読めないものが見つかったときにだけ表示され、項目はすべて重大なエラー
• 解析エラーがあると、どの種類の構造化データのつもりかが判別できない。だから、パンくずなど種類ごとのレポートには出てこず、この1つのレポートにまとまる(私の読み)。直すと、種類ごとのレポートに新しい警告やエラーが出ることがある
• エラーの種類は17個。JSON の骨組み・文字列の中の記号・値や項目の書き方、の3つに分けて読む
• 直す順番は、レポートの行 → 該当ページの URL → ページのソースで「ld+json」を探す → リッチリザルト テストで確かめる → 直す → 修正を検証
• 多くのページに同じエラーなら、テーマやプラグインの出力を先に疑う。1本だけなら自分で貼ったものを疑う。JSON-LD の中のコメントは、テストで通っても消す(公式の記述)
• 順位への影響は、解析不能のレポートのヘルプには書かれていない。ガイドラインの「掲載順位には影響しません」は手動による対策についての文

この記事で引いた公式の情報は、Search Console ヘルプ2ページ(解析できない構造化データのレポート/リッチリザルト テスト)と、Google 検索セントラルのドキュメント1ページ(構造化データに関する一般的なガイドライン)です。いずれも2026年10月9日に日本語版と英語版を取得し、引用は原文と照合しました。Search Console ヘルプの日本語版には AI による翻訳を含む場合があるという注記があり、英語版と言い回しが違うところは本文でそう書いています。画面の表示やヘルプの文は変わることがあるので、自分の Search Console でも確かめてください。

構造化データを直し終えても、その記事が検索で読まれているかどうかは別の話です。検索結果に出ているのに押されていないのか、そもそも順位が届いていないのかは、Search Console の数字を記事ごとに並べてみないと分かりません。その切り分けのために私が作ったツールがあるので、ここから宣伝として書きます。

サーチコンソールのエクスポートをZIPのまま置くだけで、4.0〜20.5位のページを、表示回数100回以上は通常判定、30〜99回は参考判定、30回未満は本文中心の監査に分け、この順に、同じ区分の中ではCTR機会差(表示回数 × (期待CTR − 実CTR)で出す「回相当」の数)の多い順に並べて出します。 判定と候補3記事のCTR機会差の確認、そのうち1記事分の診断カードまでは無料です。有料は2,980円(税込)の買い切りで、無料の1件を除いた3記事分の診断カードが対象です。3記事分が揃うとき(判定に出た候補が4件以上のとき)だけご案内します。生成の利用期限は購入から7日間で、月額課金や自動更新はありません。ログインも不要です。 CSVファイルそのものはブラウザの外に出ませんが、診断カードを出すときは選んだ1ページぶんの数値(URL・キーワード・順位・表示回数・CTR)を、タイトル取得を押したときは最大10件のURLを送ります。

⚠️ このツールは、構造化データを調べません。読み込むのは Search Console の検索パフォーマンスのエクスポートだけで、解析不能な構造化データのレポートや、ページの JSON-LD は読みません。構文の誤りの確かめ方は、この記事の手順でリッチリザルト テストを使ってください。表示回数が0のページは扱えず、掲載順位4.0〜20.5位に入るページが無いブログでは、候補が0件になることがあります。順位やクリック数が上がることを約束するものでもありません。