商品ページとカートで在庫が違う？AI検索に備える価格・販売状態の整え方

価格と在庫のずれを放置しない

商品情報は、商品ページだけに存在するとは限りません。ECシステムの商品マスター、一覧ページ、商品詳細、カート、構造化データ、広告や無料リスティング用のデータなど、複数の場所へ展開されます。一つだけ更新が遅れると、同じ商品について異なる価格や販売状態が並ぶことがあります。

GoogleのProduct構造化データに関する公式資料では、商品ページへ構造化データを追加すると、価格や在庫などを含む検索表示の対象になり得ること、Webページの構造化データとMerchant Centerのフィードを併用すると、Googleが商品データを理解・確認する助けになることが説明されています。一方、表示方法は各検索機能の判断で変わり、リッチな表示が必ず出るわけではありません。

ここで重要なのは、構造化データを増やすこと自体ではなく、購入者が見るページと機械向けデータが同じ状態を示すことです。これらを踏まえ、本記事では「購入できるか」「いくらで購入できるか」「いつから購入できるか」を、商品単位またはバリエーション単位でそろえることを優先します。

更新の基準を一つ決める

最初に、価格と在庫をどこで確定するかを決めます。ECシステムの商品マスター、在庫管理表、店舗のPOSなど、実際に注文可否を制御する場所を基準にします。複数の担当者が、それぞれの商品ページや外部サービスを直接直す運用では、更新漏れを見つけにくくなります。

管理項目	基準として確認する内容	反映先の例
通常価格・セール価格	現在購入できる金額と適用期間	商品詳細、一覧、カート、構造化データ、商品データ
販売状態	在庫あり、在庫切れ、予約、取り寄せ、販売終了	商品詳細、購入ボタン、カート、構造化データ、商品データ
バリエーション	色・サイズ・容量ごとの価格と在庫	選択肢、個別URL、カート、商品データ
受付条件	販売地域、受け取り方法、販売開始日	商品詳細、配送案内、カート、商品データ

この表の管理項目と順番は、AI BRAND CHECK運営者による実務上の提案です。サイトの仕組みによって反映先は異なります。価格表示、税、送料、返品など個別の法令や契約条件が関係する範囲は、実際の運用と必要な専門確認に合わせてください。

一時的な在庫切れと販売終了を分ける

「今は買えない」という状態でも、再入荷予定、予約受付中、取り寄せ、完売、販売終了では、購入者が必要とする説明が違います。ページ上の文言を「在庫なし」だけに統一すると、再入荷を待てる商品なのか、今後も販売しない商品なのか判断しにくくなります。

GoogleのMerchant listing構造化データに関する公式資料では、availabilityの候補として、在庫あり、在庫切れ、予約、取り寄せ、販売終了などに対応する値が案内され、一つのOfferに複数の値を指定しないよう説明されています。これは機械向けの区分であり、ページ上では購入者が意味を理解できる表現と、必要に応じて入荷・発送時期を示すことが前提です。

Merchant Centerを利用している場合、Google Merchant Centerの在庫状況に関する公式ヘルプでは、一時的に注文を受けられない商品は在庫切れ、予約や取り寄せを受け付ける場合は該当状態と入荷予定日を使い、恒久的に販売を終えた商品は商品データから削除するよう案内しています。また、商品ページ、構造化データ、カート、商品データで在庫状況を一致させることが求められています。

これらを踏まえ、本記事では、販売状態を少なくとも「通常販売」「一時的な在庫切れ」「予約・取り寄せ」「販売終了」に分け、変更日、再開予定、注文可否を記録する運用を推奨します。販売終了ページを残すか、後継商品へ案内するかは、流入や問い合わせ対応の必要性も含めて個別に判断します。

商品ページ・カート・データをそろえる

Merchant Centerの公式ヘルプでは、商品ページ、構造化データ、カート、商品データの在庫状況を一致させ、価格と在庫を最新に保つよう案内しています。ここでいう一致は、単に同じ単語を書くことではありません。商品ページで購入可能に見えるなら、対象地域の購入者がカートでも注文できる状態であることが重要です。

色やサイズがある商品では、全体を「在庫あり」とするだけでは不十分な場合があります。たとえば、Mサイズだけが完売しているなら、その選択肢を選んだ時点で状態が分かり、商品データでも同じバリエーションの在庫が対応しているかを確認します。Googleの同ヘルプも、バリエーションごとの在庫を商品ページと商品データで一致させるよう案内しています。

実務上は、次の四つを同じ商品・同じ条件で照合すると整理しやすくなります。

• 商品詳細で見える価格、販売状態、適用期間
• 購入ボタンとカートで実際に選べる商品・バリエーション
• HTMLに出力されたProduct／Offer構造化データ
• Merchant Centerなどへ送る商品データ

在庫数そのものを公開する必要がある、という意味ではありません。購入者に示す販売状態と、実際の注文可否が食い違っていないかを確認するための整理です。

構造化データは表示内容の代わりではない

構造化データは、ページにある商品情報を機械が理解しやすい形で示すものです。購入者には古い価格を見せたまま、構造化データだけを新しくする運用にはしません。まずページとカートを正し、その内容に構造化データと商品データを合わせます。

GoogleのMerchant listing公式資料では、商品リッチリザルトは原則として一つの商品、または同じ親商品のバリエーションに焦点を当てたページを対象とし、商品一覧やカテゴリーページより商品詳細ページへのマークアップが推奨されています。また、JavaScriptでProduct構造化データを生成すると、価格や在庫のように変化が速い情報ではShopping向けクロールの頻度や信頼性に影響し得ると注意されています。

Merchant Centerには、ページ上の情報を使って価格や在庫などの一時的な不一致を補正する自動更新機能があります。ただし、Googleの自動更新に関する公式ヘルプは、この機能を通常の商品データ更新の代わりにせず、正確なデータを継続的に提供するよう説明しています。

GoogleのAI検索機能に関する公式資料では、AI OverviewsやAI Modeのためだけの特別な最適化や専用の構造化データは不要で、従来のSEOの基本が引き続き有効とされています。Merchant Centerの情報を最新に保つことも確認項目として挙げられています。したがって、本記事ではProduct構造化データを「AI表示のための特別な記述」ではなく、通常の商品情報管理の一部として扱います。

小規模EC向けの更新手順

更新担当者が少ない場合は、すべてを常時監視するより、変更の発生点と確認範囲を固定する方が続けやすくなります。これらを踏まえ、本記事では次の順番を推奨します。

1. 変更を分類する：価格改定、セール、在庫切れ、再入荷、予約開始、販売終了、バリエーション追加のどれかを記録します。
2. 基準データを更新する：実際の注文可否を制御する商品マスターや在庫管理を先に直します。
3. 購入画面を確認する：商品一覧、詳細、選択肢、購入ボタン、カートで同じ価格と状態になっているかを見ます。
4. 機械向けデータを確認する：Product／Offer構造化データと外部の商品データが、画面の内容に対応しているかを見ます。
5. 公開URLで検証する：ログアウト状態とスマートフォンでも確認し、必要に応じてリッチリザルトテストやMerchant Centerの診断を使います。
6. 確認日を残す：担当者、対象商品、変更前後、反映先、エラーの有無を記録します。

在庫が頻繁に変わる商品は、手入力先を増やすほど負担が大きくなります。可能であれば、商品マスターからページ、構造化データ、商品データへ同じ値を連携し、手作業は例外確認に寄せます。ただし、自動連携を導入した後も、カートで購入できるかという最終結果は人が定期的に確認してください。

公開前後の確認項目

• 商品詳細とカートの販売価格が一致している
• セール価格には実際の適用期間が反映されている
• 在庫切れ、予約、取り寄せ、販売終了を区別している
• 予約・取り寄せでは、分かる範囲で発送または入荷時期を示している
• 色・サイズなどの選択肢ごとに注文可否が正しい
• Product／Offer構造化データの価格、通貨、在庫が画面表示と対応している
• Merchant Center利用時は、商品データと診断結果も確認している
• 販売地域、配送、受け取り方法などの条件がカートまで一貫している
• 古い価格や販売状態が一覧、関連商品、キャッシュされた表示に残っていないか確認している

すべての項目を一度に完璧にする必要はありません。まず、注文数が多い商品、価格変更があった商品、在庫変動が大きい商品から確認すると整理しやすくなります。この優先順位は運営者による実務上の提案であり、検索表示や売上への効果を保証するものではありません。

まとめ

価格や在庫のずれを減らす出発点は、構造化データの追加ではなく、更新の基準を決めることです。商品ページ、カート、構造化データ、外部の商品データを同じ商品・同じバリエーションで照合し、一時的な在庫切れと予約、取り寄せ、販売終了を分けて管理します。

購入者が見て判断できる情報を先に整え、その内容を機械向けデータへ正確に反映する。この順番で運用すれば、更新箇所が増えても確認漏れを見つけやすくなります。ただし、AI検索や通常検索での採用・表示を直接指定するものではありません。