構造化データのエラー：修正と検証

構造化データのエラーは、Search Consoleで問題の種類と影響範囲を確認し、サイト側を直して公開した後、修正の検証を始めます。ボタンを押す前に、同じ原因のページまで修正できているかを確かめてください。

公開前に一つのコードやURLを調べる操作は構造化データの検査⁠で扱っています。ここでは、公開後にGoogleが見つけた問題を、まとめて直し、検証結果を追う流れに絞ります。

製造業の製品ページや、技術記事のパンくずで同じ問題が繰り返し出たときは、ページを一枚ずつ直す前に共通の出力元を調べます。修正先が一つの型なら、そこを直した版を全対象へ反映します。

最初にどの画面を開く？

Googleのレポートの概要では、拡張の欄に種類ごとのレポートがあり、商品スニペットや販売者の情報はショッピングの欄にあると説明しています。対象の種類を選び、無効な項目の理由から問題を開きます。

記録するのは、種類、問題名、表示されたURL、最終クロールの情報です。修正を頼むときにエラー画面の数字だけを渡すと、担当者はどのコードを見ればよいか分かりません。

表示がない種類は、問題がゼロと判断しません。レポートが出る条件には、Googleが対応する種類の有効なマークアップを見つけていることが含まれます。未検出か、対象外かを切り分ける必要があります。

エラーと警告をどう分ける？

重大な問題が一つでもある項目は無効となり、その項目はリッチリザルトの対象になりません。重大ではない問題は改善点として扱われ、有効な項目にも付くことがあります。

従来の解説でエラーと警告と呼ばれていても、今の画面の区分と問題の説明を読んで対応します。色だけを見て、すべて同じ修正期限にしないでください。

警告を消すために、存在しない価格や評価を足しません。Googleの一般的な指針は、画面に見えない内容をマークアップしないよう求めています。必要な値を持っていないなら、事実を確認する作業へ戻します。

数字はページ数なのか？

レポートの数字は構造化データの項目数です。たとえば一つのページに別々の項目があれば、そのページだけで複数件になります。一つの項目が複数の問題を持つこともあるため、問題の件数を足してページ数と呼ばないでください。

Googleの公式概要には、全件の一覧ではなく、品質を把握するための標本だと書かれています。レポートにないURLでも、URL検査で確認する必要があります。

numbers in the reports reflect items not pages

項目とページを区別する、この注意書きが修正の分担に直結します。制作担当へ渡す表では、問題の件数と、同じ型を使う公開URLの範囲を別の欄にしてください。

どこを直すか決めるには？

問題の詳細で例のURLを開き、対象の項目と値を見ます。同じ型のページを選び、値があるものと空欄のものを比べます。元データの不足か、型の出力の誤りかで、直す担当が変わります。

見つかった状態ごとに、調べる場所をまとめます。

生成済みのHTMLだけを手で直すと、次に組み立てたとき戻ることがあります。元の入力か、出力する型へ修正を入れます。どこを変え、どのページへ効くかを修正記録へ残します。

画面と同じ内容かも見る

私たちは暦の自社メディアで、一覧のFAQを構造化データにだけ入れ、画面には出していませんでした。答えを画面にも出す形へ直しています。出典は自社メディアの運営記録です。

レポートに出たエラーではなく、構文が通っていても読者に答えが届いていなかった例です。警告が消えても、画面と値が違っていれば修正は終わりません。

公開後は何を確かめる？

Googleの修正の公式手順は、特定の問題を関連URL全体で直してから、公開し、取得できる状態を確認する流れです。型の問題なら、修正した型を使うページ全体へ反映します。

Search ConsoleのURL検査の説明⁠に沿い、公開URLをテストします。登録済みの版と今公開している版は、同じとは限りません。古い取得結果だけを見て、直っていないと結論づけないようにします。

代表として選ぶのは、標準的な製品ページだけではありません。必須値の境界、任意項目が空の行、名前が長い行など、出力の分岐が違うページも見ます。問題のあった分岐を確かめた後に、全体の検証へ進みます。

修正の検証はいつ始める？

公開した修正が反映され、同じ問題が対象範囲で直ったことを確認してから、問題の詳細ページで修正の検証を始めます。Googleは最初に一部を調べ、問題が残っていれば検証が止まると説明しています。クロールの頻度によっては、検証に2週間以上かかります。

手元の修正完了、公開した版の確認、Google側の検証は別の状態として記録します。検証中という表示を、すでに合格した意味で報告しないでください。

検証を始めなくても、通常のクロールで修正が認識されることはあります。ボタンを押したことだけで解決するわけでも、押さなければ永久に反映しないわけでもありません。進捗を追うために、検証の履歴を使います。

失敗したら何を見直す？

失敗したURLを開き、前の修正が入っているか、別のデータ条件で同じ問題が残ったかを確認します。新しい種類の問題が見つかったなら、以前の修正と分けて扱います。

たとえば製品名が入る行だけ直し、空欄の行を出し続けていれば、同じ問題が残ります。無条件で全ページへ仮の名称を入れるのではなく、元データの補完ができるか、出力する対象を変えるかを決めます。

公式手順は、現在の検証が終わるのを待ってから再開するよう案内しています。検証の途中で何度も開始し直すより、失敗の原因と修正範囲を確かめ、修正した版を再確認します。

合格した後も見ることは？

有効になった項目が、必ず検索結果にリッチリザルトとして出るわけではありません。一般的な指針は、テストに通っていても表示を保証しないとしています。検証の合格と、実際の検索での表示は別々に扱います。

ランキングへItemListを付ける役割は一覧の構造化データ⁠で扱います。対象外の型が拡張レポートに出ないことを、今回の修正漏れと混ぜないでください。

再発を防ぐには、今回の原因を公開前の機械検査⁠へ戻します。構造化データの役割全体は構造化データの基本⁠にあります。計測と改善の記録には、エラー件数だけでなく、直した出力元と確認した公開URLを残してください。

仕様・出典の確認日：2026年10月27日⁠。