Site search: the demand data hiding in your search box

One fork first. "Site search" is also typed by people wanting Google's site: operator — the site:yourdomain.com trick for seeing what Google has indexed. Different tool, covered in our ecommerce SEO guide. This page is about the box on your site, and it belongs with our conversion rate optimisation guide: search is the one conversion surface that reports on itself daily.

Why the search box is a commercial asset, not a feature

A browser is still deciding. A searcher has decided and is checking whether you have it. That is the mechanism, and it has three consequences.

• Intent arrives formed. Someone typing "silk saree blue" has a product in mind and a fixed amount of patience.
• You answer in one step. No second chance to merchandise. The result set either contains the thing or it does not.
• Failure is visible. A browser who gives up leaves no note. A searcher who gives up leaves the exact words they used.

You will see a claim that searchers convert several times better than browsers. Treat the multiple as unknown — it depends on what share of visitors search, how good your results are, and whether you sell one SKU or forty thousand. Measure your own: compare sessions containing a search event against sessions without one.

The sharpest signal is not the conversion rate anyway. It is the zero-results query: a customer standing in your shop, naming what they want, being told nothing exists. No cleaner statement of unmet demand exists in your analytics.

Three fates, one log.

Six failures, and who fixes each

Almost every broken search box fails one of six ways. Hand this table to a developer.

That last row is where search meets category page SEO, and it is the one most often built the obvious wrong way: filterable results are good for shoppers and terrible for crawl budget if the URLs are left open.

The India problem: one product, nine spellings

Platforms built for other markets handle this worst: their default language settings assume one script and one spelling. One shopper, one saree, nine ways to ask:

paithani saree      paithani sari       paithani sadi
pathani saree       paitani saree       पैठणी साडी
silk saree blue     blue silk sari      neeli silk saree

If your index only knows the string in your product title, eight of those nine shoppers see "no results found". Three things to brief:

1. Accept Devanagari and other Indian scripts. Not translation — just do not break when the characters are not Latin. Many boxes silently return nothing.
2. Treat transliterated queries as synonyms, not typos. "Sadi" is not a misspelling of "saree" but another romanisation of the same spoken word, and fuzzy matching misses it.
3. Add the Hinglish phrasing beside the English. People search "kurta set for ladies" and "ladies kurta combo" for one thing.

Build the list from your own zero-result log, not imagination. Your customers already wrote it.

Reading your search log: the three lists that matter

Most teams read the top ten terms once, find them unsurprising and never return. The value is in the two lists they skip.

List one — top queries. This is your real navigation, as opposed to the one your designer drew. If a term in the top twenty has no landing page, that is a page to build — pre-validated demand your keyword research may have missed. If a top-five term is already well served, promote it into the menu so people stop having to search for it.

List two — zero-result queries. Deduplicate, sort by volume, read down. Three patterns: products you do not sell (a range decision), products you sell under another name (a synonym fix), and words that are not products — "return policy", "track order", "COD" — meaning people use product search to find help pages. A navigation problem in a search costume.

List three — searched, then exited. The expensive one. Results appeared and the person left anyway. Indexing is not the problem; persuasion is. Look at the first four result cards for those queries — price, image, stock status, review count — because that is all the visitor saw. Straight ecommerce CRO work, not engineering.

Keep a fourth: searched, then converted. Those words belong in your ad copy and your ecommerce marketing calendar — customers have told you they close.

Setting up site search in GA4, honestly

GA4 can measure this, but the default setup catches fewer sites than people assume. What Google's documentation says, checked on 16 October 2026:

Site search is one of GA4's enhanced measurement events. It sends view_search_results "each time a user is presented with a search results page, as indicated by the presence of a URL query parameter", and search_term "populates the Search term dimension" (Google Analytics Help, Enhanced measurement events).

The trap is inside that definition. GA4 looks for five default parameters — q, s, search, query and keyword — and Google notes you "can optionally configure this event to look for other URL query parameters". Use none of the five and nothing fires, while everything looks fine.

/search?q=paithani+saree      q is a default parameter  -> event fires
/search?term=paithani+saree   term is not in the five   -> nothing fires
/search/paithani-saree/       no query parameter at all -> nothing fires

So the developer brief is four lines.

1. Tell me the exact search URL format, parameter name included.
2. If it is not one of the five, add it under Site search advanced settings, or send view_search_results manually with search_term.
3. If search never changes the URL — a modal, or a single-page app — the automatic event cannot see it and must be sent manually.
4. Pass the query lowercased and trimmed, or "saree " and "saree" split into two rows.

Then verify. Search a nonsense string on the live site, open GA4 Realtime, confirm the event and the term appear. Our GA4 setup walkthrough covers the wider configuration.

Two honest limits. GA4 gives you the event and the Search term dimension, not a ready-made site-search report like Universal Analytics had — you add Search term to a report or exploration yourself. And zero results are not a GA4 concept: read them from your search platform's dashboard, or fire a separate event when the result count is zero. Without that, the most valuable list on this page does not exist for you.

Should internal search result pages be indexed? No, and here is why

Plainly: internal search result pages should generally stay out of Google's index, and their URLs should generally not be crawlable. Three reasons, costliest first.

• An unlimited URL space. Every query a person or bot types creates another URL, so crawlers can spend forever inside it. Google's crawl guidance is to "block these unimportant pages using robots.txt" (Optimize your crawl budget, last updated 22 July 2026).
• They duplicate pages you want ranking. A search for "cotton kurta" returns roughly what your cotton kurta category page returns. Google's canonicalisation doc gives the reason to consolidate: "to avoid spending crawling time on duplicate pages" (How to specify a canonical URL, last updated 10 July 2026). Our duplicate content explainer covers the pattern.
• They are poor landing pages. A list assembled on the fly has no considered copy and nothing to trust.

The closest direct guidance Google publishes is its faceted navigation page — same shape of problem, parameter-driven URLs that multiply. It says to "use robots.txt to disallow crawling of faceted navigation URLs" when "you don't need the faceted navigation URLs potentially indexed" (Managing faceted navigation, last updated 18 December 2025). For accuracy: that page names filter URLs, not search URLs. We apply it by analogy; the mechanism is identical.

The no-index rule in practice: disallow the search path in robots.txt (Disallow: /search), keep links to results out of crawlable navigation, and do not pair that with a noindex tag — a blocked URL is never fetched, so the tag is never read. Pick one mechanism. Spend the crawl attention on category pages, which is what internal linking is for.

On Shopify, /search is partly platform-controlled, so check what your theme emits first — our Shopify SEO notes cover the quirks.

What we look for first in a client's search log (DH's own view)

Our own process, in the order we run it. We are an agency, so treat it as a working method rather than a law.

1. Does the event fire at all? We search a nonsense string on the live site and watch GA4 Realtime. This step most often stops the conversation — no data means the first deliverable is tracking, not strategy.
2. The zero-result list, before any keyword tool. Smaller, first-party, about products you actually sell.
3. Do the top twenty terms have pages? We put them beside the sitemap and look for gaps. A term searched hundreds of times a month with no page behind it is the easiest content brief anyone will write.
4. Is /search in the index? We check with Google's site: operator. If result URLs are showing, crawl waste is already happening and gets fixed first.

What a working search box earns you

None of this is a campaign. It is one engineering job plus a monthly habit: read the three lists, update the synonym file, brief one page.

What compounds is the information. Every month your customers rewrite your keyword list, name the products you should stock and point at the categories your navigation hides — in their own words, for free. Most sites throw that away. Reading it is the cheapest advantage available, and the same work as any other conversion rate improvement on your plan.