WordPress Search Custom Fields: How to Index ACF and Custom Post Types (YakWP 2.6.0)

For most teams, the search custom fields shortlist starts with support volume. You search your own site for a price, a location, a model number or a skill that you know is stored on the page, and you get “No results found.” The data is there. The search box cannot see it. That is the wall every directory, listing site, car dealer, job board and property site hits, and it is not a bug in the theme: it is how WordPress search is built. For background on how these systems work, see the Wikipedia entry on chatbots.

This guide explains why WordPress will not search custom fields out of the box, the three practical ways to fix it, and the free route YakWP 2.6.0 adds: indexing custom fields (ACF or plain post meta) so that both your site search and your chatbot answer from the values your content actually carries.

Pricing matters more than feature lists across search custom fields. The short answer: core search looks only at a post’s title, excerpt and body text. Custom field values live in a separate database table (wp_postmeta) that core search never touches, which is why a listing storing “48500” in a field returns nothing for “48500”. You fix it by extending the SQL query yourself, by installing a search plugin that adds metadata to its index, or by letting a semantic index read those fields and answer from them in plain language.

Why WordPress will not search custom fields

Setup effort is the hidden cost in any search custom fields decision. Core search runs one query against wp_posts. It matches post_title, post_excerpt and post_content, three columns and nothing else. WordPress does not join wp_postmeta, it does not join the term tables, and it does not read anything a page builder rendered at runtime. The moment content leaves the post body and becomes structured data, it drops out of search entirely. The WP_Query reference documents the same scope.

Data ownership decides it for regulated teams weighing search custom fields. That is a design decision, not an oversight. Custom fields are schema-free: any theme or plugin may store anything in the metadata table, including private values that must never surface in a public result list. Core cannot safely guess which keys are content and which are configuration, so it searches none of them. Even the standard post meta API is a read tool, not a search tool.

The result is a recognisable failure pattern:

• Listings and directories — the address, the floor area and the price sit in fields, while the body text says “contact us for details”. A visitor who tries to search custom fields for “two-bedroom” gets nothing.
• Car and equipment dealers — make, model, year, mileage and fuel type are fields. Someone searching “diesel automatic” sees zero results.
• Job boards — location, salary band and remote status are fields, so the search box is useless for the three things candidates care about most.
• WooCommerce beyond the product name — attributes, SKUs and custom specs sit outside the description, so “does this fit model X?” matches no page.

Every one of those is a site where visitors arrive with a filter in their head and leave with a shrug, because the search box answers with silence.

What it means to search custom fields, in practice

Two different mechanisms get called search, and the distinction decides whether your fields ever become findable.

Keyword search matches characters. It works on an inverted index of words and does exact or near-exact matching. To search custom fields this way you must copy the field value into something the index already reads: the post body, a hidden taxonomy, or the index’s own meta table. That is why the classic advice is “just put the price in the content”, and why the advice breaks the moment the value changes. Now it exists in two places and drifts.

Semantic (vector) search matches meaning. Each piece of content becomes an embedding, a numeric representation of what the text is about, and the visitor’s question is converted the same way. Retrieval is nearest-neighbour lookup, so “how much does this cost?” can land on a page that stores “1450” in a field, and “anything in Novi Sad?” can land on a page whose location is a meta value. Nothing needs duplicating into the body, which is exactly what makes semantic retrieval the practical way to search custom fields at scale.

The trade-off is worth naming early: a semantic index retrieves by similarity, not by constraint. More on that limit below.

Three ways to search custom fields on a WordPress site

There is no single right answer, only a right answer per site, depending on how much control you want and how much code you are willing to own.

Approach	How it works	Best for	Cost of ownership
Extend the core query	Hook posts_join and posts_where, join wp_postmeta, add your keys to the WHERE clause.	One or two fields, a developer on hand, exact-match needs.	You maintain every JOIN and every index; slow queries on large tables if done naively.
A search plugin	Relevanssi, SearchWP and similar build their own keyword index and can be configured to include custom field content.	Sites that want classic keyword search extended to meta.	Another plugin, its own index, and per-field configuration inside it.
A semantic index	Field values are added to the embedded text; retrieval is by meaning, and one index serves both a site search box and a chat interface.	Directories, listings, and any site where visitors ask questions instead of typing keywords.	Near zero: no SQL, no schema, works with whichever plugin stored the fields.

The manual route is worth seeing once, because it shows why so many sites give up on it. To search custom fields for a single metadata key you need a JOIN that survives core’s own query building, a prepared WHERE fragment, a guard against duplicate rows when a key holds several values, and a performance check on a table that can hold millions of rows:

// Extending core search to include one meta key (illustrative).
add_filter('posts_join', function ($join, $q) {
    global $wpdb;
    if (!$q->is_search() || is_admin()) return $join;
    return $join . " LEFT JOIN {$wpdb->postmeta} pm
                     ON ({$wpdb->posts}.ID = pm.post_id
                     AND pm.meta_key = 'listing_location') ";
}, 10, 2);

add_filter('posts_where', function ($where, $q) {
    global $wpdb;
    if (!$q->is_search() || is_admin()) return $where;
    $term = '%' . $wpdb->esc_like($q->get('s')) . '%';
    return $where . $wpdb->prepare(" OR pm.meta_value LIKE %s ", $term);
}, 10, 2);

Now multiply that by every field you care about. Five keys means five JOIN conditions and a table scan on a listing site with 50,000 posts. It works, and it is the reason a semantic index that reads any field without schema work is attractive.

Search Custom Fields: How YakWP 2.6.0 indexes custom fields

YakWP is a self-hosted AI chatbot for WordPress: bring your own model key, no monthly fee, and the conversation transcript plus the content index live in your own database. Until now it indexed post titles, bodies, pages and WooCommerce products, which meant a directory site got generic answers: the bot could describe a page, not the values inside it. Version 2.6.0 closes that gap in three parts.

• Choose your content types. A new “Indexed post types” setting lists your public custom post types beside posts, pages and products. Tick a listing, vehicle or property type and it joins the index. The core types show as “always indexed”.
• Scan and approve fields. “Scan for custom fields” inspects the published content of each indexed type and lists what it finds, with a sample value and an entry count. You tick the fields the chatbot may use, edit the label it speaks, and save. Nothing enters the index until you approve it.
• Any plugin’s fields, with real labels. Detection works at the storage level, so it reads whatever wrote the value: a builder field, a theme option, a custom meta box, or Advanced Custom Fields. For ACF the plugin resolves the genuine field label automatically instead of a prettified key, because ACF keeps a shadow record mapping each field to the label you set in the field group. The ACF field API stores values the same way, which is why the scan finds them with no configuration.

Approved fields are folded into the same text the indexer already embeds, as readable Label: value pairs, so a semantic hit carries the real value with it: a question about availability returns the listing that has an availability field, not merely one that mentions availability in prose. The same index powers the

search box, so you search custom fields on the front end too, as a live box or inside the navigation menu, and not only inside the chat widget. WooCommerce products are unchanged: price, SKU and categories are handled exactly as before.

It is free. Custom fields is a functional feature, not a cosmetic one, so it ships in the free plugin on unlimited sites, like semantic search and the search-box shortcode before it. Pro remains white-label branding, custom widget CSS, CSV conversation export and priority support.

Step by step: search custom fields with YakWP

1. Update to 2.6.0 from the downloads page, or let the built-in updater replace the installed copy. The plugin repairs its own embedding table on update, so nothing else is required.
2. Open the plugin settings and find the new Custom Fields section. If semantic search is not enabled yet, enable it first and run its index build, because custom fields are embedded by the same process.
3. Tick your content types under “Indexed post types”. The core types stay ticked; add the custom post type your listings, vehicles or jobs are stored in. Only public types are offered.
4. Click “Scan for custom fields”. The scan returns a table per content type: the field key, how many entries carry it, the label the chatbot would use, and a sample value. Re-run it after you add new fields.
5. Tick the fields you want it to answer from and rewrite any label that reads like a database key (prop_area_sqm becomes “Area (m²)”). Labels appear in the answer, so this is worth two minutes.
6. Save changes. A ticked field can be answered from; an unticked field never enters the index.
7. Let the index catch up. Newly approved fields are embedded on the next pass. The daily background job works through up to 1,000 items a day, and saving a post re-indexes that post immediately.
8. Test it by asking. Open the widget and ask something whose answer exists only in a field, such as a price, an area, a location or a model number, rather than a phrase copied from your body text.

If the values you want to search custom fields for live outside post meta, say in user meta, terms or an external table, the settings screen is not the tool. The developer filters below are.

Search Custom Fields: What happens to your existing index on upgrade

Indexed text changes in 2.6.0, so stored embeddings would be stale if they were left alone: a page indexed yesterday would keep an answer that ignores the fields you approved today. YakWP handles this with an index marker, a version string mixed into the content hash. 2.6.0 bumps that marker, every stored hash stops matching, and the plugin rebuilds automatically in the background. There is no migration step, no rebuild button to remember, and no window in which an old index serves alongside new settings.

Two practical notes. The rebuild consumes embedding requests from the same key the index already uses, so a site with a few hundred pages clears in one daily batch while a very large site takes several days. That is worth knowing before you run it on a metered key. And the rebuild is one-way: once the new index is live, answers come from the fields you approved, so if a reply looks narrower than expected, check that the relevant field is ticked before assuming the model changed behaviour.

Search Custom Fields: For developers: two filters, no forking

A plugin that indexes fields is only useful if an add-on can extend it, so 2.6.0 exposes two filters.

yakwp_indexable_post_types controls which types enter the index. This matters when another plugin registers the content type and you want to search custom fields on it without touching either plugin’s code, or when a type should be indexed but not listed in the settings UI:

add_filter('yakwp_indexable_post_types', function ($types) {
    $types[] = 'estate_listing';   // register an add-on's CPT
    return array_values(array_unique($types));
});

yakwp_fact_line_parts receives the assembled fact line, the Label: value pairs embedded with each item, plus the post ID, so you can add computed values that are not stored as meta at all: a formatted price range, a joined taxonomy value, a value from a custom table, a translated label.

add_filter('yakwp_fact_line_parts', function ($parts, $post_id) {
    $range = get_post_meta($post_id, 'price_min', true)
           . ' - ' . get_post_meta($post_id, 'price_max', true);
    if (trim($range) !== ' - ') {
        $parts[] = 'Price range: ' . $range;
    }
    return $parts;
}, 10, 2);

Both filters return arrays, both run through the same code path as the settings screen, and neither requires the field to appear in the scan table. The settings screen covers site owners, the filters cover agencies and plugin authors, and neither path is a fork.

What indexed custom fields still cannot do

This is worth stating plainly, because it is the expectation people bring to the feature: indexing makes values searchable and answerable, it does not make them filterable.

A semantic index retrieves the closest matches to a question and returns the top few. It applies no numeric or set constraint, so “show me flats under 50,000” retrieves listings that mention a price near that range, not the set of listings that satisfy the inequality. The chatbot quotes a price from a field accurately and then honestly says it cannot filter the catalogue by range, because the retrieval layer has no way to execute that comparison. Turning answerable values into filterable ones needs a typed table and a SQL path. That is separate work, and this release does not claim it.

Two smaller boundaries: field values are treated as text and capped in length, so a repeater or builder blob is flattened into a readable summary rather than indexed field by field; and only scalar values are used, so a field holding a serialised object contributes nothing instead of a garbled string.

Privacy: which fields get indexed, and which never do

This is the part to get right before you tick anything, because a chatbot answers publicly.

The scan never proposes a field whose key starts with an underscore. That prefix is WordPress’s own convention for hidden metadata, and it is where the sensitive values live: _billing_email, _customer_user, _price, _edit_lock. Keys ending in _id or _ids, keys holding a single distinct value, and anything longer than 300 characters are filtered out of the scan as well, since those are references and internal configuration rather than content. A field that survives the filter is still only indexed once you tick it, so the default state of every field is invisible to the bot.

On data flow, precisely: the transcript and the content index are stored in your own WordPress database, and you choose the model provider that answers. The prompt itself, your visitor’s question plus the retrieved facts including approved field values, is sent to that provider, because a model has to receive the question to answer it. So self-hosted means the index and the conversations stay with you; it does not mean the prompt never leaves your server. If a value should never reach an outside model call, do not tick it, because no amount of theming changes that arithmetic.

One more consequence: a chatbot has no access control. Anything you index becomes answerable to anyone who can use the widget, so internal notes, supplier costs and unpublished pricing belong in fields you leave unticked, or in a content type you never add to the index.

How to Choose the Best Search Custom Fields

Start with the workflow you want to automate, then shortlist search custom fields that connect to it without middleware. The search custom fields that look best in a demo are not always the ones your team keeps using after the first month.

Score each option against three numbers: cost per resolved conversation, hours of setup, and who owns the conversation data. Those three numbers eliminate most of the search custom fields on a long list far faster than a feature matrix will

.

To summarise, the search custom fields that fit your team are the ones you can operate without a dedicated engineer. Pick from the search custom fields above by matching one constraint first: budget, data ownership, or setup time. Whichever of the search custom fields you choose, budget an afternoon for testing real conversations before committing. Revisit your search custom fields shortlist every quarter, since pricing and model line-ups on this list change often.

FAQ

Does WordPress search custom fields by default?

No. Core search matches only post_title, post_excerpt and post_content. Field values sit in wp_postmeta, which core search never queries, so a value stored in a field returns no results however exact the search term is.

How do I search custom fields on a site that uses ACF?

In YakWP 2.6.0, open the plugin settings, tick the content types your ACF field group belongs to, run “Scan for custom fields”, and tick the ACF fields you want the chatbot to answer from. ACF labels are detected from the field group, so the chatbot speaks the label you defined instead of the meta key. Save changes and the fields enter the index on the next pass.

Which custom fields should I index?

Only the ones a visitor would reasonably ask about: prices, sizes, locations, availability, model numbers, ratings and key specs. Leave internal notes, supplier data, customer identifiers and anything stored under an underscore-prefixed key out of the index. The chatbot answers publicly, with no per-visitor access control.

Does indexing custom fields slow my site down?

The index is built by a daily background job, up to 1,000 items a day, and by a single item on post save, never on page views. Front-end search reads a stored index rather than the metadata table, so no visitor request joins wp_postmeta, and the search box throttles per visitor to protect your embedding quota.

Do I need ACF to use this feature?

No. Discovery works at the storage level, so it finds fields written by any plugin or theme, including a custom meta box, a page builder or an import routine, and falls back to a readable version of the key when no label exists. ACF users simply get better labels for free.

Is custom-field indexing a paid feature?

No. It ships in the free YakWP plugin, on unlimited sites, together with semantic search, the search-box shortcode and lead capture. Pro covers white-label branding, custom widget CSS, CSV export and priority support. You still bring your own model key, whether Google Gemini, OpenAI or OpenRouter, so usage is bounded by your own provider quota.

Can the chatbot filter listings by price range?

Not on this release. It answers from field values accurately and quotes a price it retrieved, but retrieval works by similarity rather than numeric constraint, so “under 50,000” cannot yet be executed as a filter. Typed filtering is planned as separate work and is not claimed by 2.6.0.

Getting started

If your site has content that lives in fields, whether listings, vehicles, jobs, properties or equipment, the fix is now a settings screen rather than a development project. Update to 2.6.0 from the downloads page, add your content types, approve the fields that describe what you sell, and ask the widget a question only a field can answer.

Worth reading next: how semantic search answers the questions keyword search drops, the built-in search box introduced in 2.5.0, and the documentation for step-by-step configuration. The full record of each release is on the changelog, and the pricing page explains what stays free and what Pro adds.