Predictive search gone stale: fixing autocomplete that recommends discontinued or out-of-stock products

A shopper types

A shopper types the first four letters of your bestselling jacket into the search box. Autocomplete confidently suggests it, color swatches and all. They click through, add it to cart, and hit a wall: out of stock, or worse, a 404 because the product was discontinued eight months ago.

They don't file a bug report. They don't email support. They just leave, and maybe they try a competitor's search box next. This is predictive search quietly costing you sales, and because nothing "breaks" in the traditional sense (no error, no downtime), it rarely shows up on anyone's radar until someone happens to notice.

Why autocomplete drifts from your real catalog

Most storefronts don't generate autocomplete suggestions by querying your live product database in real time. That would be slow and expensive at scale. Instead, search apps (Shopify's native search, Algolia, Klevu, Searchanise, WooCommerce search plugins, BigCommerce's search index) maintain a separate, pre-built index optimized for speed.

That index is a snapshot. It gets refreshed on a schedule, or when a webhook tells it something changed. The gap between "product discontinued in your admin" and "product removed from the search index" is where stale predictive search lives.

A few common causes of that gap:

The reindex job silently fails or times out on large catalogs, and nobody is watching the job logs.

A product is unpublished or archived rather than deleted, and the search app's "out of stock" filter doesn't treat archived the same way it treats zero inventory.

Webhooks that should trigger reindexing (inventory update, product update) get dropped or rate-limited, a failure mode similar to what we cover in when your apps throttle you.

A third-party app was uninstalled, but leftover code or an old webhook subscription keeps feeding the index data that no longer matches reality, the same pattern described in orphaned app code.

None of these are dramatic failures. They're quiet, cumulative, and they compound the longer they go unchecked.

What a stale search index actually costs you

The direct cost is the lost sale from the specific shopper who hit a dead end. The indirect cost is larger: autocomplete is often the first real interaction a motivated shopper has with your store. If it recommends a sold-out size, a discontinued color, or a product that 404s, it signals that the store isn't well maintained, even if everything else is fine.

This is a close cousin of the problem we described in why your site search returns zero results for products you actually sell. Zero results frustrate; false positives mislead. Both are symptoms of the same underlying issue: the gap between what your search layer believes about your catalog and what's actually true.

It also compounds with inventory problems you may already be tracking elsewhere. If you've dealt with overselling out-of-stock variants, you already know how inventory sync lag causes real damage. A stale search index is the same lag, surfaced in a different part of the store.

How to audit your search index for freshness

You don't need engineering resources to run this audit, just a recurring half hour and a simple checklist.

Pull a list of your 20 to 30 highest-traffic search terms (most search apps and analytics tools report this). For each one, search your storefront directly and check whether the top three autocomplete suggestions are in stock, published, and still sell at the expected price.

Cross-reference your product feed export against what the search index returns. If you maintain a product feed for Google Shopping or AI shopping assistants, you likely already have a clean, current list of active SKUs. Compare that list against a sample of search results; discrepancies point to reindex lag. This is the same discipline described in AI shopping assistants quoting stale prices, where feed freshness problems show up downstream in places you don't control directly.

Check your search app's reindex logs or dashboard, if it exposes one. Most Algolia, Klevu, and Searchanise integrations show last-sync timestamps. A timestamp that's days or weeks old on a catalog that changes daily is your answer.

Test the archive/unpublish path specifically. Archive a low-traffic test product, wait the expected sync interval, then search for it. If it still appears, your index isn't picking up status changes correctly, not just inventory changes.

Fixing the underlying sync, not just the symptom

Once you've confirmed drift, the fix usually falls into one of three categories.

If it's a scheduling problem, shorten the reindex interval for fast-moving catalogs, or move from scheduled reindexing to webhook-triggered updates where your platform supports it. Shopify, WooCommerce, and BigCommerce all document webhook topics for product and inventory updates; most modern search apps can subscribe to these directly rather than polling.

If it's a webhook delivery problem, check your app's retry and failure handling. A webhook that silently fails once rarely gets a second chance unless the app has solid retry logic. This is worth auditing the same way you'd audit duplicate orders from webhook retries, just looking for the opposite failure: events that never arrive instead of events that arrive too many times.

If it's an app configuration problem, confirm that your search app's "available" filter actually maps to your platform's real stock and status fields, not just a cached inventory count. Variant-level stock (specific sizes or colors sold out while the parent product shows available) is a common gap worth testing specifically.

Making freshness a routine check, not a one-time fix

Search index drift isn't a problem you solve once. Catalogs change constantly: new seasonal lines, discontinued SKUs, restocks, price changes. The fix is building a recurring freshness check into your regular store maintenance, the same way you'd check uptime or page speed.

A simple version: once a week, search your top queries and spot-check the results. A more durable version: set up continuous monitoring that flags when search results diverge from your live product feed, so you catch drift within hours instead of discovering it when a customer complains. This is the same logic behind routines like the Monday-morning store check, just applied specifically to search quality.

Cassian™ monitors product data freshness across your store, including feed and inventory signals that feed into search quality, and rolls findings into the Cassian Score™ so you can see when something in your catalog pipeline needs attention before it reaches a shopper's search bar.

The bottom line

Predictive search is one of the few places in your store where you're making a direct promise to a motivated buyer in real time. Keeping that promise accurate doesn't require a search overhaul, just a regular audit of index freshness and a clear understanding of what triggers your reindex. Catch the drift early, and autocomplete stays what it's supposed to be: a shortcut to a sale, not a dead end.