Search is the primary way users find content in larger wikis. Browsing works for small wikis; for thousands of pages, search dominates.
Bad search means users can't find what's there. The wiki has the answer; users don't.
This page covers the patterns for good wiki search.
Pages most relevant to the query come first. Not chronological; not alphabetical.
Standard scoring: BM25 or similar. Modifications:
"running" matches "run." "the" doesn't match anything.
Most search libraries handle this by default per language.
User searches "how to deploy"; finds pages titled "Deployment Guide" even without the words.
Synonym expansion; concept matching; semantic search (with embeddings).
Title, body, tags, headings, comments. Different weights:
Search "deployment" → narrow by section, tags, date, author.
"deplyoment" still finds "deployment." Edit-distance matching.
For small wikis, the database's built-in search. PostgreSQL's tsvector; MySQL's full-text.
Simple; same infrastructure. See FullTextSearchInPostgresql.
For larger wikis, performance ceiling.
Elasticsearch, Solr, OpenSearch. Indexed; fast; feature-rich.
For wikis at scale, this is the right answer. See ElasticsearchFundamentals.
AWS OpenSearch, Algolia, Azure Cognitive Search. Less ops; managed scaling.
Embeddings-based. "Conceptually similar" rather than "word-match."
For wikis with diverse vocabulary, semantic search finds pages keyword search misses.
Combined with keyword search (hybrid retrieval), often the best results.
Wikantik uses BM25 + dense embeddings for hybrid retrieval. KG reranking is off by default (boost=0, never wired into production; shelved 2026-06-16 after a measured zero-lift ceiling spike). See KnowledgeGraphRerank.
This pattern (hybrid retrieval) has emerged as the modern best-of-breed for wikis with diverse content.
Crawl all pages; tokenize; index. Can be slow for large wikis.
Page edited → incrementally update index. Don't rebuild from scratch.
Periodically, full reindex. Catches inconsistencies; applies any indexing changes.
Sync: edit blocks until indexed. Async: edit returns; indexing happens in background.
Async is usually better. Brief lag between save and searchability is acceptable.
Titles are searched first. Use natural-language titles users might search for.
Bad: "Wiki Page 47" Good: "How to deploy to production"
H2/H3 headings are searched. Helpful for finding specific sections within pages.
Explicit tags help filtering and topic-based discovery.
Many search engines weight first paragraph higher. Lead with the page's purpose.
Cover terms users might search for, even alternatives. "User" and "customer" might both apply; use both.
For search-result snippets. Brief, accurate.
Searches that return no results: gaps. Either content missing or content not findable.
Most-searched queries: invest in those areas. Improve titles; expand content.
For each search query, what percentage of users click a result? Low CTR = bad search results.
How often users search vs. click links. Reveals search adoption.
For most modern wikis, search dominates after a certain size.
For typos: "Did you mean: deployment?"
After viewing results: "Other people searched for X."
As user types, suggest queries. Reduces query effort.
Personalization: surface recently-viewed pages.
Highlight high-traffic pages.
Slow. Eventually unusable.
Results in wrong order. Right page on page 10 of results.
User searches term A; page uses term B. No match.
Body content not searched. Missing matches.
"deploy" doesn't match "deployment."
Don't know what searches fail.
Recent pages not searchable; old content searched as if current.
For wikis up to a few thousand pages:
For larger or more complex wikis: dedicated search infrastructure from the start.