← Meilisearch for WordPress: A Complete Guide
Should you use a plugin or build it?
Two plugins connect Meilisearch to WordPress without custom code: Yuto and Scry Search. Between the two, check which is actively maintained before you install either; plugin abandonment is a real risk in this niche. Build a custom integration if neither plugin’s approach fits how you want search to work, or your content model is complex enough that a general-purpose plugin can’t index it the way you need.
Yuto and Scry Search: two different plugins
Yuto adds a Meilisearch-powered autocomplete block and shortcode ([yuto_autocomplete]) alongside your existing search, with WooCommerce and custom post type indexing, typo tolerance, synonyms, and faceted filtering, plus WP-CLI commands for indexing. It’s a widget you place, not a replacement for WordPress’s native search. As of this writing, it has real red flags: the plugin was last updated 11 months ago, its support forum shows 0 of 1 issues resolved in the last two months, and the developer’s own website (ponopress.com) currently resolves to a suspended-account page. It’s still listed on WordPress.org and installable, but verify its status yourself before relying on it for a production site.
Scry Search takes a different approach: it’s a drop-in replacement for WordPress’s native search, intercepting your existing search forms, widgets, and page-builder search elements (Elementor, Divi, Beaver Builder) and routing them through Meilisearch with no theme changes. It indexes each post type into its own Meilisearch index (including WooCommerce products and custom meta fields), merges results across indexes with per-type search weights, and gives you a drag-and-drop admin UI for ranking rules, synonyms, and stopwords, no code or Meilisearch config files required. It also ships its own search analytics dashboard and a task/debug log for indexing operations, either self-hosted or via its own managed ScryWP Search hosting. As of this writing, it’s actively maintained (updated 3 weeks ago, 4 of 4 support issues resolved in the last two months), though it’s a newer, smaller project than Yuto (30+ installs and one published review, versus Yuto’s 70+ installs and six). It doesn’t mention WP-CLI support.
Where a plugin hits limits
Yuto’s autocomplete-widget approach means you’re adding a search box, not replacing WordPress’s search behavior; there’s no indication it indexes WooCommerce variations or ACF fields specifically. Scry Search closes most of that gap (per-post-type indexing, custom meta fields, native search replacement) but is young enough that its long-term track record isn’t established yet, and it doesn’t offer Yuto’s WP-CLI indexing.
More generally, any plugin makes a set of decisions for you: what gets indexed, how ranking works, what the frontend looks like. When those decisions don’t match your content model, or you need a search experience neither plugin’s model supports (a fully custom instant-search UI independent of native search templates, for instance), you’re limited to what the plugin exposes through settings, not what Meilisearch itself is capable of.
What a custom integration owns
A custom build is a system with four pieces: an indexer (a hook on transition_post_status, or WooCommerce’s product save/update actions, that pushes documents to Meilisearch), the document shape (deciding exactly which fields, taxonomies, and meta get indexed), a WP-CLI command for bulk reindexing, and a frontend that queries the Meilisearch API directly with whatever filtering and facet UI the site actually needs.
That’s roughly 100-150 lines of PHP for the indexer on a typical content model, plus whatever the frontend requires. You own every part of it, which means you can index anything WordPress knows about, design the results page however the project needs, and aren’t exposed to a plugin going unmaintained under you.
Cost and maintenance tradeoff
Both plugins are free beyond the Meilisearch instance itself and take an afternoon to configure, but “free” isn’t the same as “no risk”: an unmaintained plugin (Yuto, currently) is a liability you inherit silently. A custom build costs development time upfront and ongoing maintenance: when your content model changes, someone updates the indexer and reindexes, but that someone is accountable to you, not an abandoned repository.
The plugin is the right call when your site’s search needs fit what an actively maintained one already does. The custom build is the right call once your content model, your desired frontend, or your catalog’s complexity outgrows what either plugin decides for you. See Meilisearch and WooCommerce for how this plays out specifically for product search.
Talk to 84EM about a custom Meilisearch integration if a plugin’s decisions don’t fit your project.
