フィードの鮮度とクロールのタイミング
価格や在庫状況による不承認は、そのほとんどが姿を変えたタイミングの問題です。フィードとウェブサイトは、同じ商品についてGoogleに情報を伝える2つのシステムであり、不承認はその間に生じるずれの中で発生します。
データが届く3つの経路
| 方法 | 反映までの時間 | 適した用途 |
|---|---|---|
| スケジュール設定によるフィード取得 | 数時間 | カタログ全体を1日1回以上更新する場合 |
| Content API | ほぼリアルタイム | 価格や在庫の変更を発生時点で反映する場合 |
| 商品情報の自動更新 | Google側からの実行 | 戦略ではなく、あくまで安全網として |
商品情報の自動更新は、フィードの内容が食い違っている場合に、ランディングページの構造化データをもとにGoogleが価格と在庫状況を修正できるようにする機能です。予備の仕組みとして有効化しておく価値はありますが、これはサードパーティによる自社データの修正であり、正しいデータを送ることの代わりにはなりません。
取得頻度の目安
稼働中のカタログであれば、1日1回が最低ラインです。在庫の変動が大きい商品を扱う場合は、1日に数回が適切です。マーケットプレイス、タイムセール、1点限りの在庫など、実際に動きの速い在庫については、スケジュール設定による取得は適した手段ではなく、Content APIが適切な選択となります。
スケジュールを設定できないクロールが1つあります。それは、Googleによるランディングページのクロールです。これはGoogleの都合で実施されるため、フィードはページを変更した後ではなく、変更する前に正しい状態にしておく必要があります。
不承認を避けるための変更手順
- 値上げの場合：先にフィードを更新し、その後にサイトを更新します。
- 値下げの場合：先にフィードを更新し、その後にサイトを更新します。常にフィードが先です。
- 在庫切れになる場合：フィードを先に、できればAPI経由で更新します。
- 在庫が復活する場合：サイトを先に更新しても問題はありませんが、フィードを先に更新したほうが早く掲載されます。
商品ページの構造化データ
ランディングページにProductスキーマのマークアップを実装すると、Googleはレンダリングされたページを解析するのではなく、明確な価格と在庫状況を読み取れるようになります。これにより不一致による不承認が大幅に減り、自動アイテム更新が参照するのもこのデータで、AIショッピング関連の表示面が利用するのも同じマークアップです。このリストの中で最も費用対効果の高い技術的な改善策です。