Relevanssi writes every indexed term into wp_relevanssi with the post ID and term frequency, and every front-end query into wp_relevanssi_log with the search string and result count. The plugin's settings page summarises counts (total indexed posts, longest queries, common stop words) but the actual rows live in tables you can only inspect with phpMyAdmin or hand-rolled queries against term frequency, post ID, and last-query timestamp.

SleekView turns the two tables into a single sortable grid with one row per indexed term: ID, term, post ID, term frequency, last queried, status. The columns come straight from the schema Relevanssi already maintains, so no extra writes and no second store. A row for cancellation that maps to post ID 0 with TF 0 is a missing-content signal; a row for headless that maps to post ID 904 with TF 12 is a properly indexed, frequently queried term. Both rules are visible in the same grid, which is the comparison Relevanssi's own UI does not surface.

The Status column is what closes the loop between the index and the log. Relevanssi can tell you how many posts are indexed, but it cannot tell you which queries returned no matches because the term is missing entirely versus which returned nothing because the search engine excluded the post type. Joining the two tables manually answers that; the grid answers it as a sortable, filterable column. Editors finally see the cancellation-from-yesterday zero-result without anyone running a query.

Relevanssi's reputation rests on doing better search than core WordPress, and it earns that reputation by maintaining its own term-frequency index and recording every query users run. Both datasets are gold for content strategy: term frequency tells you what the corpus actually weights, and the search log tells you what users actually want. The problem is that the value is locked away because both tables are inspectable only through SQL.

Editors who would benefit most from the no-match query report do not have wp db query in their workflow, and asking engineering for a weekly export is fragile. SleekView removes the SQL barrier without changing what Relevanssi does or how it indexes. The grid is read-only against the same tables Relevanssi writes; the moment Relevanssi adds a row, the grid sees it.

That changes how often the data gets used. A weekly engineering-run export becomes a daily editor-run filter, which is the difference between content strategy that responds to user intent and content strategy that guesses at it. Stop word tuning and language-specific index quirks become first-class workflows instead of one-off investigations.