FacetWP Schedule Indexer - WordPress Plugin

How to Configure FacetWP Schedule Indexer and Safely Update the Index on a Schedule

FacetWP Schedule Indexer does not create filters or change how a catalog looks. Its purpose is narrower, and especially important on sites with frequently changing content: it runs a full FacetWP reindex on a WP-Cron schedule. This guide shows you how to build a predictable process that keeps facet data fresh, avoids making the server do the same work twice, and lets an administrator verify that the scheduled event actually ran.

We’ll cover preparation, installing the add-on, choosing an interval, disabling conflicting automatic indexing, checking the fwp_scheduled_index event, working with WP-Cron, handling bulk imports, and knowing when it makes more sense to move to a server cron job with WP-CLI. The examples assume that FacetWP is already set up: the site has a listing, configured facets, and data that needs to be indexed.

The main idea is simple: a schedule is no substitute for understanding your data. First determine exactly what FacetWP indexes and when that data changes. Then choose an interval and verify the actual outcome in the FacetWP dashboard and on a public page. This sequence helps prevent the most common mistake: enabling an hourly run at random and assuming the filters must now be up to date.

What Schedule Indexer Updates and Why It’s Different from a Typical WordPress Task

To use the add-on correctly, it helps to distinguish between two processes that sound similar. WordPress stores posts, terms, custom fields, and products. FacetWP builds its own index on top of that data so it can quickly find items that match a facet. FacetWP’s official documentation describes indexing as analyzing site data and saving facet data to a dedicated database table for faster queries. In other words, a public page with filters generally doesn’t scan all the site’s content every time someone clicks a filter. It relies on a prepared index.

Schedule Indexer does not change posts or fix incorrectly populated fields. It runs a full reindex on a recurring schedule. When the process starts, FacetWP scans the indexable data again, rebuilds the index, and completes the run. This is useful when changes arrive in batches, from an external system, or through a nightly job rather than from an editor saving a single post in the dashboard.

How Data Moves from a WordPress Object to a Facet Value

Imagine a real estate catalog. Each listing has a property type, city, price, publication status, and several custom fields. Some of these values become facet sources in FacetWP. When a visitor selects a city or price range, FacetWP needs to know which listings match. It’s not enough for an editor to see a populated field on the post edit screen. The correct value must also be present in the index built by FacetWP.

The same pattern appears in stores with products, knowledge bases with taxonomies, job boards, event catalogs, and sites with custom post types. The inputs are posts, terms, metadata, and facet settings. The internal step is building the index data. The output is a set of values that lets the public listing filter quickly. You can verify this directly: a new or updated item should appear when you select the relevant facet, and an outdated value should no longer appear in the results.

Don’t confuse the general FacetWP index with another plugin’s search index, a page cache, or thumbnail generation. Schedule Indexer is specifically responsible for running a full FacetWP reindex periodically. If a product is missing because of WooCommerce visibility rules, an incorrect listing query, or a CDN cache, running the indexer alone may not fix the problem. That’s why this guide follows the chain of cause and effect: first the data source, then the index, then the FacetWP query, and finally the visible listing.

When FacetWP’s Built-In Automatic Indexing Is Enough

FacetWP has a built-in automatic indexer. According to its documentation, it performs a single reindex when an individual item, such as a post, page, or term name/slug, is edited or saved. For a typical editorial site, this is often a convenient setup: an editor changes content, and FacetWP keeps the index current without a costly full run.

If a site publishes only a few posts a week and editors make changes manually, adding Schedule Indexer may not help. A recurring full reindex would add background work without a noticeable benefit. So the first question before installing the add-on isn’t “How do I turn on a schedule?” It’s “What process changes the data?” If one editor saves individual posts, the automatic mode is usually easier to manage. If hundreds of items are imported each night or an external system syncs the catalog in batches, a schedule makes more sense.

When the Add-On Is a Good Fit

The clearest use case is a regular bulk import. For example, a supplier provides an updated product feed, and an import system creates or updates products at a set time. Another case is a large catalog where a group of editors regularly changes terms or custom fields in bulk. A third is a recurring change to the set of indexable items after an integration with an external database. In each case, you want to run the index after the data has been saved, but before visitors need to see it.

This approach can also suit sites with little public traffic. That’s where a WP-Cron caveat becomes apparent: an event can be registered for a given interval, but whether it runs depends on activity on the public site. If there are few visitors overnight, “at night” does not mean that the task will run at an exact time. In that situation, Schedule Indexer can still be a useful, simple option, but verifying the run and, if needed, moving to a server cron job become part of the setup rather than optional optimizations.

Who Benefits from a Scheduled Full Reindex-and Who Should Keep Things Simple

Schedule Indexer is designed for a site owner who understands the cost of a full reindex and wants to control when it runs. It is not a universal speed boost. The add-on does not make filters faster by itself or remove the need to check data sources. It lets you put a full index refresh into a recurring WP-Cron workflow.

When It’s a Good Fit

• Bulk catalog updates. An import or sync finishes as a batch, and the FacetWP index needs to be brought up to date with the new data.
• Predictable update cycles. The team knows that data changes during a specific window rather than continuously every few seconds.
• A single verification point is useful. An administrator would rather confirm one completed run in FacetWP’s stats than rely on many individual automatic updates.
• WP-Cron can be monitored. You can install WP Crontrol or use your host’s tools and WP-CLI to see the event and its next scheduled run.

When to Keep Automatic Indexing or Choose a Different Setup

Don’t use Schedule Indexer just because FacetWP is installed. If editors frequently update individual items by hand, automatic indexing better matches the way the site is managed. A scheduled full reindex may leave a longer window during which new posts are not yet reflected in the facets.

The add-on is also not the best choice for a very large, constantly changing data set when a run must start at an exact time. FacetWP’s official documentation recommends considering WP-CLI and server cron for sites with a large amount of content or regular imports. They provide more control over timing and can run partial operations by post type, ID, or facet. That’s not a flaw in Schedule Indexer; it’s a practical limitation of WP-Cron as a WordPress mechanism.

Finally, don’t mistake “the facet isn’t showing the expected result” for a scheduling problem. If the facet is set to use the wrong source, the output template is not connected to FacetWP, or the item is excluded from the listing, a recurring full reindex will simply repeat the same underlying problem. First verify an individual item and the FacetWP configuration. Automate the recurring run only after that.

Choose One Way to Start the Index: Manual Run, Automatic Indexer, Schedule, or Server Job

FacetWP offers several valid ways to start a reindex. The problem isn’t that multiple options exist; it’s enabling them at the same time without defining who does what. To a site owner, that may look like “turn everything on, just in case.” To the server and anyone troubleshooting the setup, it means multiple processes may act on the same data in an unpredictable order.

The first option is the manual Re-index button on the Settings > FacetWP page. It’s useful when setting up a facet, checking after a structural change, or recovering from a known issue. The drawback is clear: someone has to remember to run it and know when a reindex is needed rather than another kind of fix. A manual run isn’t a reliable production workflow if the catalog changes overnight or data comes from an external system.

The second option is the automatic indexer, which FacetWP runs when an individual item is saved. This is a natural fit for a content site where an editor changes an item and expects to see it in the filters right away. It handles one change at a time. When changes are infrequent, the model is simple: saving an item and updating its index data happen together.

The third option is Schedule Indexer. It creates a recurring WP-Cron event that runs a full reindex. This works well for batches of data: first the entire data set is updated, then one full pass brings the index into sync. It does not make each editor’s click take effect immediately. Instead, it provides a recurring checkpoint.

The fourth option is a programmatic call or WP-CLI with server cron. FacetWP documents these methods for situations where you need to control what gets indexed and when. They are especially useful after imports and for large data sets. But setting them up requires a developer and an infrastructure process. The WordPress dashboard is no substitute for a well-planned server schedule.

A Simple Decision Matrix Before You Enable the Add-On

Match the type of change to an index trigger

Type of change	Preferred method	Why	What not to enable without a reason
An editor manually updates individual posts	FacetWP automatic indexing	Each update is tied to a single save	A recurring full reindex just in case
An occasional structural change to facets or sources	Manual Re-index	A deliberate full check is needed after a configuration change	Frequent cron runs without an update plan
A bulk sync where some delay is acceptable	Schedule Indexer	One full run after the data is updated is easier to manage	Automatic indexing running alongside the batch
A large catalog, frequent imports, or critical timing	WP-CLI and server cron	You need control over timing and the scope of the operation	Expecting WP-Cron to solve an infrastructure problem

The table doesn’t mean the setup can never change. For example, a team might temporarily switch to a manual run while investigating an incident. But the exception should be recorded in the log, and once the investigation is complete, the site should return to one clear primary method. Otherwise, a few weeks later no one may know which run happened last or why the public page changed when it did.

Why Two Concurrent Events Are Worse Than One Slow Event

Imagine an import that updates a thousand items. If automatic indexing reacts to each save, Schedule Indexer may also start a full pass during the same window. The first process sees only some of the updated data; the second uses resources to rebuild the entire index. Even if both finish without an obvious error, the overall process is hard to predict. In the worst case, database load gets in the way of the import, indexing, or site visitors.

That’s why FacetWP’s official recommendation to disable automatic indexing when using Schedule Indexer makes practical sense. It’s not a ban on features; it prevents them from competing. First choose one owner for the recurring process. Keep other methods for limited, documented tasks: a manual run after a structural change, a one-time index after a special import, or troubleshooting.

What Changes Require a Full Reindex

A full index isn’t needed after every action in the dashboard. FacetWP lists specific reasons: adding facets, changing facet settings, running a programmatic import, changing the term hierarchy, changing term custom fields, changing hooks that affect the process, registering post types, clearing the index table, and fixing indexing issues. This list is useful to include in the team’s internal instructions.

For example, changing a post’s description when it isn’t used in a facet doesn’t have to trigger an immediate full reindex. Moving a category to a new parent may require one, since the term hierarchy affects filtering. Understanding the difference saves resources and prevents false alarms. Editors should know that a post’s “published” status in WordPress and its “correctly indexed by FacetWP” status are related, but not the same.

Facet Data Rules: How to Tell a Stale Index from a Source Data Problem

The scheduler can only work with data FacetWP can index using its current configuration. Before automating anything, define a simple rule for each critical facet: where its value comes from, which item owns that value, who changes it, and what observable action will confirm the update. This is especially useful on sites with custom fields, taxonomies, and product variations.

Trace One Facet from the Editor to the Visitor

Take a “Region” facet. First identify its source: a taxonomy, custom field, product attribute, or another source supported by FacetWP. Then identify the data owner: the product, parent post, term, or external import. Next, describe how the value changes: an editor updates it manually, an import overwrites it, or an integration changes its relationship to a term. Finally, define the public check: which listing, facet value, and item should become visible?

This map takes only a few lines to write down, but it can sharply reduce troubleshooting time. When a visitor reports that the facet shows an old region, you don’t start with cron. First check the value on the post. Then check the facet source. Next compare it with the indexer’s last completion time. Only then look for a cache or queue issue. This order matters because Schedule Indexer can’t fix a value that was never saved correctly.

Custom Fields and Terms Need Different Test Cases

With custom fields, it’s often enough to select an item, change a text, number, or select value, and confirm that it appears in the facet after indexing. Terms can be more complicated. FacetWP specifically lists changes to the term hierarchy and term custom fields as cases that require reindexing. So the test set should include not only an item with a new term, but also an example where the parent relationship or an additional term field changes, if that field is used by the facet.

Don’t infer what’s in the index from the term’s name if the listing uses a different source. For example, a card may display a polished label from a template, while the actual facet indexes a meta field or attribute. Your public test should use the setting that corresponds to FacetWP’s data source. If you’re unsure, document the uncertainty and ask a developer to confirm the configuration rather than claiming an unverified connection.

Product Variations and Stock Visibility

In WooCommerce, one product can have multiple variations, and display rules may depend on stock status. This increases the volume of data and affects what you need to check. If the facet page doesn’t use variations, FacetWP’s documentation recommends leaving variation support disabled. If out-of-stock products shouldn’t appear in the listing, evaluate the setting for indexing those products separately. These settings aren’t “best” without context: on one site, visitors should see every option; on another, only items available to order should appear.

Choose one test product with a clear, simple condition. For example, according to the store’s rules, changing its availability should either hide it or leave it in the results. Don’t change its price, attribute, and stock status at the same time. One isolated test shows exactly what changed. If the condition still doesn’t behave as expected after a successful reindex, check the product visibility rules and listing query instead of increasing the Schedule Indexer frequency.

Don’t Let the Cache Hide the Outcome

A cache can make an index look stale. A browser, optimization plugin, object cache, CDN, or host-level cache may serve a previously generated page even though FacetWP rebuilt its data successfully. To avoid confusing the two, create a dedicated test procedure: use a private browser window, a fixed URL, and an approved method to bypass or clear only the cache relevant to the test.

The goal isn’t to clear every cache layer after each cron run. Clearing everything adds load and obscures the real cause of the problem. You need a sequence that provides evidence: FacetWP’s stats show that the run completed, a controlled query returns fresh results, and the regular public query is checked against the caching policy. If the first two steps work and the third doesn’t, you’re dealing with a cache issue, not a reason to change the schedule.

Record the Expected Outcome Before Automating

For each critical facet, create a test record with five fields: data source, test item, current value, new value, and public URL. Add a sixth field for the last successful Show indexer stats timestamp. This turns Schedule Indexer from an “invisible overnight plugin” into a verifiable part of the workflow: the data change has an owner, the index has a completion time, and the visitor-facing outcome has a specific page.

This discipline is especially useful before a theme update, custom code change, or site migration. If a facet behaves differently afterward, the team already has a small set of facts to compare. There’s no need to remember which filter “seemed to work” at some point. Run the recorded test and identify where the chain broke.

Before You Install: Check Your Data, Processes, and Constraints

This preparation step doesn’t need its own illustration because the main task is to map dependencies carefully. A scheduler is useful only when there’s a clear point at which “the data is ready.” Before enabling the add-on, make a short map: which items are indexed, who changes them and how, when the import finishes, which facets depend on those fields, and which page should show the outcome.

Make Sure FacetWP Works Manually First

Open the Settings > FacetWP page in the dashboard and confirm that the current configuration makes sense before automating it. For a test item, change one value used by a facet, then run a manual reindex with the Re-index button. FacetWP’s documentation says to save your changes and run a full reindex after adding or editing facets. When the run finishes, check the public listing in a new private browser window or after clearing the relevant cache.

The manual test answers two questions. First, does FacetWP find the item after a correct reindex? Second, does the expected page actually use that facet and listing? If the answer to either question is no, don’t move on to scheduling. Otherwise, you’ll automate an unverified operation and make troubleshooting harder: it will be difficult to tell a configuration problem from an event that didn’t run.

Confirm That You Need a Full Index

FacetWP’s official documentation says a full reindex is needed after changes such as adding a facet, changing its settings, importing content programmatically, changing the term hierarchy, changing term custom fields, replacing indexing hooks, or registering post types. These are specific reasons, and they’re more useful than a vague rule to “reindex occasionally.”

Also note what happens to custom fields. If an editor changes a post’s meta field through the usual form, the automatic indexer often covers that case. If an import or integration rewrites those values, the workload is different. Turning hundreds of rapid changes into hundreds of individual index updates may be inefficient. For this kind of process, it may make more sense to pause automatic indexing during the import and run one controlled full reindex afterward, or use a FacetWP method documented for imports.

Choose a Safe Window and Interval

Choose an interval based on three factors, not on a desire to see updates “as often as possible”: how often the data actually changes, how long a full index takes, and when the server is less busy. For a catalog updated once a day, a daily run may be more appropriate than an hourly one. A small directory with a few updates throughout the day may suit one of WordPress’s built-in intervals. For a custom schedule, first confirm that the frequency is necessary, then test it on a staging site or during a quiet period.

Remember that this is a full operation. When you click the regular Re-index button, FacetWP rebuilds the entire index. Schedule Indexer runs the same kind of task periodically. If you also start a bulk sync, clear the cache, or run a large backup at the same time, the processes will compete for database and CPU resources. The schedule should be part of the site’s overall maintenance calendar, not an isolated plugin setting.

Check the WP-Cron Environment Before the First Run

WP-Cron is not a continuously running system daemon. The WordPress handbook explains that it checks for tasks on page loads and runs events that are due at that point. The implication matters: an interval sets how often an event recurs, but doesn’t guarantee that processing will start to the second. On a site with steady traffic, the delay may be unnoticeable. On a private portal, new catalog, or internal site, it may matter a lot.

Ask your hosting administrator whether WP-Cron is disabled in the WordPress configuration. Schedule Indexer cannot override that setting on its own. If WP-Cron was disabled for performance reasons, the right next step is to coordinate a server scheduler and, for a large task, consider running the index through WP-CLI. Don’t run unfamiliar commands on a production server just because an article provides an example: the installation path, user permissions, and schedule depend on the project’s infrastructure.

Install FacetWP Schedule Indexer and Run a Controlled First Check

Install the add-on only as an official extension to a working FacetWP setup. FacetWP’s official instructions describe the usual process: download the add-on file from your account, upload it to WordPress through Plugins > Add Plugin > Upload Plugin or place its folder in /wp-content/plugins/, then activate it. This guide doesn’t cover obtaining files, license keys, or purchases; it assumes you already have a legitimate add-on archive.

Install It with Minimal Risk

1. Back up the site or confirm that you have a working rollback point before changing the set of plugins.
2. Make sure the main FacetWP plugin is active and that a manual reindex completes with the current amount of data.
3. Upload the Schedule Indexer ZIP file through Plugins > Add Plugin > Upload Plugin, then activate the add-on.
4. Open Settings > FacetWP and avoid changing several unrelated settings at once. First record the current automatic indexing mode.
5. Choose a test item and a page where you’ll be able to see a facet value update.

After activation, the add-on creates a WP-Cron event that runs a full index. According to its documentation, the initial interval is hourly. Don’t treat that as a recommendation for every site. At first, just confirm that installation registered the task and FacetWP can complete it using your data.

Why You Should Start with a Small Test

Choose a test post, product, or catalog item that’s easy to find. Change one value visible through a facet, such as assigning a known category or changing a verified custom field. Don’t make several changes at once. Then record the initial state: which facet selection found the item before the change and what should happen after a successful reindex.

You don’t have to wait for a visitor to happen upon the site. Open a cron event viewer, find the fwp_scheduled_index task, and confirm that it recurs and has a next scheduled run. For a controlled test, you can use an administrator tool to run that scheduled task if the project’s rules allow it. After it runs, check both the public page and FacetWP’s stats. The dropdown next to the Re-index button has a Show indexer stats option that shows when the indexer last completed.

Key requirement for the first test: the event must be registered, FacetWP’s stats must show that the indexer completed after the test, and the test item must behave as expected in the public listing. Seeing the plugin in the Plugins list is not enough.

What Not to Do Right After Installation

Don’t run several full reindexes in a row, leave automatic indexing active “just in case,” or change the interval, custom code, and import settings all at once. This doesn’t make the check faster. It only makes it impossible to tell which operation updated the index.

Don’t stop the indexer unless you have a reason to. FacetWP’s documentation warns that after you click Stop indexer, the index remains incomplete until the next full reindex. If you stop it by mistake, don’t treat the public results as a baseline. Schedule or run a proper full pass, wait for it to finish, and then repeat the test with one item.

Key Setting: Coordinate Schedule Indexer with Automatic Indexing

This is the most important part of the guide. Schedule Indexer is for running a full index periodically. FacetWP’s automatic indexer handles individual changes when items are saved. If you leave both mechanisms enabled without assigning clear roles, they may start multiple processes against the same data. Schedule Indexer’s official instructions specifically recommend disabling automatic indexing to prevent concurrent indexing events.

Configure It in FacetWP

The current FacetWP configuration includes an Enable automatic indexing setting. It’s enabled by default and makes sense for most typical use cases. However, for the chosen model of “a scheduled full index,” you should disable it. Open the FacetWP settings, find the option, save the change, and record it in the site’s technical documentation: who owns the schedule, what interval you chose, and where you verify that it ran.

Disabling the option doesn’t mean FacetWP has stopped indexing altogether. You’re changing what starts the process, not what the indexer does. Manual reindexing and the scheduled event still work. But editors need to understand the new workflow: a change may not appear in facets when it’s saved; it may not show up until the next successful scheduled full index.

When a Documented Filter Makes Sense

FacetWP also provides the facetwp_indexer_is_enabled filter, which can disable automatic indexing in code. You don’t need it just to use Schedule Indexer, since there’s a setting in the dashboard. Use code only if your team tracks these policies in version control, needs to disable indexing temporarily as part of a special process, or cannot safely rely on a manual setting.

Here’s a minimal example based on FacetWP’s documented approach. Add it to a child theme, the Custom Hooks add-on, or a managed snippet plugin-not to WordPress core, FacetWP, or the add-on’s files. Back up the site before making the change, and confirm that Schedule Indexer is installed and active.

<?php
// Disable automatic FacetWP reindexing.
// Use this only when a schedule or your own workflow manages full updates.
add_filter( 'facetwp_indexer_is_enabled', '__return_false' );

After saving the code, check two things. First, the FacetWP dashboard should show a clear indication that an external filter overrides the automatic indexing setting. Second, after you manually change the test item, don’t expect its facet value to update immediately; wait for the next scheduled or manual full run. To roll back the change, remove or disable only this snippet and set Enable automatic indexing as needed. Don’t delete tables or edit the database by hand.

How to Explain the New Delay to Editors

A managed delay is not an error if everyone has agreed to it in advance. For example, editors may update the catalog before 6:00 p.m., with the full index scheduled for a quieter window. Until the index finishes, the old value may still appear in the results. That’s expected with a batch update model. It becomes a problem only if the team promises that facet results will update immediately or if the task never runs.

Keep a short operations log with the next run time, target interval, server contact, and steps for checking Show indexer stats. This is more useful than adding another code change. It helps editors distinguish normal waiting from an incident and keeps them from starting multiple resource-intensive manual reindexes.

Choose an Interval: Built-In Schedules, Custom Intervals, and WP-Cron’s Limits

Schedule Indexer uses WordPress’s wp_schedule_event() function. The add-on supports the built-in intervals hourly, twicedaily, daily, and weekly. These are recurrence intervals, not guarantees that a task will start at a specific local time. WordPress says an event runs when it’s due and someone visits the site, so you need a system scheduler for business processes that require minute-level timing.

Choose a Built-In Interval Without Overloading the Site

An hourly schedule makes sense when changes really arrive several times a day and a full index completes within an acceptable load window. Twice-daily runs can suit catalogs with morning and evening batch updates. Daily is often a reasonable starting point for an overnight sync. A weekly interval is suitable only for occasional accumulated changes that don’t need to appear sooner.

Don’t choose a frequency based only on site size. A small catalog with expensive computed custom fields may take longer to index than a large but simple set of posts. FacetWP notes that the number of post types, posts, product variations, facets, and choice values, as well as server and database speed, all affect the size and duration of the index. The right interval should be based on observing your first completed run, not on a general number from someone else’s guide.

A Safe Example: Switching to a Daily Schedule

The official facetwp_index_schedule hook lets you pass a different built-in interval to the add-on. If a daily update fits your workflow, a minimal snippet looks like this:

<?php
// Tell Schedule Indexer to use WordPress's built-in daily schedule.
add_filter( 'facetwp_index_schedule', function() {
    return 'daily';
}, 10 );

Store this code in the same place as other tested changes to your theme or site. After adding it, deactivate and reactivate Schedule Indexer if the add-on’s documentation recommends doing so to register the event again. Then open WP Crontrol and confirm that the recurrence for fwp_scheduled_index has changed. Don’t just check that the code exists; verify that WordPress registered the event with the right interval.

Rolling back is simple: disable the snippet, reactivate the add-on, and confirm that the event has returned to the built-in interval you want. Before rolling back, make sure an index isn’t running. Don’t leave the old snippet and a new schedule active at the same time as a “backup”-that can make the frequency unpredictable again.

When to Use a Custom Interval

A custom interval makes sense when it matches a real workflow-for example, imports run every 15 minutes and the server has been shown to handle a separate full index each time. But the ability to create a custom interval doesn’t mean you should make it very short. WP-Cron stores recurrence as an interval in seconds, and WordPress runs overdue events on the next site visit. On a low-traffic site, “every 15 minutes” may really mean “after the next visit.” On a busy site, it may create too much recurring load.

Here’s the pattern from FacetWP’s documentation: first add a custom schedule through WordPress’s standard cron_schedules filter, then return its name through facetwp_index_schedule. In this example, the identifier quarterly means an interval of 900 seconds. You can rename it, but the name must match in both parts of the code.

<?php
// Add a schedule with a 900-second interval.
add_filter( 'cron_schedules', function( $schedules ) {
    $schedules['quarterly'] = array(
        'interval' => 900,
        'display'  => __( 'Once Every Quarter' )
    );
    return $schedules;
} );

// Pass the new schedule to Schedule Indexer.
add_filter( 'facetwp_index_schedule', function() {
    return 'quarterly';
}, 10 );

After saving, first open the Cron Schedules tab in WP Crontrol and look for the new schedule with the correct interval. Then open Cron Events, find fwp_scheduled_index, and check the selected recurrence. If the schedule isn’t listed, WordPress didn’t register your filter. If the schedule is listed but the event isn’t, check the code and then deactivate and reactivate the add-on. To undo the experiment, remove both parts of the snippet and reactivate the add-on; don’t edit WordPress system data by hand.

Why “Every N Minutes” Doesn’t Mean an Exact Run Time

WP-Cron’s behavior deserves a closer look. WordPress describes its scheduler as a system that uses intervals to simulate a regular system cron. When a visitor arrives, WordPress checks the queue and runs any overdue events. This is convenient for everyday tasks because not every host provides access to a system scheduler. But it matters when you run a full index. If an import ends at 2:00 a.m. and the first public page load is at 4:30 a.m., the event may start later than expected.

Don’t try to fix this by shortening the interval to a few minutes. That can make the load less predictable, but it doesn’t turn WP-Cron into a system service. For a site with a critical update window, coordinate a server job with your infrastructure team to trigger WP-Cron, or use FacetWP’s documented WP-CLI method. Keep the responsibilities clear: Schedule Indexer manages a WordPress event; reliable system-level invocation depends on the server configuration.

Example Workflow: An Overnight Catalog Import and a Verified Morning Index

Consider a concrete example without assuming a specific integration exists. A site publishes an equipment catalog. Its items are products or custom post types, and the import updates the manufacturer, availability, region, and technical specifications. A public listing uses FacetWP to filter by these fields. The import runs in batches during a quiet window. The administrator’s job is to prevent the automatic indexer from running dozens or hundreds of times as data arrives, then get one verified full index after the batch is complete.

Goal and Initial State

The goal isn’t to promise that the facet “will be faster.” It’s measurable: a new item from the latest batch appears in the right filter combination, an item with a removed or changed value no longer produces the old result, and the stats show a completed run after the update window. Before starting, choose three test items: one new item, one with a value that will change, and one that should no longer match a group. This is more reliable than testing a single example because it checks additions, changes, and disappearing results.

Check the initial state. Record the item names, their current values, and the listing URL. Note which facet and value you’ll use for the test. If the catalog is cached, decide in advance how you’ll check the public page without seeing old HTML from the browser or an intermediate cache. You don’t need to clear the entire site; just identify which layer might serve an old copy and how to get a fresh response safely.

Step 1: Separate the Import from Indexing

If an import changes many items, disable FacetWP automatic indexing for the managed workflow. That follows Schedule Indexer’s basic recommendation. If imports are rare and run manually, an administrator can temporarily turn off Enable automatic indexing before the import and restore it afterward. But for a recurring process, it’s safer to choose one permanent setup, document it, and avoid depending on someone’s memory.

FacetWP’s documentation covers WP All Import specifically: while many items are being inserted or saved, the automatic indexer can cause performance problems. The recommended approach is to prevent indexing during the import and start it after the import finishes. This supports the general principle, but it doesn’t mean you should copy complex snippets into any import tool. If you use a different tool, rely on its documented completion hooks and test them on a staging site.

Step 2: Set a Realistic Schedule

Suppose the import usually finishes overnight and the filters need to be current by the start of the workday. Don’t start with an extremely short interval. Try a daily schedule or another suitable built-in interval, and make sure the run happens after the import rather than alongside it. If WP-Cron depends on visits, arrange an agreed-upon server trigger or accept an allowable delay. You can’t guarantee an exact time unless the server setup supports it.

If the business process requires an exact run time, don’t try to hide that requirement in a Schedule Indexer setting. Give the infrastructure team a clear request: “After a successful batch import, start the approved indexing process and record its outcome.” FacetWP recommends WP-CLI with server cron for large catalogs because it provides control over what is indexed and when. Schedule Indexer is simpler for tasks where WP-Cron’s delays are acceptable.

Step 3: Confirm That the Event Was Created

If your site policy allows a diagnostic plugin, install WP Crontrol from the official WordPress directory. It provides the Tools > Cron Events and Settings > Cron Schedules screens. Find fwp_scheduled_index in the event list. Check four things: the event exists, it has the expected recurrence, it has a next run time, and it isn’t overdue without a clear explanation.

If you chose a custom interval, look for it on the schedules page first. A simple mistake often shows up here: the snippet exists but isn’t active, its name is misspelled, or the add-on was activated before the schedule was added and didn’t register the updated event. Don’t fix this by deleting random database entries by hand. Check the code, confirm the names match, then deactivate and reactivate Schedule Indexer in a controlled way and check the list again.

Step 4: Wait for or Start One Test Run

Run the first test when your team can monitor the outcome. Open Settings > FacetWP, keep the page open if possible, and watch the progress indicator after the run starts. FacetWP recommends keeping the settings page open during a regular reindex; you can also check progress through the rotating icon. Don’t click Re-index a second time before the first run finishes.

When the event is due, remember how WP-Cron works. If the site gets little traffic, load a few public pages to give WordPress a chance to process its queue. This is a test of the mechanism, not a long-term maintenance strategy. After the run finishes, open the Re-index menu, choose Show indexer stats, and record the last completion time in the procedure log.

Step 5: Verify the Outcome on a Public Page

Now test the three items you prepared. For the new item, select the relevant facet value and confirm that it appears. For the changed item, check the new value and confirm separately that the old value no longer returns it. For the excluded item, confirm that it no longer appears in the wrong set of results. This verifies not only that the events exist, but also the business outcome the index is meant to support.

If the outcome differs from what you expected, don’t conclude that “the schedule is broken” before you identify the cause. First check FacetWP’s stats. If there’s no record of a completed run, investigate cron. If there is, check the saved item value, whether the selected facet applies, the listing, and the cache. If only one item behaves oddly, run a manual reindex and review the server logs. That’s faster than changing the interval several times.

How to Verify That the Schedule Ran: Check the Event, Stats, and Public Results

A proper check has at least three independent levels. First, WordPress knows about the task. Second, FacetWP shows that the indexer completed. Third, the facets on a public page reflect the changes. Each level catches a different kind of problem. Don’t treat them as interchangeable.

Level 1: The fwp_scheduled_index Event in the Queue

In WP Crontrol, open Tools > Cron Events, search for fwp_scheduled_index, and check the recurrence column. When configured correctly, it should show the selected built-in or custom interval. If the event isn’t there, WordPress has nothing to run. Don’t check the catalog yet; first fix the event registration, schedule code, or add-on activation.

If the event exists but its next run time is long past, don’t edit it at random. Check whether WP-Cron is working, whether the public site has had activity, and whether the server is blocking outgoing or internal requests. FacetWP’s official documentation notes that WP-Cron is triggered by public site activity. Low traffic and disabled WP-Cron are different causes, so check them separately.

Level 2: The Last Completion Time in FacetWP

The dropdown next to Re-index and its Show indexer stats option provide evidence from FacetWP itself. After the expected run, check whether the last completion time has changed. This matters because an event can exist without completing successfully. For example, the process may have stopped because of resource limits, a problematic item, or a server restriction.

Don’t judge completion by whether the settings page loaded without an error. The indexer has a status and stats. If a run appears stuck, give it a few minutes: FacetWP documents an automatic resume for temporarily stalled runs if the settings page remains open. If it repeatedly stalls at about the same percentage, treat that as a diagnostic clue. You’ll need logs and a data check, not simply more time until the next hourly run.

Level 3: Confirm the Outcome in the Listing

Your public test should be repeatable. Use a recorded listing URL, the same sequence of actions, and known test items. First apply a facet that should include the test item. Then reset the selection and apply a condition that should exclude it. Check the item itself, not only the number of results. This matters when several items have similar titles or the listing has its own sorting rules.

If the site uses caching, record which layer you bypassed or cleared for the test. Caching a page and indexing data are not the same thing. Old HTML served by a browser is not evidence of a fresh index. But clearing every cache after each run shouldn’t become an automatic habit either: first find out which layer is storing the stale result.

A Quick Verification Matrix

Three checks to make after a scheduled reindex

What to check	Where to check	Expected sign	What a failure may mean
Task registration	Tools > Cron Events	fwp_scheduled_index exists with the expected interval	The add-on or custom schedule did not register the task
Indexer completion	Settings > FacetWP, Show indexer stats	The last completion time matches the run being checked	The event may not have run, or the indexer may not have finished
Updated results	Public listing with test items	The new value finds the item; the old value does not	The issue may be in the data, facet configuration, listing, or cache

A run counts as successful only after all three checks pass. A cron entry without updated stats doesn’t prove that indexing occurred, and updated stats without a correct listing don’t prove the visitor-facing outcome.

Large Catalogs, Imports, and Performance: Where Schedule Indexer Stops Being Convenient

Schedule Indexer has a clear advantage: it provides a simple recurring full reindex within WordPress. But a full index becomes more demanding as the data set and data model grow. FacetWP’s documentation notes that a large number of post types, items, WooCommerce variations, facets, and choices can quickly increase the number of index rows. So performance planning starts with the amount of data you actually need to index, not with the interval.

Reduce Unnecessary Work Before Scheduling

Check which post types FacetWP considers indexable. The dashboard has a Show indexable post types command. It’s a useful starting point for a conversation with a developer: should internal post types, old items, or unused entities be included in a full run? If they aren’t needed for facet listings, indexing them adds cost without helping visitors.

In stores, variation support and indexing out-of-stock products also matter. In its performance guidance, FacetWP recommends disabling variation support if variations aren’t used on the facet page, and not indexing out-of-stock products if they aren’t displayed. Don’t turn these options on or off by default. The right choice depends on what customers actually see. First define the display rule, then make sure the index settings match it.

Imports: One Well-Timed Index Is Better Than Several Competing Runs

With batch imports, the main risk is overlapping processes. Posts and terms may be saved repeatedly during the import. If the automatic indexer reacts to each action, load increases and the update process becomes harder to follow. For WP All Import, FacetWP recommends preventing automatic indexing during the import and running it after the import finishes. For recurring imports, this is usually better than hoping an hourly schedule happens to run at the right time.

If you build the workflow around Schedule Indexer, coordinate it with the import. In one setup, the import finishes well before the next event, so a periodic full run is appropriate. In another, a documented import completion hook that starts a one-time reindex may be a better fit. A third option for larger projects is server cron with WP-CLI. Don’t use all three methods at once without a clear reason. Choose one primary method, and keep the others as controlled manual recovery tools.

When to Move to WP-CLI and Server Cron

FacetWP recommends WP-CLI for sites with a large volume of frequently changing content and regular imports. Unlike a run started by a button in the browser, a command-line run isn’t subject to web-page PHP process limits in the same way, and it can perform full or partial operations. The documentation says you can limit indexing by post type, ID, or facet, while server cron gives you control over when it starts.

This is not an invitation to run a command at random. Moving to this setup requires server administrator access, documentation for your WP-CLI installation, a test environment, and an accepted rollback plan. As a site or content owner, watch for signs that you’ve reached the limit: the index regularly runs past its acceptable window, WP-Cron starts too late, the catalog is large and changes often, and imports already run on a server schedule. At that point, create a technical task instead of setting increasingly short WordPress intervals.

Why Automatic Indexing Should Stay Disabled with an Alternative Trigger

When an external process starts a full index, FacetWP also recommends disabling automatic indexing. The reasoning is the same as with Schedule Indexer: one managed trigger is easier to monitor and safer for server load than overlapping operations. But this isn’t an absolute rule for every site. If your setup needs to reflect individual editorial changes immediately and also run a full index overnight, a developer should make that decision after measuring the workload and defining which changes each method handles.

Small, Safe Improvements Without Editing Plugin Core

For this setup, decorative CSS changes aren’t particularly useful. Two small, reversible improvements are: using the documented filter to choose a schedule, and confirming that automatic indexing is disabled only when you’ve chosen a batch update model. Both approaches use official FacetWP hooks. Neither requires changes to WordPress core, FacetWP files, or Schedule Indexer’s source code.

Keep Snippets Separate from the Theme You Update

FacetWP’s documentation allows you to add PHP to a child theme’s functions.php, the Custom Hooks add-on, or a snippet plugin. For long-term maintenance, choose a location the team can identify and disable. If you edit a child theme, record the file path and keep a backup. If you use Custom Hooks, its main advantage is that it isolates custom code from the theme and makes rollback easier through deactivation.

Add a comment to each snippet explaining its purpose, the date of the internal decision, and who owns the process. Don’t store credentials, server addresses, or private keys in code. The point isn’t to make the code more complicated; it’s to help an administrator understand six months from now why Enable automatic indexing is disabled and what process replaced it.

A Short Run Log Is Often Better Than More Code

The most useful improvement is often organizational. Add a short entry to the project documentation with five items: the chosen interval, the expected run window, the fwp_scheduled_index event name, where to check Show indexer stats, and the test listing URL. Add an escalation rule: if the stats haven’t updated within the acceptable window, check the cron event first, then logs and resources; don’t keep starting manual reindexes.

This log prevents a common problem when staff change. A new editor sees an outdated product in a filter and enables automatic indexing without knowing about Schedule Indexer. That creates competing processes. Documented settings make the system easier to understand: the delay until the next run is expected, while a missing event or stats update indicates a specific problem.

Safely Roll Back an Interval Experiment

If you tested a custom interval and saw excessive load, first disable the snippet that adds and selects it. Then reactivate the add-on according to the developer’s instructions, check that the event disappeared or changed in WP Crontrol, and wait for any current index run to finish. Finally, restore a conservative built-in interval and run one test.

Don’t delete the index table by hand, paste SQL commands from random discussions, or disable WP-Cron before a server scheduler is set up. A rollback should return the system to a known working configuration, not create a gap where no process keeps the index current.

Troubleshooting Schedule Indexer: Symptoms, Causes, and Safe Fixes

You can’t diagnose a scheduling problem based only on “the filter didn’t update.” The cause may be in the data, FacetWP itself, the WP-Cron queue, server resources, the import, or a cache. The symptoms below start with the easiest facts to observe and move on to more involved checks.

The Event Is Missing from WP Crontrol

Symptom: A search for fwp_scheduled_index in Tools > Cron Events returns no results. Likely cause: The add-on is inactive, the custom schedule has an error, or the event wasn’t registered after a configuration change. Check: The plugin list, whether Schedule Indexer is active, and whether the custom schedule identifier appears with the exact same spelling in both filters.

Fix: Correct one confirmed cause, then deactivate and reactivate the add-on in a controlled way and check the list again. If you’re using a custom interval, first confirm that it appears on the Cron Schedules tab. When to roll back: If the test snippet doesn’t register the schedule or your team can’t maintain it safely, remove both parts of the snippet and return to a built-in interval.

The Event Exists, but the Index Doesn’t Run When Expected

Symptom: fwp_scheduled_index is present, but Show indexer stats has no new completion time. Likely cause: A low-traffic site had no public activity, WP-Cron is disabled, or a server issue is preventing the queue from running. Check: Whether public pages were loaded after the event was due, whether your host says WP-Cron is disabled, and whether the cron tools show overdue tasks.

Fix: Generate public traffic for the test, then check FacetWP’s stats again. If the task is time-critical, don’t rely on random visits to keep it running; coordinate a system scheduler or WP-CLI with the server administrator. When to roll back: If you chose Schedule Indexer for a precise workflow that WP-Cron cannot reliably support, don’t try to compensate with a shorter interval. Return to manual runs until a suitable server setup is in place.

The Indexer Stops or Repeatedly Stalls at About the Same Percentage

Symptom: A run starts but the completion stats don’t update, or it stops around the same point after waiting. Likely cause: FacetWP lists insufficient memory, a blocked internal wp_remote_post() request, an issue with the facetwp_indexer_cron task, or a specific post that triggers an error among common causes. Check: The server error log, /wp-content/debug.log if debugging has been enabled safely, internal request access, and cron activity.

Fix: First give the built-in resume mechanism a few minutes to work without closing the settings page. If the problem keeps happening, send your host the exact time, percentage, and logs. Isolate a suspicious import or item in a test environment. When to roll back: If the issue started right after a new hook was added, disable that specific change and run one proper full index. Don’t reduce the memory limit, edit database tables, or start several processes at once.

Facet Results Still Show Old Data After the Stats Confirm a Successful Run

Symptom: The last completion time is recent, but the public results don’t match the test item. Likely cause: The saved value is wrong, the facet uses the wrong source, the listing is different, the page is cached, or another visibility rule applies. Check: The saved item in the dashboard, the specific facet setting, the public URL, the results without the cache, and whether the selected value should be indexed.

Fix: Repeat the test with one simple item and one manual reindex. If the issue remains, investigate the FacetWP configuration rather than the schedule. When to roll back: If you find that Schedule Indexer doesn’t address the original problem, you can temporarily switch to a manual check. But don’t enable automatic indexing without deciding who owns future data updates.

The Server Reports Errors During an Import or the Catalog Is Only Partially Updated

Symptom: Server-level errors appear during a bulk import, the import slows down, or the facet index behaves inconsistently. Likely cause: Automatic indexing starts repeatedly during the import, or a scheduled full run overlaps with it. FacetWP describes these risks specifically for WP All Import. Check: The import time, whether automatic indexing is enabled, the fwp_scheduled_index schedule, and the error logs.

Fix: Separate the processes: temporarily or permanently disable automatic indexing according to the chosen setup, and run the index after the import finishes. For large data sets, consider WP-CLI and server cron. When to roll back: If the changed workflow fails its test, return to the last documented working setup. Don’t continue importing on the production site until you know what caused the problem.

The Custom Interval Is Listed but Isn’t Applied to the Event

Symptom: The interval appears on the Cron Schedules page, but fwp_scheduled_index still shows a different schedule. Likely cause: The facetwp_index_schedule filter returns a different name, the code wasn’t loaded when the event was registered, or the add-on didn’t register the event again. Check: That the identifiers match, there are no duplicate snippets, and the code is loaded in the right order.

Fix: Keep only one version of the code, check its syntax in a test environment, then reactivate the add-on and check the event. When to roll back: If daily, twicedaily, or hourly meets your needs and a custom interval hasn’t shown a clear benefit, return to a built-in interval. It’s easier to maintain.

Posts in One Language Disappear from a Multilingual Site After a Cron Reindex

Symptom: After a scheduled run, posts in one language no longer appear in the index or facet choices. Likely cause: FacetWP documents a known issue involving WPML, Post Types Order, and cron indexing, including use with Schedule Indexer. The issue is associated with the Auto Sort setting being enabled in Post Types Order. This isn’t a general diagnosis for every multilingual site; confirm that the affected plugins are installed.

Check: Whether WPML and Post Types Order are both active, cron indexing is in use, the issue appears only after a scheduled run, and Auto Sort is enabled. Fix: First test disabling this setting on a staging copy, following FacetWP’s official instructions. Then run a controlled reindex and check test items in every language. When to roll back: If sorting is critical for other queries, don’t apply the change to the production site without a developer. The documentation warns that you may need to set orderby explicitly in the relevant WP_Query calls.

Common Questions About Running a Schedule

Do I Need to Reindex After Every Post Is Saved?

No. If FacetWP automatic indexing is enabled, it handles individual saves. If you’ve deliberately chosen Schedule Indexer and disabled automatic indexing, changes will appear after the next successful scheduled run or a controlled manual full reindex. Choose one clear method for each workflow.

Which Interval Should I Choose for FacetWP Schedule Indexer?

Start with a frequency that matches how often the data actually changes. WordPress’s built-in options are hourly, twicedaily, daily, and weekly. Don’t shorten the interval just to keep data fresher. Consider how long a full index takes, database load, site traffic, and when the import finishes.

Why Did the Event Run Later Than Its Scheduled Time?

WP-Cron runs overdue tasks when there’s public site activity; it doesn’t run continuously like system cron. On a site with few visitors, a run may be delayed. If timing is critical, discuss a system scheduler or server cron with WP-CLI with your host. WP Crontrol and Show indexer stats are useful for checking whether a run was delayed.

Should I Disable Enable automatic indexing When Using the Add-On?

Yes. Schedule Indexer’s official documentation recommends disabling automatic indexing to avoid overlapping indexing events. This applies when the add-on manages recurring full updates. If your site has a more complex setup, make the decision with a developer and don’t leave both methods active without a clear reason.

Can I Set a Custom Interval, Such as Every 15 Minutes?

Yes. First add a schedule through WordPress’s cron_schedules filter, then return its name through the facetwp_index_schedule filter. But do this only after measuring the server load. A short interval doesn’t guarantee precise timing because of how WP-Cron works, and it may create repeated resource-intensive tasks.

How Can I Tell Whether a Full Index Finished?

Open the menu next to the Re-index button on the Settings > FacetWP page and choose Show indexer stats. Compare the last completion time with the expected run, then verify the outcome using a test item on a public page. Stats and correct results together provide a reliable answer.

What Should I Do If the Indexer Stalls?

First, wait a few minutes and keep the settings page open: FacetWP can resume a temporarily stalled process. If the problem keeps happening, check the error logs, memory, the internal wp_remote_post() request, the facetwp_indexer_cron event, and any suspicious items. Don’t start parallel manual reindexes.

Is Schedule Indexer a Good Fit for a Large WooCommerce Catalog?

It may be part of the solution, but it doesn’t replace an assessment of your data volume and server. FacetWP says product variations, the number of facets and choices, and the amount of content all affect indexing. For a large catalog with frequent updates and regular imports, consider WP-CLI and server cron, and limit indexing to the data you actually use.

When FacetWP Schedule Indexer Is the Right Choice

FacetWP Schedule Indexer is useful when a site receives batch updates and the team needs one clear, recurring time for a full index refresh. It’s especially suitable when you’ve tested manual reindexing, disabled conflicting automatic indexing, chosen a realistic interval, and built a verification process around the fwp_scheduled_index event, FacetWP stats, and the public listing.

If data changes one item at a time and needs to become available right away, FacetWP’s built-in automatic mode is probably simpler. If the catalog is huge, imports are frequent, or run timing is critical, consider moving to WP-CLI and server cron. Otherwise, start with a conservative schedule, one test workflow, and clear process documentation. Once the setup passes your checks, you can download the FacetWP Schedule Indexer archive and deploy it on a staging copy of the site before moving to production.