構造化データのエラー確認と直し方｜テストツール手順

「構造化データにエラーがあります」とSearch Consoleに出たけれど、どこを直せばいいか分からない。そんな状態で止まっていませんか。

この記事では、構造化データのエラーをテストツールで確認し、実際に直すところまでを手順で解説します。WordPressやHTMLを触る広報・Web担当の方に向けた内容で、読み終わる頃には「どのツールで何を見て、どこを直すか」の判断が自分でできる状態を目指します。JSON-LDのコード例も載せるので、コピーして自社用に書き換えられます。

なお、構造化データの前段にあたるインデックスの確認はサーチコンソールで除外を確認する手順で扱っています。まだページがインデックスされていない方は、先にそちらを確認すると回り道せずに済みます。

Contents / 目次

1. 構造化データのエラーは「2つのツール」で確認して直す
2. エラーを確認して直す手順。ツール操作から再検証まで
3. エラーを直すと何が変わるのか。成果のイメージ
4. よくある失敗と、その防ぎ方
5. 実務で見えてくる、構造化データの限界と割り切りどころ

構造化データのエラーは「2つのツール」で確認して直す

結論から言うと、構造化データのエラーはリッチリザルトテストで個別ページを検証し、Search Consoleでサイト全体を監視する、この2本立てで確認します。片方だけでは見落としが出ます。

構造化データとは、ページの内容を検索エンジンやAIが理解しやすいように、決められた形式で補足説明を書いたデータのことです。かんたんに言うと、ページに「これは記事です」「著者はこの人です」という名札を付ける作業です。この名札の書き方が間違っているとエラーになります。

2026年時点で主流の書き方はJSON-LD形式です。まずは、どのツールが何を教えてくれるのかを整理しておきましょう。

ツール	何を確認できるか	使う場面
リッチリザルトテスト	個別ページがGoogleのリッチリザルト対象として有効か。Google固有のエラー・警告	1ページずつ直したいとき、公開前の確認
スキーマ マークアップ検証ツール	Schema.orgの規格に沿った構文になっているか（Google固有の警告は出ない）	書き方そのものの文法チェック
Search Console リッチリザルトレポート	サイト全体で、どのタイプに何件のエラーがあるか	影響範囲の把握、テンプレート起因の一括発見
URL検査ツール	個別URLの、Googleが実際に取得した状態と修正の反映	直した後に反映を確かめるとき

ポイントは役割分担です。Search Consoleは「サイト全体でどこが壊れているか」を教えてくれますが、細かい原因までは分かりにくい。そこで、指摘されたページをリッチリザルトテストにかけて、具体的なエラー箇所を突き止めます。ツールの正確な名称や仕様は変わることがあるため、Google検索セントラルの構造化データ マークアップをテストするページで最新の案内を確認してください。

まず押さえること。エラーには「必須項目が足りないエラー」と「あると良い項目が足りない警告」の2種類があります。検索結果への影響が大きいのはエラーの方なので、直す優先順位もエラーが先です。

エラーを確認して直す手順。ツール操作から再検証まで

ここからが本題です。実際の直し方を、確認から再検証まで順番に進めます。特別な知識がなくても、上から順にやれば1つのエラーは直せます。

ステップ1。Search Consoleで壊れている範囲をつかむ

最初にやるのは、サイト全体で「どのタイプに」「何件」エラーが出ているかの把握です。Search Consoleの左メニューに「拡張」や「リッチリザルト」といった項目があり、そこにパンくずリストやArticleなど、タイプごとのレポートが並びます。

ここで見るべきは、エラーの件数と対象URLの数です。1つのテンプレートから作られた記事ページがまとめてエラーになっている場合、原因は個別ページではなくテンプレート（WordPressのテーマやプラグイン）にあります。数十件が同じエラーなら、まずテンプレートを疑うのが近道です。全体の直し方はSearch Consoleで構造化データの問題を修正するヘルプで公式に手順が示されています。

ステップ2。リッチリザルトテストで原因のプロパティを特定する

次に、エラーが出ている代表URLを1つ選び、リッチリザルトテストにかけます。URLを入力して検証すると、検出されたタイプと、赤いエラー・黄色い警告が一覧で出ます。

エラー表示には「どのプロパティが問題か」が書かれています。たとえば「image フィールドがありません」「author が指定されていません」といった具合です。ここで表示された項目名を、あとで直すためにメモしておきましょう。エラーの多くは、次の3つのどれかに当てはまります。

• 構文ミス：カンマや波かっこの閉じ忘れ、日付フォーマットの誤りなど書き方の間違い
• 必須プロパティの欠落：そのタイプに必要な項目（Articleならauthorやpublisherなど）が抜けている
• 内容の不一致：構造化データに書いた情報が、ページ本文に存在しない・矛盾している

ステップ3。JSON-LDを正しい形に書き換える

原因が分かったら、実際にコードを直します。構文ミスや必須項目の欠落は、正しい雛形と見比べるのが一番確実です。下は記事ページ向けのArticle構造化データの基本形です。コメントの箇所を自社の値に書き換えて使ってください。

<script type="application/ld+json">
{
  "@context": "https://schema.org",
  "@type": "Article",
  "headline": "記事のタイトルをここに入れる",
  "image": [
    "https://example.com/images/article.jpg"
  ],
  "datePublished": "2026-07-19T09:00:00+09:00",
  "dateModified": "2026-07-19T09:00:00+09:00",
  "author": {
    "@type": "Person",
    "name": "著者名を入れる"
  },
  "publisher": {
    "@type": "Organization",
    "name": "会社名を入れる",
    "logo": {
      "@type": "ImageObject",
      "url": "https://example.com/images/logo.png"
    }
  }
}
</script>

書き換えるときに事故が起きやすいのが日付の形式です。datePublishedは「年-月-日T時:分:秒+時差」の形（例では日本時間の+09:00）で書きます。ここを「2026/07/19」のような形にするとエラーになります。

もう1つ、次の3点を守るだけで、構文エラーの多くは消えます。

• 値をダブルクォーテーションで囲む
• 項目の区切りにカンマを付ける
• 最後の項目にはカンマを付けない

手で書いたコードは、公開前に必ず構造化データのテストと検証ツールにかけて、構文エラーが残っていないか確認してください。

ステップ4。内容の不一致をなくす

内容の不一致は、ツールでは「エラー」と出ないことも多く、見落とされがちです。構造化データは、あくまでページに書いてある内容の補足です。ページ本文に載っていない評価スコアやレビュー件数を構造化データにだけ書くのは、Googleのガイドライン違反にあたります。

直し方はシンプルで、構造化データに書いた項目が、本当にページ上に表示されているかを目視で1つずつ確認します。著者名、公開日、価格、レビューなど、書いた情報が画面にも見えていればOKです。片方にしか無いものは、本文に足すか、構造化データから消すかのどちらかで揃えます。

ステップ5。直したページを公開して再検証する

コードを直したら、修正版を実際のページに反映（公開）します。下書きのままではGoogleは新しい状態を見られません。公開したら、もう一度リッチリザルトテストに同じURLをかけて、エラーが消えたかを確認します。

そのうえで、Search Consoleの該当エラーの詳細画面にある「修正を検証」を実行します。これを押すとGoogleがサンプルページをチェックし、問題が解決していれば、同じエラーを持つ他のページの検証にも進みます。検証には数日かかることがあるので、押したあとは待ちます。ここまでが1エラーを直しきる一連の流れです。

「修正を検証」を押さずに放置すると、Search Console上ではエラー扱いのまま残り続けます。直したつもりでもレポートが更新されないので、必ず検証開始まで行ってください。

エラーを直すと何が変わるのか。成果のイメージ

構造化データのエラーを直すと、検索エンジンやAIがページの内容を正確に読み取れるようになります。ただし、ここは誤解が多いので先に線引きします。エラーを直しても、検索順位が直接上がることは保証されませんし、リッチリザルト（検索結果での特別な表示）が必ず出るわけでもありません。

構造化データの役割は、あくまで検索エンジンに内容を正しく伝える「ヒント」です。とはいえ、検索エンジンに内容を正しく伝えておく価値は変わりません。ページの意味が正確に伝わっていれば、内容を取り違えられるリスクを減らせます。

成果として現れやすいのは、次のような変化です。順位そのものより、検索結果での「見え方」や「拾われやすさ」が整う方向に効きます。

• 検索結果の表示が整う：パンくずリストや記事情報が正しく認識され、意図しない表示崩れが減る
• 内容が正しく伝わる：ページの著者・公開日・内容の対応関係が明確になり、検索エンジンがページの内容を取り違えにくくなる
• Search Consoleが静かになる：エラー通知が止まり、本当に見るべき別の問題に集中できる

実際の運用では、エラーを直すことそのものより「エラーが出ない状態を保つ仕組み」を作れているかで差が付きます。エラーが出るたびに手作業で直していると追いつきません。テンプレート側で正しい構造化データを出力する設定にしておけば、新しい記事を追加してもエラーが増えないようになります。ここが、単発の修正と継続運用の分かれ目です。

なお、構造化データはSEO全体の一部です。土台となる内部対策と合わせて点検したい方はSEO内部対策チェックリストも参考になります。優先順位の付け方まで整理しています。

よくある失敗と、その防ぎ方

現場で実際によく見かける失敗を挙げます。どれも「知っていれば避けられる」ものばかりなので、直す前にひと通り目を通しておくと、同じ落とし穴にはまらずに済みます。

失敗1。実装すれば順位が上がると思い込む

一番多い誤解が、構造化データを入れれば検索順位が上がる、リッチリザルトが必ず出るという思い込みです。この前提で作業すると、エラーを全部消したのに順位が動かず「意味がなかった」と結論づけてしまいます。

構造化データは内容を正確に伝えるためのもので、順位や表示を約束する仕組みではありません。 防ぐには、目的を「表示崩れをなくし、正しく理解してもらうこと」に設定しておくことです。順位対策は別軸として、コンテンツの質や内部対策で取り組みます。

失敗2。サポートが終了したタイプを使い続ける

Googleがサポートを終了した構造化データのタイプを、そのまま実装し続けている失敗もよく起きます。構造化データのタイプによっては、実装しても期待した表示が出ないことがあります。どのタイプが今どのように扱われるかは変わることがあるため、使う前にGoogle検索セントラルで最新の対応状況を確認する必要があります。

この状態だと、期待した表示が出ないうえ、レポートから項目が消えて「エラーが直ったのか消えたのか分からない」という混乱を招きます。防ぐには、Google検索セントラルの最新情報を定期的に確認し、終了したタイプは削除するか別の構造化データに切り替えます。FAQ構造化データの現状についてはFAQ構造化データが表示されない原因と実装手順で詳しくまとめています。

失敗3。ページに無い情報を構造化データに書く

レビューの星評価やパンくず情報を、ページに表示していないのに構造化データにだけ書き込む失敗です。件数を盛る意図がなくても、テンプレートの使い回しで起きてしまうことがあります。ページに表示していない情報を構造化データに書くと、内容とページが食い違った状態になり、正しく認識されず、リッチリザルトが表示されなくなることがあります。

防ぐには、構造化データに書いた項目が必ずページ上にも見えている状態を保つことです。テンプレートを作るときに「表示している情報しか構造化データに入れない」というルールを最初に決めておくと、あとで慌てずに済みます。

失敗4。1ページを直して満足してしまう

リッチリザルトテストで1ページのエラーを消して安心し、他のページを放置する失敗です。テンプレート起因のエラーは、同じ構造の全ページで同時に起きています。1つ直しても、残り数百ページは壊れたままです。

防ぐには、直す前にSearch Consoleで影響ページ数を確認し、テンプレート側を修正することです。テンプレートを直せば、対象ページがまとめて解消され、再検証も一括で進みます。

実務で見えてくる、構造化データの限界と割り切りどころ

ここは教科書には載りにくい、現場でぶつかる本音の部分です。構造化データは「やれば全部良くなる」ものではなく、力を入れるべき所とそうでない所があります。

まず、AIで生成したサイトやコードを使っている場合、構造化データが二重に出力されていることがよくあります。プラグインとテーマの両方が同じArticleを出力していて、検索エンジンがどちらを信じればいいか迷う状態です。

これはエラーとしては出ないのに評価が安定しない、という厄介な形になります。AIにコードを書かせたときは、公開前に「同じタイプの構造化データが2つ出ていないか」を必ず確認してください。ここはAIが見落としやすく、人の目が要る部分です。

次に、プラグインへの依存です。WordPressのSEOプラグインは構造化データを自動生成してくれて便利ですが、プラグインの仕様が変わると、ある日突然エラーが増えることがあります。自動化に任せきりにせず、月に一度はSearch Consoleのレポートを見る習慣を持っておくと、変化に早く気づけます。

内製と外注の線引き。1ページ単位の修正や日付フォーマットの直しは、この記事の手順で自社でも十分できます。一方、テンプレート全体の設計、複数タイプの整理、AI生成サイトの重複解消は、HTMLとSEOの知識が両方必要になり、判断ミスが全ページに波及します。ここは外部の目を入れた方が結果的に速くて安全です。

もう1つ率直に言うと、構造化データは「やれば必ず報われる」施策ではありません。エラーをゼロにしても、コンテンツ自体が読者の検索意図に合っていなければ成果は出ません。構造化データの整備は、良いコンテンツがある前提で効いてくる補助輪です。順番を間違えないことが、限られた時間を無駄にしないコツです。

この記事は出口宣佳（株式会社コレットラボ）が、実際の中小企業サイトの改善現場で見てきた内容をもとに書いています。

まずは今日、自社サイトの記事を1ページだけリッチリザルトテストにかけて、赤いエラーが出ていないか見てみてください。1分で状況が分かります。もし構造化データより先にインデックスでつまずいていそうなら、ホームページが検索で出てこない原因と直し方から確認するのがおすすめです。

ここまで読んで、テンプレート全体の修正やAI生成サイトの構造化データ整理まで手が回らない、判断に自信が持てないと感じた方は、気軽に相談してください。コレットラボは、検索エンジンにもAIにも正しく伝わるサイトづくりを、現状の整理から一緒に進めます。AI時代に引用される記事・サイトづくりの詳細はこちらで取り組みをご紹介しています。まずは現状を見せてもらうだけでも大丈夫です。