Changing a facet calls FacetWP's current REST route (/wp-json/facetwp/v1/refresh, public by default) or, on older setups, a legacy admin-ajax fallback. Facet choices update the real address-bar query string, so filtered views are bookmarkable and shareable, not just in-memory state — which also means a site can have far more filter-combination URLs than get built ahead of time.
Hybrid
Nothing about FacetWP itself is served static — the underlying post/product listing it filters is whatever page type is being faceted.
Every facet change needs a live query; there's no cached-page equivalent for an arbitrary filter combination.
The current REST route already reaches WordPress rather than a cached page under Hybrid/Static + Bridges mode, since it sits under /wp-json/ — a path already excluded from static serving — and the older admin-ajax fallback works the same way there too, since /wp-admin/ requests are excluded generically. Under Zero-WordPress Mode or Vault Mode, neither path is exempted by default; we've built a receiving endpoint for the admin-ajax fallback, but nothing yet automatically redirects FacetWP's own frontend calls to it — that still needs to happen before this genuinely works under those stricter modes, not just be theoretically bridgeable.
No special setup for Hybrid or Static + Bridges mode. Verify facet filtering actually works before enabling Zero-WordPress Mode or Vault Mode.
Being honest about where this actually stands: under Zero-WordPress Mode or Vault Mode, FacetWP needs explicit verification, not just a declared bridge, before you rely on it. Separately, however many filter combinations your build actually generates as static pages, a shopper can always land on one that wasn't — that's a fundamental shape of faceted filtering, not something any static site tool fully eliminates.
Static Shield Lite is free to install and inspects your actual plugins, not just what's publicly visible.
Get Static Shield
Tulapp