FullText Search for WP: A Community Plugin

For years, people have said that WordPress search “just sucks.” In wp-admin, they are right more often than they should be. But with all the tools we have available today, why don’t we just fix it?

FullText Search for WP is my attempt to close that gap as a community project. It is not a product launch. I am not trying to win customers. I want wp-admin search to behave like a tool we can trust and extend together, and I hope this plugin gives the community something concrete to push on.

You can read the code and docs here: FullText Search for WP

FullTExt Search for WP

By Roots-and-Fruit

Star 15

Fixes WordPress admin search. Find posts by tag, custom field, or SKU — not just title and content.

• Last Update 08-08-2026
• Subscribers 1
• Forks 0

What WordPress admin search does today

Every search box in wp-admin that uses the default query is doing roughly the same thing for posts:

• Look at post_title, post_content, and post_excerpt
• Run LIKE '%term%' on those three columns
• Ignore post meta, taxonomies, and most of the structure that actually carries meaning
• Run on columns with no dedicated search index

For small sites, this feels rough but tolerable. For anything larger, it becomes both slow and unreliable.

Maybe you stored a WooCommerce product SKU and tagged it well, but when you search for the product you only find things related to the title and content. SKUs are a big deal in ecommerce. They should be searchable.

Maybe you track events with dates, locations, and regions in custom fields, but you cannot find “Seattle” unless it appears in the body content.

Maybe your team relies on tags, product attributes, or user profile fields to organize work, but the admin search box still acts like none of that exists.

Over time, teams work around these things. They memorize IDs or build extra menus. They rely on WooCommerce or other plugins to bolt on their own search experiences. The default admin search keeps falling behind what a modern MySQL or MariaDB database can actually do.

Why FullText Search and Indexing Matters

When people hear “better search,” they often picture a complicated syntax with special operators. FULLTEXT is not that. In MySQL and MariaDB, FULLTEXT search is designed for natural language queries. You type words the way you would normally type them, and the engine scores each row based on relevance.

That relevance scoring matters. Instead of asking, “does this field contain these characters,” FULLTEXT asks a better question: how much does this row actually match what the person is looking for? Short titles with strong matches tend to rise. Long bodies with weak matches fall behind. You get ranking instead of a flat pile of partial matches.

Indexing is what makes that possible. A proper index is a precomputed structure the database can use to answer questions quickly. Without it, every search becomes a sweep across raw rows. On a typical WordPress site, that means scanning titles and content over and over with LIKE, and almost never touching post meta at all.

Post meta is where a lot of real meaning lives: SKUs, event dates, regions, internal IDs, feature flags. With a naive LIKE query, every new meta field becomes another join and another place to search. That does not scale well. A dedicated index table lets you collect all of that text in one place, build a FULLTEXT index on it, and let the database do what it is good at.

You can see this most clearly in the “Meta Value” search benchmark here:

In the test data, “chartreuse” only appears as a color meta value. Core search finds zero posts for that term, because it never looks at post meta. The FULLTEXT index finds eighty-three posts instead, with the same simple query a human would type into the admin search box. No special operators, no syntax to learn, just natural language search over an index that actually includes the fields where your data lives.

There is a fair objection here, and WordPress VIP makes it explicitly. They recommend against adding FULLTEXT indexes directly to WordPress core tables. In their world, that makes sense. If you add a FULLTEXT index straight onto a large, busy wp_posts table, every write has to maintain that index too. On high-traffic enterprise sites, that can hurt overall database performance.

That is not what this plugin does.

FullText Search for WP uses a separate dedicated index table. It does not alter wp_posts or try to hang a massive FULLTEXT index directly off core tables. That isolates the search workload from the main content tables and makes the tradeoff much more practical for normal WordPress sites. If you are running an enormous media property with Elasticsearch infrastructure, WordPress VIP is right to point you there. But for the large middle of the WordPress ecosystem, there is a very reasonable space between “do nothing” and “stand up a separate search stack.”

When FULLTEXT is not available, for example on SQLite in Studio or Playground, the plugin falls back to LIKE queries on the denormalized index table. That is still better than default behavior because it still includes meta and taxonomies without stacking more complexity onto the core query.

The point is not to invent a search engine. The point is to give wp-admin a sane index that matches how people already store data in WordPress.

And it’s fast

The benchmark script that ships with FullText Search for WP creates 500 posts with real block content, tags, categories, and custom meta fields, then runs the same queries through core search and the FULLTEXT index. At that scale, MySQL can still brute-force LIKE in a few milliseconds, so the most useful speed comparisons are the ones where both approaches return the same result counts.

Two examples stand out.

For the query “Infrastructure,” core returns 150 results in 6.2 ms. FullText Search for WP returns the same 150 results in 2.8 ms. That is more than twice as fast on the same dataset.

For the query “kubernetes,” core returns 62 results in 4.7 ms. FullText Search for WP returns the same 62 results in 3.7 ms. The gap is smaller, but the indexed search still wins while returning the same result count.

Across all six sample queries, total time is close: 25.7 ms for core and 23.6 ms for FullText Search for WP. At 500 posts, that is exactly what you would expect. LIKE is still cheap at small scale, and FULLTEXT has some overhead. The more important point is that the indexed approach is already faster in the cases where the result set is the same, and that advantage grows as the table gets larger. Once you reach thousands of posts, core search becomes a full table scan, while the FULLTEXT path stays an index lookup.

Just turn it on and it works

Today, FullText Search for WP is something you can activate and use right away. You might not even notice it is on until you experience the results. The only visible sign is a small admin bar notice that tells you the state of your index and gives you a manual reindexing option.

In practice, it becomes the machine behind a lot of places you already use inside wp-admin:

• Posts and Pages list tables: searches include tags, categories, and public custom fields, with title matches ranked higher.
• Block editor link search: the plugin replaces the REST search handler so link lookup uses the same index and relevance rules.
• Users list table: searches include first_name, last_name, nickname, bio, and WooCommerce billing fields when WooCommerce is active.
• WooCommerce products: searches can match SKU, GTIN, categories, tags, and attribute values like size and color.

Under the hood, the index stays in sync incrementally. Post saves, deletes, term changes, and meta changes update the relevant rows. User registration, profile edits, deletion, and user meta changes do the same for users. There are also WP-CLI commands to inspect index health, rebuild it when needed, and run searches directly.

I also found the existing Full-Text Search plugin by ishitaka while building this. It is solid work, but it takes a different path. It is aimed primarily at frontend search, hooks in later through WP_Query, and focuses on titles, content, excerpts, and document parsing. That makes sense for its goals.

This plugin is aimed at the admin experience first. It searches its own index table, hands IDs back to WordPress, and puts much more emphasis on post meta, taxonomy terms, user data, and WooCommerce-specific fields. That is the gap I cared about most. I did not want a better frontend search box. I wanted wp-admin search to understand the kinds of data modern WordPress sites actually use.

It is also designed to be extended by other plugins. Public meta is indexed by default. Private meta can be allowlisted. Taxonomies can be excluded. User meta keys can be added. Relevance can be tuned. Cache behavior can be adjusted. These are small extension points, but they matter. They let a membership plugin, an events plugin, or a CRM plugin say, “these fields carry meaning in my world, please make them searchable.”

If you are comfortable with WordPress hooks, none of this should feel strange. The goal is for it to be invisible in the best way possible.

What success looks like and how you can help

I am not trying to build a business around this. I do not want people choosing “my search plugin” over someone else’s. What I want is for wp-admin search to become something useful, not an embarassment.

In practice, success could look like plugin authors adding a few lines of code so their key meta fields are part of the index. It could look like agencies and site builders feeling comfortable installing this on client sites because it behaves like core, not like a bolt-on product. It could look like core contributors looking at these patterns and deciding which parts belong in a broader solution.

Ultimately, I would love to see this become a Canonical plugin, or better yet, a step toward something that lands in core.

If you want to help move this forward, install FullText Search for WP in a development or staging environment and run the searches you actually care about. Open issues or pull requests with concrete bugs, ideas, and integration examples. If your plugin stores important data in meta or user fields, try hooking into the filters and see what the experience feels like.

We have had FULLTEXT in MySQL for more than thirteen years. WordPress has the hooks, the APIs, and the community to use it well. FullText Search for WP is not revolutionary, it’s just the next right step in the right direction.