Common search problems
Almost every search complaint arrives in one of three forms: it is not found, the wrong one is first, or it is slow. This is the diagnosis order for each. Most causes are product data, and every product-data check below runs on fields that exist on your tenant today. Where a fix needs a Search app screen, the page says so.
The product exists but is not found
Work down this list. Stop at the first "no"; that is your cause.
| Check | Where | If no |
|---|---|---|
| Is the product enabled? | PIM › Products, Status filter (enabled) | Enable it |
| Is it assigned to the buyer's channel? | Configuration › Channels: the channel's Unassigned rows setting, then the product's assignment | Product not visible |
| Is the buyer on the channel you think? | A punchout buyer searches the punchout channel, not the web shop | Repeat the checks for that channel |
| Does the searched word appear in an indexed field? | sku, name, description, manufacturer, ean, category codes and labels | Put it in name or description |
| Is the value in a technical attribute only? | Attribute values travel with the product but are not text-indexed today | Same fix; searchable attributes are planned |
| Is the localized name filled? | The product's name in the buyer's locale | Translation gap |
| Has the index caught up? | Minutes after a bulk change | Below |
The two that catch people most often are the channel and the locale. A buyer inside a closed punchout channel and a buyer on the English storefront are each searching a different slice of the index from the one you are looking at, because the index is scoped by channel and locale.
The products app defines that index. It reads sku, name, description,
manufacturer, ean and the category codes and labels as searchable text,
and carries kind, enabled, manufacturer and categories as facets.
Other attribute values are stored with the product for display and filtering
but are not searched as text, so thread_size = M8 is not found by typing
M8 unless M8 also appears in the name or description. The planned index
configuration in the Search app is where attributes become searchable and
weighted; Configure the index
describes how that is meant to work. The catalog-side view of the same problem
is Product not searchable.
Index lag after an import
The index is derived from the catalog and updated after changes; it is not read live. In normal operation the delay is seconds and nobody notices. After a bulk import it is different: tens of thousands of product changes land at once and are applied in order.
| Observation | Meaning |
|---|---|
| New products appear over several minutes | Normal. The backlog is draining. |
| Some appear, some do not, an hour later | Not normal. Those rows either did not import or did not reach the index. |
| Nothing changed at all | The import did not commit, or it wrote to a different channel or locale than the one you are searching |
| Counts in search lower than in the Cockpit | Expected while the backlog drains; wrong afterwards |
When rows are still missing after an hour, read the import result first, under Integration Studio › Data exchange › Import & Export. Rows the import rejected never reach the index, and a single malformed value on one row is the usual whole explanation for "the import did not work". If the import shows the rows as written and search still does not, open a support case with three example SKUs. The index status and failed-update views planned for the Search app are meant to make this visible without one.
The wrong product comes first
| Symptom | Usual cause | Fix |
|---|---|---|
| An exact article number returns something else first | A boost or pin outranks identity, or description outweighs sku | Remove the boost; the identity rule in Merchandising |
| A near-miss article number matches | Typo tolerance applied to identifier fields | Planned: switch it off for sku and ean in the index configuration |
| A long-tail article beats the obvious one | description weighted too high | Planned: lower it. Today: keep the distinguishing words in name |
| Fifty lengths of the same screw fill page one | Nothing groups the family and no standard variant is boosted | Planned: group by family, boost the standard size |
| A discontinued article ranks first | Its name matches best and it is still enabled | Disable it. This works today |
| Results are right in German, wrong in English | English name and description are empty or still hold the German text | Translation quality |
Facet counts that do not add up
The facets on the products index today are kind, enabled, manufacturer
and categories; attribute facets come with
filterable attributes. Three behaviours
look like bugs and are not:
- The Cockpit says 412 products, the facet says 380. The facet counts what the buyer may see: the channel's slice, with disabled products filtered out.
- Selecting an option does not reduce the counts in the same facet. In a standard facet panel, options within one facet combine with OR, so the other options stay countable. Counts in the other facets do reduce.
- A facet shows an option with a count of zero. The attribute has an
option (
attribute_options) that no product in this result set carries. Either the option is unused and should go, or the facet is shown in a category where it does not belong; see Facets and filters.
One that is a bug: counts that change between two identical requests. That points at an index mid-rebuild or at nodes with different data. Note the two requests and the time, and report it. Do not tune anything until it is explained.
Search is slow
The engine answers in well under 100 milliseconds; that is what it is built for. When a results page does not:
| Cause | Sign | What to do |
|---|---|---|
| The storefront resolves prices or stock per result row | Slow results page, fast autocomplete | Fix the storefront. This is the most common cause by far |
| The page requests every facet | Only listing pages are slow | Request only the facets the page renders |
| Broad queries return the whole result set | Slow on schraube, fast on 4711-A | Paginate |
| Autocomplete queries every field | Only the dropdown is slow | Identifiers and name only; see Autocomplete |
| The index is being rebuilt | Slow for a bounded period after a large change | Wait; schedule large imports outside business hours |
Field weighting and the number of searchable fields also affect speed, and both are part of the planned index configuration. Until it ships, the field list is fixed by the products app, so the causes you can act on are the storefront ones above.
Next
- Search analytics
- Product not visible — the catalog-side version of "it is not found".