Anyone who has built search for a text corpus has run into the same wall: users do not remember exact strings. They remember fragments, and fragments are messy.
Bible study is an unusually clean case study for this problem, because the corpus is fixed, well-indexed, and people quote it constantly from memory.
What users actually type
Three patterns dominate:
- Half-remembered phrasing. The wording is close but not exact. Punctuation is guessed.
- Distinctive noun plus context. A person, a place, or an object from the passage, with a rough idea of what happened.
- A concept, not words. The user wants passages about a theme and has no specific text in mind.
A substring search handles the first pattern only when the guess is perfect. It handles the other two not at all.
Why exact matching fails
Exact matching assumes the query is a fragment of the document. Real queries are fragments of the user's memory. Those two things diverge in ways that are invisible to a LIKE '%query%' implementation: word order, inflections, synonyms, and the very common case where the user's memory is simply wrong about a detail.
The fix is not a bigger search engine. It is accepting that the query is approximate and ranking candidates by how much of the query they explain.
The interface matters as much as the ranking
Here is the part that gets skipped. Even a good ranking is useless if the result list makes the user read everything to find the match. A result should show the matching fragment in context, not the whole paragraph, and it should be obvious at a glance which result is the right one.
There is also a structural requirement underneath: every result needs a stable address. A passage that cannot be linked cannot be shared, cited, or returned to. Search results without stable addresses are dead ends.
The lesson for other search products
If you are building search over a fixed corpus — documentation, legal text, internal wikis — the same three patterns apply. The users are not quoting the document. They are reconstructing it from memory, and the interface should be built for that.
https://www.scriptureside.app/ is a study tool built around this model: fragment search, side-by-side translation comparison, and notes that attach to the passage rather than to a list.
Top comments (0)