商品ページの構造化データは画像だけでなく名前、価格、在庫を表示内容とそろえる

商品ページへ構造化データを入れるなら、画像だけを登録して終えません。商品名、画像、価格、通貨、在庫状況を、読者がページで確認できる内容とそろえます。検索結果で何らかの表示が増えることを先に期待するのではなく、商品を探した人が、開いた先で同じ商品と条件を確認できる状態を作ります。

Googleの画像検索に関する案内は、商品ページにschema.org/Productのmarkupを置き、画像、商品名、価格と通貨、在庫状況のmetadataを持つ商品を対象として案内しています。画像検索の表示対象になることと、すべての商品やすべての画面で同じ表示になることは別です。まず、自分のページが扱う商品と販売条件を、表示とmarkupの両方で正しく伝えます。

商品の写真と販売する商品を同じものとして扱わない

商品写真があるからといって、その写真の中にある全ての物を販売しているとは限りません。服と鞄を一緒に写した写真で、鞄だけを販売している場合もあります。構造化データのProductは、写真の雰囲気や記事の主題ではなく、ページで販売条件を示す商品へ対応させます。

説明用の仮例として、一つの鞄を販売するページを考えます。本文には鞄の商品名、正面と使用例の写真、価格、通貨、在庫状況、注文へ進むlinkを置きます。構造化データにも、その鞄の名前、画像、価格、通貨、在庫状況を置きます。使用例の写真へ帽子や財布が写っていても、それらをこの鞄の商品情報へ混ぜません。

反対に、一つのページで複数の商品を並べる場合は、どの名前、価格、在庫がどの商品に属するかを分けます。まとめて「おすすめ商品」と見出しを付け、写真だけを並べた状態では、読者も検索サービスも販売条件を確かめにくくなります。商品ごとに見出し、画像、価格、購入または問い合わせへの入口を対応させます。markupも同じまとまりで出力します。

商品説明の文章と販売情報も分けます。「上質な素材」「使いやすい形」といった説明は、商品を選ぶ助けになります。しかし価格、通貨、在庫は、注文を決める条件です。写真の近くに雰囲気だけを書き、価格を別のpageに隠すと、商品が見つかっても購入条件を確認できません。構造化データを足す前に、商品pageの本文でその条件が読めるかを確認します。

価格と通貨は更新する場所を一つにする

価格を表示用HTMLと構造化データへ別々に入力すると、片方だけを直す事故が起こります。商品pageには新しい価格が出ているのにmarkupには古い価格が残る、あるいは在庫切れなのに購入可能として出る、といった状態です。検索結果に何が出るか以前に、読者へ異なる条件を伝えることになります。

WordPressやECのtemplateを使う場合は、商品名、価格、通貨、在庫をどこで管理するかを先に決めます。商品情報を一つの入力欄または商品dataから出し、画面の価格とmarkupの価格を同じdataから組み立てます。template内に価格を手で二度書かない方が、更新する担当者と確認する箇所を減らせます。

たとえば、商品dataにprice、currency、availabilityを持たせる方法を考えます。pageの本文ではpriceとcurrencyを「12,000円」のように表示し、markupでは同じ値を価格と通貨の項目へ使います。在庫がなくなったときは、本文の「在庫あり」とmarkupの在庫状況を同じ更新で変えます。これは説明用の設計例です。実際に使うproperty名やtemplateの構成は、採用するsystemの仕様で確認します。

税込みか税別か、送料を含むかどうかも、表示と購入画面で食い違わせません。価格の数字だけが一致していても、あとから加わる費用が大きければ、読者は条件を判断できません。構造化データへ何を入れるかと、注文前に何を画面へ示すかを同じ作業として見ます。markupを担当する人と販売条件を決める人が別なら、誰が最終確認をするかを決めます。

価格を期間限定で変える場合は、終了日を過ぎた条件が残りやすくなります。page本文、一覧、構造化データ、購入画面を別々に更新する手順では、どこかに古い数字が残ります。キャンペーンを始める前に、変更するURL、更新するdata、戻す時刻、確認する画面を一枚に記録します。売るための表示を急いで増やすことと、誤った条件を出さないことを両立させるためです。

在庫状況は注文できる状態と対応させる

在庫状況は、棚に商品があるかどうかだけではありません。読者がそのpageから注文できるのか、予約なのか、入荷待ちなのかを判断する条件です。「在庫あり」と書いて注文へ進ませても、実際には受付を止めているなら、問い合わせや取消しの対応が増えます。購入buttonを非表示にしただけでなく、本文、構造化データ、注文画面の扱いをそろえます。

説明用の仮例として、在庫が一つだけ残る商品を考えます。商品pageには「在庫あり」と表示し、注文を受けられる間は同じ状態をmarkupにも出します。注文が確定して在庫がなくなったら、本文の表示、注文button、構造化データを更新します。在庫管理systemとの連携がないなら、更新できる担当者と確認する時刻を決めます。売れた後の自動化を想像して、実際に更新できない仕組みを先に公開しません。

受注生産や予約販売は、通常の在庫ありと混同しやすい条件です。発送までの期間、予約を受ける数、注文の締切を商品pageで説明します。数量が確定していない、納期を約束できない商品なら、在庫状況だけで購入できると受け取らせません。構造化データの指定に合わせるために、販売側がまだ決めていない条件を作りません。

商品情報を制作会社へ渡す場合も、写真と商品名だけを渡して終えません。価格の税の扱い、通貨、在庫を更新する人、注文を止めたときの表示、商品を終売したときのURLを渡します。制作会社がmarkupを実装しても、日々変わる在庫を確認する責任まで引き受けるとは限りません。公開後に誰が変更し、誰が画面を確認するかを、作業範囲として残します。

検証はmarkupの形式と読者が見るpageを分けて行う

Googleは、商品markupの形式を構造化データテストツールで確認する方法を案内しています。検査で形式上の問題がないことと、商品pageが正しい販売条件を示していることは別です。toolで項目を確認した後に、公開pageを読者の画面として開き、商品名、画像、価格、通貨、在庫、注文への入口を順に見ます。

検査用のpageへ仮の価格や在庫を入れたまま本番へ出さないようにします。商品dataを複製すると、古い画像、古い価格、別の商品名が残ることがあります。新しい商品を登録したときは、少なくとも次の対応を確認します。

1. pageの見出しと商品名が、注文を受ける商品を指しているか確認する。
2. 主な画像が、その商品を説明する画像になっているか確認する。
3. 表示した価格と通貨が、注文画面の条件と一致するか確認する。
4. 在庫状況と、注文または問い合わせを受ける状態が一致するか確認する。
5. 構造化データテストツールで、商品markupの形式を確認する。

この順序は、検索結果へ出す項目を増やすためだけのものではありません。ページで売る商品と、受ける注文の条件を一致させるための確認です。画像検索の表示はGoogle側が決めるものであり、markupを入れたpageが必ず表示されるものではありません。表示されることを約束する説明より、読者がpageで確認できる条件を正しく保つ方を優先します。

Googleの案内では、Googlebotが再クロールするまでに一週間程度かかることがあるとされています。価格や在庫を変えた直後に検索画面の表示だけを見て、更新が失敗したと決めません。まず公開page、商品data、markupの検査結果を確認し、その後に検索から見つかる情報を別に見ます。更新作業と外部service側の取得時刻を分けることで、不要な修正を減らせます。

最初の一手は、注文を受ける商品pageを一つ選び、商品名、画像、価格、通貨、在庫、注文への入口を画面で並べて確認することです。その値をmarkupにも同じsourceから出し、価格や在庫を変えたときに誰がどこを確認するかを決めます。