Who this is for. The technical lead deciding, with the client, whether a site's search stays on the platform or moves to a separate engine. Afterwards you can name the requirement that forces the move, or show that the built-in index meets it.
What the built-in index does not do
The built-in index is Elasticsearch, configured by the platform for the common case and managed with it. Its edges, each met on an earlier page of this guide:
- A fixed set of record types. Pages, blogs, blog posts, FAQ questions and product descriptions, and books on releases after 2026.8.1. Custom entity records, orders, people and files are never in it (What gets indexed).
- Public content only. Records a signed-out visitor cannot read are never indexed, so a search that must respect each member's permissions cannot use it.
- Fixed English analysis. No synonym list, an English stop-word list that cannot be edited, English stems whatever the site's language (The limits).
- Simple scoring. Field weights and the view's query settings; no per-record boost, no date decay, no learning from clicks.
- Limited typo tolerance. One or two wrong letters per word, and none at all on a Match phrase view, which cannot be combined with fuzzy search.
- Exact filters, capped counts. No range filters, counts that stop at 10,000, no results past the 10,000th, and facets with counts only for products.
The decision
These are the factors, not a recommendation either way. The built-in index is the right answer until one of them is clearly true, because a second engine doubles the moving parts.
| Lean towards an external engine when | Stay with the built-in index when |
|---|---|
| The catalogue is very large and relevance has to be measured and tuned beyond field weights | Field weights and minimum should match get the common queries right |
| Synonyms, typo tolerance beyond a letter or two, or ranking that learns from clicks are central to the experience | Stems and fuzzy matching are enough |
| Several languages each need their own analysis | The site is in one language, or English carries it |
| Search must cover data the index does not hold, such as custom entity records, or respect each member's permissions | The indexed types cover what people search for |
| A hosted search product, with its own interface and analytics, is part of the brief | The site's own search page and its analytics are enough |
Count the cost before deciding: a second service to run and pay for, credentials to keep, a search page that calls it, and the synchronisation that keeps it current, to build and to monitor. A hosted product removes the hosting, not the synchronisation. If the honest answer is that the built-in index is most of the way there, the rest is usually cheaper as better mapping and weights than as a new system.
Keeping an external engine current, by pushing every change from record events and catching what the push missed with a scheduled job, is on Keeping an external index in sync.
The push, a job on record events, is on Push from record events.
The scheduled reconciliation is on The reconciliation job.