Why wiki search keeps failing you

You are three days into a new job. Someone mentions “the expense claim process” in a meeting and you think: wiki. You open it, type “expense claim” into the search bar, and get eleven results. You click the top one. It describes a system that was replaced eighteen months ago. You click the second. It is a project page from a finance initiative that mentions expense claims once, in passing. The third is the right page — you find out later, when a colleague sends you the link directly.

This is not an edge case. It is the most common single experience people have with a wiki, repeated dozens of times a day across organisations of every size. And it is almost never caused by what people assume it is caused by.

Poor wiki search is not primarily a technical failure on the part of vendors. It is a consequence of two things that interact badly: the structural limitations of how most wiki search is built, and the content quality problems that accumulate in most wikis over time. Understanding both helps explain why “fixing search” is harder than it looks, and what conditions are actually required for search to work well.

The keyword search problem

The majority of wiki search engines are built on full-text keyword indexing. They are good at finding pages that contain the exact words you typed. They are poor at finding pages that contain the concept you had in mind, expressed using different words.

In a small, well-maintained wiki, this is manageable. As wikis grow, the vocabulary problem compounds. The page about the customer contract process might use the word “agreement” while you searched for “contract”. The security incident procedure might be titled “Critical response playbook” when you searched for “what to do if we get hacked”. The result is not that the content does not exist; it is that the search engine cannot connect your query to the page that answers it.

This is compounded by synonym problems, abbreviation problems, and language problems in international organisations. A company operating in German and English, or using both industry-standard terms and internal jargon, will routinely fail to surface relevant content through keyword search — not because the content is wrong, but because the words do not match.

The content decay problem

Search can only return what the index contains. When a wiki has accumulated years of content — some current, some outdated, some superseded but never deleted — the search index reflects all of it equally. There is no signal in the index that a page was last reviewed three years ago, that it has been flagged by readers as potentially outdated, or that a newer page covers the same topic more accurately.

The practical effect is that search results are polluted by content graveyard entries. A search for “expense claim process” might surface four pages: the current one, two from before the last system change, and one from a project that was cancelled. There is no visual distinction between them in search results. The user reads the top result, follows the procedure, and discovers it is wrong. The conclusion they draw is that the wiki cannot be trusted — not that search needs to be calibrated.

This is the compounding failure: bad content governance makes search worse, and bad search results make people trust the wiki less, so they stop contributing to it, which makes content governance worse. The decay is self-reinforcing.

What semantic search changes

The most significant recent shift in wiki search technology is the move from pure keyword indexing to semantic search, powered by vector embeddings. Instead of matching words, a semantic search engine encodes the meaning of both the query and the content as numerical vectors, and returns results where the meanings are similar — even if the vocabulary is completely different.

This directly addresses the keyword mismatch problem. A query for “what to do if we get hacked” can return the page titled “Critical response playbook” because the embedding model understands that these expressions are semantically related. Queries in German can return results from English pages where the concepts match. Informal questions — the way people naturally ask things — can find formal documentation.

Semantic search does not solve the content decay problem. It is just as good at finding outdated content as current content — arguably better, since an outdated page that was once well-written may score highly on relevance while being wrong. The combination of semantic search and content governance is what produces trustworthy results: semantic search expands the range of relevant content that can be found; content governance ensures that what is found is current.

A further dimension is what the index covers. Many wiki search tools only index wiki pages. Files attached to pages — PDFs, Word documents, spreadsheets — are either excluded or indexed only as filenames. For organisations where significant knowledge lives in attached documents, this means search misses a large proportion of the knowledge base entirely. A search engine that indexes page content and the full text of attached files, including scanned PDFs through OCR, covers the knowledge base as people actually use it.

Beyond the wiki: search across everything with MCP

Even a wiki with excellent semantic search and well-maintained content has a structural limitation: it can only surface what has been written into it. In most organisations, a significant proportion of institutional knowledge never makes it there. It lives in GitHub repositories, Jira tickets, Confluence spaces, Google Drive folders, Slack threads, and recorded meetings. A search that stops at the wiki boundary returns an incomplete picture by definition.

The Model Context Protocol (MCP) opens a different possibility. MCP is an open standard that allows AI systems to connect to external data sources through a consistent interface. When the tools an organisation already uses expose MCP servers — their code repository, their project tracker, their file storage — a search layer can query all of them simultaneously, not as separate searches in separate tabs, but as a single query that spans the whole knowledge landscape.

The practical difference is significant. An engineer searching for how a particular authentication flow was implemented no longer has to search the wiki, then switch to GitHub, then check Jira for the original requirements ticket. A product manager looking for everything related to a feature launch does not have to reconstruct it from four systems manually. The query goes out once; the results come back from wherever the relevant knowledge actually lives.

This changes the role of the wiki in the search picture. Rather than needing to be the single source of everything — an unrealistic expectation that causes most documentation initiatives to collapse under their own scope — the wiki becomes the home for knowledge that has been reviewed, structured, and considered reliable. Other systems contribute their raw artefacts. MCP-connected search surfaces both, in the right context, in response to a single question.

The wiki is still where you want answers to land when they have been validated. But MCP-powered search means that the journey to finding something no longer ends at the wiki’s edge.

The conditions for search to actually work

Good search is not a single feature; it is an outcome that depends on several conditions being met simultaneously. The search technology needs to handle meaning as well as keywords. The index needs to cover the full content surface — pages, files, and their text content. The content it indexes needs to be reasonably current and non-duplicated.

Of these, the content quality condition is the one most frequently ignored during tool evaluation. Organisations test search by searching for things they know are in the wiki — which tends to work fine on a clean demo environment. In production, after two years of uneven contributions, duplicate pages, and outdated procedures, the same search quality degrades significantly. The tool that looked impressive in the demo fails in production not because the technology changed, but because the content did.

Evaluating wiki search realistically means testing it on content that resembles your actual knowledge base: some well-written pages, some outdated ones, some with inconsistent terminology, and some that cover the same topic from different angles. The platforms that maintain search quality under these realistic conditions are the ones worth deploying at scale.

The new employee on their third day deserves better than eleven results and a colleague who finally sends the link.