Google Schema Markup Validatorの構造化データエラーをどう調べるか

まずエラーを確認し、いきなりコードを修正しない

　　技術評価担当者が google schema markup validator を使って構造化データを調査する際、最も陥りやすい落とし穴は「エラーが理解できない」ことではなく、赤字を見てすぐにフィールドを修正し、結果として問題をさらに複雑にしてしまうことです。より効果的な方法は、まずエラーがどの種類に属するかを判断することです。構文エラー、型エラー、フィールド不足、フィールド値の無効、あるいはページ内容とマークアップの不一致のいずれかを確認します。前の2種類は通常、解析失敗につながります。後の種類は解析できる場合が多いものの、検索エンジンによるデータ理解に影響し、深刻な場合はリッチリザルトが無効になることもあります。

　　日常的なコンテンツ管理ではなく、Webサイトの技術評価を担当している場合、重点的に判断すべきなのは次の3点です。エラーが解析を妨げるか、対象ページの検索表示に影響するか、テンプレートレベルの問題に該当するか。この3点によって修正の優先順位が決まります。

google schema markup validator のエラーは、まずどこから確認すべきか？

　　まず、構造化データがどのようにページへ埋め込まれているかを確認します。多くのサイトでは JSON-LD を手作業で記述するのではなく、CMS、テーマテンプレート、プラグイン、タグ管理ツール、またはフロントエンドコンポーネントによって動的に生成しています。出所を把握しないままでは、その後の原因特定が困難になります。

　　実際の調査では、通常、次の順序で確認します。

1. ページのソースに構造化データが何か所あり、それぞれどのタイプか。
2. エラーがどの部分を指しているか。JSON-LD、Microdata、RDFa のいずれか。
3. そのデータを生成しているのは誰か。テンプレート、プラグイン、またはAPIレスポンスか。
4. 同じ種類のページにも同じエラーが発生しているか。単一ページの問題か、一括発生している問題かを判断する。
5. ページ上の可視コンテンツがこれらのマークアップを裏付けているか。「マークアップはあるがページには表示されていない」という状態を避ける。

　　この手順は基本的に見えますが、非常に重要です。特に多言語サイト、製品サイト、記事サイトでテンプレートを共用している場合、同じコードでもページタイプによってまったく異なるエラーが発生する可能性があります。

よくあるエラーには何があり、優先順位はどう分けるべきか？

　　すべてのエラーが同じ深刻度というわけではありません。技術評価では、エラーを分けて確認することをおすすめします。

　　多くのチームは「警告」を放置しがちですが、その警告が依存しているリッチリザルトのフィールド、たとえば商品の価格、在庫、記事の公開日などに関係している場合、解析失敗を直接引き起こさないとしても、検索結果での表示に影響する可能性があります。

ページは正常に開けるのに、なぜ validator で構文エラーが出るのか？

　　ブラウザは多くのフロントエンド上の問題を許容できますが、構造化データのパーサーはそうとは限らないためです。典型的なケースは3つあります。

• バックエンドテンプレートで JSON を連結する際、あるフィールドが空になり、最後に余分なカンマが入っている。
• フィールド値にエスケープされていない二重引用符が含まれ、JSON-LD 全体が途中で途切れている。
• スクリプトで構造化データを動的に挿入しているものの、正しい JSON ではなくオブジェクトのテキストを出力している。

　　このような問題はページ上で目視確認するだけでなく、ソース内の application/ld+json の内容を直接確認してください。必要に応じて、JSON を1ブロックだけコピーして検証ツールで単独テストすると、ページ全体をまとめて確認するよりも迅速に原因を特定できます。

「フィールドが不足」と「フィールドが無効」の本質的な違いは？

　　両者には大きな違いがあります。フィールド不足は、そのマークアップの情報が不完全であることを意味します。フィールドが無効というのは、値は入力されているものの、認識される形式ではないということです。前者はテンプレートが業務データを完全に出力していない場合に多く、後者は形式、列挙値、データ型が正しくない場合に多く見られます。

　　よくある例として、商品ページに価格があるにもかかわらず、schema では価格を「USD 199」のように通貨と数値が混在したテキストで記述しているケースがあります。この場合、検証ツールは値が無効だと表示する可能性があります。また、日付を標準形式以外で記述すると、ページのユーザーには理解できても、パーサーには認識されないことがあります。

　　したがって、修正時はフィールド名を追加するだけでなく、フィールド値の形式が対応するタイプの要件を満たしているかも確認してください。技術評価の段階で、この点からデータソースの設計が適切かどうかを直接判断できます。

構造化データのタイプを間違えると、どのような結果になるのか？

　　タイプの選択ミスは、フィールドが1つ不足するよりも厄介です。単に「入力漏れ」があるのではなく、セマンティクス全体がずれてしまうためです。たとえば、企業サイトのサービスページに Product を無理に適用したり、一般的な情報ページに FAQ や Review を適用したりするケースです。ページ自体がその内容に対応していなければ、validator では一部が通過しても、検索エンジンはその後、期待どおりに理解しません。

　　判断方法は実際的です。まずページの主な目的を確認し、ページの主体に最も近いタイプを選びます。検索表示を増やすために、追加できる schema をすべて追加してはいけません。技術評価担当者にとって、タイプとページの意図が一致しているかどうかは、「マークアップがあるか」よりも重要な基準です。

同じページに複数の schema があるのは、正常か、それとも競合か？

　　それらが同じページ内の異なるエンティティを説明している、またはエンティティ間の関係が明確であることが前提であれば、正常です。たとえば記事ページに Article、BreadcrumbList、Organization が同時に存在しても、通常は問題ありません。問題となるのは重複と矛盾です。

　　よくある競合には次のようなものがあります。

• 同じ商品ページについて、プラグインとテンプレートがそれぞれ Product を出力している。
• 2つのデータにおける名称、価格、リンクが一致していない。
• パンくずリストの経路と、ページ上の実際のナビゲーションが一致していない。

　　このような状態は、validator ですべて赤く表示されなくても対処すべきです。検索エンジンにとって、エンティティの重複は理解の負担を増やし、深刻な場合には重要なシグナル同士が打ち消し合う可能性があるためです。

検証に合格したのに、なぜ検索結果にリッチ表示が出ないのか？

　　これは google schema markup validator について多くの人が誤解している点です。このツールが解決するのは「正しく解析できるかどうか」であり、「検索結果に必ず表示されるかどうか」ではありません。検証に合格したことから分かるのは、構造化データが基本的に有効だということだけです。

　　リッチ表示がない場合は、通常、次の項目も確認する必要があります。

1. ページがクロールされ、インデックス登録されているか。
2. ページの内容自体が、対応する表示条件を満たしているか。
3. 構造化データがページ上の可視情報と一致しているか。
4. 対象タイプが、検索エンジンで現在サポートされている表示範囲に含まれているか。

　　言い換えれば、検証ツールは第一関門であり、最終的な表示結果を判断するツールではありません。技術担当者が評価を行う際は、「正しく解析されること」と「表示を獲得できること」を分けて報告するのが望ましいでしょう。

テンプレートレベルのエラーはどう判断し、なぜ単一ページのエラーより優先して対処すべきなのか？

　　同じ種類の URL でエラーが安定して発生しているかを確認します。たとえば、すべての商品詳細ページで brand が不足している、またはすべてのブログ詳細ページで公開日の形式が間違っている場合、これは典型的なテンプレートレベルの問題です。そのリスクは特定の1ページにあるのではなく、新しいページが追加されるたびに拡大していく点にあります。

　　方法は簡単です。同じディレクトリ、同じテンプレート、異なる言語バージョンのページをサンプルとして確認します。エラーのパターンが一致している場合は、テンプレートまたはデータインターフェースのレイヤーに戻って修正を優先します。スマートWebサイト構築システムや複数サイトで共通の管理画面を利用しているチームにとって、この種の問題は1か所の修正で一括ページに反映できることが多く、修正効果が最も高くなります。

評価時に、特に注目すべきフィールドは？

　　すべての属性を1つずつ詳しく調べる必要はありません。まず、ページの価値に最も関連するフィールドを確認します。ページタイプによって重点項目は異なります。

• 商品ページ：名称、画像、価格、通貨、在庫、リンク。
• 記事ページ：タイトル、公開日、更新日、著者、メイン画像。
• 企業ページ：組織名、公式サイト、ロゴ、連絡先。
• パンくずリスト：階層名と対象リンクが実際にアクセス可能かどうか。

　　これらの主要フィールド自体が安定していなければ、その後でロングテール属性を追加しても意味は大きくありません。まず基本構造を正しく整え、そのうえで拡張を検討します。

修正後、本当に問題が解決したことをどう確認するか？

　　ローカルテストに合格したかどうかだけを確認してはいけません。より確実な確認方法は、「コードレベル、ページレベル、サンプルレベル」の3段階で再確認することです。

1. コードレベル：一時的に単一ページを修正したのではなく、正しいテンプレートまたはインターフェースの生成ロジックを修正したことを確認する。
2. ページレベル：オンラインページのソースを再クロールし、出力内容が変化していることを確認する。
3. サンプルレベル：同じ種類のページを抽出して確認し、特定の URL だけが偶然正常になっていないことを検証する。

　　Webサイト構築や海外マーケティングプロジェクトの技術受け入れを行う場合、この手順は特に省略できません。構造化データのエラーは「修正できない」のではなく、「このページは修正したが、他のページではまだエラーが出ている」ということがよくあるためです。

最後に、構造化データが基準を満たしているかを判断するには？

　　実用的な基準は、安定して解析でき、タイプがページと一致し、主要フィールドが完全で、フィールド値の形式が正しく、ページ上の可視コンテンツと一致していることです。この5点を満たしていれば、google schema markup validator のエラー調査は基本的に適切に行えたといえます。

　　技術評価では、推奨属性をすべて埋める必要はありません。まず、解析、理解、表示に影響する重要な問題を解消し、その後で schema タイプをさらに拡張する必要があるかを検討します。この方が実際のプロジェクトの進行に適しており、修正結果を一度限りの手作業によるエラー調査で終わらせず、テンプレートやプロセスに反映しやすくなります。