Radar.

The pitch

Everything Radar does

A self-hosted search engine inside WordPress — no SaaS, no per-query fees, no sending your content to someone else's index.

Chapter 1

Why WordPress search fails (and what to build instead)

Core WordPress search is one SQL query: WHERE post_title LIKE '%term%' OR post_content LIKE '%term%'. No ranking — a passing mention in paragraph nine ties with an exact title match. No tolerance — "optimise" never finds "optimize". And LIKE '%…%' can't use an index, so every search scans every row.

The fix is the same one every real search engine uses: an inverted index. Instead of scanning documents for words at query time, you store words → documents at index time. Searching becomes an indexed lookup plus a relevance sort. That's Radar in one sentence; the next seven chapters are the details.

Chapter 2

The index: tokenise once, search forever

When a post is saved, Radar tokenises it: lowercase, strip markup, split on word boundaries, drop stopwords and anything shorter than the minimum length, then write one row per term-occurrence with its source field and weight into wp_aisearch_index.

term        post_id   field      weight
─────────────────────────────────────────
"prompt"    142       title      10
"prompt"    142       content    5
"prompt"    98        excerpt    7
"theory"    142       title      10

-- query "prompt theory" → two indexed lookups,
-- SUM(weight) per post, ORDER BY score DESC. Done.

Indexing happens on save_post and delete_post hooks so the index tracks your content automatically, and the Tools tab has a one-click full reindex (batched, so big sites don't time out). The Content Sources tab decides what gets indexed: which post types, which taxonomies, which custom fields.

Chapter 3

Relevance weights: the editorial dials

Relevance is opinion encoded as arithmetic. Radar's defaults encode a sensible one — a title match outranks a content mention two-to-one — but every weight is a dial in the admin:

'title'        => aisearch_get_setting( 'weight_title',        10 ),
'excerpt'      => aisearch_get_setting( 'weight_excerpt',       7 ),
'content'      => aisearch_get_setting( 'weight_content',       5 ),
'taxonomy'     => aisearch_get_setting( 'weight_taxonomy',      4 ),
'custom_field' => aisearch_get_setting( 'weight_custom_field',  3 ),

A post's score for a query is the weighted sum of its matching terms. Run a documentation site? Crank custom-field weight for your product SKUs. News site? Boost taxonomy so topic pages surface. The Weights tab makes search behaviour an editorial decision instead of a developer ticket.

Chapter 4

Synonyms & stopwords: speaking your visitors' language

Your visitors don't use your vocabulary. They type "wp" when your posts say "WordPress", "ai" when you wrote "artificial intelligence". Radar keeps a synonym dictionary in its own table — at query time, search terms expand through it, so either word finds both posts.

Stopwords work the opposite direction: "the", "and", "is" appear in every post, so indexing them costs space and ranking noise while helping nobody. The stopword list ships with sane defaults and is fully editable — one word per line in the General tab, applied at both index and query time so the two sides always agree.

Chapter 5

Live search: results before they finish typing

The front-end widget listens to the search box, debounces keystrokes (no query per letter), and hits a lightweight AJAX endpoint that returns the top N results — title, thumbnail, snippet — rendered in a dropdown. Because the inverted index makes each query cheap, live search doesn't melt the server the way LIKE-based "instant search" plugins do.

Everything degrades gracefully: no JavaScript means the form submits normally to the (Radar-powered) results page. Keyboard navigation, escape-to-close and click-outside handling are all in the public JS — the unglamorous details that make it feel native.

Chapter 6

Taking over WordPress search — politely

The takeover is one filter: when a search query runs and "Replace default WP search" is on, Radar intercepts pre_get_posts, runs its own ranked query, and hands WordPress the ordered post IDs via post__in. Your theme's search template, pagination, highlighting — all untouched. The results are just right now.

That one-toggle reversibility is the design principle: turn Radar off and core search is exactly as it was. No template overrides, no rewrite rules, no lock-in. The related-content module reuses the same index — "posts sharing weighted terms with this one" — which is precisely what a related-posts widget should be.

Chapter 7

Search analytics: your readers tell you what to write

Every search is logged: the query, the result count, the timestamp. The Analytics tab turns that into the two lists every content strategist wants:

1. Top searches — what your audience actually wants, in their own words. Free keyword research from people already on your site.
2. Zero-result queries — searches that found nothing. This is a literal, prioritised content-gap list: people came looking for it, and you don't have it yet. Feed it to Engine and close the loop.

Logging is privacy-light by design: queries and counts, no user identification — enough to inform strategy without surveilling readers.

Chapter 8

Shipping it — including the scars

And the standing checklist: prepared statements for every index and query operation, nonces and capability checks on admin AJAX, escaped output in result templates, translation-ready strings, and a clean uninstall that drops the index tables — gated, as Chapter 8 of every guide in this series now reminds you.

Make it yours

Rebrand it. Seriously, we encourage it.

The rename map for Radar — change these consistently and nothing breaks: