構造化データの手動対策を解除する修正と再審査の手順

Search Console に「構造化データの問題」という手動による対策が届いた。リッチリザルトテストでは「有効」と出ている。なのに、何が悪いのか分からない。

答えを先に書きます。見るべきは文法ではなく、マークアップの中身と、画面に見えている中身が一致しているかです。ずれている箇所を全ページで直し、そのあとで再審査をリクエストする。手順はこれだけです。

まず落ち着いてよい点が1つあります。Google のガイドラインは、構造化データの手動による対策について「ページがリッチリザルトとして表示される資格を失うもので、Google ウェブ検索での掲載順位には影響しない」と説明しています。失うのは星評価などの拡張表示です。順位まで下がったわけではありません。

なぜ「有効」なのに違反になるのか

ここでつまずく人が多いです。

Google は構造化データのガイドラインを2種類に分けています。1つは技術的なガイドラインで、リッチリザルトテストや URL 検査ツールでほとんどの技術的なエラーを見つけられる、とされています。もう1つは品質のガイドラインです。こちらは自動のツールでは簡単に検査できない、と明記されています。

そして、品質のガイドラインに違反すると、文法として正しい構造化データでもリッチリザルトとして表示されなくなることがある、とも書かれています。

つまり、テストツールの「有効」は文法の合格証です。中身の正しさまでは保証しません。手動による対策が届いたのにテストが「有効」なら、まず中身の側を疑うのが近道です。

何が「構造化データの問題」にあたるのか

手動による対策レポートのヘルプは、この対策の例として次の3つを挙げています。

• ユーザーに見えないコンテンツをマークアップしている
• 無関係な、または誤解を招くコンテンツをマークアップしている
• そのほかの操作的な行為

構造化データの一般的なガイドラインも同じ方向です。ページの読者に見えないコンテンツをマークアップしない。たとえば JSON-LD がある出演者を説明しているなら、HTML の本文も同じ出演者を説明していなければならない、という例が示されています。構造化データの概要ページには、さらに一歩踏み込んだ一文があります。ユーザーに見えない情報は、たとえ正確な情報であっても構造化データに加えないこと。

ここが大事です。「中身は本当のことだから大丈夫」は通りません。見えていなければ、正確でも対象になります。

修正から再審査までの手順

ここからが実作業です。順番どおりに進めてください。

1. レポートで対象を確かめる。 Search Console の「手動による対策」レポートを開きます。対策がある場合は、レポートの上部に件数が出ます。対策の種類が「構造化データの問題」であることと、例として挙がっている URL を控えます。同じ通知は Search Console のメッセージにも届きます。
2. 例の URL を1本選び、画面と JSON-LD を並べる。 ブラウザで実際のページを開き、ソースから application/ld+json の中身を取り出します。マークアップの各項目（名前・価格・評価・レビュー本文など）について、同じ情報が画面のどこに出ているかを1つずつ指でさします。指させない項目が、違反の候補です。
3. 原因をテンプレート単位で特定する。 候補が見つかったら、それがどこで出力されているかを追います。多くの場合、1ページだけの問題ではありません。商品ページや記事ページの共通テンプレート、CMS のプラグイン、タグ管理ツールで差し込んだコードが出どころになっていることがあります。
4. マークアップか画面のどちらかを直す。 画面に出していない情報は、マークアップから外すか、画面にきちんと表示するかのどちらかに揃えます。ページと無関係な内容（たとえば全ページに同じ評価を埋め込んでいる）は削除します。
5. 全ページに反映されたかを確かめる。 修正したテンプレートを使う URL を複数抜き出し、URL 検査ツールで Google から見えるページを確認します。ヘルプは「レポートに挙がった問題がすべてのページで修正されたら」再審査をリクエストするよう案内しています。例の URL だけ直して申請しないでください。
6. 再審査をリクエストする。 レポートの「Request Review（審査をリクエスト）」から、修正内容を書いて送ります。書き方は次の節で扱います。
7. 結果を待つ。 ヘルプによると、再審査の多くは数日から数週間かかります。リクエストを受け付けるとメールで知らせが届き、Google が違反は解消したと判断すれば手動による対策は取り消されます。

手順2が要です。ここを飛ばして文法チェックだけ回しても、原因には届きません。

ワークスルー: レビュー評価の「見えない星」

架空の例で一度通してみます。革小物を売る自社 EC サイトに、構造化データの手動による対策が届いたとします。例として挙がった URL は商品ページ3本でした。

手順2で、1本目の商品ページを開きます。JSON-LD には Product があり、aggregateRating に「評価4.8・レビュー120件」と入っていました。ところが画面を上から下まで見ても、星もレビューも表示されていません。

調べると、レビューは数年前に外部サービスで集めたもので、表示用の部品は撤去済みでした。数値だけが商品テンプレートに残り、全商品に出力され続けていたのです。

ここで手順3の判断です。例の3本だけの問題ではありません。商品テンプレートを使う全ページが同じ状態です。

手順4の選択肢は2つでした。

このケースでは、古いレビューを今出す意味が薄いので、削除を選びました。

手順5では、商品テンプレートを使う URL を新旧・カテゴリ違いで5本ほど選び、URL 検査ツールで aggregateRating が消えたことを確かめます。キャッシュ設定によっては古い HTML が配信され続けることがあるので、ここは省略しないほうが安全です。

最初の例を思い出してください。テストは「有効」でした。文法は正しく、数値も過去には本当でした。それでも、画面に見えていない。違反の理由はそこにありました。

再審査リクエストに書くこと

ヘルプは、よい再審査リクエストがすることを3つ挙げています。サイトの品質の問題を正確に説明すること。問題を直すために取った手順を説明すること。そして、それを記録として示すことです。

「修正しました」の一行では足りません。上の例なら、次のような形にまとめられます。

• 問題: 商品ページのテンプレートが、画面に表示していない評価とレビュー件数（aggregateRating）を全商品の JSON-LD に出力していました。
• 対応: 商品テンプレートから aggregateRating と review を削除しました。同じテンプレートを使う全商品ページに反映済みです。
• 確認: カテゴリの異なる商品ページ5件を URL 検査ツールで確認し、評価のマークアップが出力されていないことを確かめました。確認した URL は以下のとおりです。（URL を列挙）
• 再発防止: 構造化データに載せる項目は、画面に表示している値と同じデータから出力する運用に改めました。

書くときのコツは、例の URL だけでなく、原因のテンプレートと影響範囲まで書くことです。審査する側が「同じ問題が他に残っていないか」を確かめやすくなる場合があります。逆に、直していない箇所があるのに申請を急ぐと、もう一度直して出し直す手間が増えることがあります。

よくある誤解: ページを消せば終わる？

警告の出たページを noindex にしたり、削除したりすれば対策も消える、と考えたくなります。

おすすめしません。手動による対策は、Google が違反の解消を確かめて取り消すものです。ページを消しても、テンプレートに原因が残っていれば、ほかのページで同じ問題が続きます。しかも、本来は検索に出したいページを自分から外してしまうおそれがあります。

もう1つの注意点もあります。ガイドラインは、構造化データのあるページを robots.txt や noindex などで Googlebot からブロックしないよう求めています。直したページを確認してもらうためにも、ブロックは外しておきましょう。

自己点検表

再審査を出す前に、全項目に「はい」と言えるかを確かめてください。

1つでも「いいえ」なら、まだ出すタイミングではありません。

解除のあとにやること

解除されたあとも、Search Console のリッチリザルトのステータスレポートを定期的に見ておくと安心です。テンプレートを変えた拍子に、マークアップが意図せず変わることがあるからです。今回のように「部品は撤去したのにデータだけ残る」事故も、テンプレートの変更時に起きやすい種類です。

テンプレートを変えたら、点検表の上2行だけでも確かめる。それを習慣にしておくと、同じ通知を受け取る可能性を下げられます。

文法エラーと警告の区別がまだあいまいなら、「構造化データのエラーと警告の違い」もあわせて確認してください。CSS で隠した文字の扱いは「display:noneは隠しテキスト違反？」で整理しています。