Enterprise WordPress search that ranks by relevance, not by date

No, but VIP is the shortest path. Enterprise Search there runs on Elasticsearch, managed by Automattic, so no one on your side or ours operates a search cluster.

Off VIP the engine changes. SearchWP gives finer control over what is indexed and works well on self-managed hosting, though it is not VIP compatible. Algolia is a hosted option for non-VIP sites, and we have not used it on a client project yet. The interface layer stays the same either way.

Site search answers a typed query. Faceted search serves the visitor who does not know the right word yet, and lets them narrow a list by attributes you already store: content type, industry, publication year, author, region.

Most enterprise libraries need both, and the first decision is which one a given page is for. Someone who wants to search, someone who wants to explore and someone who wants to filter need different interfaces. Trying to serve all three with one input is how search pages end up satisfying nobody.

More than most teams expect. Facets are made out of structure, so if everything is a generic post there is nothing to filter on. Before the search build starts we need:

• Custom post types and taxonomies defined, not improvised during the build.
• ACF fields specified, with a decision on which ones get indexed.
• A layout for results and filters, since Enterprise Search ships without a front end.
• Hosting that supports the engine you have chosen.

This is why advanced search normally follows content architecture instead of running alongside it.

The engine indexes whatever your content model exposes, so multilingual and multisite search is largely a question of specification: which sites share an index, which filters appear where, and how a language is represented in the data.

Those decisions belong in the requirements phase, not in a retrofit. How content itself is structured across languages is covered on our multilingual page, and the search layer inherits whatever that structure decides.

By indexing less than you think you need. Every additional indexed field costs performance, so the index is a deliberate list rather than a copy of the whole content model.

The rest is practical. Use the search plugin’s own query instead of a standard WP_Query so the two do not fight each other, and keep heavy filtering off the front end.

Our internal QA target for response time is under 500 milliseconds, checked alongside combined filter behaviour, mobile and cross-browser results. That is the threshold we accept work against, not a benchmark measured on a client platform.