Searchnik is a hosted tool for managing the rules that shape your search results: synonyms, boosts, filters, redirects. This page covers what it manages, how it is organized and how it runs.
You can change how the ranking algorithm works, you can change the content that gets indexed, or you can tell the search engine how to treat specific queries. That third option is what we call rules.
An algorithm change touches everything and has to be tested as such. A content edit fixes one document. A rule reaches every document a query touches, but only for the queries you choose, and it can go live without a release cycle. Most teams see a large share of their practical improvements here for that reason. It is also the layer that tends to be managed least carefully: rules end up in tickets, spreadsheets and config files, and a year later nobody can say why a particular one exists.
A rule does the same thing every time the same query comes in and it is easier to understand than your overall ranking model. That relative determinism is what you want wherever someone has to be able to say what search will do: merchandising (the campaign page leads for "sneakers" this month), compliance-sensitive wording, excluding products or documents for legal or brand reasons, or part-number and synonym handling in B2B catalogs.
It also makes rules a useful companion to AI-driven ranking: an explicit, reviewable layer that sets the guardrails around a model's behavior.
Querqy is an open-source query rewriting library that runs inside the search engine. Searchnik manages Querqy rules for OpenSearch, Elasticsearch and Solr: you edit and approve rules in Searchnik, and Searchnik puts the resulting configuration onto your search cluster.
Searchnik is never in the live query path. Your own cluster answers every search. If Searchnik were unavailable you could not edit rules for a while, but search would keep serving whatever was last deployed.
Searchnik is built around three things. Each one answers a question a search team keeps asking: what matters, what do we do about it, and why did we do it.
Queries come from your search analytics, through a simple upload. They tell you where to spend your time: Searchnik ranks them by your KPIs and query volume, and derives a criticality score from the two.
They also tell you what a rule will affect. For any rule you can see which queries it touches and how much traffic that is (its blast radius), summarized as a low, medium or high impact.
Rules are what you create and manage to control search, in an editor rather than a config file. Searchnik covers the Querqy Replace rewriter and the Common Rules rewriter.
A task describes a piece of work: what is wrong now and what the target is. It has an owner, a status and a comment thread, and it is attached to the queries it concerns and, through them, to the rules that affect those queries.
Over time tasks become the documentation. A year from now, "why did we create that rule?" has an answer.
Some teams want every change reviewed; others want to move fast. Searchnik supports both, and the review step is optional.
Rules move from draft to submitted to approved, with roles for editors and approvers. Use the review steps where they help and leave them out where they do not.
Every change to a rule creates a new version, and the previous version keeps serving until the new one is approved. Who changed what, and when, can be traced.
Give a rule a start and an end date. The seasonal campaign switches itself on and off, and expired rules do not linger.
Editors see the results for a query before and after a rule is applied, run against your real index, before anything goes live.
Rules are connected to your analytics, so you can look at how the KPIs of the affected queries moved after a rule went live.
Rule import, tags, separate sites for staging and production, user roles, an audit log and passkey sign-in, among other things.
Searchnik is a hosted solution. Bring-your-own-cloud and on-premises deployments are possible if your requirements call for them.
A small agent runs in your own environment and connects outward to Searchnik, so no inbound firewall opening is needed. It deploys the rule configuration to your search cluster and runs the preview queries there.
Everything the interface does is also available through an extensive API, so rule management can be scripted or connected to your own tooling.
Searchnik was written by consultants at OpenSource Connections, who bring decades of experience in search development and search management to the product. It reflects what we kept running into on client projects.
If you would like to see Searchnik, or have questions about how it would fit your setup, tell us a little about your search and we will get back to you.
You can also write to hello@searchnik.com.
Illustrative example.
A rule is built from a term, which is what the searcher types, and instructions, which are what should happen: boost, filter, add a synonym. Before it goes live you see how many queries and how much traffic it touches.
Optionally, a rule can start and end on dates you choose, so a seasonal campaign switches itself on and off.