FacetWP

FacetWP is an index, not a filter widget. It builds its own table of filterable values, then answers filter requests from that table instead of running increasingly expensive queries against posts and meta. That design is why it stays fast where hand-built filters collapse, and it is also the source of every odd behaviour people report.

What it actually does

• Renders facets — checkboxes, dropdowns, sliders, date ranges, search boxes, hierarchies — from taxonomies, custom fields and post fields.
• Filters the listing without a page reload, updating counts as selections narrow.
• Keeps selections in the URL, so a filtered view is linkable and shareable.
• Handles pagination, sorting and result counts as part of the same system.
• Integrates with WooCommerce, the major page builders and custom post type archives.

The URL behaviour is worth more than it sounds. Filtered views that cannot be linked to are invisible to support, to campaigns and to anyone trying to share a result — and filtered views that all share one URL are a common cause of pages not showing what you expect when someone else looks at the same link.

The indexer, and why it is the whole story

Every value that can be filtered on is copied into FacetWP's index. Filtering reads the index; the site's posts are only fetched once the matching set is known.

Consequences to plan for:

• Bulk changes require re-indexing. A CSV product import, a migration, or anything writing directly to the database leaves the index describing the old data.
• Indexing is work. On a large catalogue the first index takes real time, and it runs through cron — so a site with broken WP-Cron has an index that never finishes.
• The index is the performance win. Filters that would otherwise be several joined meta queries per request become one lookup, which is the difference between a shop that filters instantly and one that times out.

Where it earns its licence

FacetWP is expensive relative to free filter plugins and cheap relative to the alternative on the sites it suits. The dividing line is scale and field complexity:

If you are here because a filter you already have does not work, fix that first — WooCommerce filter not working covers the usual causes, and most of them are not a missing plugin.

The template dependency

FacetWP needs to know which query to filter, which means a small edit to the listing template — or, on a builder, using that builder's integration.

That edit is the lock-in. Your archive templates end up written around the plugin: the listing markup, the pagination, the result counts and often the sorting come from it. Remove FacetWP and the listing does not vanish — it reverts to an unfiltered archive — but everything that made it usable is gone and there is no equivalent to migrate the configuration into.

This is a mild form of lock-in compared with a page builder, because content stays in posts and custom fields where it belongs. See custom post types for keeping the data model itself portable, which matters more than the filter layer.

Performance, honestly

The index makes filtering fast. It does not make an unoptimised listing fast. A page rendering 60 items with a full-size image each is slow whatever filters it — the fix is image sizes and pagination, per optimising images and speeding up WordPress.

Two FacetWP-specific costs: every filter interaction is an AJAX request that runs a query, so aggressive facet counts on a busy site are real load; and the index adds a table that grows with catalogue size and field count.

Common mistakes

• Adding twelve facets because the fields exist, producing a sidebar nobody reads and a query nobody can cache.
• Forgetting to re-index after an import, then debugging "wrong results" that are correct answers about stale data.
• Filtering on a secondary query the plugin was never told about.
• Letting the licence lapse and running an un-updated plugin inside every listing query.
• Buying it for a site with three categories, where core archives already do the job.

Deciding

FacetWP is the right answer when the listing is the product — a directory, a large catalogue, a data-heavy archive — and the filtering is across custom fields at a scale where naive queries fall over. It is the wrong answer on a small shop or a blog, where the free options are adequate and the annual cost buys nothing you will use. Between those, the deciding question is not how many filters you want, but how many rows they run against.