Log WooCommerce search queries and the products they return

WooCommerce Analytics keeps search terms under the Searches tab, filterable by date and exportable as a CSV sorted by count. It shows what is popular, how volume moves over time, and which terms spike with outside traffic. For the broad picture of demand it is adequate.

GA4 adds user-level detail when site search tracking is set up: device, acquisition source, session properties. Neither shows which products appeared in a given result set. They record that a search happened, not what the customer found.

SearchWP and Relevanssi replace the search engine and come with their own reporting, including zero-result queries and sometimes conversion rates. This log is for stores on native WooCommerce search that want to see result content without buying a search upgrade.

Wrong results do not show up as zero results. Someone types 'linen shirt', gets ten cotton blouses and leaves, and to your analytics that looks like a successful search. Seeing product names beside the term is the only way to tell the difference without running every query yourself.

Zero-result searches matter too, for different reasons: either the customer wanted something you do not carry, or you carry it under a name that does not match their words. One calls for a new product, the other for renaming an existing one with the words customers use.

Each row has a timestamp, so you can see whether a failing term is a one-off or a habit. Twice with bad results is minor; forty times is lost revenue.

When WooCommerce starts building a product search, woocommerce_product_query passes the WP_Query object and the plugin keeps the search term. When WordPress assembles the results, the posts_results filter lets it record the term and what came back before returning the array untouched. That covers the shop page, category archives and the main WordPress search page when WooCommerce has it return products, which is the default.

Each row stores the time, the term as typed, the total result count and the first ten product titles, comma-separated. Ten keeps rows readable, and the count shows when there were more. The table is created on activation with dbDelta, which also handles schema changes cleanly.

WooCommerce > Search Log shows the 500 most recent searches, newest first, and Clear Log truncates the table in one step. Each search adds one database write and no front-end reads, which is negligible for most stores; on a store with thousands of searches a day, clear the log now and then.

Clicks are not captured. You see what appeared, not what the customer chose, and tying searches to purchases needs session tracking; SearchWP and Relevanssi both link queries to downstream sales.

Autosuggest dropdowns and search-as-you-type usually fire their own requests and never pass through woocommerce_product_query. If WooCommerce Product Search, Doofinder or any plugin replaces the search backend entirely, the log records nothing.

Nothing is aggregated: 200 searches for 'silver bracelet' are 200 rows. A follow-up message can add a summary tab grouping terms by frequency with their latest date and average result count, a CSV export, and the referring URL with whether the searcher was logged in.

If native search is simply wrong for your catalogue, the log will show it on almost every query and then stop being useful, because the fix is a better search engine, not a naming change. Stores with several hundred products tend to hit the limits of exact-string matching quickly. Relevanssi (with a free tier) and SearchWP (paid) rebuild the index with stemming, fuzzy matching and relevance scoring.

If you need analytics as well as better search, buy them together: SearchWP and Relevanssi Pro both include zero-result reports and frequent-query dashboards. A log on top of a search engine you plan to replace is maintenance with no lasting value.