How to Add Site Search to Your Website

The right way to add search to a website is to first decide what will be searched and across how many records. On a site with a few thousand pages or products, the database’s own full-text search (PostgreSQL, for example) is enough; when you need many filters, instant suggestions and a large catalogue, a dedicated search engine (such as Elasticsearch, OpenSearch, Meilisearch, Typesense or Algolia) comes in. Whichever you choose, the real work is the same: tolerating accents and typos, ranking results meaningfully and measuring searches that return nothing.

Why site search is not just a LIKE query

The first idea is usually to check whether the database record "contains" what was typed into the search box. It seems to work on a small table, but it does not match what users actually type:

• Accents and special characters: the user types "cafe", the record says "café"; in Turkish content, I/ı and İ/i case conversion causes extra trouble.
• Word forms: a search for "shoes" should find the record "shoe".
• Typos: a user who types "sheos" should not see an empty page.
• Ranking: a "contains" query returns matches but does not say which one is more relevant; a word in the title should outrank a word in the description.
• Performance: a "contains" query with a leading wildcard cannot use a standard index, so every search scans the whole table as data grows.

Database search or a separate search engine?

The decision depends on your list of needs more than on technology preference. For most corporate sites, blogs and mid-sized catalogues, the existing database does the job and there is no second system to operate. We covered the database choice in our PostgreSQL vs MySQL article; PostgreSQL, with full-text search and a similarity extension, is a strong starting point here.

• Database search is enough: limited content, few filters, results return instantly and the team does not want to run a second system.
• A search engine is needed: a large product catalogue, many filters with result counts next to each (facets), suggestions while typing, synonym management and heavy traffic where search must not slow the site down.
• Hosted search service: the provider carries the operational load, but pricing is based on records or requests and your data is stored outside; work out the cost and data protection side up front.

A search engine does not replace the database; it sits next to it. The source of truth stays in the database, the search index is a copy fed from it, and keeping that copy current is a separate part of the project.

Example: full-text search with PostgreSQL

The example below uses the unaccent extension for accent-insensitive search and pg_trgm for typo tolerance. Full-text matching runs first; if it returns nothing, a similarity search kicks in. Titles are weighted higher than descriptions.

CREATE EXTENSION IF NOT EXISTS unaccent;
CREATE EXTENSION IF NOT EXISTS pg_trgm;

-- IMMUTABLE wrapper so unaccent can be used in index expressions
CREATE OR REPLACE FUNCTION f_unaccent(text) RETURNS text
  LANGUAGE sql IMMUTABLE PARALLEL SAFE
  AS $$ SELECT public.unaccent('public.unaccent', $1) $$;

ALTER TABLE products ADD COLUMN search_doc tsvector
  GENERATED ALWAYS AS (
    setweight(to_tsvector('english', f_unaccent(coalesce(name, ''))), 'A') ||
    setweight(to_tsvector('english', f_unaccent(coalesce(description, ''))), 'B')
  ) STORED;

CREATE INDEX products_search_idx ON products USING gin (search_doc);
CREATE INDEX products_name_trgm_idx ON products
  USING gin (f_unaccent(lower(name)) gin_trgm_ops);

-- 1) Full-text search, ordered by relevance
SELECT id, name, ts_rank(search_doc, q) AS rank
FROM products,
     websearch_to_tsquery('english', f_unaccent($1)) AS q
WHERE search_doc @@ q
ORDER BY rank DESC
LIMIT 20;

-- 2) No results: typo-tolerant similarity search
SELECT id, name
FROM products
WHERE f_unaccent(lower(name)) % f_unaccent(lower($1))
ORDER BY similarity(f_unaccent(lower(name)), f_unaccent(lower($1))) DESC
LIMIT 10;

Two things to watch: how lower() converts characters such as the Turkish I/ı depends on the database’s locale settings, so test with real uppercase records; and tune the similarity threshold against real searches on your own data instead of leaving it at the default.

What a good search experience includes

• An empty results page should not be a dead end: show similar results, popular categories or a way to get in touch.
• The search term should live in the URL (?q=...), so results can be shared and the back button works.
• Filters should show result counts and never offer an option that leads to zero results.
• On mobile, the search box should be on the first screen, and the results area should not collapse when the keyboard opens.
• Instant suggestions should send a request after a short pause (debounce), not on every keystroke; otherwise the server does needless work.

How does site search affect SEO?

Search result pages are not suitable for Google’s index: they generate endless URLs and count as thin content. Mark them noindex and keep them out of the sitemap. Site search data, on the other hand, is a valuable SEO source: every term users search for on your site but cannot find points to a page you should write or a product you are missing. You can collect it as a site search event in Google Analytics 4. Fast-loading results also directly affect your Core Web Vitals.

The most valuable search report is not the most searched terms but the searches that return zero results. Each one is a missing page, a missing synonym or a missing product.

Common mistakes

• Updating the search index only overnight: a product whose price or stock changed looks wrong all day; update on change or through a queue.
• Indexing unpublished or permission-protected content: a search result can leak information that the page itself would not show.
• Leaving the search endpoint open without rate limits: bots wear it down; the website security principles apply here too.
• Using a single index on a multilingual site: each language should be indexed separately with its own language rules; details in our multilingual website article.
• Keeping search terms together with personal data indefinitely: search logs can contain personal data, so set a retention period.

On e-commerce sites search is a direct sales channel; we covered the cost items of search infrastructure in our e-commerce website cost article. In projects such as a B2B dealer ordering system, where dealers order quickly by product code, search should prioritise exact matches on product codes and barcodes.

Conclusion

Adding search to a website is more than placing a search box: you need a setup that tolerates accents and typos, ranks results by relevance and reports searches that return nothing. For most sites the database’s own full-text search is a good start; you move to a dedicated search engine when catalogue and filter needs grow. If you want search that actually helps your visitors, take a look at our web development service or request a quote.