Building Site Search for Websites and Apps: Chinese Word Segmentation, Typo Tolerance, and Designing for No Results

“We definitely carry that product, but customers say they cannot find it.” Owners of online stores, content sites, and membership apps hear this complaint often. A site search feature looks like a single input box, but behind it sit questions of how data is stored, how Chinese text is split into words, what happens with typos, and how results are ranked.

Many sites launch with search built the simplest way: take what the user typed and check whether any title in the database contains that string. With few products or articles, the problem stays hidden. Once content grows and users describe things in all kinds of ways, a search for one name for a product misses the listing that uses another, and a single typo returns nothing.

This guide explains the difference between database queries and a search engine service, Chinese word segmentation and synonyms, typo tolerance, filtering and sorting, page design when there are no results, and how to turn search logs into a basis for planning content and products.

Why site search deserves real effort

People who use site search usually already know what they want. They do not want to browse categories slowly; they want to go straight to the target. For an online store, these are often the customers closest to placing an order. For a content site or knowledge base, they are readers arriving with a specific question.

The cost of poor search is just as direct. Users who cannot find something rarely try another word; they leave, or they ask customer service. So search quality is not only a technical matter. It shows up in support volume and conversions.

Another frequently overlooked value: the search box is the one place where users tell you directly, in their own words, what they need. What people search for, and what they fail to find, is firsthand material for planning products, content, and categories.

Database queries versus a search engine service

Site search is broadly built in one of two ways.

Database queries. Text is matched directly in the site’s existing database. It is simple, needs no extra system, and the data is always current. The limit is weak handling of Chinese: most of the time it can only check whether a string is contained, with no understanding of words, synonyms, or typos, and performance drops as data grows.

A search engine service. A dedicated search service is set up or subscribed to, and the searchable data is synced to it to build an index. It handles word segmentation, synonyms, typo tolerance, relevance ranking, and multi-condition filtering, and stays fast at large data volumes. The cost is one more system to maintain, and the data sync must be designed carefully, or you will see products that have been taken down still showing up in search.

How to decide which to use

• Little content, users mostly browse categories → database queries plus thorough categories and filters are enough.
• Search is the main entry point and “I cannot find it” complaints are common → consider a search engine service.
• You need multi-condition filters that show the count for each option in real time → a search engine service suits this better.
• Data changes very often, such as stock and prices moving constantly → either way, design the sync mechanism first.

If you use an off-the-shelf CMS or e-commerce platform, search capability depends on the platform and its plugins, so include search in the evaluation when choosing. See the CMS Selection Guide and the E-commerce Website Development Guide.

Chinese word segmentation: the foundation of search quality

English separates words with spaces, so a search system can easily tell where one word ends. Chinese has no spaces. A product name like “wireless Bluetooth earbuds” is written as one unbroken run of characters, and whether it splits into “wireless / Bluetooth / earbuds” or some other combination has to be handled by word segmentation.

Poor segmentation causes two problems:

• Things that should be found are not. A user searches for “Bluetooth earbuds,” but the product is named “wireless Bluetooth in-ear earbuds.” The two are not the same continuous string of characters, so simple matching misses it.
• Things that should not appear do. When text is split too finely, a search for “peanut” (花生, whose two characters on their own mean “flower” and “grow”) can pull in every result containing either character.

How this is handled in practice:

• Choose a search solution that supports Traditional Chinese segmentation, and check how it handles the terms people use in Taiwan.
• Build a custom dictionary with brand names, product model numbers, industry terms, and the product names your store commonly uses, so they are not split incorrectly.
• Weight titles, categories, tags, and body text differently, so results matching in the title rank higher.

A custom dictionary needs ongoing maintenance and should be updated whenever new products or brands go live. That is usually an operations task, so ideally the admin panel lets non-engineers manage the dictionary directly.

Synonyms and typo tolerance: letting users find things in their own words

Users do not search the way you named your products. They use everyday language, nicknames, and abbreviations, and they make typos.

Synonyms

The same item goes by many names: insulated cup and thermos, phone case and phone cover, coat and jacket. The search system needs a synonym list that maps these terms to one another.

Sources for building the synonym list:

• Frequent searches in the logs that return zero results, which on inspection turn out to be another name for something you sell.
• Phrasings customer service hears often.
• Mixed Chinese and English, such as a brand’s Chinese name and its original English name.
• Common colloquial terms and abbreviations used in Taiwan.

Synonyms also have a direction: a search for “coat” should bring up “jacket,” but a search for “jacket” does not necessarily need to bring up every coat. Think this through when setting them up, and again, ideally let operations staff adjust them in the admin panel.

Typo tolerance

Choosing the wrong character in a phonetic input method (most people in Taiwan type Chinese with Zhuyin, a phonetic system) or dropping a letter from an English model number are both common. Search engine services can usually tolerate typos in English and numbers, so a model number one character off can still be found. Chinese typos are more complex; common reinforcements are adding frequent typos directly to the synonym list and offering a “Did you mean…” suggestion.

Filtering and sorting: helping users narrow down a long list

Too many results are as frustrating as too few. Filtering and sorting are the tools that help users narrow down.

Filters should be designed around the nature of the content. Online stores commonly offer category, price, brand, size, color, and in-stock status; content sites commonly offer topic, date, and article type. When designing them:

• Show the number of matches next to each filter option, so users do not tap one only to find zero results.
• If a combination of filters produces no results, suggest which condition to relax.
• On mobile, the filter panel should collapse rather than fill the screen.
• Show applied filters clearly, with a one-tap way to clear them.

Sorting usually defaults to relevance, with options such as “Newest” and “Popular.” Business rules can feed into relevance, for example ranking in-stock items first or boosting featured products, but the rules should be transparent and manageable, and relevance should not be completely overridden by manual rules.

The response speed of search and filters also directly affects the experience; if every change to a filter means a long wait, users give up. For directions on performance work, see the Website Performance and Core Web Vitals Guide.

What the page should show when there are no results

The zero-result page is the screen most often rushed through, usually just “No results found.” Yet this is exactly the moment users most need help.

Zero-result page checklist

• Repeat the keyword the user searched for, so they can confirm they did not mistype it.
• Offer spelling or wording suggestions: “Did you mean…”
• Recommend popular categories, products, or articles so the user has somewhere to go.
• If filters were applied, suggest relaxing them and offer a one-tap clear.
• Provide a contact route, such as “Can’t find what you need? Tell us,” and collect those replies in the admin panel.
• Do not leave the page blank, and do not redirect straight to the home page.

If people are searching for something you genuinely do not sell, the zero-result page is also a chance to learn about demand. Organize what users leave there, and you have a product wish list written by your customers.

Using search logs to plan content and products

Search logs are the most honest demand data on your site. Build logging in during development and record at least the keyword, the time of the search, the number of results, and which result the user clicked.

A monthly search log review you can follow

1. List the most-searched keywords: check whether the first page of results for each makes sense, and whether the top results are what users actually want.
2. List the zero-result keywords: decide one by one whether each is a typo, a synonym, or something you genuinely do not have. Add typos and synonyms to the lists; pass the genuine gaps to the content or purchasing team to evaluate.
3. List keywords that return results but rarely get clicks: these mean the results do not match expectations, so check ranking and relevance settings.
4. Watch for people leaving the site after searching: deal first with the terms that make people leave.
5. Feed popular search terms back into navigation: consider adding frequently searched categories to the main menu or the home page.

These findings also carry over to external SEO: the words people search for on your site are often the words they use on Google, which makes them a basis for planning new category pages or articles. For the indexing settings of the result pages themselves, plan them alongside Technical SEO for Website Projects. To track search behavior, you can also set up site search events in your analytics tool, as described in the GA4 Setup Guide.

What to settle with the development team before building

Site search requirements are easily reduced to a single line, “it needs search,” and only after launch do people discover they understood the scope differently. Before development, write these points into the requirements:

• What should be searchable: products, articles, store locations, FAQs, and which fields of each.
• How soon after data changes the search results should reflect them.
• Which filters and sort options are needed.
• Who maintains the dictionary and synonyms, and where.
• What the zero-result page should show.
• Which fields the search logs should keep, and who can see the reports.
• Whether the search box needs autocomplete suggestions.

For how to organize the requirements document, see How to Write Software Requirements.

When search is done well, users barely notice it exists; done poorly, it turns into support calls and lost orders. If people often tell you they cannot find things on your website or app, or you are planning to rebuild search, talk to NETVANA about your search needs. We start by looking at your content structure and existing search logs, then recommend whether to strengthen database queries or bring in a search engine service. Software work is quoted after a consultation; what each service includes is listed in the software services overview.

Further reading: For search and product structure on an online store, start with the E-commerce Website Development Guide. A platform’s search capability depends on what you choose, so read the CMS Selection Guide. To decide whether Google should index result pages, see Technical SEO for Website Projects. For speed problems with search and filters, refer to the Website Performance and Core Web Vitals Guide. And to track what users search for, see the GA4 Setup Guide. Once internal documents pile up, finding them matters as much as writing them down, so see Building an Internal Knowledge Base System.