I Read 155,000 WooCommerce Searches So You Don't Have To

Between 31 March and 20 July 2026, the search API I run logged 155,730 queries that contained actual text. I can see every one of them, across every store connected to it.

Here is the first thing I found, and it changed how I read everything after it:

Under 3% of those queries came from a real store.

The other 97% matters, because if you look at your own search data without stripping it out first, you will reach confident conclusions that are wrong. I know, because I did.

Your ?s= endpoint is public. It is crawlable, it accepts any string, and bots hit it whether or not you even show a search box. One site I looked at had no visible search field at all and was still collecting queries.

What arrives there:

Bare numbers. A steady volume of searches that are nothing but a number, most often a year. Every one returns zero. This puzzled me for weeks. The mundane explanation: spam networks stand up throwaway pages and use a site's own search to check whether those pages still resolve.

Volume that dwarfs everything real. A single source sent roughly 65,000 queries in the period. That is about fourteen times the entire genuine shopper traffic across every connected store combined.

Exploit probes. Injection strings and framework attack paths, arriving through the search box because it is the easiest unauthenticated text field on a WordPress site.

Filler. test. sdf. A short phrase in a language with no audience on the site and no content to match.

There is a practical cost here that has nothing to do with security. A store owner on a plan with a monthly search allowance decided the product was too limited and left. When I went through his log, a large share of his allowance had been spent by traffic that was never going to buy anything. He was right that he ran out. He was wrong about who used it.

If your search analytics do not separate bots from buyers, they are not analytics. They are a blend, and the blend lies.

Every AI search demo shows a sentence. Mine did too:

something for oily skin that isn't greasy
a gift for my mum who likes candles

Those are real queries. I have them in the log. But when I looked at when they arrive, the pattern was uncomfortable: sentences cluster in the first day or two after a store connects, in a burst, from one location. That is the shop owner, testing.

What shows up weeks later, steadily, from real visitors looks like this:

drifter salts
xros 5
epson emc800

Names. Model numbers. Part codes. Often misspelled.

Both populations are real. They are not the same population and they do not want the same thing. Names need tolerance for bad spelling and the ability to read a brand and a model out of a fragment. One shopper typed an Epson code next to the word "cartlidge" and still landed on the right cartridge. Sentences need genuine intent understanding, and they are a growing tail, not the bulk.

Most stores get far more of the first than any vendor demo admits, mine included. If you are choosing a search tool, test it on the ugly half of your own log, not on the tidy sentence in the brochure.

I went through one store's zero-result list in detail. The headline number was 48.9% of searches returning nothing, and half of a store's searches finding nothing looks like a five-alarm fire.

It was not a fire. After stripping the bot traffic from the section above, the rate was 15.3%. After the store finished importing its catalogue, it was under 7%. Three different numbers for the same store, and only the last one was about customers. That store synced in stages over several days, and most of the genuine empty results landed before the final import completed.

That last point is also the most embarrassing mistake I made in this whole exercise, and it is worth saying out loud. I looked at one query that came back empty on eight separate tries and concluded the store simply did not sell that thing. It did. I had not synced it yet. I was one step from writing that down as a customer insight when it was a gap in my own pipeline.

Once you have a clean zero-result list, the genuine part breaks into three groups:

Things the store really does not sell. Useful, and cheap to act on: stock it, or stop paying for the traffic.

Things the store does sell, under a different name. This is the biggest and most commonly missed group. A retailer of TV wall mounts had shoppers searching for a mounting style using a word that appeared in none of the product titles. The products existed. The vocabulary did not match. Better search bridges that gap, and so does rewriting three product titles, and rewriting the titles also helps you in Google, which semantic search does not.

Questions, not products. Requests for information the site had never published. A content site I looked at had visitors asking, several different ways, how to get out of debt. Every one of those is a page somebody wanted and nobody had written.

That third group is why I now read a zero-result list as an editorial plan, not a bug report.

A sample of things people actually typed, from stores in several languages:

• The same person asking one thing four ways in a single session: spelled out, then as a digit, then with a space, then without.
• Hebrew typed into a Hebrew catalogue.
• para reglar a mama. Spanish, a missing accent and a wrong letter, meaning "something for mum". It resolved to the right products, which is the only reason I noticed it.
• Polish typed into an English catalogue, by a visitor who never saw a Polish word on the site.

Two things I did not expect to be so consistent. Your customers do not spell your product names correctly. And a real share of them are not searching in the language your catalogue is written in, even when nothing on the page invites them to.

None of this needs you to buy anything. It needs the data and one afternoon.

1. Get the log. WooCommerce does not record searches by default. Your server access log already has every ?s= hit. Several search plugins record them too.
2. Filter before you conclude. Drop requests with no referrer, no session, and no following page view. Drop identical strings arriving faster than a person can type. Drop anything that is only a number. Do this first, or your top-ten list is a bot's top-ten list.
3. Cut yourself out. Compare query dates against the day you set the site up. Your own testing is the single largest contaminant in a young store's log, and it is the one that looks most like a promising insight.
4. Sort by frequency, never by novelty. The interesting query is not the strange one. It is the boring one that forty people typed.
5. Read the zero-result list last, and read it as a to-do list. Stock, rename, or write. Most entries resolve to one of those three verbs.

I built a semantic search engine and then spent months marketing it with sentences, because sentences demo beautifully. The log says most of my customers' real traffic is names and codes, typed badly. Both things are true, and I had been talking about the smaller half.

I still think the sentence half is where this goes. The queries arriving from people who learned to search by talking to a chatbot get longer and more specific every month. But if you run a store today, the ugly half is the half you already have, and any tool you evaluate should be tested against it.

If you want to see what your own visitors are typing, you do not need me for that. You need a log and an afternoon. I keep search history in the dashboard because the engine needs it anyway, so if you happen to run Queryra it is already there. If you do not, your server has it too.

The data is the point, not the tool.