Meta Box + AI Search: Making Custom Fields Searchable in WooCommerce

Meta Box is one of the most popular custom-fields frameworks in the WordPress ecosystem — fast, developer-friendly, and a natural choice for shops that need to model rich product data beyond what core WooCommerce gives you. The question that comes up the moment you pair it with an AI search plugin: *will my Meta Box fields be searchable?*

Short answer: standard product and post information is searchable automatically. Values stored in custom Meta Box fields aren't included in the search index yet — that's planned for Queryra v1.3. Until then, three simple workarounds cover almost every case, and the easiest takes about two minutes with zero code.

This post explains exactly what works today, why custom fields are a separate problem, and how to bridge the gap. The same pattern applies to ACF, Pods, JetEngine, and any other plugin that stores custom values in wp_postmeta.

When you install Queryra alongside Meta Box, no configuration is required for the bulk of your content. Here's what gets indexed automatically:

• Post title, content, and excerpt — the standard WordPress fields every theme renders
• Product short description, price, stock quantity, SKU, and featured image
• All WooCommerce product attributes — both global attributes from Products → Attributes and custom per-product attributes
• Categories and tags — including hierarchical product categories
• Brand taxonomies — detected automatically across the major brand plugins: product_brand from WooCommerce native (since WooCommerce 9.4), yith_product_brand from YITH WooCommerce Brands, and pwb-brand from Perfect Brands for WooCommerce

Re-indexing happens whenever WordPress fires the save_post action — which is whenever any post is saved, including from Meta Box's editor UI. Meta Box itself doesn't fire save_post; it hooks into it (just like Queryra does). The takeaway is the same either way: you don't need a separate sync trigger for Meta Box, the standard WordPress save flow handles it.

A narrower point worth being precise about: if a Gutenberg block writes a Meta Box value into post_content as rendered HTML at save time, that value is searchable — Queryra reads stored post_content directly. Values rendered at request time aren't: a <?php echo rwmb_meta('field'); ?> call in a theme template, a the_content filter that injects the value on display, or a [rwmb_meta key="…"] shortcode in the post body — none of those land in stored post_content. (The shortcode body itself is in post_content as literal text, but Queryra doesn't expand shortcodes during indexing.) For all of these, use one of the workarounds below.

Here's the honest part: if you create a Meta Box field — say a material text field, or a country_of_origin select — and the value lives only in wp_postmeta, it's not in the search index in v1.2.

This isn't a Meta Box-specific limitation. It's the same situation for ACF, Pods, JetEngine, and any other plugin that uses postmeta. The reason is intentional: Queryra's current indexer reads the published content surface (title, content, excerpt, attributes, taxonomies). Postmeta is a flat key-value store with no schema, used by hundreds of plugins for hundreds of unrelated purposes — order data, SEO meta, layout settings, internal flags. Indexing it blindly would inflate the embedding noise and degrade search relevance for the things people actually search for.

The v1.3 plan (more on that below) introduces an opt-in whitelist so you pick exactly which custom fields enter the index, per content type. Until then, three workarounds:

This is the easiest option and requires zero code. Meta Box ships with a built-in field type called Taxonomy — instead of storing values in postmeta, it stores them as terms in a real WordPress taxonomy.

When you set up the field in Meta Box, choose taxonomy as the field type and point it at one of the searchable taxonomies. For most cases, product_tag works perfectly — every value you fill in becomes a regular tag, which Queryra already reads.

This is the right fit when your field has a finite list of values: Cotton, Wool, Linen, Polyester for a material field. The editor experience is the same as a select dropdown, and search Just Works.

Trade-off: if your value is free-form text (a paragraph of marketing copy, for example), a taxonomy field isn't the right model. For those, see workaround 3.

If your field is product-specific — Color, Size, Material, Pattern, Capacity — define it as a WooCommerce attribute under Products → Attributes instead of as a Meta Box field. WooCommerce attributes are first-class taxonomies (pa_color, pa_size, pa_material...) and are indexed automatically.

You get more than just searchability:

• Built-in attribute filtering on shop and category pages
• Layered nav widget support
• Display on the product page from one place
• Variation support out of the box if the attribute is variation-relevant

Trade-off: WooCommerce attributes are products-only. If you need the field on posts, pages, or a custom post type, this doesn't apply — fall back to workaround 1 or 3.

When you want the editor experience of a regular Meta Box text or select field but also want the value searchable, the cleanest pattern is to mirror it to a product_tag term whenever the field is saved. Meta Box exposes rwmb_after_save_post for exactly this kind of post-save logic.

Here's a minimal version that copies a material field to product_tag:

add_action('rwmb_after_save_post', function ($post_id) {
    if (get_post_type($post_id) !== 'product') {
        return;
    }

    $material = rwmb_meta('material', [], $post_id);

    // Field cleared — leave existing tags untouched.
    // (Don't call wp_set_object_terms with [] here — that would wipe ALL tags.)
    if (empty($material)) {
        return;
    }

    // Append, don't overwrite — preserves other tags on the product.
    wp_set_object_terms($post_id, (array) $material, 'product_tag', true);
}, 10, 1);

A few things worth flagging in this snippet:

• The empty($material) early return is intentional. A naive version that calls wp_set_object_terms($post_id, [], 'product_tag') when the field is empty would delete every tag on the product on every save. That's a data-loss bug. The early return preserves whatever's already there.
• The fourth argument true to wp_set_object_terms means append. Without it, the function replaces all tags in that taxonomy with the new set, which would wipe tags from other sources.
• The get_post_type guard prevents the hook from running on posts and pages where product_tag isn't relevant.

One important timing note: Queryra's auto-sync also hooks into save_post, and the order in which save_post callbacks run isn't guaranteed across plugins. On the very first save after activating this snippet, Queryra may index the product *before* rwmb_after_save_post adds the new tag — in which case the tag won't be in the index yet. Run a manual sync once from your Queryra dashboard after you set up the hook. Subsequent saves stabilize, because by then the tag is already attached to the product before any sync runs.

Trade-off: if material changes from Cotton to Wool, the old Cotton tag stays attached. For most catalogs that's a non-issue (a product can have several material tags); if it's a problem in your case, store the previously-set value in a separate postmeta key and remove it before adding the new term.

A reasonable question: why doesn't the plugin just read every postmeta key and dump it into the embedding? A few reasons:

Signal-to-noise. Postmeta is a global namespace shared by every plugin on the site. A typical WooCommerce store has 50-200 distinct meta keys per product — _price, _regular_price, _stock, _sku, _yoast_wpseo_title, _elementor_data, _wp_attachment_metadata, internal cache markers, layout JSON, and on and on. Indexing everything blindly drowns the actual product information in unrelated noise.

Type ambiguity. Postmeta has no schema. The same key can hold a string, a serialized PHP array, JSON, a relative URL, or a boolean encoded as "1". A search indexer needs to know what's text and what's structural — without that, you get embeddings that include a:5:{i:0;...} strings that mean nothing semantically.

User control matters. The right answer for one store ('I want material indexed') is the wrong answer for another ('I have a 50KB JSON blob in _elementor_data and definitely don't want it indexed'). A whitelist gives both stores what they want.

The v1.3 design takes this seriously: discover the available keys from existing data, present them as a checklist per content type, let the merchant pick. No guessing.

Three things on the roadmap that close the gap directly:

• Custom-taxonomy auto-detection — any taxonomy registered as public => true is picked up automatically, without the current fixed list. Means custom taxonomies you register from your theme or another plugin become searchable as soon as you re-sync.
• Opt-in custom-fields whitelist — pick which Meta Box (and ACF, Pods, JetEngine) fields belong in the index, per content type. The UI auto-discovers the available keys from existing posts so you don't have to type meta keys by hand.
• Plugin-specific integrations — Direct hooks into Meta Box's field metadata API and ACF's field schema may follow, allowing the indexer to handle complex types (repeaters, flexible content, groups) sensibly. Whether this ships in v1.3 or later depends on user demand — the whitelist covers most cases without needing it.

No timeline commitment beyond "the next minor release." If your situation is blocking, email — sometimes we can prioritize specific field types.

• Meta Box and Queryra work together out of the box for standard fields — title, content, excerpt, WooCommerce attributes, taxonomies, brand
• Values stored in custom Meta Box fields (postmeta) aren't indexed in v1.2 — same as ACF, Pods, JetEngine
• Three workarounds: use Meta Box's taxonomy field type (zero code), use a WooCommerce attribute (zero code, products only), or mirror to product_tag with a save hook
• The save-hook pattern needs the empty($material) → return guard to avoid wiping all existing tags
• v1.3 adds an opt-in custom-fields whitelist with auto-discovery — no more workarounds

More Meta Box extensions and add-ons: docs.metabox.io/extensions/.