Search ConsoleのRich Cards reportは対応するpage種類を決めてからmarkupを確認する

Search ConsoleのRich Cards reportを使う前に、自社siteに対象となるpage種類があるかを決めます。reportがあるからといって、すべての会社siteへmarkupを足す理由にはなりません。まず公開pageにある情報を確かめ、その情報に対応するmarkupを付け、最後にreportで読まれているかを確認します。

構造化dataは、検索結果の見た目を飾るために先に足すものではありません。pageに表示している内容を、検索エンジンが読み取りやすい形で伝える方法です。画面にない情報や、更新する予定がない情報をmarkupだけに書けば、読者が読める内容と検索エンジンへ伝える内容が分かれます。始める順序を、page、markup、検査、reportの順にします。

GoogleのSearchに関する案内は、Rich Cardsをschema.org markupを使う検索結果形式として紹介しています。Rich Cardsに対応するのは、英語のrecipeとmovieです。同じ案内では、Search ConsoleにRich Cards markupがvalidか確認するreportが加わり、より多くのfieldをmarkupできるcardも示すと説明しています。

reportがあることと対象pageがあることを分ける

小規模な会社siteでは、最初に「何でもmarkupする」より、対象になるpageがあるかを確認します。Rich Cardsは、英語のrecipeとmovieを対象にしています。会社案内、service紹介、news記事だけのsiteは、reportを見つけても、Rich Cardsのために内容を作り替える必要はありません。対象外のsiteで無理に作業を始めれば、読者に必要な情報を整える時間が減ります。

たとえば、料理教室が英語のrecipe pageを公開している場合でも、画像や材料を検索結果のためだけに作るのは順序が逆です。最初にpageの利用者へ必要な情報を整えます。その画面にある情報をmarkupし、testing toolとSearch Consoleで確認します。

recipe pageなら、料理名、材料、手順、画像といった情報を、pageを読む人が確認できる形で整えます。movie pageなら、作品を見たい人が必要とする名称、説明、画像などを先に確認します。markupのfieldを埋めるために、画面の説明を不自然に増やす必要はありません。利用者がpageで判断するために必要な情報があり、その情報を正確に対応させられるかを見ます。

複数のpageを扱うsiteでは、最初から全pageへ同じmarkupを入れません。内容がそろっている代表pageを一つ選びます。そのpageでHTMLとmarkupの対応を確認してから、同じ種類のpageへ広げます。pageごとに情報が違うのに、同じ値をコピーすると、pageの内容とmarkupが食い違います。

markupの確認と検索結果の表示を同じにしない

Rich Cards reportでmarkupがvalidと確認できても、検索結果での表示が決まるわけではありません。reportは、Googleがmarkupを確認する入口です。検索結果の形式を約束するものではありません。

反対に、検索結果の見え方だけを見て、pageの情報が正しいと判断することもできません。公開page、HTML、testing tool、Search Console reportには、それぞれ確認する役割があります。

1. 対象になるpage種類を決める。
2. pageで利用者へ実際に見せる情報を確認する。
3. 表示内容と同じ情報をmarkupする。
4. Structured Data Testing Toolで抽出結果を確認する。
5. Search ConsoleのRich Cards reportでvalidなmarkupを確認する。
6. pageを更新したら、表示内容とmarkupを同じ変更として見直す。

markupを作る人とpageを更新する人が別なら、対象URLと確認結果を残します。作業を頼んでも、どの情報を公開するか、何を変更したかの確認まで外部へ渡し切る必要はありません。

validityを確認する場所と、読者に見える場所も分けます。pageをブラウザで開いて、名称、説明、画像などが意図した内容かを確認します。次にHTMLを確認し、markupが画面の内容と対応しているかを見ます。そのあとStructured Data Testing Toolで抽出結果を確認し、Search Console reportで対象URLを確認します。どこか一つだけを見て、すべて正しいと判断しません。

pageを更新したときは、本文や画像だけを直してmarkupを残さないようにします。料理名を替えた、手順を減らした、作品の説明を更新した場合は、markupも同じ変更として見直します。反対にmarkupだけを更新して画面を変えない場合も、利用者が読めない情報を伝えていないかを確認します。更新担当が違うなら、どのpageでmarkupを使っているかを共有します。

対応しないsiteは通常のpageを先に整える

対象に当てはまらないsiteは、Rich Cardsを無理に追いません。title、本文、画像、内部linkのように、利用者がpage内容を理解するための要素を先に整えます。新しい検索結果形式は、対象となる情報があり、その情報を正確に出せる場合に検討します。

通常のpageを整える作業は、Rich Cardsより価値が低い作業ではありません。service紹介pageなら、誰に何を提供し、どの条件で問い合わせられるかが読めることが先です。news記事なら、題名、公開内容、関連pageへのlinkがそろっていることが先です。対象外のmarkupを探すより、すでに読まれているpageの説明を正しくする方が、読者にも運用する人にも分かりやすい場合があります。

最初の一手は、site内に英語のrecipeまたはmovie pageがあるかを一つずつ確認することです。なければRich Cardsの作業を保留し、現在公開しているpageの内容と更新手順を整えてください。ある場合も、対象URLを一つ選び、画面の情報、markup、testing tool、reportの順で確認します。reportの数字を増やすことではなく、公開している情報を正しく扱うことを目的にします。