Why Adobe Commerce Live Search Shows Products You No Longer Have

A customer searches your store, finds a product, clicks through, and the product is out of stock. Or the price on the results page is last week's. The catalogue in the admin is correct, the product is correct, and the search results are still wrong.

We flagged this in passing when we wrote about what Live Search and AI recommendations actually deliver: across those implementations, keeping Live Search's product data accurately synced took real integration work, particularly on catalogues where stock and pricing move constantly. It is a data-pipeline problem rather than an AI one, and it deserves its own explanation.

Live Search does not read your database

This is the part that catches most teams out, and everything else follows from it.

Live Search is a SaaS service. Your storefront does not query your own MySQL catalogue when a customer types in the search box. It queries Adobe's service, and that service answers from a copy of your catalogue that your store exported to it earlier. The SaaS Data Export extension — opens in a new tab is what maintains that copy.

So "the product is right in the admin" and "the product is right in search results" are two separate claims. The first says your database is correct. The second says the export pipeline delivered that correction, and those can be days apart without anything appearing broken.

How a product change actually reaches the search index

Adobe documents the flow — opens in a new tab as a chain, and it is worth knowing because a fault at any link produces the same symptom:

1. Change detection. Mview spots the modified row in a table such as catalog_product_entity and writes an entry to a changelog.
2. Feed indexing. The feed indexer reads the changelog and assembles feed items.
3. Collection. Providers gather the field data for each feed's schema.
4. Hash deduplication. Content hashes decide what actually changed. Unmodified data is skipped rather than resent.
5. Submission. Batches POST to Adobe's Feed Ingestion Service.
6. Status write-back. The response updates the feed table, per item.
7. Retry. Failures are resubmitted on a schedule.

None of it is instant, and all of it rides on cron:

Adobe's own guidance is that a product update should be indexed within a few minutes, that incremental updates can take 15 to 20 minutes, and that the very first index after installation can take over 30. If cron is unhealthy, or the changelog has backed up behind a large catalogue operation, none of those numbers hold.

The setting that quietly stops updates

Here is the sharpest edge in the whole subject. Ongoing changes reach the service through partial sync, and partial sync only runs when cron is enabled and the indexers are in Update by Schedule mode.

Put an indexer back into Update on Save and there is no changelog for the feed indexer to read. Nothing errors. The admin looks healthy. Your catalogue simply stops reaching Live Search, and you find out from a customer.

This connects directly to the 2.4.8 upgrade: Adobe changed the default indexer mode from Update on Save to Update by Schedule on new installs and upgrades. That default now works in your favour. What it does not do is protect a store where someone switched an indexer back to Update on Save while debugging something else and never switched it forward again.

"Submitted" is not the same as "live"

The admin has a real answer for this, at System > Data Transfer > Data Feed Sync Status. It reports four states per feed:

It also shows source records against sent records, the changelog backlog, and which mode each indexer is in, which is the fastest way to catch the problem in the previous section.

One caveat from Adobe's own documentation is worth quoting plainly, because it is the difference between a five-minute check and a two-day hunt: a successful export does not guarantee the data is available downstream in the connected service. Submitted to service means your store handed the data over. It does not mean the search index has finished absorbing it.

Finding the single SKU that is wrong

When one product misbehaves rather than the whole catalogue, the question is which link in the chain dropped it. Adobe's troubleshooting article — opens in a new tab goes at the feed tables directly, and carries the queries to copy.

Look the SKU up in cde_products_feed, matching on the sku and storeViewCode values inside its feed_data JSON. If no row comes back, the change never became a feed item at all, and the fault is upstream at change detection or feed indexing. If the row is there but stale, compare its modified_at against the product's own modification time, then check the last export timestamp in scopes_website_data_exporter. That single comparison separates "we never collected it" from "we collected it and never sent it", which are different faults with different fixes. Product attributes have their own feed, cde_product_attributes_feed, worth checking separately when the product is present but one field is wrong.

For forcing the pipeline by hand:

• bin/magento cron:run --group=saas_data_exporter triggers a sync immediately
• bin/magento indexer:reindex cde_products_feed rebuilds the product feed
• bin/magento saas:resync --feed products resends new, updated, and previously failed items

Treat --cleanup-feed with care. It appears in Adobe's instructions for recovering from a changed Data Space ID, and Adobe is explicit that it is for full environment rebuilds rather than routine troubleshooting. It is not the flag to add because a resync did not work the first time.

Why frequent stock and price changes are the hard case

A catalogue that changes twice a day is barely affected by any of this. A fifteen minute lag on a product edit is invisible.

The difficulty arrives when stock and prices move continuously, which is the normal condition for a retailer running promotions, marketplace channels, or an ERP that pushes updates all day. Now the changelog is never quiet, the export is always working, and the window in which the exported copy disagrees with the catalogue is permanently open rather than occasionally.

That is also why this so often turns out not to be a search problem at all. If stock levels reach the catalogue late from the ERP or POS upstream, Live Search is faithfully exporting numbers that were already wrong when it received them. The pipeline is doing its job on bad input. Diagnosing the search index first, when the fault is a system two hops upstream, is the most common way to lose a week on this.

For retailers whose stock genuinely lives in several places at once, across a webstore, marketplaces, and physical stores, the underlying fix is a single source of truth for product, price, and inventory rather than tighter tuning of one export. That is the problem WOW Sync exists to solve, and it sits upstream of everything described here.

If your Live Search results and your catalogue disagree and you would rather not spend a week finding out where, talk to us.

---

Sources: Adobe Experience League, SaaS Data Export Guide — opens in a new tab, Synchronize Data with SaaS Data Export — opens in a new tab, Data Feed Sync Status — opens in a new tab, and Live search catalog not synchronized — opens in a new tab, plus our own integration experience on Adobe Commerce catalogues.