FacetWP Elementor - WordPress Plugin

FacetWP Elementor Setup Guide for Filterable WordPress Pages

FacetWP Elementor is not meant to "add one more widget" to the editor. Its real purpose is to connect two different layers of your site: visual page building in Elementor and precise post filtering through FacetWP. In this guide, we will walk through how to prepare your data, enable the correct Elementor widget as the filterable listing, display facets, verify the result on the live page, and quickly figure out why the filters are not responding.

This guide is written for a site owner, webmaster, or developer who already uses WordPress, Elementor, and FacetWP, but wants to build a clear catalog page, archive, resource library, portfolio, or WooCommerce listing without manually coding a template. We will not repeat the product's marketing copy. Instead, we will focus on the working logic: what data FacetWP indexes, what query Elementor needs to expose for filtering, where Enable FacetWP is turned on, why Element Cache can break things, and how to avoid ending up with two conflicting listings on the same page.

Special attention is given to the scenarios that most often break the result: Elementor archive templates, Loop Grid pagination, multiple lists on the same page, Shortcode widgets, static Listing Builder blocks, mobile filter layouts, and conflicts with performance settings. If your filters are already on the page but do not appear, disappear after selection, or return the wrong posts, the troubleshooting section will help you narrow down the cause without randomly disabling every plugin.

What Problem FacetWP and Elementor Solve Together

FacetWP works as a faceted filtering system for WordPress. A facet is a selection control: checkboxes, a dropdown, search, a range, sorting, pagination, reset, and other types. The user selects parameters, and FacetWP updates the listing without a full page reload. In this setup, Elementor handles the visual page build: the card grid, archive template, filter placement, spacing, buttons, and responsive layout.

Without the integration add-on, there is a practical gap between the two. Elementor can beautifully display Posts, Loop Grid, Archive Posts, or a WooCommerce widget, but FacetWP still needs to understand which exact query on the page it is supposed to filter. FacetWP Elementor adds that detection and control layer: supported Elementor widgets get an Enable FacetWP setting, and the editor gains dedicated FacetWP widgets for facets, Listing Builder output, and buttons.

The key idea: this add-on is useful when you want to build the result visually in Elementor but keep filtering on the FacetWP side, with its index, facet types, query rules, and support for complex data sources.

Typical use cases look like this:

• A post catalog with filters by categories, tags, authors, dates, or custom fields.
• A WooCommerce product catalog with facets for attributes, price, stock status, rating, or custom data.
• A database of properties, jobs, specialists, recipes, courses, events, or documents where users need to narrow the list quickly.
• An Elementor Theme Builder archive template where you need to preserve the native WordPress archive query and avoid mixing it with an arbitrary widget query.
• A page with a visually styled FacetWP Listing Builder output inserted into Elementor through the dedicated widget.

Unlike a basic "category plus post list" filter, the FacetWP Elementor combination becomes especially important on pages with multiple data sources, custom fields, nested taxonomies, search, pagination, and the need to keep a polished Elementor grid. This is where query or caching mistakes show up most clearly: the filter may appear, but affect the wrong listing, change nothing at all, or disappear after the first selection.

When FacetWP Elementor Is a Good Fit, and When Another Approach Makes More Sense

Before installing it, make sure you are not trying to solve an integration problem that would be easier to handle with core FacetWP features or another tool. The add-on does not replace FacetWP itself, does not create data, does not magically build product cards, and does not fix a poor site structure. Its purpose is specifically to serve as a bridge between FacetWP filters and Elementor-based output.

Good Use Cases

FacetWP Elementor is a solid choice if your site already uses Elementor pages or archive templates, and your content lives in standard WordPress entities: posts, products, custom post types, taxonomies, ACF fields, Meta Box, Pods, or similar sources. In that setup, FacetWP indexes the data, while Elementor controls how the result is presented.

The combination works especially well when you need:

• A visual grid built with Loop Grid, Posts, Archive Posts, Products, or a supported third-party Elementor widget.
• One main results list on the page that should update based on the selected facets.
• Flexible filter placement: above the listing, in a sidebar, inside a container, in a separate Elementor column, or through a mobile slide-out panel.
• The option to use FacetWP Listing Builder while placing it inside an Elementor layout like a regular widget.
• Control over UX: auto-refresh, an apply button, a reset button, result counts, sorting, and pagination.

Situations Where the Add-on May Be Unnecessary

If your site does not use Elementor for listings, you do not need Elementor integration. FacetWP already works with WordPress archives, custom queries, blocks, Listing Builder, and other supported template types. In that case, it is simpler to choose the listing template type that is actually used on the page than to add Elementor into the chain just for the visual editor.

You should also be more cautious if the page is designed as a complex combination of several independent catalogs. The official FacetWP documentation is explicit here: there should be only one FacetWP-enabled listing on a page. Multiple static blocks may be acceptable in some cases, but several filterable listings reacting to the same or different facets usually lead to unpredictable behavior.

A practical test before deciding: define the page's one main listing. If you cannot clearly answer which list is supposed to be filtered, simplify the page architecture first, then add FacetWP Elementor.

What to Check Before Installing on a Live Site

Preparation matters not because installation is difficult, but because filtering depends on both the data and the query. The add-on requires very little separate setup after activation, but it will not fix an empty index, incorrect facet names, an unsupported widget, a cache conflict, or an archive template with the wrong post source.

Platform, Plugins, and Roles

Make sure your staging copy of the site has WordPress, Elementor, FacetWP, and the FacetWP Elementor add-on installed and activated. Some supported Elementor widgets require Elementor Pro or a specific third-party widget pack. At the same time, the dedicated FacetWP widgets added by the add-on work with the free version of Elementor, but the listing itself may still depend on which widget you use to build it.

For a typical project, it helps to prepare a short checklist in advance:

• What entity is being filtered: posts, products, a custom post type, users, or another supported source.
• What data the facets will control: taxonomies, custom fields, WooCommerce attributes, date, author, search, or a numeric range.
• Which Elementor widget will serve as the main listing: Loop Grid, Posts, Archive Posts, Products, Archive Products, or a supported third-party widget.
• Whether the page will be a regular Elementor page or a Theme Builder archive template.
• Whether you need a mobile filter panel, an apply button, or a separate results page.

Data and Index

FacetWP builds its own index so it can quickly find facet choices and update listings. After creating or changing facets, you need to re-index. If data was imported in bulk, the term hierarchy changed, fields were added, or registered post types changed, the index should also be rebuilt. This is not a "just in case" step. It is a basic requirement for getting correct values in your filters.

On a new site, do not rush to test FacetWP Elementor against an empty database. Add several posts with different categories, field values, prices, or attributes. If all items are identical, the facets may look sparse or fail to show the options you expect. If all products are hidden, in draft status, or excluded from the current query, the filter may technically work while still producing an empty result.

Caching and Optimization

Also review Elementor Performance settings. FacetWP documentation states that Element Cache is not compatible with FacetWP on related widgets. Symptoms can vary: facets may not appear, may disappear after use, or you may get a listing auto-detection error. So before troubleshooting filters, disable Element Cache globally or explicitly set Cache Settings to Inactive for all related widgets.

If your site uses caching plugins, JavaScript optimization, lazy loading, or minification, do not disable them blindly forever. First test the page in a safe environment, then exclude only the optimizations that interfere with FacetWP AJAX updates or Elementor scripts. A filterable page is almost always more sensitive to aggressive caching than a regular static landing page.

Installation and the First Check After Activation

Installing the add-on usually means uploading the ZIP file through Plugins > Add New > Upload Plugin, activating it, and confirming that Elementor now includes the additional FacetWP functionality. Do not frame this step around buying or registering a license. In real work, what matters more than activation itself is whether the editor sees the required widgets and whether the Enable FacetWP setting appears where it should.

What Should Change in Elementor

After activation, supported Elementor listing widgets receive an additional Enable FacetWP setting. This tells FacetWP: this is the main posts list that should be filtered dynamically. In addition, Elementor's widget panel gains dedicated FacetWP elements:

• FacetWP Facet - displays an existing facet and lets you choose it from a dropdown.
• FacetWP Listing - displays a FacetWP Listing Builder template inside an Elementor page.
• FacetWP Button - adds an apply button, a mobile button, or a submit button depending on the available add-ons.

At this stage, do not build a complex catalog right away. Start with a minimal page: one list, one facet, one verification step. If that basic setup works, you can then add sorting, pagination, mobile output, and design.

A Minimal Test Without Extra Variables

1. Open Settings > FacetWP and create a simple facet, such as one based on a category or taxonomy.
2. Save the facet and click Re-index if FacetWP indicates that re-indexing is needed.
3. Create a test Elementor page.
4. Add one supported listing widget and enable Enable FacetWP in it.
5. Add FacetWP Facet next to it and select the facet you created.
6. Publish or update the page and check the result on the live site, not inside the editor.

This is an important point: in the Elementor editor, a facet may appear as a placeholder rather than as a fully working filter. You need to test functionality on the published page. If you only see a service placeholder in the editor, that is not necessarily an error. The real problem starts when the live page has no facet, no listing, or selections do not change the results.

Configuring a Supported Elementor Widget as the Filterable Listing

The most common source of problems is not the facet but the listing. FacetWP needs to filter a specific query. If the page contains a visual list but the add-on cannot tell that it is the main list, the facets either will not appear or will change something other than what you expect. That is why setup should start not with checkbox styling, but with choosing the correct listing widget.

Regular Elementor Page

On a regular page, you can use supported widgets that build their own query, such as Posts, Loop Grid, WooCommerce widgets, or supported widgets from third-party Elementor packs. In the widget settings, enable Enable FacetWP. After that, FacetWP will use that widget's query as the results source.

If you are displaying posts through a Query Loop or Posts widget, configure the post source before connecting facets. For example, choose the correct post type, exclude unnecessary categories, and define the sort order. Then add the facets. That makes it easier to tell whether the problem is in the Elementor query or in FacetWP.

What to Choose for a Typical Catalog

For a post or resource catalog, Loop Grid or Posts is usually enough. Loop Grid is more convenient if you want visual control over the card layout through a loop template. Posts is faster to configure if the standard card structure is sufficient. For a WooCommerce archive, it is better to use widgets that preserve the archive query logic rather than an arbitrary product list.

Elementor Theme Builder Archive Template

Archives require a different approach. On a category, tag, search, or shop page, WordPress already runs the native archive query. If you place a standard Posts or Loop Grid widget with an arbitrary source inside the archive template, FacetWP may detect the native archive query while the user sees a different listing in the Elementor widget. That is where the mismatch comes from: the facet seems to be filtering "the wrong posts."

For an archive template, use Archive Posts or Archive Products, or configure a supported widget so it uses Current Query or Main Query. The FacetWP documentation calls out this nuance separately: on archive pages, it is important not to replace the current query with an arbitrary source. If you need fine-grained changes to archive query arguments, it is usually safer to work through the WordPress pre_get_posts hook rather than through a custom Elementor filter for an arbitrary widget query.

How to Verify the Query Is Correct

After publishing, open the archive with no facets selected and make sure Elementor displays the posts you expect. Then select a facet and confirm that the number and composition of results change logically. If a category page suddenly starts showing posts from another category after filtering, the problem is almost always the query source or the fact that the widget is not using the current archive query.

How to Display Facets and Buttons in an Elementor Layout

Once the listing has been chosen, you can design the filter panel. FacetWP Elementor gives you two practical options: use the dedicated FacetWP Facet widget or insert a shortcode through a Shortcode or HTML widget. The official documentation recommends the FacetWP widget as the more convenient alternative to manual shortcodes, because it shows the list of facets you have already created and reduces the risk of a naming mistake.

The FacetWP Facet Widget

Add FacetWP Facet to the desired place on the page and choose the facet in the Facet field. If you need a heading above the filter, use the Header field and select an appropriate HTML tag. Do not make facet headings image-only or rely on pseudo-elements if the site is multilingual. Text inside the widget is easier to translate and verify.

It is important to remember that in the Elementor editor, the facet itself may not behave the way it does on the live page. The editor shows a placeholder. So keep design and validation as separate steps: in Elementor, you position the widget and review the layout; on the live site, you verify real values, URL behavior, and AJAX updates.

The Shortcode Approach

Shortcodes are useful if you are already comfortable with FacetWP markup or want to insert a facet into an existing block. The example looks like this:

[facetwp facet="category"]

Here, category is the facet's technical name, not its display title. It is best to keep facet names short, Latin-based, and easy to understand, because they are used in the URL and in the plugin's internal logic. If you rename a facet, update the shortcode and rebuild the index.

Apply Button, Mobile Button, and Submit Button

FacetWP Button covers three different scenarios. Apply disables auto-refresh and applies the selection on click. This is useful if the page has many facets or the user needs to choose several parameters first. Flyout opens a mobile filter panel if the Mobile Flyout add-on is installed. Submit sends the selection to a separate results page if the Submit Button add-on is installed.

Do not enable every button at once. For a standard catalog, auto-refresh or a single Apply button is enough. For a mobile catalog, adding Flyout makes sense. For a search form that should send the user to a dedicated results page, Submit is the right fit. The fewer overlapping scenarios you create, the easier the page will be to maintain.

Listing Builder Inside Elementor: When to Use It and When Not To

FacetWP Listing Builder lets you create your own results template inside the FacetWP interface. With the add-on, you can display it in Elementor through FacetWP Listing. This is useful if you do not want to depend on Elementor cards but still want to place the list inside an Elementor page next to other sections.

Filterable Listing Builder Output

Add FacetWP Listing and choose an existing Listing Builder template. That list can serve as the page's main filterable block. The main rule stays the same: the page should contain one filterable list. If you place another supported Elementor Posts widget next to it with Enable FacetWP turned on, the behavior becomes conflicting.

Listing Builder is helpful when the result card depends heavily on custom fields, short metadata, custom HTML fragments, or a repeated custom structure. But if the card is easier to build in an Elementor Loop Template, there is no strong reason to switch to Listing Builder.

Static Listing Builder Blocks

In newer versions of the add-on, you can add static Listing Builder outputs. A static block does not respond to facets. This is useful for supporting sections such as "popular resources," "recommended products," or "new posts." But the static block should not confuse the user. Keep it visually separate from the filterable area, otherwise it will look like some of the cards are not responding to the filters.

How to Verify That a Block Is Truly Static

Select a facet and see whether the static list changes. It should stay the same, while the main filterable list updates. If both lists change, check whether you accidentally enabled filterable mode where you meant to use a static block. If neither list changes, go back to the main listing setup.

Practical Example: A Course Catalog with Topic and Level Filters

Let us walk through a scenario that is easy to adapt to a specialist directory, a document library, a property catalog, or a store. Suppose the site has a custom post type called course. Each course has a course_topic taxonomy and a custom field called difficulty. The goal is to build an Elementor page where filters appear on the left and course cards on the right update without a page reload.

Goal

The user should be able to open the "Courses" page, choose a topic and a level, see only matching cards, reset the selection, and click through to an individual course page. The administrator should have a clear validation flow: data exists, facets are created, the index is built, one Elementor widget is enabled for FacetWP, and the result has been checked on the live site.

Preparation

1. Create several test courses with different topics and levels.
2. In Settings > FacetWP, create a course_topic facet using the topic taxonomy as its source.
3. Create a difficulty facet using the corresponding custom field as its source.
4. Save the facets and run Re-index.
5. Make sure the technical facet names do not contain Cyrillic characters, spaces, or conflicting words.

Steps in Elementor

1. Create a "Courses" page and open it in Elementor.
2. Add a two-column container: a narrow column for facets and a wide column for the listing.
3. In the wide column, add Loop Grid or Posts configured for the course post type.
4. Enable Enable FacetWP in the settings of that listing widget.
5. In the left column, add two FacetWP Facet widgets and select the topic and level facets.
6. Add a reset facet or reset button if users need a quick way back to the full list.
7. Publish the page and open it in a new tab outside the editor.

Verifying the Result

First, check the state with no filters selected: the cards should match the Elementor query. Then select one topic. A FacetWP parameter should appear in the URL, and the listing should narrow down to courses in that topic. Select a level. If the result becomes empty, make sure your test data actually includes a course with that combination of topic and level. Click reset and confirm that the full list returns.

Quick takeaway: if one simple page works, add design, pagination, and a mobile panel gradually. Do not change the query source, facet type, cache, and card markup all at once, or you will lose your clear testing point.

A Nuance for Archive Templates

If you are building a course_topic archive through Elementor Theme Builder instead of a regular page, do not use an arbitrary post source unless you truly need it. The archive already knows the current topic. In this case, the listing widget should use the current archive query, otherwise FacetWP may filter the archive query while Elementor displays a different list.

Pagination, Buttons, and Mobile UX Without Conflicts

After the basic setup, the next step is usually improving usability by adding pagination, an apply button, a mobile panel, or a reset button. These elements do matter, but they also change the page behavior. So introduce them one at a time and check how FacetWP updates the listing after each change.

Elementor Pagination

FacetWP can work with Elementor pagination, but with limitations. The FacetWP documentation specifically warns that only numeric pagination variants are supported, while Load on Click and Infinite Scroll are not suitable for FacetWP. For Loop Grid, you need to choose Page Reload for the Load Type setting, because AJAX conflicts with the way FacetWP intercepts and processes updates on its own.

If you need pagination that behaves reliably and consistently in every scenario, consider the FacetWP Pager facet. It is created and displayed like a regular facet, but it controls result pages or the loading of additional items. That is often easier to maintain than mixing several AJAX mechanisms from different plugins.

Apply Instead of Auto-Refresh

Auto-refresh works well on short lists and simple filters: the user clicks a checkbox and immediately sees the result. But if there are many facets, a search field, several ranges, or heavy product cards, it is better to let the user choose parameters first and then click Apply. FacetWP Elementor supports this through FacetWP Button with the Apply type, which disables auto-refresh and triggers the update on click.

You should not add custom JavaScript to disable auto-refresh while also using the Apply widget if the widget already solves the problem. Duplicating that logic can create odd effects: the user clicks the button, but some facets update early, or nothing updates at all.

Mobile Filter Panel

In mobile catalogs, a sidebar often takes up too much space. The Mobile Flyout add-on creates a slide-out filter panel, and FacetWP Button can output the button that opens it. By default, the flyout uses the facets that already exist on the page, with the exception of certain service-oriented types. That means you do not need to create a separate facet set just for mobile.

If you use a third-party off-canvas widget, make sure the same facet is not duplicated both on the page and inside the panel. Facets that exist twice in the markup often cause confusing behavior: the selection appears to be made, but FacetWP receives two competing elements that represent the same control.

Cache, Performance, and Safe Changes

A filterable page is always more dynamic than a regular one. It involves the FacetWP index, the WordPress query, Elementor output, AJAX updates, URL parameters, client-side scripts, and sometimes a caching layer. Good performance does not come from turning on every optimization available. It comes from understanding what each layer is responsible for.

Element Cache and FacetWP Widgets

The most important conflict in this integration is Elementor's Element Cache. For all FacetWP-related widgets, this setting should be inactive. That includes dedicated FacetWP widgets, Shortcode, HTML, Text Editor with a shortcode inside, as well as supported post or listing widgets with Enable FacetWP turned on. If caching is enabled globally, check the individual Cache Settings for every related widget.

The Index and Heavy Data

FacetWP uses an indexed table for speed. That is a strength, but it requires discipline: after changing facet sources, running a bulk import, modifying the term hierarchy, or adjusting indexing hooks, run re-indexing. If the index hangs, first check memory, server logs, cron, and whether the site can send HTTP requests to itself. Do not start by deleting plugins, and do not edit the database manually.

A Safe CSS Tweak for a Sticky Filter Panel

In some catalogs, it is useful to keep the left filter panel fixed in view while users scroll. The FacetWP documentation recommends using CSS position: sticky for this effect instead of scripts that duplicate elements. Duplicating facets can break filtering because FacetWP ends up receiving multiple copies of the same interface.

Example of a safe tweak for a container with facets:

.catalog-filters {
  position: sticky;
  top: 24px;
  align-self: flex-start;
}

Add this CSS in a child theme, in a safe custom CSS area provided by the theme, or through the standard custom styles mechanism. Do not place it into WordPress core files, Elementor files, FacetWP files, or the add-on files. After saving, test the page on desktop and mobile: the panel should not overlap the header, lower elements, or the apply button. If the behavior feels awkward on small screens, limit the sticky effect with a media query or disable it for mobile.

How to Roll Back the Tweak

Delete the CSS block or temporarily comment it out, clear the page cache, and verify that the facets behave like normal flow elements again. This rollback is safe because it changes only the container positioning, not queries, the index, or the data.

Checking the Result Before Publishing

Once the page is built, do not stop at a visual review inside Elementor. Filtering has several layers of validation: data, interface, query, URL, accessibility, mobile behavior, and behavior after cache clearing. It is better to spend 20 minutes before launch than to deal with complaints later that the filter "sometimes" does not work.

Live Site Checks

• Open the page as a visitor, not only as an administrator.
• Test each facet individually: the selection should change the list, not just the URL.
• Test a combination of two or three facets to make sure the results narrow logically.
• Click reset and confirm that all selected parameters are cleared.
• Reload the page with active URL parameters and verify that the selected values are restored.
• Go to the second page of pagination, then select a facet and check that the listing does not fall into an empty state because of an old page number.

Query and Debug Checks

If the listing looks strange, enable Debug Mode in Settings > FacetWP > Settings, identify which query FacetWP is using, and turn debugging off again after diagnosis. Do not leave Debug Mode enabled on a production site unless you have a clear reason, because it can affect load speed.

Do not limit your check to "there are results" or "there are no results." What matters is whether they are the right results. For example, if the "Marketing" category archive starts showing courses from the "Development" category after selecting the "Beginner" level, the issue is not the checkbox. It means the Elementor widget and FacetWP are using different queries.

SEO and Indexability

FacetWP adds selection parameters to the URL. For standard filtering, that is fine: users can refresh the page with their chosen parameters intact. But do not turn every filter combination into an SEO page without a strategy. If indexing facet pages matters on your site, review URL settings, canonical handling, sitemaps, and search indexing rules separately. Do not assume traffic will grow simply because the filter became easier to use. The main benefit of FacetWP Elementor is controlled on-site search, not automatic creation of SEO sections.

Limitations and Edge Cases Worth Knowing in Advance

Even a strong integration has boundaries. If you account for them upfront, FacetWP Elementor behaves predictably. If you ignore them, the project turns into a collection of exceptions where every new block breaks the existing filtering logic.

One Filterable Listing Per Page

This limitation is worth repeating on its own. FacetWP filters one main listing. Yes, the page can contain other blocks, but they should be static or visually separated. If the business requirement calls for several independent catalogs, it is better to create separate pages, tabs with separate logic, or a more custom architecture than to force FacetWP to filter multiple main queries at the same time.

Elementor Popups Are Not a Good Place for Facets

The official FacetWP documentation does not support using facets inside Elementor popups. For mobile output, it is better to use the Mobile Flyout add-on or a clean off-canvas approach where you fully understand which facets exist in the source code and where they are not duplicated. Popups often change load timing, DOM structure, and element visibility, while filtering expects a stable page.

Entrance Animations and Duplicated Elements

Elementor Entrance Animation can keep a section invisible until it appears. That is not a problem for a purely decorative block, but for a facet or listing it creates risk: FacetWP needs to see those elements and update them correctly. If you want a visual effect, use safer CSS transitions that do not hide a critical block from the filtering logic.

Custom Queries in Elementor

Elementor has a documented Custom Query Filter, but on archive pages FacetWP recommends not using it in place of the native WordPress approach if the widget is supposed to work with the current archive query. On a regular page, a custom query filter may be appropriate, but make sure FacetWP is filtering that modified query and not something else. For archives, it is usually safer to adjust the main WordPress query.

When FacetWP Elementor Is the Right Choice

FacetWP Elementor is worth using when you want to keep Elementor's visual control while gaining the mature faceted filtering of FacetWP. Its strength is not the number of buttons. It is the quality of the connection: one supported listing widget, clear facets, a working index, the correct query, and verifiable AJAX behavior on the live page.

If you are just getting started, do not try to build the perfect catalog all at once with a mobile panel, static blocks, multiple pagination styles, and complex caching. Start with a simple page that has one list and one facet. After that, add a second facet, reset, pagination, an apply button, a mobile flyout, and styles. That order reduces risk and makes every error easier to understand.

Before rolling it out on the live site, prepare a staging copy, verify compatibility with your Elementor template, disable Element Cache for related widgets, run re-indexing, and work through the checklist in the validation section. If the scenario is stable after that, you can download the WordPress version and repeat the setup on the main page with a clear rollback path already in mind.

The bottom line is simple: this add-on does not make filtering work "by itself," but it does provide the right bridge between FacetWP and Elementor. When the data is prepared, the query is chosen correctly, cache is not interfering, and the page contains only one filterable listing, FacetWP Elementor turns a visual Elementor layout into a usable catalog that works without page reloads and without manually building a separate template.