100 Days of Elasticsearch & Woocommerce guides for WordPress & WooCommerce

In Elasticsearch, choosing between text and keyword fields directly affects how WooCommerce product data is searched, filtered, sorted, and aggregated. The distinction is especially important for agencies building catalog search, layered navigation, reporting, and integrations that synchronize products from WordPress and WooCommerce. What is a text field? A text field is designed for full-text search. Elasticsearch analyzes the value when it indexes the document. Analysis commonly includes tokenization, lowercasing, stemming, stop-word removal, or other language-specific processing. For example, a WooCommerce product title such as Organic Cotton Running Shirt might be indexed as separate terms such as organic, cotton, running, and shirt. A search for cotton shirt can then match the product even though the query does not exactly reproduce the stored title. { "product_name": {

Field types determine how Elasticsearch indexes WooCommerce data and what operations are available at query time. A product name needs full-text analysis, while a SKU must support exact matching. A price should be numeric, and product attributes may require nested documents when each attribute combination must remain associated with the correct variation. Start with the operation, not the source value The same WooCommerce value can be represented differently depending on how the store searches and filters it. Before defining a mapping, list the required operations: Full-text search: Use text for product names, descriptions, and other prose. Exact matching: Use keyword for SKUs, brand slugs, order statuses, and identifiers. Filtering and aggregations: Use keyword, numeric types, boolean, or date. Sorting: Use a numeric, date, or keyword

Define the product document before indexing A reliable WooCommerce search experience starts with a deliberate Elasticsearch document structure. Do not send the entire wp_posts row or raw post metadata and expect Elasticsearch to infer the right behavior. Build one search document per product, or per variation when customers need to search and filter variations independently. A typical product document can contain separate fields for the values customers search as text and the values they match exactly: { "product_id": 1842, "title": "Organic Cotton Crew Neck T-Shirt", "sku": "TSH-COT-ORG-BLK-M", "description": "A lightweight crew neck T-shirt made from certified organic cotton.", "short_description": "Certified organic cotton T-shirt.", "status": "publish", "stock_status": "instock", "categories": ["T-Shirts", "Organic Clothing"] } Keep the source fields in the document even if you also create a

Why the WooCommerce-to-Elasticsearch mapping matters A WooCommerce product contains much more than a name and price. It may include SKUs, descriptions, taxonomies, attributes, stock state, sale dates, images, custom fields, and multiple variations. Elasticsearch can search and filter this data efficiently, but only when the document structure reflects how customers use the catalogue. For agencies, the mapping should be designed before indexing the first product. A reliable design prevents common problems such as prices being indexed as text, category filters behaving inconsistently, and variation attributes being matched across different variants. Start with a stable product document Each Elasticsearch document should represent one searchable WooCommerce product unless the project specifically requires one document per variation. Include a stable identifier that connects the document to the WooCommerce

Start with the search experience An Elasticsearch index for WooCommerce should be designed around the queries customers and merchandisers need to run, not as a direct copy of the WordPress database. WooCommerce stores products across posts, post metadata, taxonomy tables, lookup tables, and variation records. Elasticsearch performs best when the fields required for search, filtering, sorting, and display are denormalized into a document that can be read without joining those sources at query time. Before creating a mapping, list the required operations: Full-text search across product names, SKUs, descriptions, and attributes Exact filtering by category, brand, stock status, and product attributes Numeric range filtering and sorting by price Sorting by relevance, popularity, rating, or date Variant-aware filtering for size, color, and other options Boosting products

The indexing workflow WooCommerce does not send a product to Elasticsearch by itself. An integration plugin, a custom WordPress process, or an external synchronization service must convert the WooCommerce product into an Elasticsearch document and write it to an index. A typical workflow looks like this: A product is created or updated in WooCommerce. WordPress fires product-related hooks such as save_post_product or WooCommerce-specific product update actions. The integration loads the product, its variations, taxonomies, attributes, stock data, and metadata. It transforms those values into a search document. The document is indexed using the Elasticsearch API. Search requests query the resulting index rather than the WordPress database. For large catalogs, the initial synchronization is usually performed with the Elasticsearch Bulk API. Incremental updates then keep individual

Choosing the Right Search Engine for WooCommerce WooCommerce product search often starts with WordPress and MySQL. That approach is straightforward and works well for small catalogs, but search quality and response times can decline as product counts, variations, attributes, and custom fields increase. Elasticsearch provides a separate search engine designed for fast, relevance-aware retrieval. The right choice depends on catalog size, query complexity, traffic, operational capacity, and how quickly product changes must appear in search results. How WooCommerce Search Works with MySQL In a standard WooCommerce installation, product data is stored across WordPress tables, including wp_posts, wp_postmeta, taxonomy tables, and lookup tables such as wp_wc_product_meta_lookup. A simple product search may use a query similar to: SELECT ID, post_title FROM wp_posts WHERE post_type = 'product' AND

Search Is a Revenue Feature WooCommerce search is often treated as a small theme or template concern. In a catalog with a few dozen products, the default WordPress search may be adequate. For a store with thousands of products, variations, technical specifications, or inconsistent customer terminology, search becomes a core part of the buying journey. Elasticsearch changes that experience by moving product discovery from database text matching to a dedicated search engine. Instead of relying primarily on SQL queries against post titles and content, a WooCommerce integration can index product data and search it using relevance scoring, analyzers, filters, aggregations, and typo tolerance. Why Default WooCommerce Search Struggles WordPress and WooCommerce search commonly depend on database queries that look for matching text in fields such