リッチリザルト テストツールはcodeの通過だけで終えずpage本文と対象種類を照合する

リッチリザルト テストツールで問題が出なかったpageも、構造化データの確認を終えたとは限りません。先に照合するのは、page本文に書いてある内容、構造化データの種類、読者へ表示している条件です。codeが読み取れることと、そのpageが検索結果でどのように表示されるか、読者へ正しい案内をしているかは別です。

Googleは12月19日、構造化データを診断するリッチリザルト テストツールを公開しました。このtoolはJSON-LD、Microdata、RDFaを検査でき、動的に読み込む内容の構造化データにも対応しています。公開時点ではrecipe、job、movie、courseのtestを扱います。すべての構造化データ種類を判定するtoolではありません。対象種類とpageの役割を確かめてから使います。 Google Webmaster Central Blog

構造化データの種類とpageの目的を先に合わせる

構造化データは、pageに書いた内容を検索エンジンへ伝えるための記述です。検索結果を目立たせるためだけに、pageの内容と違う種類を付けるものではありません。求人を出していない会社案内へjobの情報を置く、recipeではない商品紹介へrecipeの項目を入れるといった使い方では、読者が読むpageと記述の意味が離れます。

たとえば、採用pageへ求人情報を付ける場合を考えます。page本文には、募集する職種、仕事内容、勤務地、応募の条件、応募方法を書きます。構造化データにも、pageで確認できる同じ募集内容を入れます。募集を止めたのに構造化データだけ残すと、toolがcodeを読み取れても、読者へ古い求人を示すことになります。

一方で、会社が採用方針を説明するpageは、求人の条件を示すpageとは役割が違います。採用に関する文章があるからといって、同じ構造化データを付ける理由にはなりません。どのpageが、誰へ、何を約束するためのpageなのかを決めます。そのうえで、対応する種類があるかを確かめます。

この表は、種類を選ぶための例です。対象の種類があるからpageを作るのではありません。事業者が公開する内容が先で、構造化データはその内容を読み取りやすくするために付けます。順番を逆にすると、必要のない項目を埋めるために本文まで不自然になります。

JSON-LDとMicrodataは形式ではなく内容の一致で選ぶ

Googleの案内では、リッチリザルト テストツールはJSON-LD、Microdata、RDFaを検査します。JSON-LDを推奨すると案内していますが、形式を替えるだけでpageの説明が正しくなるわけではありません。既存のHTMLにMicrodataを付けているsiteなら、どの情報をHTMLから読むのかを追いやすい場合があります。JSON-LDなら、HTMLの表示と記述する情報を別に管理する場合があります。

大切なのは、どちらの形式でも、本文と別の情報を作らないことです。title、画像、価格、募集条件、日付のように変更される情報は、表示用のdataと構造化データ用のdataが別々になると食い違いやすくなります。更新担当者が本文だけを直し、制作担当者が後でJSON-LDを直す運用では、公開直後に差が出ます。

仮に、求人pageの給与表現を変更する場合を考えます。本文の条件を確認し、構造化データにも同じ条件があるかを見る順にします。どちらか一方だけが先に公開されるなら、公開を承認する人が差を把握します。形式をJSON-LDへ替える作業と、募集条件を確認する作業は別です。toolの結果を共有しても、内容の承認まで済んだことにはなりません。

toolで見る範囲と公開画面で見る範囲を分ける

リッチリザルト テストツールへURLを入れると、対象となる構造化データ、問題のあるcode、previewを確認できます。Googleは、問題があればpage source内の無効なcodeを示し、対象になり得るリッチリザルトをpreviewできると案内しています。これはdiagnosisに役立ちますが、検索結果での表示を約束するものではありません。

toolで見るのは、記述の形式、対象種類、問題箇所、previewです。公開画面で見るのは、本文、画像、価格や条件、link先、更新日時、問い合わせ先です。二つを同じ画面で確認できない場合は、URLを並べ、どの項目を照合したか記録します。page sourceだけを渡されても、実際のpageに何が表示されるかは判断できません。

動的に読み込む内容を使うpageでは、さらに注意します。Googleは新toolが動的に読み込まれる内容の構造化データをより適切に扱うと案内しています。しかし、利用者の画面で必要な情報が読めない、操作しないと重要な条件へ進めない、scriptの失敗で内容が消える状態まで解決するわけではありません。構造化データのtestと、利用者が読むpageのtestを分けます。

修正の優先順位をcodeの数で決めない

toolが多くの問題を示すと、表示された順に直したくなります。先に直すべきなのは、読者の判断を変える内容です。終了した求人、違う価格、存在しないcourse、別の商品を指す画像があるなら、codeの細かな形式より前に本文と記述をそろえます。反対に、対象外の構造化データを無理に追加して問題を増やす必要はありません。

修正を外部へ依頼する場合は、errorの一覧だけを渡しません。対象URL、pageの役割、本文で確認する条件、修正後に見る人を決めます。制作担当者はcodeを直し、内容の担当者は募集や商品やserviceの条件を確認します。どちらかが不在だと、toolの通過だけが残り、情報が古くなったことに気付きにくくなります。

最初の一手は、構造化データを付けた代表pageを一件開き、本文に書かれた条件を三つ選ぶことです。その三つが構造化データにも同じ意味で入っているかを確認してから、リッチリザルト テストツールで対象種類と問題箇所を見ます。構造化データはcodeを増やすための作業ではありません。読者へ公開した内容と、検索エンジンへ伝える内容を同じに保つ作業です。