🔍 📍 ✨
Here's what nobody tells you: site search is a band-aid. It's not a feature. It's an admission that your navigation lost the user.
When someone types into a search box, they're not doing you a favour — they're opting out of your information architecture. They've given up finding it your way. And you know what? They convert 40% higher through search than through browsing. Not because they're happier. Because they're desperate.
So the question isn't "should we add search?" It's "is our navigation so broken that users need to search?"
Most sites under 500 pages don't need search. You need better navigation. A clear category structure, breadcrumbs, faceted filters, and internal linking that actually teaches the user where things are. Stripe, Figma, and Linear all have search, but only because they have thousands of docs that *can't* be browsed intuitively. For a 20-page brochure site? You're solving the wrong problem.
But here's when you actually do need it: when you have **product libraries over 50 items, docs over 200 pages, or a blog archive users can't scan**. Shopify has 10,000 SKUs — search isn't optional. A personal blog with 300 posts? Users *need* to find that one post about CSS they read six months ago. That's search.
The second your users hit "I know what I want, I just can't find it," search moves from nice-to-have to conversion factor.
The trap most teams fall into is building mediocre search. A search box that's too small, tucked in the footer, with zero-results pages that say "nothing found" and offer no next steps. That's worse than no search — it's a broken promise. If you're going to search, commit to it.
Here's the baseline implementation:
```jsx
export function SearchBox() {
const [query, setQuery] = useState('');
const [results, setResults] = useState([]);
const handleSearch = (e) => {
const q = e.target.value;
setQuery(q);
if (q.length > 2) {
const matches = pages.filter(p =>
p.title.toLowerCase().includes(q.toLowerCase())
);
setResults(matches);
}
};
return (
{results.map(r => (
{r.title}
))}
{query.length > 2 && results.length === 0 && (
);
}
```
That's client-side search over a static list. If you have under 1,000 pages, this works. Load your sitemap as JSON, search in-browser, done. No API. No Algolia bill.
The moment you have 5,000+ items, or you need typo tolerance and ranked results, *then* you reach for Algolia or Meilisearch. But understand what you're buying: you're not buying search. You're buying the *expectation* of great search. Users will type typos and expect them to work. They'll expect autocomplete. They'll expect results ranked by relevance, not alphabetically. Once you open that door, mediocre search feels broken.
The real cost of search isn't the API. It's the zero-results page. That's where you win or lose. Show them alternatives: "Did you mean X?" "Popular pages:" "Browse by category:" A zero-results page that offers *nothing* is a dead end. Make it a waypoint.
Most sites add search and watch conversion drop because they optimize for *having* search instead of optimizing search *outcomes*. Fix your nav first. Add autocomplete second. Build zero-results handling last. That's the order.
No results. Try browsing by category.
)}