Every product in a shopping feed eventually goes out of stock. What happens next usually gets treated as data hygiene: someone updates the feed, the disapprovals clear, the week moves on. That framing hides the decision you actually made.
What you'll take away
- The item id is the asset — clicks, conversions and auction confidence accumulate against it, and a removed row stops accruing anything.
- out_of_stock keeps the id warm — ads stop serving, budget stops leaking, the listing keeps its history.
- backorder is the only value that keeps selling — it needs an availability_date and a landing page that says the same thing.
- At catalogue scale it becomes a rule — restock window in, known date to backorder, everything else out.
Why this is a merchandising decision, not a schema question
Shopping channels tie everything they know about a product to its item id. Clicks, conversions, and the confidence the auction places in a listing all accumulate against that identifier, which is why Google's product data specification asks you to keep ids stable over time. An id with history is worth more than an identical product introduced as a stranger.
So the out-of-stock question is really this: when inventory pauses, does the item's memory pause with it? Remove the row and the id goes quiet. Delete it, then re-add it later under a new id, and you have introduced a product with no track record into an auction that rewards track records. Keep the row and flag it, and the id stays warm for the day stock returns.
None of this appears in a feed validation report. That is exactly why it tends to get decided by accident.
The three options, side by side
| Strategy | What it costs you | When it's right |
|---|---|---|
| Remove the row | Reporting stops, and the product returns as a stranger if the id changes | Discontinued lines, seasonal one-offs, no resupply planned |
| availability: out_of_stock | Every dark row still has to be generated, fetched and kept honest | Core catalogue items on a regular restock cadence |
| availability: backorder | Needs a date, a matching landing page, and a supply chain that delivers | Known resupply dates and buyers willing to wait |
Removing the item
Removal is clean on paper. The feed shrinks, the item cannot accrue disapprovals, no shopper is misled. The cost is the part you cannot see: the item stops reporting, so any before-and-after comparison around the restock is gone, and when the product comes back the channel processes it as new.
The remove-and-re-add path is where the money goes
If your feed source regenerates ids from row order, an export timestamp, or a re-imported catalogue, the returning product arrives under a fresh identifier and the old history is orphaned. The listing restarts cold. For a product that sold well before the gap, that is an expensive way to handle two quiet weeks.
Removal fits items that are not coming back: discontinued lines, seasonal one-offs, long-tail SKUs with no planned resupply. If you do remove, remove under a rule, and make sure the id scheme hands back the same id if the product ever returns.
Keeping it listed, marked unavailable
Feeds have a dedicated value for this. Google's specification accepts four availability values, and the difference between them is the entire strategy:
in_stock | out_of_stock | preorder | backorderSetting availability to out_of_stock tells the channel the offer exists but cannot convert right now. Shopping ads for that item stop serving, so budget stops leaking into clicks on a product nobody can buy, while the listing can still appear in free results for people searching by name. Meta and TikTok carry equivalent values under slightly different names, so the approach ports across channels.
The trade-off is carrying weight. Every unavailable row still has to be generated, fetched, validated, and kept honest against a landing page that agrees with it. On catalogues where a large share of SKUs sits dark at any moment, that is real overhead, and it only works while the flag is accurate.
The flag has to be right in both directions
A feed that says in_stock while the page says sold out invites a disapproval under Google's misrepresentation policy. A feed that says out_of_stock while the page quietly sells burns selling days nobody is counting. Both failures come from the same missing sync.
This is the default answer for core catalogue items on a regular restock cadence. When a product returns within days or weeks, keeping the row warm costs less than rebuilding the listing's standing from zero.
Keeping it listed with a backorder signal
Backorder and preorder are the values most merchants never touch, and they are the only ones that let an out-of-stock item keep selling. Marking a product backorder tells the channel it can be ordered now and shipped later, which keeps the listing serving through the gap instead of handing the query to whoever else ranks for it.
What backorder requires beyond the flag
Google requires an availability_date on preorder and backorder items, and recommends a date no more than a year out. The landing page has to state the ship expectation as plainly as the feed does. And the promise has to be one your supply chain actually keeps, because the complaint lands on your brand rather than on the feed.
Use it for products with known resupply dates and buyers who will wait: high-consideration goods, proven sellers on a reliable cycle, launches where preorder is the natural posture. For commodity items where the next tab sells the same thing today, backorder mostly adds friction.
Choosing by catalogue size and restock cadence
Two variables decide most of it. How fast items come back, and how many items you are deciding for.
Cadence sets the strategy per item. Products that return within days should never leave the feed, which is what out_of_stock is for. Products with a known return date and patient buyers are backorder candidates. Products with no resupply planned should go, under a rule that preserves their ids against the unlikely return.
Size decides whether any of that can be manual. A store with two hundred SKUs can go item by item. At catalogue scale the choice has to be a rule the feed applies on its own, and the strategy moves up a level into the restock window you set and the categories you decide can tolerate waiting. What it cannot depend on is a human noticing.
What to check before committing
Four checks that decide whether your strategy survives contact with the feed
Most out-of-stock mistakes trace back to the first two. A strategy chosen at the merchandising level, undone by a feed that was never configured to carry it out.
Common questions
Should I remove out-of-stock products from my Google Shopping feed?
Only when they are not coming back. Removing a row stops the item reporting and risks a new item id on return, which restarts the listing's history. For anything on a normal restock cadence, keep the row and set availability to out_of_stock instead.
What does availability out_of_stock do to my ads?
Shopping ads for that item stop serving, so you stop paying for clicks on something nobody can buy. The listing keeps its item id and its accumulated history, and it can return to serving as soon as your inventory system flips the value back to in_stock.
When should I use backorder instead of out_of_stock?
Use backorder when the product can still be ordered and shipped later, you know the date, and the landing page says so. It keeps the listing serving through the gap. Use out_of_stock when the item cannot be bought at all right now.
Does an out-of-stock product still show in free listings?
It can. Shopping ads stop for an out_of_stock item, while the product may still appear in free product listings for shoppers searching it by name. That is one more reason to flag the row rather than delete it.
Free tool
Not sure if your feed has errors?
Run your Google Shopping, Meta, or TikTok product feed through our free validator and get a prioritized error report before channels reject your products.
Editorial note
Written by Muhammad Norafif
This article was published on August 23, 2026 and last updated on August 23, 2026. NextFeed builds product feed management software for Shopify, Google Shopping, Meta, and other commerce channels.