構造化データのエラーと警告｜直す順番の決め方

警告をゼロにしようとして、手が止まっていませんか

Search Console のレポートに「エラー」と「警告」が並んでいる。両方つぶさないと落ち着かない——そう思って着手すると、たいてい途中で止まります。推奨項目のなかには、そもそも自社に存在しないデータがあるからです。

先に結論を書きます。手をつける順番は、Google が「資格がある」と明記している側から決まります。 リッチリザルト（検索結果に星評価や画像などが追加で表示される見た目）について、Search Console ヘルプは「有効な構造化データは、Google 検索でリッチリザルトとして表示される資格があります」と書いています。資格の話をしているのは「有効」の側だけです。

だから、無効に分類された項目を有効に寄せる作業が先。推奨項目を埋める作業は、そのあとです。あとは、その順番を実際のテンプレート修正に1回通してみれば、どこで判断が要るかが見えてきます。

「有効」の意味は、表示の約束ではない

まず、公式が言っていることの範囲を正確に押さえます。Search Console ヘルプのリッチリザルトのステータスレポートは、レポートの役割をこう説明しています。

Rich result reports in Google Search Console show structured data (and its validity) found on your site. Valid structured data is eligible to appear as rich results in Google Search. （Search Console のリッチリザルトのレポートは、サイト上で見つかった構造化データとその有効性を示します。有効な構造化データは、Google 検索でリッチリザルトとして表示される資格があります）

「eligible（資格がある）」であって、「表示される」ではありません。ここを取り違えると、有効になった直後に「まだ星が出ない、設定が間違っている」と探し回ることになります。有効化は入口の条件で、そこから先は別の話です。

同じページには、レポートがサイトで見つかったリッチリザルトの種類ごとに分かれていること、ナビゲーションの「拡張（Enhancements）」の下から開けることも書かれています。探しているレポートが見当たらないなら、そもそもその種類が検出されていないだけ、ということがあります。

必須と推奨は、公式の例文にも全部は載っていない

エラーと警告を分ける実体は、プロパティ（構造化データに書く項目）の扱いの違いです。構造化データの一般的なガイドラインは、掲載しているコード例についてこう断っています。

These examples are trimmed for brevity, and they don't include all the required and recommended properties for the features. （これらの例は簡潔にするため省略されており、その機能に必要なすべての必須プロパティと推奨プロパティを含んでいるわけではありません）

公式ドキュメントに「required（必須）」と「recommended（推奨）」という2つの区分があること、そしてガイドラインのコード例には、その機能の必須プロパティと推奨プロパティが全部は載っていないことが、ここで明言されています。

だから、コード例を出発点にすると足りない項目が残ることがあります。公式のサンプルをコピーしてテンプレートに埋め込み、テストが通ったので完了にした。しばらくして無効が並ぶ。そういう経路があり得るということです。コード例からではなく、機能ごとの構造化データのドキュメントにある必須プロパティ一覧と突き合わせて作るほうが安全でしょう。

構造化データの仕組みについてのページも、同じ方向を向いています。「Use the Rich Results Test for validation. Adhere to guidelines and prioritize complete, accurate properties.（検証にはリッチリザルトテストを使い、ガイドラインに従い、完全で正確なプロパティを優先します）」。優先すべきは、項目数の多さではありません。完全さと正確さです。

なお、対応している記述形式は3つです。ガイドラインは「In order to be eligible for rich results, mark up your site's pages using one of three supported formats: JSON-LD (recommended) Microdata RDFa」と書いています。JSON-LD が推奨。新規に入れるなら、迷わずこれを選んでかまいません。

直す順番を決める4段階

ここまでの公式の記述だけで、優先順位は次のように置けます。判断の根拠が「公式に書いてある」のか「こちらの運用判断」なのかも分けて示します。

段階4を最後に置いた理由を補います。ガイドラインは「Don't mark up irrelevant or misleading content, such as fake reviews or content unrelated to the focus of a page.（偽のレビューやページの主題と無関係な内容など、無関係または誤解を招く内容をマークアップしないでください）」とも書いています。警告を消すために存在しない値を埋めるのは、この線に近づく方向です。手作りの商品に世界共通の識別コードがない、レビューがまだ1件もない——そういうときは、警告を残すほうが素直です。

段階3も具体があります。同じガイドラインは「Structured data must comply with Google's content and spam policies to be eligible for rich results in Search.（構造化データが検索でリッチリザルトの資格を得るには、Google のコンテンツポリシーとスパムポリシーに準拠している必要があります）」と述べています。準拠は資格の条件です。構文が正しいこととは別に効いてきます。

実際に通してみる：商品ページの無効が急に増えたとき

抽象論だけでは動けないので、1本通します。想定は「先週まで0件だった無効が、商品ページで数百件に増えた」という状況です。

1. レポートで問題の名前と初回検出日を控える。ステータスレポートの課題詳細には「First detected（その問題を最初に検出した日）」が表示されます。この日付をテンプレートやプラグインの更新履歴と突き合わせると、原因の当たりが一気に絞れます。数百件が同時に立ち上がったなら、個別ページではなく共通テンプレート側を疑うのが自然です。
2. 例の一覧から1URLだけ選ぶ。全部見る必要はありません。同じテンプレートから出ている以上、1本直せば残りも同じ形になります。
3. そのURLをURL検査ツールにかける。ステータスレポートのヘルプは、エラーの詳細と、インデックス済みの結果・ライブテストの結果を見るためにURL検査ツールを使う流れを案内しています。まずインデックス済みの結果を開いて、何が欠けていると報告されているかを確認します。
4. テンプレートを直して、ライブテストで確認する。URL検査ツールのヘルプは、ライブテストはページを修正しているときに、問題が直ったかどうかを確かめるのに役立つと書いています。ページがまだインデックスされていなくても、インデックスに失敗していても実行できます。ただし、ページがインターネットからアクセスできる状態であることが条件として書かれています。公開前の環境や、社内からしか開けないページでは、この時点で確認が取れないことがあります。
5. インデックス済みとライブの差を読む。同ヘルプは、公開URL側だけを直してまだインデックスされていない場合に、インデックス済みの結果とライブの結果の差を見るよう案内しています。ライブが直っていて、インデックス済みが古いまま。これは想定どおりの状態です。
6. レポートの更新は待つ。Search Console 側に「この問題を直す」ボタンはありません。ヘルプが理由まで書いています。「The structured data resides on your website, not Google's servers. Fixes must be applied to your site's source code to resolve issues permanently.（構造化データは Google のサーバーではなく、あなたのウェブサイトにあります。恒久的に解決するには、修正をサイトのソースコードに適用する必要があります）」。直す場所は常に自分のコード側です。

この6手順のうち、判断が要るのは1と2だけ。あとは機械的に流せます。数百件を1件ずつ開いていた作業が、テンプレート1本の修正に変わるのが、この順番の効き目です。

テストが緑でも「表示される」ではない

修正が終わってテストが通ると、そこで完了にしたくなります。ただ、テストの守備範囲は公式に限定されています。URL検査ツールのヘルプには「What isn't tested（テストされないこと）」という節があり、Google に表示されるために必要でありながらテストの対象外になるものが挙げられています。ページと構造化データが品質・セキュリティのガイドラインに適合していること、サイトが手動による対策やセキュリティの問題を受けていないこと——これらはテストされません。

一般的なガイドラインの書き方も同じ趣旨です。「You can test compliance with technical guidelines using the Rich Results Test and the URL Inspection tool, which catch most technical errors.（技術ガイドラインへの準拠は、リッチリザルトテストとURL検査ツールで確認できます。これらは技術的なエラーの大半を捕捉します）」。most、つまり大半です。全部ではありません。

だから、テストが緑になったことは「技術的な穴の大半が埋まった」までを意味します。表示の約束ではない。ここまで踏まえておくと、出ない理由を構造化データの中だけで探し続ける遠回りを避けられます。検索結果の見た目が思いどおりにならない例としては、検索結果に出る日付の仕組みやファビコンが表示されない原因も同じ系統です。

レポートの件数を、そのまま信じない

もう1つ、実務でつまずくところがあります。レポートの数字です。ステータスレポートのヘルプには、よくある質問として次の2つが載っています。

ひとつめ。「Why are structured data item totals lower than valid + invalid totals?（構造化データの項目の合計が、有効＋無効の合計より少ないのはなぜですか）」に対して、レポートに表示される項目の合計は、さまざまな理由でサイト上の実際の既知の項目数より少なくなることがある、と説明されています。合計が合わないのは、あなたの読み違いとは限りません。

ふたつめ。課題詳細の「Examples（例）」の欄について、「the examples list might omit rows for various reasons, such as issue instances that happened after the last crawl of（例の一覧は、最後のクロール以降に発生した問題の事例など、さまざまな理由で行が省略されることがあります）」と書かれています。例の一覧は全件ではないのです。

この2つを知らないと、「例に出ている5件を全部直したのに件数が減らない」という詰まり方をします。例の一覧は、原因を特定するためのサンプル。網羅の担保には使わないほうがよいでしょう。実際に何件残っているかは、テンプレートの適用範囲を自分のサイト側で数えるほうが確かです。

同じページには、1つの問題が課題の表に複数回現れ、無効タブの合計には1回だけ数えられる場合がある、という説明もあります。件数のズレを追いかけるより、テンプレート単位で直したかどうかを自分の側で管理するほうが早い、というのが実感に近い落とし所です。

よくある誤解を3つ

「警告が残っているとペナルティを受ける」。 ポリシー側で明確に禁じられているのは、偽のレビューやページの主題と無関係な内容のマークアップです。推奨プロパティを埋められないことと、禁じられている行為とは、話の層が違います。警告を消すために値をでっちあげるほうが、リスクの方向としては近いことがあります。

「構造化データを入れれば順位が上がる」。 構造化データの仕組みについてのページが紹介しているのは、「Case studies show increased click-through rates, visits, and user engagement on pages with structured data.（ケーススタディでは、構造化データのあるページでクリック率、訪問、ユーザーのエンゲージメントの増加が示されています）」という事例の話です。事例で増加が示されている、という記述と、順位が上がるという主張は別のものです。自分のサイトで同じ結果になるかは、実装後の数字で見るしかありません。

「テストが通れば表示される」。 前の節のとおりです。テストの対象外が公式に明記されている以上、緑は必要条件の一部にすぎません。

自己点検チェックリスト

いま自分がどこにいるかを、この表で当ててみてください。

7行のうち、上から3行が「有効に寄せる」作業、下の4行が「有効になったあと」の作業です。手が止まっているときは、たいてい下の4行に先に入ってしまっています。

まとめ

エラーと警告のどちらを先に直すかは、好みの問題ではありません。Search Console ヘルプが「表示される資格がある」と書いているのは有効な構造化データについてであり、そこが優先順位の起点になります。必須プロパティを満たして無効を減らす。ポリシー違反を消す。推奨項目は、埋められるデータが実在するときだけ埋める。

そして、直したかどうかの確認はレポートの件数ではなくライブテストで取る。テストが緑になっても、品質・セキュリティ面はテストされていない。この2点を押さえておけば、構造化データの警告に振り回される時間は、かなり短くできます。