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

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

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

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

Contents / 目次

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

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

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

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

Googleが推奨している書き方はJSON-LD形式です。まずは、どのツールが何を教えてくれるのかを整理しておきましょう。

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

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

まず押さえること。指摘には「エラー」と「警告」の2種類があります。エラーがあるアイテムは無効になり、リッチリザルトとして表示できません。警告は推奨プロパティの不足などで、アイテムは有効なままです。そのため、エラーから先に修正します。Search Consoleのレポートでは、エラーは「アイテムが無効な理由」、警告は「検索での見え方を改善できるアイテム」の表に出ます。

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

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

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

最初にやるのは、サイト全体で「どのタイプに」「何件」エラーが出ているかの把握です。Search Consoleのナビゲーション バーの［拡張機能］に、パンくずリストやレビュー スニペットなど、タイプごとのリッチリザルト レポートが並びます。レポートが表示されるのは、サポートされているタイプのうち、Googleがサイトで有効なマークアップを検出したものだけです。Article（記事）のレポートはありません。

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

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

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

エラー表示には「どのプロパティが問題か」が書かれています。たとえば「項目『image』がありません」のように、項目名が表示されます（推奨プロパティの不足は、エラーではなく警告として出ます）。ここで表示された項目名を、あとで直すためにメモしておきましょう。エラーの多くは、次の3つのどれかに当てはまります。

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

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

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

<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）で書きます。Googleの記事（Article）の説明では、日付をISO 8601形式で書き、タイムゾーンも入れるよう勧めています。「2026/07/19」のような形はISO 8601形式ではありません。

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

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

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

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

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

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

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

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

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

「修正を検証」を実行すると、修正が機能しているかを確かめられ、Googleによる再クロールも早まります。進み具合もログで確認できるので、直したら検証開始まで行ってください。

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

構造化データのエラーを修正すると、検索エンジンがページの内容を正確に読み取れるようになります。なお、GoogleはGoogle 検索の生成 AI 機能向けにウェブサイトを最適化するのページで、生成AI検索に構造化データは必要ないと説明しています。リッチリザルトの対象になるために、SEO全体の一部として使い続けることは勧めています。ただし、ここは誤解が多いので先に線引きします。エラーを直しても、検索順位が直接上がることは保証されませんし、リッチリザルト（検索結果での特別な表示）が必ず出るわけでもありません。

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

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

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

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

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

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

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

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

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

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

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

Googleがサポートを終了した構造化データのタイプを、そのまま実装し続けている失敗もよく起きます。たとえばFAQのリッチリザルトは、2026年5月7日からGoogle検索に表示されなくなり、説明のページも2026年6月15日に削除されました。HowTo（手順）のリッチリザルトも、2023年9月に表示が終わっています。Search Consoleのリッチリザルト レポートの対象にも、FAQとHowToは入っていません。どのタイプが今どのように扱われるかは変わることがあるため、使う前にGoogle検索セントラルで最新の対応状況を確認する必要があります。

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

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

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

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

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

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

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

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

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

まず、プラグインとテーマの両方が同じArticleを出力していると、構造化データが二重に出力されます。AIで生成したサイトやコードを使っている場合も、同じことが起きることがあります。

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

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

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

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

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

ここまで読んで、テンプレート全体の修正やAI生成サイトの構造化データの修正まで手が回らない、判断に自信が持てないと感じた方は、気軽に相談してください。ホームページ制作・LP制作では、ホームページの新規制作やリニューアルの際に、実装の工程で構造化データを入れます。まずは現状を伺うところからでも大丈夫です。