Handle out-of-stock products: UX and search-visibility choices

When a SKU runs out, choose a policy that matches its commercial future: keep the page live and mark it OutOfStock, publish but hide from catalog lists, or remove and redirect/return 410 for permanently discontinued items.

Editorial illustration: a product card with a navy ‘Out of stock’ badge and a small back‑in‑stock signup card on a pale mint background, with soft shadows and teal accents.

If you expect to restock, keep the product page published, show a clear “Out of stock” state and offer a back‑in‑stock signup. That single choice preserves customer routes (bookmarks, shared links) and is usually the simplest path. Below is a concise guide that explains the three practical policies, the WooCommerce settings you must check, how to expose availability to search engines, and a one‑SKU test you can run end‑to‑end.

In this guide

Why this matters ·
Pick a policy ·
Configure inventory ·
Structured data ·
Verify emitted markup ·
Verification checklist ·
One‑SKU test ·
Fictional example ·
Next action ·
References

Why this matters

Keeping a live product page when you will restock preserves the customer route (bookmarks, saved links, email referrals) and keeps whatever search signals the page already has. Removing a permanently discontinued page avoids customer frustration and reduces irrelevant search results. Structured data and HTTP responses control how search engines interpret availability and whether a URL should remain indexed—so both the user experience and the search signals matter.

Pick a policy: keep, hide or remove

Choose based on the SKU’s commercial future and importance:

  • Keep the page live and show “Out of stock” — best for items you plan to restock. Visible availability, an estimated restock date if known, and a back‑in‑stock signup (email or SMS) give shoppers a clear next step.
  • Keep published but hide from catalog listings — useful when you want existing direct links (marketing, saved links) to work but don’t want the SKU showing in category pages or site search. This preserves the URL while removing it from discovery channels you control.
  • Remove and redirect or return 410 — for permanently discontinued products. 301‑redirect to a highly relevant alternative if one exists; otherwise serve 410 (or 404) to indicate the content is gone. Google’s guidance on how status codes affect crawling/indexing is useful when you decide.

Configure WooCommerce inventory & visibility

Before you act, confirm the product’s inventory and visibility settings in WooCommerce admin. The fields you frequently need are:

  • manage_stock — whether stock is tracked for this product (yes/no).
  • stock_status — canonical availability values (for example: instock, outofstock, onbackorder).
  • stock_quantity — numeric quantity; when manage_stock is disabled this can be null.

Unmanaged stock can have a null quantity; check both manage_stock and stock_quantity when automating or importing. Use the product editor Inventory panel for single edits, and confirm CSV import/export uses the canonical field names (stock_status, manage_stock) when bulk updating. If you want out‑of‑stock items hidden from category pages, check the global “Out Of Stock Visibility” toggle and the product Catalog visibility options in WooCommerce settings. Official WooCommerce docs are linked in References below for these controls.

Mark availability for search engines (structured data)

Search engines read structured data to understand product availability. Use the schema.org ItemAvailability values inside the Offer block (offers.availability). For a temporarily unavailable item the canonical value is schema.org: OutOfStock. Google’s Product structured‑data documentation shows the expected JSON‑LD shape and examples.

Important qualification: WooCommerce core, themes and plugins differ. There is no universal guarantee that any given shop will output Product/Offer JSON‑LD or that availability is included by default. You must inspect the rendered page for your theme and plugins rather than assume the markup exists. If availability is injected client‑side with JavaScript or emitted by an SEO plugin, Google must render the page before it can process that markup. Verify the rendered result on the live URL (or a staging copy) as described next. To confirm what Search actually reads, run the checks in our Validate product markup guide (Validate product markup).

Verify what the public page actually emits

Do these checks on a live product URL or on a staging copy that mirrors production. Don’t run destructive actions on the live store.

  1. Open the product page in a browser and confirm the visible customer state: out‑of‑stock label, any restock estimate and the back‑in‑stock signup form are present to visitors.
  2. View page source (Ctrl+U / Cmd+Option+U) or use the browser inspector and look for a <script type=”application/ld+json”> tag. Search it for “offers”, “availability” and the schema.org value “schema.org“.
  3. If you don’t find availability in the static source but you see it in the DOM inspector, the availability is client‑rendered with JavaScript. Google processes JavaScript in separate crawling, rendering and indexing phases, and rendering can be queued, so use Google’s testing tools to confirm the rendered markup.
  4. Run Google’s structured‑data testing resources to see how Google parses the page (for example Rich Results Test or use the URL Inspection tool in Search Console). Remember that server‑rendered JSON‑LD is present in the initial HTML, while client‑rendered data depends on Google’s rendering step. Test the URL rather than assuming either implementation is being read correctly.
  5. If availability is dynamic (stock updates via inventory jobs, caches, or external systems), check how quickly caches expire and whether those updates are reflected in the rendered JSON‑LD you inspected.

Practical verification checklist (one product test)

  1. In WooCommerce admin: open the product → Inventory. Confirm manage_stock, stock_quantity and stock_status reflect the intended state. Note that stock_quantity may be null if manage_stock is disabled.
  2. Decide the policy for this SKU: keep + back‑in‑stock form, keep published but hide from catalog, or remove + redirect/410.
  3. Confirm the public page shows a clear customer message (Out of stock, restock estimate, back‑in‑stock signup).
  4. Inspect the public product HTML for Product/Offer JSON‑LD and offers.availability using the schema.org value. If it’s missing, trace which component (theme or plugin) should provide the structured data.
  5. For permanently removed SKUs: implement a 301 to a close match or return 410. Use Search Console and Google’s HTTP status code guidance if you need faster removal or troubleshooting.

Worked mini‑case: a runnable one‑SKU test

Run this exact sequence on one representative SKU. It’s deliberately precise so you can copy the checks and produce an observable pass/fail result.

  1. Pick one SKU and note its public product URL (for example: example product (example.com/product/sku-slug)). Work on a staging copy if you have one; if not, use the live URL but do not change payments, orders or customer accounts during the test.
  2. In WooCommerce admin (Products → open the product):
    1. Record these three visible values in the product editor Inventory panel: Manage stock (Yes/No), Stock quantity (number or empty), Stock status (instock / outofstock / onbackorder).
    2. Record the product’s Catalog visibility setting (Public / Hidden / Search / Shop) if present.

    Expected: you must be able to reproduce these values on your screen; they are the authoritative admin state.

  3. Open the product’s public URL in a fresh browser tab as a normal customer (not logged in):
    1. Check the visible label: is there a clear “Out of stock” message or a different phrasing? Note the exact text you see.
    2. Check that any back‑in‑stock email or SMS signup is present and functional at UI level (shows an input and submit button); do not submit test personal data — just confirm the form appears.

    Pass/fail: pass if the visible message and signup appear as you expect; fail if nothing indicates the item is unavailable.

  4. Inspect the page source for structured data:
    1. Open view source (Ctrl+U / Cmd+Option+U). Search (Ctrl+F) for application/ld+json. If found, copy the nearest JSON‑LD block to a text editor and search it for the keys “offers” and “availability”.
    2. If you find an offers.availability value, record the exact string (for example: "https://schema.org/OutOfStock").
    3. If you do not find availability in the static source, open the browser inspector (Elements/DOM) and search there. If availability appears only in the DOM inspector and not in view source, note that the markup is client‑rendered (JavaScript) rather than server‑rendered.

    Expected outcomes you can observe:

    • Server‑rendered availability present: you will find the application/ld+json in view source and the offers.availability string inside it. This is the clearest signal for search crawlers.
    • Availability only in the DOM inspector: the value is client‑rendered. That is observable because it is absent from view‑source but present in Elements after JavaScript runs.
    • No structured data at all: you will find neither an application/ld+json block nor an offers object in the DOM. That means your theme/plugins are not emitting Product/Offer JSON‑LD by default.
  5. Validate with a search tool: paste the public URL into your Rich Results Test (or run URL Inspection in Search Console). The tool will report Product structured data it can parse and any errors. Record whether the tool reports offers.availability and whether it flags errors or warnings.
    Expected: the tool either detects the Product/Offer markup (with availability) or it reports none. Use that single result to decide whether you must add or fix structured data.
  6. Decide action from observable results:
    • If admin shows manage_stock=yes and stock_status=outofstock, the public page shows a visible out‑of‑stock label, and offers.availability exists as https://schema.org/OutOfStock, then the site is emitting availability and you can concentrate on customer UX (signup, restock dates, alternatives).
    • If admin and public UI both show out‑of‑stock but there is no offers.availability in view source, plan to add structured data via your theme or an SEO/product schema plugin (or consult the theme/plugin docs). Before changing code, test on staging or ask the maintainer which component emits schema.
    • If availability is client‑rendered, inspect Google’s rendered HTML with URL Inspection and follow its JavaScript structured‑data guidance. If the property is missing there, fix the theme or plugin that emits the markup.

These steps produce clear, copyable evidence: the admin screenshots/notes, the view‑source JSON‑LD snippet (or its absence), and the Rich Results Test/URL Inspection result. That evidence decides whether you need a UX change, structured‑data work, or a redirect/410 for a permanently removed SKU.

Fictional example (illustrative)

HYPOTHETICAL: A shoe model “Hillside Runner” is temporarily out of stock. The shop keeps the product page live, displays “Out of stock” on the product card, shows an email signup labelled “Notify me when this is back” and leaves the product URL active for customers who saved it. The owner verifies the public URL contains a Product Offer JSON‑LD block where offers.availability uses schema.org. They monitor customer signups and Google Search Console for evidence the page remains useful.

{
  "@context": "https://schema.org/",
  "@type": "Product",
  "name": "Hillside Runner",
  "offers": {
    "@type": "Offer",
    "priceCurrency": "USD",
    "price": "79.00",
    "availability": "https://schema.org/OutOfStock"
  }
}

This snippet is illustrative. Do not assume your store emits this exact block—verify the rendered page for your theme and plugins.

Next practical action

Choose one representative SKU and run the five‑step verification checklist and the worked mini‑case above. That single, concrete test tells you whether your theme or plugins already publish availability, whether the page must be hidden or removed, and what to change in WooCommerce admin or your theme/plugin stack.

Official references mentioned in the guide:

Related guides on this site (search these titles on our site):

  • Add the product structured data search engines expect (WooCommerce)
  • Validate product structured data with Google’s Rich Results Test and URL Inspection

Decide the policy for one SKU now, run the verification checklist and the worked mini‑case on its public URL, and then act: update admin settings, add a back‑in‑stock form, change visibility or implement redirects. That single test shows the practical next steps for the rest of your catalogue.