When search belongs on the site — and when a sitemap is enough

A search field is a promise: what you type can be found. The promise holds when there is an index of the things you actually want found, and a page that says honestly when they are not there. It rots when the field searches blog posts because you meant the catalogue, when it 200s an empty layout without saying 'none', or when it is an icon that opens the same menu you already have. You think you have site search. You have an input that disappoints.

Teams inherit the word search from another product. In a shop it is find-the-item. On a docs site it is find-the-page. In a portal it is find-the-order. On a marketing site with a dozen pages it is usually 'someone wants a field because the header looks like everyone else's'. That last one is decoration. It costs crawl, it costs origin if the plugin scans, and it costs trust the first time someone types 'price' and gets three old posts and no page that answers.

It is also an SEO and a product question. Internal result pages you let get indexed are thin URLs you donate to the crawler. Search that is not noindexed is how you make 'site:you' look like a hole. Search that only lives behind login is a different job — portal, not marketing header. If nobody owns the empty state, the field is chrome. It is not findability.

We write this because 'we need search' has become a purchase you make before you have talked about what should be findable. An honest setup is boring: navigation and sitemap until the inventory is too large; then an index you own, an empty page you have written, and a log you read. Without that sentence you have Algolia on a site a menu would have handled. You do not have site search.

Site search is a named index over a named inventory: products, articles, tickets, documents — and a query that returns that inventory, not the whole site because you forgot to scope it. It is a product choice because it says what you think people came to find. It is not an icon. Most marketing sites need a sitemap and a menu. They do not need a field.

It is not 'put an input in the header'. A field without an index is a GET against a page that scans or hits the database on every keystroke. A WordPress plugin that LIKEs wp_posts is that pattern. It works on a site with little content. It becomes the expensive call the rate-limit post is about the day someone scrapes `?s=`. An honest index is built: you know what is in it, you know what is not, and you know what happens at zero hits.

It is not 'buy Algolia, Typesense or a shop-search add-on and we are done' either. A vendor index can be right when the inventory is large and you want typeahead and relevance you do not want to own. It is a second system: sync, keys, a preview that must not leak what you have not published. If you do not have a query log and an empty state, you have bought relevance for a field you do not have a product for. Start by counting what people would type. Buy the index after, if the count requires it.

And it is not a sitemap. The sitemap is for the crawler and for you: here are the pages we mean. Navigation is for the human who will browse. Search is for the human who will look up, because browse is not enough. If you can stand behind every important thing living in the menu or on a filter page with honest facets, sitemap and nav are enough. The field arrives when you can honestly say: 'this inventory cannot be surveyed without asking'.

The first failure is searching the wrong inventory. You wanted products. The field searches the blog, cases and the old privacy policy because the plugin indexed 'all posts'. The user types a product name and gets a post about a webinar that ended. Scope the index. If the job is the catalogue, marketing pages are not hits. If the job is docs, the shop is not hits. One field over everything is how you get relevance you cannot explain.

The second failure is the empty state you did not write. Zero hits is 200 with a white hole, or '0 results' without a next step. The empty page should say you understood the query, that it did not hit, and what they can do: see the catalogue, write to us, try another word you actually have. An empty page without an owner is a broken promise. The error-page post is 404 chrome. Here is letting 'no hit' be a product, not a failure you are ashamed of.

The third failure is indexing the result page. `/search?q=` as a crawler-friendly page is thin content you have asked Google to rank. Noindex search that is a tool. Index the things search points at. If you are proud of a search page as a landing page, you have a different problem: then the query is a topic you owe a real page — not a result layout with three hits.

The fourth failure is buying vendor before you have a log. You sync 'the whole site', you turn on typeahead, you get a bill the day the preview environment syncs too. You still do not know whether people type product numbers, synonyms or 'contact'. Log the query. Read it for a month. Then you know whether you need synonyms, whether you need an index at all, or whether you need a page named what people type. A clever index without a log is a slide.

The marketing site is the job that most often should not have search. A dozen pages, five services, a contact. Sitemap and nav are the findability. A field here is a promise you do not have an inventory for: people type 'price' and 'next.js' and get whatever the plugin happened to index. Build the pages you owe. Let the menu point at them. The Next.js agency landing is what you link to when the job is the site. The field does not arrive because the header looks like a shop.

The catalogue and the shop are the job that is most often right as search — and most often wrong as 'search the whole site'. Find the item. Scope the index to what can be bought or chosen. A filter page with honest facets lasts a long time if the list can still be seen. Vendor lasts when typeahead and spelling are the job and you have read the log. The B2B shop post is the difference between B2B and B2C. Here is letting find be a product in the catalogue, not a field that also hits the blog.

Docs and the help centre are the job that most often looks like search and most often dies as a sidebar you forgot. If the articles cannot be surveyed, you owe an index over docs — not over marketing. The empty state should point at a contact or an article you actually have. The RAG post is when the answer must be generated. This one is when the answer is already a page you wrote, and the human must find it. Do not mix the two: a chat field is not site search, and site search is not a model you have not scoped.

The portal is the job that is most often right as search and wrong as a public field. Find the order, the case, the file — behind login. That is not the header on www. It is an index you must not leak, and a query you rate-limit. The portal post and the form-to-portal post are access. Here is findability inside. One vendor index over public and private is how you get a preview or a script to show what you promised was behind the passcode.