Filtering starts with how the values are stored
A filter can only narrow a list by something the site stores in a consistent, queryable form. In WordPress that means a category, tag or custom taxonomy for values chosen from a fixed list, or a custom field for values such as a date, a price or a short label. Text typed freely into each entry's body cannot be filtered: "North", "north side" and "N." are three different things to a query. If your values are free text, the first step is not code but a clean-up that moves them into fields or taxonomies, which is why a directory build begins with the content type. Decide for each filter whether it has a short fixed list of values (a dropdown) or a long open set (a search box).
- List each filter, its values and where each value is stored.
- Write down what each filter means when two are combined: and, or, or both options.
Change the listing's own query, and only that
WordPress lets code adjust a query before it runs through the pre_get_posts action. The reference page says the action fires after the query object is created but before the query runs, and recommends combining ! is_admin() with $query->is_main_query() so that only the front-end main query is changed, not sidebar loops or admin screens. Because the query object is not fully set up at that point, conditional tags should be called as methods on it, and a few, such as is_front_page(), do not work there. The page also warns that using offset can break pagination, and that you cannot simply turn a single-post query into an archive. For a filter on an archive these cautions all apply: scope the change, read the incoming parameters, and let WordPress paginate.
- Test the admin list and a sidebar after the change to prove they are unaffected.
- Validate and escape every incoming parameter; they come from the visitor.
Addresses, sharing and pagination
If the visitor's choices live in the page address, a result set can be bookmarked, shared and reloaded, and moving to page two keeps the choice. That is also the source of the search-engine question: every combination of filters is another address. Build the filters as an ordinary form that works without JavaScript, with an optional script that updates the list in place, so that the address always reflects the state. Keep parameter names stable and use the standard separator between parameters.
- Reload the address in a fresh window and check you get the same list.
- Click through pages two and three with filters on and check they persist.
What search engines do with filter addresses
Google's guidance on faceted navigation says parameter-based filters can generate an effectively infinite number of addresses, that crawlers cannot know a filtered address is worthless until they fetch it, and that this slows the discovery of new pages. It suggests letting individual item pages and one unfiltered listing be crawled and using robots.txt rules to disallow filter parameters. It describes canonical and nofollow as generally less effective in the long term, and says fragments are generally not supported for crawling or indexing. It recommends a 404 status for combinations that return no results, are duplicates or make no sense. Agree an explicit policy before launch instead of discovering the effect later.
- Decide which addresses should be crawlable and which not.
- Decide the status code for an empty result and test it.
What the paid job covers
The search and filter job has a published test price of GBP 590 for one listing, up to three filters and sorting, with values already stored and up to a few thousand entries. It is accepted when at least twelve combinations return exactly the expected entries on a fixture set, choices persist through pagination and reload, the form works with JavaScript off, and an empty combination shows the agreed state and status. It excludes map or distance search, live counts on very large lists, and replacing the site-wide search. Prices are untested proposals and payment follows the agreed checks.
- Send the listing address, the filters and three example searches.
- If the values are only in free text, ask about the content-type job first.
Sources and limits
- WordPress developer reference: pre_get_posts Checked 2026-10-11.
- The hook runs after the query variable object is created but before the query runs; changes should be limited with ! is_admin() && $query->is_main_query(); conditional tags should be called as methods on the passed query; is_front_page() does not work at this stage; using offset can break pagination.
- Google Search Central: managing crawling of faceted navigation URLs Checked 2026-10-11.
- Parameter-based filters can generate effectively infinite URL spaces and cause overcrawling; robots.txt disallow rules are the suggested control, URL fragments are generally not supported for crawling and indexing, and rel=canonical or nofollow are described as generally less effective in the long term.
- Use the standard & as the parameter separator, keep the logical order of path filters constant, and serve a 404 status for filter combinations that return no results, are duplicates or are nonsensical.