Shopify site search optimization: what to change and how to measure it

How does Shopify storefront search work?

Storefront search is driven by query parameters on the /search URL. Shopify's storefront search documentation lists them: q for the query, type to restrict results to product, page or article, options[unavailable_products] to show, hide or push unavailable items to the end, options[prefix] to control partial word matching, and sort_by for relevance or price order. Only q needs input from the shopper. The rest are normally hidden inputs in the search form, which means the defaults your theme ships with are choices someone made once and nobody revisited.

Three of those defaults decide what a shopper sees:

• Result types. If type is not set, the search returns products, pages and articles. A store whose blog posts outrank the product a shopper typed is usually showing all three.
• Unavailable products. The documented default is last: sold-out products and variants appear after everything else. hide removes them, show leaves them in their found order. Which is right depends on whether a sold-out product is information (it will return) or noise (it is discontinued).
• Partial words. For product results the engine matches partial words automatically. For pages and articles it matches partial words on the last term only, by default. A search for "winter snow" can find a page containing "snowshoe", but a half-typed word at the start of the query will not.

You can see all of this in your own store in a minute. Search for a term, then read the address bar: the parameters your form sends are in the URL, and type=product added by hand shows how different the page looks when only products are returned.

What does predictive search change?

Predictive search is the dropdown that appears while the shopper types. According to Shopify's predictive search documentation, it can suggest products, collections, queries, pages and articles, and it matches either exactly or with typo tolerance. Before it looks for products it may replace what was typed with the best-matching query suggestion, such as completing snowbo to "snowboard". The page says plainly that, because of this, product suggestions can differ from the search results page for the same text.

That sentence explains a common complaint. A shopper types a word, sees the right product in the dropdown, presses Enter, and lands on a results page that ranks it differently. Neither is broken. They are two requests that can disagree, so test both with the same ten queries and write down where they diverge.

Two other facts from the same documentation affect how you set the store up:

• Variants are returned only when the query matches terms specific to the variant title. If a snowboard has a blue and a light blue variant, snowbo returns the product and light blue snowbo returns the light blue variant. Variant titles are therefore search copy, so "Default Title" is a wasted opportunity on a store with real options.
• To keep a product out of predictive search, set its status to Unlisted or hide it from search engines and sitemaps with the seo.hidden metafield. The API returns no more than 10 suggestions per request type.

Which search settings can a merchant change without code?

Shopify's theme documentation points to the Shopify Search & Discovery app as the way to customise product recommendations and search results, and says the defaults for type and unavailable_products can be changed in its search settings. We read that as the place to start before anyone touches theme code: it is the sanctioned route, and changes there carry through to storefront search.

We are deliberately not listing every control the app offers. The features move, and the documentation we rely on describes only what is above. Open the app in your admin and look at what it lets you change on your plan, then choose by the evidence in the next section rather than by the feature list.

How do you find what your search is failing at?

Search is the one place on a store where shoppers tell you, in their own words, what they could not find. Read it before changing anything.

1. Collect the terms. Use the search report in your analytics or in the Search & Discovery app if your plan shows one, or the search terms in your analytics tool if you track them. If you have none of these, ask your developer to send the q value as an analytics event; it is a short change.
2. Sort out the zero-result terms. For each one, ask which of four things is true: the product exists under another name (a synonym problem), the product is spelled differently (a typo, which predictive search should tolerate), the product is a variant attribute the title does not carry, or you simply do not sell it.
3. Handle each kind differently. A name mismatch is fixed by putting the shopper's word into the product title, tags or description, because those are the fields search reads. A missing product is a merchandising signal and not a search bug. A term that is really a navigation request ("returns", "shipping") deserves a page that search can return, which is why the type setting matters.
4. Check the common terms by hand. Take the ten most frequent searches, run each in the dropdown and on the results page, and record whether the first three results are what the shopper wanted. If they are not, that is where to spend the first hour.

How long the zero-result list is depends on your catalogue, and we have no figure to quote, so read your own data.

How should you measure whether a change helped?

Define the measure before the change, and keep it narrow. The question is whether people who search go on to buy, so compare the add-to-cart rate of sessions that used search with the rest of your traffic, before and after. Define "used search" in your analytics tool, because the definition is yours, and write it down.

Two cautions we apply:

• Searchers are not typical visitors. They arrive with intent, so their add-to-cart rate will run higher than the average session. That is expected. Compare searchers with searchers across time, never with the whole store.
• Change one thing at a time. Switching unavailable_products to hide and rewriting forty product titles in the same week leaves you unable to say which one moved anything. This is the same discipline as in our CRO roadmap: one change, one measure, a fixed window.

We do not quote a typical lift from search work. We have not read a source we would put our name to, and a made-up percentage is worse than none.

What if the store is headless?

On a custom storefront the same engine is reached through the Storefront API. Shopify's search query returns paginated products, pages and articles, sorted by relevance by default, and a search returns up to 1,000 results. When products are included it returns up to 2 pages or articles on the first page of results only; to get more, run a separate search with types: [PAGE, ARTICLE]. Product results match partial words automatically, and for pages and articles the prefix argument decides whether the last term matches partially. The predictiveSearch query offers limit from 1 to 10 and a limitScope that decides whether the limit applies across all result types or per type.

The practical point for a headless build is that your own interface decides what is shown. If you cap suggestions across all types, a single strong product match can crowd out the collections and pages that would have answered the query.

What should you fix first, and how long does it take?

1. Search your own store for ten terms a customer would use, in the dropdown and on the results page, and note where they disagree or fail (thirty minutes).
2. Read the zero-result terms and sort them into synonym, spelling, variant and not-sold groups (an hour).
3. Put the shoppers' words into titles, tags and variant titles for the first group, and replace "Default Title" where real options exist (an afternoon for a focused list).
4. Decide the unavailable_products setting and the type default deliberately, in the Search & Discovery app or the form (fifteen minutes).
5. Measure searchers against searchers for a fixed window, with one change at a time.

Search is one section of a wider review; the audit checklist shows where it sits. If you would like it checked against your real search terms alongside speed and the buy path, that is part of a Store Teardown, and the services page explains how we work on the fixes.