Improving On-Site Product Search Through Customer Vocabulary and Result Relevance

Separate Four Reasons a Search Can Fail

Search relevance means how well the returned results satisfy the intended task. Catalogue coverage means whether the eligible products are represented in the records available to the search engine. Filters narrow the result set, while ranking controls the order of the remaining matches. Vocabulary handling determines how the words entered relate to searchable product information.

These distinctions prevent a common misdiagnosis: adding synonyms for a product that never entered the searchable catalogue. A synonym cannot retrieve an absent record. Conversely, a complete record does not guarantee that a buyer’s informal name will retrieve it.

Consider the whole journey. A useful suggestion while typing can lead to a poor results page after submission. A relevant result card can open the wrong variant. Record each surface separately rather than treating everything behind the search box as one result.

Define what a good result means before testing

For an exact, unique product code, the expected item should normally be the leading result. Treat that as an acceptance criterion you agree with the business, not a universal platform rule. If a code belongs to several pack sizes, the expected outcome must account for the ambiguity.

A broad query needs a relevant choice of products. It does not necessarily have one correct first result. Agree which attributes are essential, which alternatives are acceptable and which matches should be excluded. Keep product eligibility separate from commercial preferences such as margin or a promotion.

Choose the Investigation from the Observed Failure

The expected product is absent for every query

Check whether the product is published to the relevant storefront and included in the search catalogue. Ask the developer to confirm searchable fields, exclusion rules and the latest successful data update. A visible product page establishes that the page exists; it does not establish inclusion in a separate search index.

Use this route when the exact product name and identifier both fail with filters cleared. Do not begin with a ranking boost. If the record is missing, correct coverage and retest retrieval before judging its position.

The exact name works but the customer’s wording fails

Investigate a vocabulary mismatch. Compare the entered phrase with searchable names, attributes and any approved aliases. A synonym is appropriate only where the terms genuinely describe the same relevant concept in your catalogue.

A directional expansion can be preferable when a broad everyday term should retrieve several specific products but those specific names should not all retrieve the broad set. Check what your search implementation supports. Do not assume every synonym feature behaves in both directions or supports directional rules.

Pause a synonym change if the proposed terms also describe materially different products. Test the conflicting meaning first. A lower zero-result count is not an improvement when the new results misrepresent suitability.

The product appears only after a filter is cleared

Compare the active filter with the product’s stored attribute and current eligibility. A product excluded by an accurately selected size is behaving correctly. A matching product excluded because its size is missing or recorded inconsistently points towards a data or filter-mapping problem.

Inspect whether filters remain active when a new search begins. Record that behaviour before deciding whether the interface should retain or clear them. Either approach needs to make the current restrictions understandable to the shopper.

The right product is present but hard to reach

Review the results above it. Are they valid alternatives, loosely related accessories or promoted items that fail the request? Investigate matching weights and merchandising rules only after confirming the relevant record is present.

Prefer a narrowly scoped correction supported by repeatable evidence. A global boost can move the same product upwards for unrelated queries. Where intent remains unclear, improve the choice presented or the clarification offered instead of forcing a single winner.

Build a Judged Search Set You Can Repeat

1. Gather language from several sources

Use approved search reports, anonymised enquiry themes, product identifiers and observations of customers attempting realistic tasks. Separate observed customer terms from staff suggestions and deliberately invented test queries. All can be useful, but they represent different evidence.

Include common requests and a smaller group of difficult cases: similar product codes, spelling errors, size qualifiers, pack quantities and terms that could mean two different things. Add a negative control for an item the shop genuinely does not sell. The aim is to distinguish useful retrieval from indiscriminate matching.

When observing customers, give them a believable goal without supplying the exact search phrase you hope they will type. The GOV.UK guidance on moderated usability testing explains task design and neutral instructions. Staff tests provide reproducible checks; customer sessions help reveal language and misunderstandings those checks may miss.

2. Write the expected result before running the search

For each query, record its class, the intended task, the expected product or acceptable set, and the reason those products qualify. Include any prohibited result, such as a different size or an accessory presented as the main item.

Have a person who understands the catalogue review ambiguous cases. If reviewers disagree, record the judgement as unresolved. Do not count an unresolved expectation as a search failure merely because the tester prefers a different product.

3. Record the conditions and observations

Keep one row per query and test condition. A useful record contains:

• Query: the exact entered text and whether it came from a customer, staff member or synthetic test.
• Expected match: product or variant identifier, acceptable alternatives and the reason for inclusion.
• Context: storefront, device, account state, selected filters, sort order and test time.
• Observed result: zero-result state, relevant result position, incorrect leading matches and the destination opened.
• Decision: pass, fail or unresolved, supported by a screenshot or concise observation.
• Follow-up: suspected cause, owner, proposed correction and retest outcome.

For predictable ordering, count positions consistently. Decide whether promoted cards and grouped variants count as result slots and retain that definition. Capture both the suggestion panel and submitted results where both are part of the journey.

4. Change one relevant factor and compare

Save the baseline before applying a correction in an appropriate test environment. Rerun the failing query, its related queries and the negative controls. Hold stock assumptions, filters and sorting constant where possible. Record unavoidable changes so that the comparison is not presented as controlled when it is not.

Use a simple judgement scale: 2 for a result that satisfies the stated task, 1 for a useful but qualified alternative and 0 for an unsuitable result. These are proposed working labels, not an industry standard. Record the reason alongside the score; a number alone cannot explain a compatibility or pack-size concern.

Worked Example: One Product, Several Search Outcomes

The following is a fictional training example, not a customer case or a test performed by KAP SEO Services. Assume the catalogue contains an eligible, available 150 mm sanding disc, P120 grit, pack of 10, with the invented identifier DISC150-P120-10. For this exercise, “orbital sanding discs” is an approved description of the relevant product family. No real product compatibility is asserted.

The exact-code pass shows that the product can be retrieved in the tested context. It does not prove that every product record is complete. The customer phrase and misspelling fail independently, so they should not automatically receive the same fix.

For the attribute-led query, inspect why smaller discs lead before changing weights. The fictional observation supports a relevance concern, but it does not reveal whether the cause is field configuration, query interpretation or a promotion. That cause remains unresolved until the configuration and result evidence are checked.

The filtered exact-code search is the counterexample: zero results are correct because the selected size contradicts the requested item. Removing the size restriction from search altogether would repair the metric while damaging the shopper’s control.

A useful decision record would say: retain the exact-code behaviour; investigate the approved vocabulary phrase; test spelling separately; examine the size mismatch; and keep valid filter exclusion. Acceptance requires passing those cases without introducing incorrect sizes into the related control queries.

Avoid Metrics and Fixes That Hide the Problem

Do not equate any result with success. Define zero-result rate as searches returning no products divided by all included searches, using a consistent reporting population. Also record cases with products returned but no acceptable match. A search that produces twenty irrelevant items is not a successful discovery.

Keep diagnostic scores separate from customer outcomes. A pass rate on your fixed test set measures that set, not every customer journey. Report query classes separately so numerous easy code searches do not conceal poor vocabulary matching.

Check the measurement implementation. GA4 enhanced measurement can generate view_search_results from recognised URL query parameters and collect search_term. That event does not, by itself, prove that an acceptable product was returned, clicked or bought. Search interfaces without the expected URL behaviour need their tracking checked rather than assumed complete.

Avoid title stuffing to compensate for search configuration. A product name should identify the product clearly. Where the platform supports suitable search fields or controlled aliases, assess those before adding every spelling and synonym to public-facing copy. Product information should remain readable and accurate.

Do not silently replace an unavailable exact match. For a specific code, preserve the identity of the requested item and distinguish alternatives. For a broad request, available suitable options may reasonably take priority. Availability cannot make an otherwise unsuitable product relevant.

Keep Relevance Stable as the Catalogue Changes

Retain a small fixed regression set and add new cases when customer language, catalogue structure or search behaviour changes. Review the set after imports, stock-rule changes, search updates and merchandising interventions. Remove obsolete expectations deliberately, with a reason, rather than quietly editing failed cases into passes.

Assign ownership across catalogue data, search configuration and result presentation. A correction is complete only when its observed outcome has been retested. Keep the previous rule available for reversal until the business accepts the change.

After release, monitor the agreed search measures alongside customer feedback. If broader sales or conversion figures change, consider traffic mix, availability, promotions and measurement coverage before attributing the difference to search. A before-and-after movement alone does not isolate the cause.

How to Get This Done

Brief the work with the failing queries, expected items, observed positions and exact conditions. Include representative passing queries so the developer knows which behaviour to preserve. Ask for the proposed cause, the smallest justified correction, the affected query classes and a rollback plan.

Professional help is sensible where several data sources feed search, variants behave inconsistently or the team cannot distinguish catalogue omissions from ranking rules. An e-commerce journey and SEO review can put the search issue into the context of product information and the wider store. Agree the search-specific investigation and acceptance criteria before commissioning changes.

Keep the handover practical: one judged query set, one issue record per distinct cause, and evidence of the retest. The aim is a correction the business can explain and maintain.