一部の商品が欠品している棚
一部の商品が欠品している棚
この記事の内容
  1. 在庫ゼロになった理由を確認する
  2. 一時的な品切れは状態を明確にする
  3. 購入操作と店内検索をそろえる
  4. 販売終了は後継品と情報の価値で決める
  5. 商品データの在庫状態も直す
  6. 少数の商品で切り替えを試す
  7. 費用は連携より更新の責任から考える
  8. 再入荷と検索実績を別々に追う

在庫ゼロになった理由を確認する

例として、手作りの保存瓶を販売する店で、定番品が一時的に売り切れた場合を考えます。次の製造予定がある商品、入荷見込みが決まらない商品、今後販売しない商品は同じ扱いにしません。商品ID、販売チャネル、バリエーション、在庫の確認時刻、再入荷の見込み、判断担当を記録します。注文済みの顧客が説明書や寸法を見に来る可能性も確認します。数値がゼロという理由だけで全商品を一括削除すると、再入荷時に必要な情報や既存リンクまで失うおそれがあります。

一時的な品切れは状態を明確にする

再販売する定番品は、ページの説明を維持しながら現在購入できないことを分かる位置に表示します。再入荷日が未確定なら、日付を予想で入れず、確認できた時点で更新する運用にします。通知登録を受け付ける場合は、登録と注文確定を区別し、通知後も在庫を保証する表示にしません。色や容量の一部だけが品切れなら、選択中のバリエーションに合う状態を示します。別の容量が買えるという理由で、売り切れた型番まで購入可能に見せないことが重要です。

購入操作と店内検索をそろえる

商品ページの表示だけでなく、カートへ追加する操作、検索結果、カテゴリ一覧、関連商品のカードも確認します。売り切れを末尾へ並べるか、絞り込みで外すかは店の探し方に合わせて決めます。既存顧客が型番で探す場合は、ページを見つけられる導線も残します。Shopifyなどの管理画面では、在庫数と商品の公開状態は別の設定です。公開停止やアーカイブを選ぶ前に、購入操作を止めたいのか、ページそのものを見せたくないのかを分けて確認します。

在庫棚の商品箱と空の保管トレー
在庫棚の商品箱と空の保管トレー

販売終了は後継品と情報の価値で決める

販売終了の商品は、後継品が実際に同じ用途を満たすかを確認します。寸法、対応部品、容量が違う商品へ無条件に転送すると、過去の購入者が誤った情報を読むことになります。説明書や交換部品の案内が必要なら、販売終了と明記した資料ページとして残す方法もあります。同等の置き換え先があり内容を移した場合は、適切な恒久転送を検討します。残す価値も対応する移転先もないページを削除する場合は、正常な本文のように200を返すのではなく、実際の削除状態を配信側で確認します。

在庫状態ごとのページの扱い
在庫状態ごとのページの扱い
状態ページの対応確認するもの
一時的な品切れ説明を残し品切れを表示購入操作と再入荷の案内
一部の選択肢のみ品切れ選択中の型番に状態を合わせる色・容量の切り替え
販売終了で資料が必要販売終了を明記して維持説明書と部品の対応
同等の後継品へ移行移す内容と転送を確認元の用途に答えられるか
残す価値も移転先もない削除と実際の応答を確認関連リンクの整理

商品データの在庫状態も直す

ページに商品構造化データを出している場合は、見える在庫表示とOfferのavailabilityを照合します。Googleの販売者向け資料ではOutOfStockとDiscontinuedは異なる状態です。さらに商品フィードを使う店では、ページ、フィード、購入画面の更新時刻がずれていないか確認します。構造化データを直せば必ず商品枠へ表示されるという意味ではありません。価格やレビューを埋めるために架空の値を加えず、実際に公開している商品情報と整合する範囲で設定を更新します。

少数の商品で切り替えを試す

最初は一時品切れ、販売終了、一部の色だけ品切れという三例で確認します。公開ページをログインなしで開き、選択肢を変え、購入操作と案内文を比べます。後継品へのリンクは型番と仕様を照合し、ページ内の画像や説明書が旧商品に対応していることも見ます。検索向けの設定を変えた場合は、実際の応答と公開HTMLを確認します。すべての商品へ適用する前に、在庫が戻った際に通常販売へ復帰できることまで一連の確認に含めます。

例えば青色だけが売り切れた商品では、青色を選ぶ前、選んだ後、別の容量へ戻した後をそれぞれ確認します。ページを再読込した場合も状態が一致するかを見れば、最初の表示だけ直って選択後の表示が古いままという不具合を見つけやすくなります。

販売終了時の案内先を選ぶ
販売終了時の案内先を選ぶ再入荷して販売するか → 品切れを表示して維持 (はい); 再入荷して販売するか → 同等の移転先があるか (いいえ); 同等の移転先があるか → 内容を移して転送を検討 (はい); 同等の移転先があるか → 資料として残すか削除を判断 (いいえ)はいいいえはいいいえ再入荷して販売するか品切れを表示して維持同等の移転先があるか内容を移して転送を検討資料として残すか削除を判断販売終了時の案内先を選ぶ再入荷して販売するか → 品切れを表示して維持 (はい); 再入荷して販売するか → 同等の移転先があるか (いいえ); 同等の移転先があるか → 内容を移して転送を検討 (はい); 同等の移転先があるか → 資料として残すか削除を判断 (いいえ)はいいいえはいいいえ再入荷して販売するか品切れを表示して維持同等の移転先があるか内容を移して転送を検討資料として残すか削除を判断

入荷見込みと後継品の判断は、商品管理の担当者が確認します。

費用は連携より更新の責任から考える

少数の商品なら、在庫判断と公開状態を担当者が確認する表から始められます。件数が増えたときに、商品管理、通知メール、外部フィードの連携費用を比較します。既存プランに含まれる機能と追加アプリの料金を分け、配信数や商品件数の上限は契約前に確認します。自動化する場合も、入荷見込みの判断や後継品の選定は担当者が確定させます。更新作業を省けるという理由だけで、商品説明まで機械的に削除する運用にしないことが大切です。

再入荷と検索実績を別々に追う

再入荷したら在庫表示、購入ボタン、選択肢、構造化データ、フィードを再確認します。Search Consoleでは対象URLをまとめて記録し、同じ期間と条件で検索の表示やクリックを見ます。検索の変動をすべて在庫対応の効果とせず、販売期間や季節性、他の更新も記録します。誤って公開停止にした場合は元の公開設定へ戻し、関連するリンクも直します。確認表に変更前後の状態と担当を残すと、同じ商品が次に品切れになったときも一貫した対応を取れます。

参照した公式情報

料金・提供条件・対応範囲は変更されることがあります。契約前に、下記の公式ページでご確認ください。

比較方針を読む広告について