Custom website development: the site has fewer than a hundred pages, the client insists on adding site search, operations says it's unnecessary — should we push back first?

Bottom line first: when a website has fewer than a hundred pages, site search usually isn't a must-have, and it has a high chance of becoming decorative. Based on 2026 project delivery experience, first look at content volume, visitor intent, and navigation coverage, then decide whether to skip it, replace it with category filtering, or use a third-party search service or build your own; a presentation-oriented website doesn't need to force it in just so the site looks complete.

What problem does site search actually solve?

Site search is not a default requirement for every website. Its real purpose is to give visitors a keyword-based path to content when the content volume exceeds what navigation can carry. Its value comes from findability, not from making the page look complete.

Presentation-oriented websites are mainly browsed. Visitors usually care only about services, cases, and contact details. A search box may instead create the expectation that there is a lot of content to search here, and when visitors click through, there aren't enough results.

• Visitors with a clear lookup target: product model, specifications, document number, article title.
• Sites with complex, deep content structures: multiple levels of categories under product centers, resource libraries, help centers.
• Sites with frequent updates and continuously growing entries: news, announcements, technical articles.

If visitors mainly arrive from ads, business cards, or trade shows and the browsing path is clear, the marginal value of search is low. Conversely, if support is asked every day “do you have a certain model?” and the site has no direct entry point, that's when search deserves priority.

When content is under a hundred pages, run the three checks and one calculation first

This framework orders the decision by content volume, visitor intent, navigation coverage, and maintenance cost. First check whether there is real lookup demand, then whether the current structure can support it, and only then whether it's worth the investment. The order shouldn't be reversed, or it easily turns into wanting a search box first and finding reasons afterward.

1. Content volume and type: A few dozen text-only pages usually don't need it; product models, specs, and documents above the typical range raise the value of search.
2. Visitor intent: Look at search terms and support records. Are visitors searching for the company name, or for a specific model, issue, or document number?
3. Navigation coverage: Can categories, filters, and tags get visitors to their target within two clicks? If not, search is a patch, not decoration.
4. Maintenance cost: Search indexing, tokenization, result ranking, and content update syncing all need someone to maintain them; the less content there is, the higher the per-unit maintenance cost.

Note that steps two and three are often decided by gut feeling. A client saying “customers will search” and actual backend behavior are two different things. In 2026 projects, it's common to see dozens of pages in the backend and search usage staying below one percent for a long time, while empty-result prompts, search page indexing, and maintenance issues persist.

Three common paths for site search, with different costs and timelines

Based on common practices in 2026, there are roughly three tiers. The most expensive isn't always the best; it depends on content volume and search depth. Define content volume first, then choose the approach, to avoid building something and finding there's no content to index.

• Replace the search box with categories, tags, and parameter filters: Low cost, typically a few working days; suitable for presentation-oriented sites with dozens to one or two hundred pages and clear field structures.
• Use a third-party search service: Call a mature search API that supports tokenization, highlighting, and ranking. Typical timeline is 3-10 working days (experience range), billed by call volume or package, typically tens to hundreds of yuan per month (typical range); suitable for sites with medium content volume that don't want to build their own index.
• Build full-text search yourself: Based on database full-text indexes or an in-site search component. It offers high control but requires handling tokenization, ranking, index updates, and performance. Typical timeline is 2-6 weeks (experience range); suitable for sites with large content volume where search is a core feature.

Before choosing, ask three questions: Will content volume keep growing? Do search results need to be ranked by business weight? Is there someone to maintain the index long term? If you can't answer these, it's usually safer to skip full search for now.

Common pitfalls and acceptance criteria: what counts as passable

The difference between usable site search and qualified site search is in the details. The standard isn't having a search box; it's that common terms return results, no-result cases have fallbacks, and search pages don't drag down SEO. These pitfalls are often missed during delivery acceptance.

• Searching titles only, not body content: Visitors remember model numbers or issues from the body text, which titles may not match.
• Blank page when there are no results: Provide recommended content, popular categories, or contact details to avoid visitors bouncing immediately.
• Search result pages get indexed in bulk: Search pages are usually better set to noindex or with a canonical to keep empty and duplicate pages out of the index.
• Mobile keyboard covers results, buttons too small: Mobile search entry and result pages need separate acceptance testing.
• Messy pagination parameters: Multiple URLs for the same result set create duplicate content; unify the rules at delivery.

For acceptance, randomly pick 10 keywords from backend content, including long-tail terms, model numbers, and typos, and check whether returned results and ranking are reasonable. Search response time should typically stay within one second (experience range); beyond that, visitors tend to give up.

Applicable scenarios and boundaries

Site search suits sites with large content volume where visitors arrive with a lookup target; it doesn't suit using “the site looks complete” as the reason to add search. Judge by content volume and visitor behavior first, then discuss features.

• Suitable: Product models above the typical range (experience suggests more than three hundred to five hundred SKUs or entries), many help center documents, frequently updated news, internal knowledge bases, or dealer lookups.
• Not suitable: Presentation-oriented websites, service-introduction-focused sites, a few dozen pages, visitors mainly viewing cases and contact details.
• Boundary statement: When content is under a hundred pages and visitors mainly browse, site search is usually not a necessary feature; prioritize categories, filters, and in-page find.

On the delivery site, the constraints are often insufficient budget and content readiness. The client insists on a search box on the homepage, but the backend has only a few dozen products and the materials are still scattered spreadsheets. A common approach is to start with category and parameter filters, and add search once product data is organized to a certain scale. This usually saves about one to two weeks of index development and follow-up maintenance (experience range). The trade-off is that the search entry is temporarily missing at launch, and the boundary needs to be communicated to the client in advance; otherwise it may later be treated as an omission.

FAQ

Does site search affect SEO?

Site search itself doesn't directly improve rankings, but if search pages are indexed in bulk, they can create duplicate or empty-result pages. A common practice is to set result pages to noindex so search serves visitors rather than the index.

With only a few dozen pages, will adding a search box make the site look empty?

Yes. When content volume is insufficient, search often returns the same batch of content or nothing at all, giving visitors a worse experience than clear category navigation. In that case, prioritize improving navigation and in-page find.

Should we use a third-party search service or build our own?

If content volume is small and budget is limited, start with category filtering; if content volume is medium and you need tokenization and highlighting, a third-party search service can work; if content volume is large and search is a core feature, consider building your own full-text index, depending on long-term maintenance capacity.

Can site search and navigation menus replace each other?

No. Navigation suits browsing without a clear target, while search suits visitors arriving with a model or keyword. The two usually work together, with search covering deep content that navigation can't reach.

After search goes live, how do we tell whether it was a waste?

Look at search usage rate, click-through rate after search, and the share of no-result terms. If usage stays low for a long time and no-result terms are concentrated, it means content is insufficient, the entry point is poorly placed, or visitors simply don't need search.

First count backend content entries and visitor lookup paths. Under a hundred pages, prioritize categories, filters, and in-page find; if content volume exceeds the typical range, choose third-party or self-built search based on budget, and add noindex and no-result fallbacks to search pages. The applicable boundaries should be written into the delivery checklist: when content is limited and visitors mainly browse, not adding site search is not an omission. At project close, we usually accept the search entry and content categories together to avoid patching after launch.