Written, 4 June 2026

What people type into your search box

There is a list on your own site of things people wanted and could not find, written in their words, timestamped, attached to the page they were on when they gave up. Nobody exported it. It costs nothing, it needs no tooling you do not already have, and it is more directly useful than most of the research people pay for.

A search is somebody telling you the navigation failed

Nobody uses a site search box first. They use it after scanning the header, after guessing which section a thing belongs in, and after not finding it. By the time somebody types into that box they have already tried the route you designed, and the query is a record of the moment they abandoned it.

That makes it a fundamentally different signal from anything gathered before a visit. It is post arrival intent: this person has already chosen you, is already on your site, and still cannot find the thing. There is no acquisition question mixed in, no question of whether they are the right audience. They are, demonstrably, and they are stuck.

It is also unmediated by your own vocabulary in a way almost nothing else is. A menu offers words and a visitor picks one. A search box offers nothing, so what comes out is what was in their head, which is the wording you need if you want your material to match how people actually ask.

What it tells you that a keyword tool cannot

Search volume research describes a market. It tells you what strangers type when they do not yet know who you are, aggregated across everybody selling something similar, and weighted towards the phrasings that are common in general rather than the ones common among your customers.

Your own search log describes your customers. It contains your product names, your regional spellings, the abbreviation your industry uses that no outsider would type, and the specific confusions your specific site creates. None of that is in a general dataset, because none of it has enough volume anywhere to appear in one.

The two are answering different questions and the confusion between them is expensive. Market research tells you what to write about to be found. Your search log tells you what to fix for the people who already found you. If you only have time for one, and you are trying to reduce the number of people who end up writing to you, the second one is the one that pays.

The zero result rows are the top of the list

Sort by the searches that returned nothing and read them all. This is a short list on most sites and it is the most concentrated collection of unmet intent you will find anywhere in your own data. Every row is somebody who wanted a specific thing, said so in their own words, and was told there was nothing.

They fall into recognisable kinds and each kind implies a different action. Things you genuinely do not offer, which need a clear no somewhere findable rather than silence. Things you do offer under a different name, which is a vocabulary problem and the cheapest fix on the list. Things that exist on the site but are not reachable by the search, usually because they are in a file, behind a tab, or on a page the search does not cover. And misspellings and product codes, which mostly need the search itself to be more forgiving rather than any content work.

There is a fifth kind worth separating out, which is queries that are whole questions rather than keywords. Somebody typing a full sentence into a search box is a person who has stopped expecting the site to have a page and started hoping something will understand them. Those rows are the closest thing you have to a free list of what people would ask an assistant, before you have one.

The phrasing matters more than the topic

The usual way this exercise gets ruined is by summarising. Somebody exports the log, groups it into themes, and produces a list of topics. The topics are almost always things you knew, and the summary threw away the only part that was new, which was the exact words.

Keep the verbatim strings. The value is in the difference between what they typed and what your pages say: they search for the returns window, your page is headed Terms of Sale. They search for a word your industry stopped using a decade ago and your marketing replaced. They use the plural, the brand name, the shorter form, the regional term. Each of those is a one line edit to a heading that makes an existing page findable, and none of them are visible once the log has been tidied into themes.

This is also why the log outperforms asking people. If you ask a customer what they would search for, they will construct a sensible phrase. What they actually type when frustrated is shorter, blunter, less grammatical, and much more useful, and it is only recoverable from the log.

Where they were standing when they typed it

If your log records the page a search was run from, that column is worth as much as the query. The same words mean different things from different places, and the action they imply is different.

A query about delivery from a product page is somebody deciding whether to buy. The same query from an order confirmation page is somebody who has already bought and wants to know where their thing is. Answering both with the same page satisfies neither of them well, and the log is what tells you both populations exist and are asking in identical words.

The page context also localises the fix. A run of searches from one page for something that page should obviously have contained is not a content gap at all, it is a page that is missing a section or burying it. That is a fifteen minute fix and you would never have found it from a list of queries with no context attached.

The traps in the log

Internal traffic contaminates it. Your own staff use the site search constantly, and they search for things customers never would, in vocabulary customers do not have. If you cannot separate them, at least learn to recognise them, because they are usually the queries that are suspiciously precise.

Repetition is not always popularity. One frustrated visitor rewording the same query six times in four minutes appears in a naive count as six people who want that thing. It is one person, and it is a more interesting signal than six would be, because the sequence of rewordings shows you exactly how somebody gropes towards your vocabulary. Read runs as runs rather than counting rows.

And be careful with the seasonal and the campaign driven. A spike in queries for a thing you mentioned in an email last Tuesday is a fact about the email, not about ongoing demand. The queries worth building around are the ones that persist across months, which is an argument for looking at the log regularly rather than once.

What to do with the list once you have it

Sort every row into three buckets and act on them differently. Rewording, which means an existing page gains the visitor's words in its title, its first paragraph or a heading, and nothing else changes. Missing, which means a genuinely absent answer that needs writing, and there will be fewer of these than you expect. And broken, which means the answer exists and something structural is preventing anybody reaching it.

Do the rewording bucket first and do it all in one sitting. It is the cheapest work in the whole exercise, it does not require anybody to write anything new, and it produces the largest immediate change in whether people find things, both through your search and through anything else that reads your text.

Then keep the verbatim list. If you run anything that answers questions from your material, that list is the test set: run the exact strings and see what comes back. Phrasings drawn from your own visitors are a much harsher and much more relevant test than questions written by whoever built the thing, because the person who built it unconsciously writes questions in the vocabulary of the material.

Ten minutes a month

This does not need to be a project. Export the queries once a month, read the zero result rows, and compare against last month. The whole thing fits in ten minutes once the export is set up, and it is one of the few recurring tasks in this area that reliably produces work small enough to actually do.

The comparison is where the payoff accumulates. A query that was in the zero result list last month and is not this month is a fix that worked. A query that keeps coming back after you thought you had fixed it means the answer exists and still is not reachable, which is a different problem from the one you solved.

New arrivals are worth more attention than volume. A phrase that has never appeared before and now appears several times a week usually corresponds to something you changed: a new product, a new price, a rewritten page, a policy that took effect. Your search box will tell you about the confusion it caused before anybody writes in to complain about it.

If you take one thing away

The one thing
Export a month of site search queries, read every row that returned nothing, and spend one sitting adding your visitors' actual words to the headings of pages that already answer them.

Everything above is the reasoning. This is the part that changes what you do on Monday.

Questions

Our site search is not very good. Is the log still useful?
More useful, if anything. A weak search produces more zero result rows and more rewording runs, and both of those are the informative parts. The quality of the search affects how well visitors are served in the moment. It does not affect the value of the record they left behind.
How much volume do we need for this to be worth doing?
Very little, because you are not computing a rate. Twenty zero result queries you can read individually are actionable in a way that a large aggregate is not. On a quiet site you can read every search from the last three months in a single sitting, and you should.
Should we add the searched phrases as keywords to our pages?
Add them where they are genuinely how a reader would ask, in headings and opening sentences that a person would want to read. What does not work is appending a list of phrases to the bottom of a page, which helps nobody looking at the page and produces material that reads badly to anything trying to answer from it.

Keep reading

Try it on your own material

Upload a document or point it at your site, paste one line of HTML, then ask it something only your business could answer.