← Meilisearch for WordPress: A Complete Guide
Is Meilisearch good for WooCommerce?
Yes, when catalog size or product complexity makes WordPress’s default search too slow or too shallow. Meilisearch indexes product data separately from your database and returns typo-tolerant, ranked results in milliseconds. The setup cost is real: you need an indexer that keeps Meilisearch in sync with your catalog, and there’s no mature InstantSearch-style frontend built specifically for WooCommerce.
What off-the-shelf connectors miss
Default WooCommerce search covers product name and description. That’s thin for stores with variations (size, color, material), custom taxonomy, or product data stored in ACF or other custom fields. Shoppers searching by an attribute that lives outside the title won’t find the product.
Two plugins narrow that gap, to different degrees. The Yuto plugin adds a Meilisearch autocomplete widget alongside WooCommerce, with custom post type support and typo-tolerant, faceted results, but its documentation doesn’t spell out variation-level or custom-field indexing, and (as of this writing) it hasn’t been updated in 11 months. Scry Search goes further: it indexes WooCommerce products into their own Meilisearch index, including custom post meta fields, and replaces native WooCommerce search directly rather than adding a separate widget. It’s actively maintained, but newer and smaller than Yuto. See plugin vs custom build for the full comparison, including each plugin’s maintenance status.
Indexing a WooCommerce catalog correctly
A correct build indexes each product (or each variation, if your store needs attribute-level search) with the fields that actually matter to a buyer: title, description, price, stock status, category, brand, and any custom taxonomy or meta your store uses to differentiate products. The indexer hooks into WooCommerce’s product save/update/delete actions and pushes the current state to Meilisearch, the same pattern as a standard post indexer but scoped to product and its variations.
Stock status matters more here than on a content site. Sold-out or discontinued products need to drop out of results or get flagged, not sit in the index as if they’re purchasable.
The frontend
There’s no first-party InstantSearch library built specifically for WooCommerce and Meilisearch, but the plugins take different approaches to the gap: Yuto adds a separate autocomplete widget you place on the page; Scry Search intercepts your existing search forms, widgets, and page-builder search elements so the storefront’s frontend doesn’t change at all. A custom frontend gives you full control over filtering and facets beyond what either plugin’s UI exposes.
Plugin vs a custom build
Yuto and Scry Search are both legitimate starting points if you want WooCommerce search working without writing an indexer, with real tradeoffs between them: Yuto has WP-CLI and Elementor shortcode support but hasn’t been updated in 11 months; Scry Search is actively maintained and replaces native search directly, but is newer and doesn’t offer WP-CLI.
A custom build makes sense when your catalog needs attribute- or variation-level search neither plugin confirms, when you want a fully custom results UI, or when your product data model is complex enough that a general-purpose plugin can’t index it the way you need. See Meilisearch on WordPress: plugin vs custom build for that decision in full.
Talk to 84EM about a custom Meilisearch build for WooCommerce if your catalog has outgrown what a plugin can index.
