Does Your Small Business Website Need Site Search, Category Filters or Just Better Navigation?

2026-10-24

Short answer: it depends on what your visitors are trying to do and what kind of content you hold, not on how many pages you have. If visitors often arrive knowing the name of what they want and your menus do not get them there quickly, keyword search may earn its place. If they arrive with a situation rather than a name, categories and filters may help. If the important pages are few and clearly signposted, better navigation may be all you need. Many sites end up with a combination, and it is worth deciding which parts you want before anyone builds them.

If you are commissioning a website, this guide gives you a way to decide what to ask for and how to check it once it is delivered. It focuses on decisions and acceptance checks rather than code.

A hypothetical example: a training provider's course directory

Picture a made up training provider with a directory of courses. It is an illustration, not a real business. Three visitors arrive with three different tasks:

One types "Excel course" because they know what they want.
One needs "something for new team leads, in the evening, online" and does not know any course titles.
One simply wants the booking page.

The first visitor may be well served by keyword search, or by a clearly named menu item if the course list is short and tidy. The second is describing properties of courses, which suits categories and filters that can be combined. The third needs a visible link, not a search feature. The point is to match tools to tasks, and to accept that one tool may cover more than one task.

Start with visitor tasks

Before choosing a feature, write five to ten real tasks in visitors' own words. Take them from emails, phone calls, messages and the questions your staff keep answering. For each one, note whether the visitor knows the exact name, knows a property (level, location, format, price band), or only knows the problem they want solved.

If most tasks turn out to be known destinations, I would put the budget into clear menus, page titles and internal links first. Search added to confusing navigation can simply expose the confusion, so fix the structure, then watch which tasks still fail.

Keyword lookup

Keyword search suits content that people recall by name, code or distinctive words. It helps to know what a search box actually is. MDN's description of the search input type says these are functionally identical to text inputs, but may be styled differently by the user agent. In other words, the HTML element collects the words a visitor types. Finding, matching and ranking your content is separate work, done by whatever search approach sits behind the box. When you ask for a quote, ask which approach is proposed and what it will and will not match.

Categories and combining filters

Filters suit content with consistent properties, such as topic, level, format, location and duration in the course example. Two decisions deserve attention.

First, who maintains the categories? If new items are added without an agreed list, categories can drift and overlap, which makes filters less trustworthy. A fixed list with a simple rule for adding to it reduces that risk.

Second, how do filters combine? Decide whether choosing two locations widens the results, and whether choosing online and evening narrows them. Visitors cannot see this logic, so write down examples and test them.

Result cards that support a decision

A result is useful when the visitor can judge it without opening it. For each course, decide which fields appear on the card: title, one line summary, format, next date and a clear link. Include only what your team will keep current. A card with an out of date date can mislead more than a card without one.

No results recovery

Any search or filter feature can return nothing. Decide what the visitor sees then. Options include naming the filter to remove, suggesting broader categories, listing popular items and offering a contact route. A blank page or a bare "0 results" leaves the visitor stuck.

Searchable fields and update ownership

List the fields search should look at: titles, summaries, tags, course codes, perhaps full descriptions. Then name the person who owns each one. If nobody reviews tags after launch, results can slowly stop matching how visitors talk. I would limit searchable fields to those with a named owner and a review habit, and keep that list in the project handover.

Public and restricted content

State what search must never reveal: drafts, internal notes, customer specific price lists, members only material. Test this by searching while logged out for known restricted items and confirming they do not appear, not even as a title. That test checks one thing. It is not a complete security review, and if restricted content matters to your business, access control needs its own scoping and checking.

Multilingual matching is explicit scope

If the site has more than one language, do not assume search handles it. Decide whether a visitor typing in one language should find content written in another, whether each language gets its own results, and how names that stay in English are treated. Each answer is a piece of work to specify and test.

Typos and synonyms: optional and product specific

Handling misspellings or related words is a capability some search products provide and others do not. As one product specific illustration, Algolia's documentation says "This is done by matching words that are close in spelling." That describes one product's behaviour. It does not describe every search tool, and it is not a recommendation to use that product.

If you want typo or synonym handling, scope it. List the cases that matter, such as a common misspelling of a course name, or "bookkeeping" and "accounting" treated as related, and test those cases. A general promise that search is smart is hard to verify.

Mobile and accessibility

On a phone, filters can take over the screen. Check that they open and close easily, that the number of results is visible, and that active filters can be seen and removed.

Labelling needs care too. The W3C tutorial says to "Provide labels to identify all form controls, including text fields, checkboxes, radio buttons, and drop-down menus." It also notes that "most users prefer or even need visible labels to understand the form." MDN advises: "Avoid using the placeholder attribute if you can. It is not as semantically useful as other ways to explain your form, and can cause unexpected technical issues with your content." My recommendation follows from these: a placeholder only presentation is not a substitute for an appropriately associated accessible label, so ask for a visible label, with placeholder text at most as a sample of what to type.

MDN also describes the effect of leaving the label out: "This could, however, cause confusion for screen reader users, as they will not receive any verbal indication of what the search input is." Include keyboard and screen reader checks in acceptance: the visitor can find search, reach the filters, and learn when results change.

Acceptance tests from real visitor wording

Turn each visitor task into a test written in the visitor's words, including misspellings your staff have really seen. For the course directory:

Typing the exact course name returns that course first.
Typing an informal or partial name returns the right course on the first page.
Choosing online plus evening returns only courses that are both.
A combination with no match shows a recovery message.
A draft course does not appear when logged out.

For a method of writing these clearly, see how to write acceptance criteria for a small web app.

Practical acceptance checklist

Five to ten visitor tasks are written in visitor wording.
Each task is assigned to navigation, search or filters.
The search field has a visible, associated label.
Searchable fields are listed, each with a named owner.
Categories are an agreed list with a rule for changes.
Filter combining behaviour is described and tested.
Result cards show only fields that will be kept current.
No results states offer a next step.
Restricted content is tested as absent from public results.
Language scope is stated.
Any typo or synonym cases are listed and tested.
Phone, keyboard and screen reader use are checked.

Frequently asked questions

Is a search box enough on its own? Sometimes. If visitors already know the words to type and your content is simple, it can be. If they come with a need rather than a name, filters or clearer categories may serve them better, and navigation still has to reach the pages people simply want to visit.

Can I start with navigation and add search later? Yes, and for many sites that is a sensible order. Improve menus and page titles, then note which questions still reach you by email or phone. Those become your first search tests.

Does search create ongoing work? It can. Someone has to keep searchable fields, categories and result card details accurate. Agree who that is before launch.

Next step

If you want help turning your visitor tasks into a scoped brief, you can see how I work with small teams. Each capability above would be scoped and agreed for your project rather than assumed.