Googleの構造化データ テストツールではitem一覧とHTMLの問題箇所を分けて確認する

構造化データを追加したら、Googleの構造化データ テストツールで、認識されたitemとHTML内の問題箇所を分けて確認します。エラーが消えたかだけを見ず、ページに表示した名称、日付、URLなどが、意図したpropertyとして読み取られているかまで照合してください。

テストの合格は、検索結果での表示を保証するものではありません。構文を直す作業、内容を正しく保つ運用、Googleが検索結果を決める処理は別です。

検出されたitemとHTMLの問題箇所は役割が違う

Googleの構造化データ テストツールは、ページから認識したitemを整理して表示し、markupの問題をHTML source内で強調します。

item一覧では、意図した型とpropertyが組になっているかを確認します。HTML sourceでは、括弧、引用符、属性、値など、問題として示された位置を確認します。二つは同じ結果の見方ではありません。

HTML sourceの一行を直しても、itemの型や親子関係が意図と違えば、作業は終わりません。反対に、itemが表示されても、会社名や日付が画面と違えば、正しい情報を伝えたことにはなりません。

表示内容とpropertyを一組ずつ照合する

最初に、一つのページで、利用者に見せる事実とpropertyの対応を決めます。会社ページなら会社名、URL、ロゴ、連絡先、記事ページなら見出し、公開日、著者などです。ページに存在しない情報を、検索表示を目立たせるためだけに加えてはいけません。

次に、テスト結果のitemを開き、値を画面と一組ずつ比べます。確認する順番を決めておくと、propertyが多いページでも判断を混ぜずに済みます。

1. 意図した型が認識されているか。
2. 必要なpropertyが、その型の中にあるか。
3. 値がページ表示と一致しているか。
4. URLが、公開する正規のURLを指しているか。

これは、propertyを多く埋める作業ではありません。表示内容を機械が読める形へ写し、その対応が崩れていないかを確かめる作業です。

JSON-LDと動的HTMLも認識結果から確認する

構造化データ テストツールは、JSON-LDのmarkupを扱い、動的に読み込まれるHTML内のJSON-LDも検査します。記述形式が違っても、確認する対象は同じです。認識されたitem、property、値、問題箇所を順に見ます。

JavaScriptがJSON-LDを出力する場合は、編集したsource fileだけを見て判断しません。実際のページをテストし、出力後のitemを確認します。template側の変数名が正しくても、空の値や別ページのURLが出ていれば、公開結果は正しくありません。

microdataを使う場合も、HTMLに属性があることだけで終えず、どのitemへどのpropertyが入ったかを確認します。記述形式を選ぶことと、内容を正しく対応させることを分けてください。

templateを直したら種類の違うページも試す

WordPressなどのtemplateで構造化データを出力すると、一度の修正が多くのURLへ反映されます。作業時間を減らせる一方で、一つの誤りも広がります。

記事templateを直したなら、短い記事、画像がない記事、著者や日付の条件が違う記事を選びます。会社情報なら、電話番号やロゴを管理している元データも確認します。説明用に一ページだけ成功させず、値の入り方が違う代表ページを少数選んで試してください。

制作を委託しても、会社名、連絡先、公開日などの正本はサイト所有者が管理します。制作者はmarkupの出力を直せますが、元データが正しいか、変更後も保たれているかを決める責任までは代行できません。

公開後はウェブマスターツールの検出結果も確認する

構造化データ テストツールは、修正中の一ページを調べるために使います。ウェブマスターツールの構造化データ ダッシュボードは、GoogleがcrawlしたURLで検出したitemとerrorを、種類ごとに調べるために使います。

修正直後のテスト結果と、crawl後に更新されるダッシュボードを同じ時点の結果として比べてはいけません。まず代表ページをテストし、公開後は、同じtemplateを使うURLにerrorが残っていないかをダッシュボードで追います。

最初の一手は、構造化データを出力しているtemplateを一つ選び、代表ページをテストすることです。item一覧、HTMLの問題箇所、画面表示を三列に並べ、最初に食い違った一項目から直してください。