Ecommerce indexing: keeping stock and prices current in search results

An out-of-date price in a search result is worse than no result at all: you pay for the click with your crawl budget and lose the customer at the landing page. For catalogues that change daily, keeping search results current is a genuine operational problem.

Why shops are the hardest case

• Volume. Thousands of URLs, each individually low-traffic.
• Rate of change. Prices, stock levels and variants shift constantly, often via automated feeds.
• Uneven importance. A handful of products drive most revenue; the long tail is crawled rarely.
• URL sprawl. Faceted navigation can generate combinatorially many URLs that consume crawl and index nothing useful.

The result is predictable: your bestsellers stay reasonably fresh and the long tail drifts months out of date.

Decide what a "change" is

This is the decision that determines whether your setup works or gets you rate limited. Not every database write deserves a submission.

Worth submitting:

• New product published
• Price change
• Went out of stock, or came back into stock
• Title, description or images substantially changed
• Product discontinued (so the 404 or redirect is picked up)

Not worth submitting:

• Stock level moving from 47 to 46
• Review count incrementing
• "Recently viewed" or recommendation blocks changing
• Template or CSS changes
• Anything on a page you have canonicalised elsewhere

The distinction is whether the change alters what a search result would say. That is the test.

Get the structured data right first

Before worrying about submission frequency, make sure the page states its facts machine-readably. Product schema with offers.price, priceCurrency and availability is what lets an engine show a current price and stock state — and lets it detect a change without a human reading the page.

{
  "@context": "https://schema.org",
  "@type": "Product",
  "name": "Cast Iron Skillet 26cm",
  "sku": "CIS-26",
  "offers": {
    "@type": "Offer",
    "price": "42.00",
    "priceCurrency": "GBP",
    "availability": "https://schema.org/InStock",
    "url": "https://example.com/products/cast-iron-skillet-26"
  }
}

Structured data that disagrees with the visible page is worse than none — engines detect the mismatch and discount both.

Handle out-of-stock properly

A recurring mistake. Three cases, three correct answers:

• Temporarily out of stock, returning: keep the page live, keep it indexed, set availability to OutOfStock. Do not 404 it — you will lose the accumulated ranking and have to rebuild it.
• Permanently discontinued, with a successor: 301 to the replacement product.
• Permanently discontinued, no successor: return 410 Gone, and remove it from your sitemap.

Sitemap hygiene at scale

• Split into multiple sitemaps of under 50,000 URLs each, referenced from a sitemap index.
• Consider separating fast-changing products from stable category and content pages — it makes lastmod genuinely informative.
• Make lastmod reflect real product changes, not your nightly rebuild. If every URL shows today's date every day, the field is noise and gets ignored.
• Exclude out-of-stock-permanently, canonicalised and parameterised URLs.

Control the faceted navigation

Colour × size × price × brand generates an enormous URL space that indexes nothing anyone searches for. Pick the few facet combinations with real search demand, allow those, and block the rest in robots.txt or canonicalise them to the parent category. This is usually the single biggest crawl efficiency win available to a shop.

Then automate the notification

With the above in place, notifying engines of genuine changes is straightforward — and this is where IndexNow earns its keep on ecommerce specifically, because the volume of legitimate changes is exactly the case manual submission cannot handle.

Two approaches, and they combine well:

1. Event-driven: when your system writes a price or stock change, call the submission API for that URL. Fastest, but needs the "what counts as a change" logic to live in your codebase.
2. Sitemap-driven: an external service reads your sitemap on a schedule and submits what moved. Nothing to build, and it catches changes made outside your application — bulk imports, supplier feeds, direct database edits — which event hooks routinely miss.

Index-now does the second, with an API for the first, at $12 per domain per year.