A well-run Salesforce Commerce Cloud catalog is a real achievement. Categories are structured, products are assigned, variation masters have their attributes, images resolve, price books are current, and the search index rebuilds without errors. From inside Business Manager, everything is in order.

Then you watch a session recording, or read a search analytics report, and a shopper types “waterproof jacket”, gets 400 results sorted by something that made sense to nobody, refines twice, and leaves.

Catalog management and product discovery are related, but they are not the same job. One is about the data being correct. The other is about the data being found.

Where the two jobs separate

Catalog management asks: is this product modelled correctly? Discovery asks: when someone describes what they want, in their words, does this product come back — and does it come back near the top?

Those questions come apart in ordinary ways:

  • The product is categorized correctly, but the shopper searched for a use case (“running in the rain”) rather than a category.
  • Attributes exist, but they are not searchable, not refinable, or populated inconsistently enough that a refinement returns half the products it should.
  • Search returns the right set of products in an order that buries the ones people actually buy.
  • Synonyms are missing, so the brand’s internal vocabulary (“gilet”, “trainers”) and the shopper’s vocabulary never meet.
  • A query returns nothing, and the no-results page is a dead end rather than a recovery.

None of these are catalog errors. Every one of them is a lost sale.

The tuning you can do inside SFCC

Commerce Cloud gives you a real set of levers, and they are worth exhausting before concluding that search is a lost cause:

Searchable attributes. Which attributes are indexed for search, and with what weighting, decides what a keyword can match at all. This is the single most under-configured area in most implementations.

Search refinements. Refinement definitions per category, with sensible ordering and value grouping, are what turn 400 results into a browsable set. Refinements built on sparsely populated attributes actively mislead — a filter that hides good products is worse than no filter.

Sorting rules. The default sort on a category is a merchandising decision, not a technical default. Sorting by relevance, by revenue, by margin or by newness all produce different businesses.

Synonyms and stop words. Synonym lists are cheap to maintain and pay back immediately. Mine them from your own search logs rather than inventing them: the queries that return zero results are a ready-made list of vocabulary your catalog does not speak.

Search redirects. For a small number of high-volume, high-intent queries, sending shoppers straight to a curated landing page beats any amount of relevance tuning.

Product ranking and sorting rules per category. Boost and bury are blunt instruments, but for a seasonal push or a problem category they are the fastest fix available.

Working through these means a lot of Business Manager time: search indexes, sorting rules, refinement definitions, one category at a time, with a reindex and a storefront check between changes. Getting to those screens quickly, rebuilding the right index without walking through four menus, and having a session that does not expire mid-edit is the difference between doing this properly and doing it once.

Where configuration runs out

There is a point past which the built-in tools stop being the constraint, and the model itself is. It shows up as symptoms like:

  • Relevance that is only fixable query by query, so the list of manual rules grows forever.
  • Queries that mix intent and constraint — “cheap waterproof jacket for hiking” — where keyword matching has no way to weigh the parts.
  • No usable signal from behaviour: what shoppers clicked, ignored, added to cart or returned to never feeds back into ranking.
  • Merchandisers who cannot see why a product ranks where it does, so tuning is guesswork with a reindex between each guess.
  • Long-tail queries — the majority of unique searches — that nobody has time to hand-tune.

At that stage the honest diagnosis is not “the catalog is wrong”. It is that keyword search over a static index is being asked to model shopper intent, which is not what it was built to do.

What to do about it

Two things, in order. First, finish the configuration work — most storefronts have measurable gains left in searchable attributes, synonyms and refinement quality, and those are free. Second, instrument it: track zero-result queries, click-through position, search-to-cart rate and refinement usage. Without that, every relevance change is an opinion.

If, with that done, discovery is still the bottleneck — if intent, behavioural signals and long-tail relevance are the problem rather than data quality — the next step is a discovery layer that ranks on more than keyword matches.