On this page
Most agencies run surveys to find out what residents want from their website. Meanwhile a few thousand residents a month type exactly that into a box on the homepage, unprompted, in their own words, at the moment they actually need it — and nobody reads the results.
Site search data is the cheapest research a local authority has. It needs no budget, no recruitment and no fieldwork, and it reflects real need rather than remembered need. An afternoon with it will usually reshape a content plan more than a quarter of meetings will.
What is your search box already telling you?
Four things: what residents came for, what words they used for it, what you have not published, and when they needed it. Nothing else you have gives you all four from the same source.
It is worth being clear about why this data is unusually honest. A survey asks people to recall what they needed and predict what they would want. A search query is captured at the moment of need, in the resident’s own vocabulary, with no interviewer shaping the answer and no incentive to be helpful.
The four signals worth looking for
- Zero-result queries
- Searches that returned nothing. Either the content does not exist, or it exists under a word nobody uses. Both are findings, and both are actionable this week.
- High-volume queries
- What residents search for most. Usually a navigation failure rather than a popularity contest: if hundreds of people search for the thing, it should not need searching for.
- Search-then-exit
- A search that returned results, after which the resident left. The search worked and the content did not. The most easily missed failure of the four.
- Vocabulary mismatch
- Residents searching "bin day" while your page says "refuse collection schedule". Harmless once you know, and invisible until you look.
How to run the review
An afternoon, once a quarter. It does not need a specialist and it does not need a tool beyond whatever your analytics already records.
- Export three months of queries. Shorter periods are too noisy to read.
- Sort by volume and read the top fifty aloud. Reading them aloud is not a flourish — it makes vocabulary mismatches audible.
- Pull out every query that returned nothing and group them by topic.
- For each group, decide: does this content exist under another name, or does it not exist?
- Check the top ten queries against your navigation. If a resident has to search for it, ask why it is not linked.
- Look for seasonal clusters and note the date they began, not just the term.
- Write the findings as a list of pages to create, rename or relink. Not as a report.
Turning queries into content decisions
A list of search terms is not a plan. The useful step is deciding what each pattern actually asks you to do.
| What you see | What it usually means | What to do |
|---|---|---|
| A query returning nothing, asked repeatedly | The content does not exist | Write the page. This is the clearest content brief you will get. |
| High volume for something already published | A navigation failure | Link it from where people start, rather than rewriting it. |
| Many spellings of one thing | Vocabulary mismatch | Add the resident’s word to the page in plain prose, and keep the formal name too. |
| Searches for a department name | People are navigating by structure | Usually staff or regular users. Check before redesigning around it. |
| A spike with a date attached | Seasonal or event-driven need | Publish ahead of the spike next year, and link it prominently for the period. |
| Results returned, then an exit | The page was found and did not answer | Read the page as though you were the person who searched. It is usually written for the department. |
The vocabulary problem
This is where most of the quick wins are, and it is almost always a consequence of organisational structure leaking onto the website. Pages get named after the department that owns them rather than the thing a resident wants.
- Residents search for the outcome — "replace my bin" — not the service that delivers it.
- They use the common word, not the statutory one. "The tip", not "household waste recycling centre".
- They search for the problem, not your solution: "tree fell on my fence", not "highways maintenance request".
- They rarely know which department does what, and there is no reason they should.
What search data cannot tell you
It is a record of attempts, not of outcomes, and over-reading it is a real risk.
- It cannot tell you whether anybody found what they wanted. A result was returned; what happened next is a different measurement.
- It says nothing about residents who never searched — who browsed, phoned, or gave up on the homepage.
- It under-represents people who find search boxes difficult, including some users of assistive technology and anybody unsure of the spelling.
- A low-volume query is not necessarily unimportant. Twelve searches for an emergency housing form matter more than four hundred for the pool timetable.
- It tells you what was asked, never why. The why usually needs five minutes with the front desk.
Where SmartBot fits
An assistant extends this record rather than replacing it. A search query is two or three words; a question asked conversationally carries the whole context — the condition, the deadline, the circumstance that made it complicated.
SmartBot gives insight into the common questions residents ask and the gaps in content behind them. Read alongside your existing zero-result queries, that is the same signal from two directions: what people looked for and could not find, and what they asked and could not be told.
Frequently asked questions
How much data do we need before this is worth doing?
Three months is usually enough to see patterns, and even a single month of zero-result queries is worth reading. Smaller agencies see less volume but often clearer signals, because the queries are less diluted.
Our search box is barely used. Is the data still useful?
Yes, and the low usage is itself a finding worth chasing. Check whether it is visible on mobile, whether it appears on interior pages, and whether people tried it once and gave up. A search box that returns nothing useful trains people to stop using it.
Should we publish a page for every zero-result query?
No. Group them first. Twenty variations on one missing topic are one page, and a long tail of one-off queries is usually noise rather than need.
What if the content exists but people cannot find it?
That is a navigation and naming problem, and it is cheaper to fix than writing. Link it from where people actually start, and put the resident’s word in the page title.
How does this relate to search engine optimisation?
It overlaps usefully. The words residents type into your site are close to the words they type into a search engine, so writing the page in their vocabulary serves both. Site search data has the advantage of being specific to your own residents.
Who should own this review?
Whoever owns website content, usually communications. It needs someone who can commission a page off the back of it, otherwise it becomes a report nobody acts on.
Where to go next
Export last quarter’s search queries this week and read only the ones that returned nothing. It will take under an hour. You will recognise most of them, several will be things you assumed were published, and at least one will explain a phone call your front desk takes every day.