How to Filter Queryra AI Search Results by Category, Tag or Taxonomy

Semantic search is good at understanding what somebody means. By default it understands it across your whole catalogue.

Most of the time that is exactly right. Sometimes it is not. A visitor already browsing your Winter collection should not get a summer jacket back, however well it matches the words they typed. A course platform showing the Business track should not answer with a Photography lesson. The shopper's question is the same either way. What changes is which shelf the question is asked of.

That is what filter_ parameters are for. One addition to the search URL, and the AI runs on the slice you chose.

https://yourstore.com/?s=boots&filter_category=Winter

The shopper still types boots in plain language, and still gets everything semantic search normally gives them: synonyms, misspellings, intent. It just happens inside Winter.

This is not a shortcode, a settings page or a rebuild of your search form. It is a URL parameter, so it works with whatever already links to your search results: a category page, a menu item, a facet UI you already run, a button you add by hand.

Content type. Useful the moment a site has more than products in it.

?s=refund&filter_type=page          only pages
?s=jacket&filter_type=product       only products

Category and tag. WooCommerce product categories and WordPress categories both land here.

?s=boots&filter_category=Winter
?s=serum&filter_tag=sale

Brand, where your catalogue provides one.

?s=cream&filter_brand=Cocolo

Any custom taxonomy on your site, with a tax_ prefix in front of its slug. This is where it gets genuinely useful, because most WordPress sites that are not shops keep their real structure in custom taxonomies.

?s=business&filter_tax_course_cat=Business
?s=react&filter_tax_course_difficulty=Advanced

Combined, and every filter has to match.

?s=jacket&filter_type=product&filter_category=Outerwear

This is the part worth knowing about, because guessing taxonomy slugs from memory is how an afternoon disappears.

The WordPress plugin builds the list for your site specifically. Not a generic table from documentation: your own parameters, with your own values next to each one, read from your actual catalogue.

WP Admin → Queryra → Support → Search filters

On a course site it will show you something like this:

On a WooCommerce store it shows your product categories instead. Every value is copy-and-paste ready, and where a taxonomy is empty it says so in plain words rather than offering you a parameter that would return nothing.

There is a full example URL at the top of the same panel, already filled in with a real value from your site.

1. Values are the term name, not the slug. A track called *Software Development* is filtered as software development, not software-development. Encode the space as %20. Capitalisation does not matter.

✅ ?s=react&filter_tax_course_track=software%20development
❌ ?s=react&filter_tax_course_track=software-development

2. Custom taxonomies need the tax_ prefix. A taxonomy called course_cat is filter_tax_course_cat. Only the built-in dimensions above work without it.

3. Filters narrow, they never widen. Adding a second filter can only reduce the set. If a combination returns nothing, that is the honest answer for that combination, not a fault.

There are two ways to build this, and they feel completely different to the person searching.

The naive way is to run the search, take the top results, then throw away everything outside the filter. Ask for boots in Winter and you get whatever handful of Winter items happened to survive a general ranking. Narrow filters look empty, and the emptier the filter, the worse it gets.

Queryra applies the filter before ranking. The AI ranks within the slice you chose, so a narrow filter returns the best matches inside it rather than the leftovers of a wider list. A category with fifteen products behaves like a small store, not like a large store with almost everything deleted.

Searches without a filter_ parameter behave exactly as they always did. Nothing changes until you ask for it.

There is a trap in filtered search that has nothing to do with the filter working or not.

Look at a search history with filters in it and you will see the same query returning completely different counts:

12:14:43  "cream"  →  36
12:14:39  "cream"  →  36
12:14:38  "cream"  →   0
12:14:33  "cream"  →   0

Identical query, opposite outcome, minutes apart. Read a week later that looks like search breaking at random. It is not: those rows ran with different filters, and the filter was never written down anywhere.

So Queryra now records it. Search History in your dashboard marks every filtered search with a small badge next to the query, and opening the row shows the exact parameters that search ran with, values included. A count that looks wrong stops being a mystery, because the reason is on the same screen.

This starts from the moment it ships, so older rows show nothing. Nothing is recorded beyond the parameters your own site sent.

Worth naming, because the word is overloaded and the wrong one costs you an afternoon.

URL filters. This post. You decide the slice.

Filters read from the query itself — a shopper typing *wireless headphones under $80, not Beats* gets the price cap and the brand exclusion applied automatically. Nothing to configure, and it happens on every search whether or not you use URL filters.

PHP filters (hooks). For developers extending what gets indexed, such as queryra_indexable_meta_content. A different thing entirely, covered in Queryra Developer Filters.

The full parameter reference lives in the docs: Search Filters.

1. Open Queryra → Support → Search filters in WP Admin and look at what your site actually exposes.
2. Copy the full example URL from the top of that panel and run it. You will see the filter working on real content in about five seconds.
3. Add the parameter to whatever already links to your search results: a category page, a menu, an existing facet UI.

If a filter returns nothing you did not expect, check the value against the panel first. Nine times out of ten it is a slug where a term name should be.