Configure the index
The index decides what search can possibly find. This is the one search setting that is worth getting right before launch, because everything else — facets, synonyms, boosting — operates on what the index already contains.
10 bar from 4,000 free-text descriptions is not.Three roles a field can have
Every field in the index has one or more of three roles. They are independent, and confusing them is the most common configuration mistake.
| Role | Means | Example |
|---|---|---|
| Searchable | The text is matched against the query | name, sku, manufacturer_part_number |
| Filterable (facet) | The engine can count and filter by it | material, thread_size, pressure_rating |
| Displayed / sortable | Returned with the hit, or used to order results | price, stock, image |
A field can be all three. manufacturer usually is: buyers type it, filter by
it, and see it in the result row. But description should be searchable and
never a facet — a facet over free text produces 4,000 buckets of one product
each. And pressure_rating should be a facet and usually not searchable, so
that typing 100 does not match every product with 100 anywhere in it.
Set field weights
When a query matches in several fields, weight decides which hit counts more. Weights are relative; only the order and the gaps between them matter.
A working starting point for a technical catalog:
| Field | Weight | Why |
|---|---|---|
sku | highest | Your article number. Identity. |
manufacturer_part_number | highest | The number buyers actually know |
cross_reference | high | Competitor numbers, after a supplier change |
name | high | The main descriptive field |
manufacturer | medium | Narrows, rarely identifies alone |
category_path | medium | Lets a vague word land on a listing |
option labels | medium | v4a → Stainless steel V4A |
description | low | Long text; matches easily and means little |
application_notes | lowest | Useful, noisy |
description a high weight to "improve recall". It is the
longest field, so it matches almost everything, and raising it pushes the right
article off position one for every descriptive query. If a fact matters enough
to search by, model it as an attribute instead.Steps
- Open App Studio › Services › Search and confirm the products collection exists and its document count roughly matches your enabled product count. If it does not, nothing below will have an effect.
- Decide, per attribute, which of the three roles it has. Do this in a spreadsheet against your attribute list — twenty minutes here saves a rebuild later.
- Mark every attribute a buyer filters by as Filterable (facet) in PIM › Data model › Attributes. This is the only source of facet fields; see Facets and filters.
- Set the searchable fields and their weights for the products index in the order above, adjusted to your catalog.
- Configure identifier behaviour for
sku,manufacturer_part_numberandcross_reference: typo tolerance off, whole-string match preserved, mid-string matching enabled, and the same normalisation applied to the query as to the value. This is what makes4711-A,4711andKAT-4711-Aall land on the right article. - Set typo tolerance for text fields: one typo for words of six characters
or more, none for short words. Short words are where typo tolerance does the
most damage — with typos allowed,
M8matchesM6. - Set the tie-break sort order after text relevance. In-stock before out-of-stock is the one almost every B2B catalog wants; see Merchandising for the rest.
- Save, then reindex.
Per-channel and per-locale indexes
One products index is not enough once you have more than one audience.
- Locale. Each language gets its own index, with its own text, its own synonyms and its own tokenisation. Adding a language in Localization is what creates it.
- Channel. Each channel gets its own, containing only the products assigned to it, with the channel-scoped values of scopable attributes. A punchout catalog and your web shop are different indexes even though they come from the same products.
The multiplication is real: three languages and two channels is six indexes and six reindex runs. This is an argument for being deliberate about how many scopable attributes and how many channels you create, not an argument against having them.
Reindexing, and what it costs
Two different operations get called "reindexing":
- Incremental update — a product changed, one document is rewritten. Seconds. This is what happens all day.
- Full rebuild — the index is built again from scratch. Required after any change to the index structure: adding a facet field, changing a field type, changing tokenisation. Minutes to an hour depending on catalog size.
A full rebuild does not take search offline. The new index is built alongside the live one and switched over in one step when it is complete. The old one is kept briefly so a bad change can be reverted by switching back.
What it does cost you is time before the change is visible, and that catches people out: you add a facet field, look at the storefront, see nothing, and assume it failed. Check the rebuild has finished before you conclude anything.
What to check
- Search your ten most-ordered article numbers. Each must return its own article first — not second.
- Search a partial article number. The right article must appear in autocomplete.
- Search a manufacturer part number you do not use internally. It must be found.
- Search a common descriptive phrase. The first three results must be plausible to someone from the Innendienst, not just to you.
Next
- Facets and filters — turning filterable attributes into a usable filter panel.
- Synonyms, stop words and rules — closing the vocabulary gap.