Ecommerce site search is the search bar on your own store: the shopper types a query, the search engine matches it against your product data and returns a ranked list of products. When it works, shoppers who know what they want reach a product page in one step. When it fails, they see the wrong products or a "no results" page, and many leave.
Most stores fail somewhere. In Baymard Institute's search benchmark, 56% of sites did not adequately support users' search needs. The usual fixes are on the engine side (typo tolerance, synonyms, autocomplete), but many failures come from the data the engine searches: attributes that sit in free text, product types missing from titles, model numbers stored nowhere searchable. This guide covers both, plus the internal site search metrics that show you where to start.
Index, match, rank: what every site search engine does
Every site search engine, from a platform's built-in search to a dedicated search app, does three things:
- Index: it copies selected product fields into a search index. Fields that are not indexed cannot be found, however good they are.
- Match: it compares the query with the indexed text, with or without typo tolerance, synonyms, stemming ("drill" and "drills") and semantic matching.
- Rank: it orders the matches by relevance, popularity, stock or merchandising rules.
The first step is where product data decides the outcome. Shopify's built-in storefront search is a useful example because its rules are documented. According to Shopify's help center, it searches the product title, body (description), product type, tags, vendor, variant title, variant SKU and variant barcode. Typo tolerance only applies to title, product type, variant title and vendor, and the first four letters of a word must be correct. A misspelled query will not match a word that only appears in a tag or the description.
That has practical consequences. If "cordless" exists only as a tag and a shopper types "cordles", Shopify's search will not match it. If the product type field is empty, you lose a typo-tolerant field that would have matched "drill". Other platforms and search apps index different fields, so check your own engine's documentation before you decide where a value needs to live.
The eight query types shoppers use, and the data each one needs
Baymard groups search queries into eight types and tests every site against each. For seven of them, the share in brackets is the share of benchmarked sites with issues for that type, from the same Baymard article. For each type, we added the product data that has to exist before any engine can answer it.
Eight search query types and the product data each one needs
| Exact | "Bosch GSR 18V-55" | Not reported | The model number or MPN in an indexed field, not only in an image or PDF |
|---|---|---|---|
| Product type | "cordless drill", "sandals" | 20% | The product type in the title or product type field, in the words shoppers use, not your internal category code |
| Feature | "red linen dress", "18V drill under 100" | 39% | Color, material, voltage and price as structured attributes that search and filters can read |
| Use case | "wedding gift", "drill for concrete" | 43% | Use-case attributes or descriptive copy that names the use ("suitable for masonry and concrete") |
| Abbreviation and symbol | "13in laptop sleeve", "tv" | 54% | Synonyms and normalized units, so "13 inch", "13in" and "13-inch" resolve to the same value |
| Compatibility | "case for Sony RX100" | 44% | A "compatible with" attribute listing models, not a sentence buried in the description |
| Symptom | "stained rug", "dry skin" | 37% | Copy that names the problem the product solves, and synonyms that map symptoms to product types |
| Non-product | "return policy", "track my order" | 66% | Indexed content pages or redirects for common service queries |
Leave out non-product queries and the types with the most issues are abbreviations, compatibility, use case and feature queries. Those are also the types that depend most on structured product data. A synonym list cannot help if the size is only written as "33 cm" in the third paragraph of the description.
Why "13 inch laptop sleeve" returns nothing
Take a store selling a laptop sleeve with this data:
- Title: NeoShell Sleeve Charcoal
- Product type: empty
- Tags: new-in, summer-sale
- Description: "Protective neoprene cover with a soft lining. Fits devices up to 33 cm."
- Variants: Charcoal / Navy
A shopper types "13 inch laptop sleeve". Nothing in the indexed fields contains "13", "inch" or "laptop". "Sleeve" matches, but if the engine requires all terms to match, the result is zero products. If it does not, the sleeve appears somewhere between phone cases and a sleeveless dress.
The fix is in the data, in this order:
- Title: "NeoShell Laptop Sleeve 13 inch, Neoprene, Charcoal". Product type and size are now in the most heavily matched field. Our title optimization guide covers the full pattern.
- Product type: "Laptop sleeve".
- Attributes: screen size 13 inch, material neoprene, color charcoal. These also power the filters on the results page.
- Compatibility: "Fits MacBook Air 13, MacBook Pro 13, Dell XPS 13", in a dedicated field the engine indexes.
- Synonyms: "13in" and "13 inch", "laptop" and "notebook", "sleeve" and "case" (one-way, so a search for "case" also shows sleeves).
Multiply that by every product in the category and you see why site search projects are often catalog projects. Consistent attribute values matter as much as filled ones: if half your sleeves say "13 inch" and half say "13in", both search and filters split them. The attribute standardization guide shows how to normalize values like these.
Ecommerce site search best practices for the interface
With the data in place, these interface practices make the most difference:
- Visible search field. On stores with a large catalog, show an open search field on desktop and a clear search icon or field on mobile, not one hidden in a menu.
- Autocomplete with product types and categories. Suggest "laptop sleeves" and "laptop bags" as the shopper types, not only individual products. It steers queries toward terms your catalog can answer.
- Typo tolerance and stemming. Check which fields your engine applies them to, as the Shopify example shows.
- Filters on the results page. A search for "drill" returning 140 products needs filters for voltage, battery included and brand. Filters only work when the attributes are filled and consistent; see our post on product filter UX.
- Sensible ranking. Push sold-out products down, and use merchandising boosts sparingly. Boosting many products for one term buries the relevant ones.
- Answers for non-product queries. Map "returns", "shipping costs" and "opening hours" to the right page.
Design the no-results page as a recovery page
Some queries will always return nothing. According to Baymard's no-results research, nearly 50% of sites fail to give users an effective way to recover from a search without results. Baymard recommends showing related categories, suggesting alternative queries with a preview of their top products, showing popular or recommended products and offering contact options such as live chat. A "check your spelling" message alone is not enough.
Internal site search analytics: the metrics to track
Your search log is the most direct record of demand you have: shoppers telling you, in their own words, what they want. Track these metrics monthly:
Six internal site search metrics with their formulas
| Search usage rate | Sessions with a search / all sessions | Tells you how much of your traffic depends on search. |
|---|---|---|
| Zero-result rate | Searches with no results / all searches | The first number to bring down. |
| Search exit rate | Searches after which the shopper leaves the site / all searches | How often a search ends the visit. |
| Search click-through rate | Searches followed by a click on a result / all searches | Low CTR with results means the results look irrelevant. |
| Refinement rate | Searches followed by a new or changed query | High refinement on one term means the first results missed. |
| Search conversion rate | Sessions with a search that end in an order / sessions with a search | Compare it with the conversion rate of sessions without search. |
The view_search_results event and its search_term parameter
Google Analytics 4 records site searches through enhanced measurement. Per Google's documentation, it fires a view_search_results event when a page loads with a search query parameter in the URL, and stores the query in the search_term parameter. By default it recognizes the parameters q, s, search, query and keyword; you can add others in the enhanced measurement settings. Shopify uses q and WordPress uses s, so both are covered out of the box.
Enhanced measurement only reads the query from the URL. It does not know how many results the page showed, so it cannot tell a zero-result search from a successful one on its own. To report zero-result queries, have your search results page send the result count with the event, for example as a custom parameter, or use the reporting of your search app.
A monthly pass through the search log
Monthly search log review in five steps
The review also exposes the habits that keep search results poor:
- Buying a new search engine for a data problem. A smarter engine still cannot match a voltage that lives in a PDF.
- Synonym lists as a dumping ground. Hundreds of synonyms that patch inconsistent attribute values are hard to maintain. Normalize the values instead.
- Internal jargon in titles. A supplier code such as "CDT-18-PRO" instead of "cordless drill", the words shoppers type.
- Tags as the only place for important terms. On engines without typo tolerance on tags, a single typo hides the product.
- Ignoring the search log. Zero-result queries for products you do not stock are free product research.
- Measuring only search conversion. Without zero-result and exit rates you see that search sells, but not where it fails.
Filling the product fields your search depends on
WISEPIM is not a site search engine, and it does not collect your store's search log; your store, search app or GA4 keeps that data. It works on the input search depends on most: the product data. AI enrichment fills missing attributes, product types and descriptions across the catalog, and Quality Guard flags products where a field your search needs, such as product type or a key attribute, is empty. With the Google Search Console connection, WISEPIM analytics also shows the queries people type on Google to find your products, a second source for the words shoppers actually use.
If you are starting from scratch, take your top 20 zero-result queries this month, check the products that should have matched, and fill the fields they are missing. The data completeness guide helps you decide which fields to require per category.
