Cache Autopilot – Documentation

Troubleshooting

Updated:

25. September 2026

URLs Not Warming After Changes

Possible causes

Cache Invalidator disabled

Check that the main switch is enabled.

Post Type not enabled (or relationiship not set)

See: Cache Invalidator → Post Type Tabs to verify your configuration.

Sitemap membership

The URL may not be present in configured sitemaps. Only URLs included in your sitemap are eligible for targeted warmup.

Membership is maintained automatically in the background. If a URL was recently added or changed, it may take a short moment to be included.

See: Cache Invalidator → Settings Reference to verify your configuration.

Verify

the URL appears in your sitemap
the URL is canonical (matches sitemap format)

Automatic Cache Warmup disabled

Check the warmup main switch.

No cache adapter detected

Both engines are designed to operate with a supported cache plugin. Without one, invalidation and warmup have no practical effect.

Full warmup preparing

If a full warmup is currently preparing, targeted URLs may be buffered and warmed shortly after preparation completes.

See: Cache Warmup → Settings Reference to verify your configuration.

Cache Plugin Recommendations

Cache Autopilot works alongside your existing cache plugin. The recommendations below help avoid unnecessary cache expiry, duplicate purges and duplicate preload activity.

Leave unrelated features — such as object cache, CSS/JS optimisation, image optimisation and fonts — unchanged unless specifically noted.

General recommendations

Cache lifespan

If your cache plugin automatically expires page cache after a fixed period, consider disabling that expiry where possible or setting a very long lifespan, such as one year.

Cache Autopilot refreshes affected pages when content changes, so a short fixed cache lifetime is usually unnecessary. Otherwise-valid cached pages may expire and need to be rebuilt even though nothing affecting them has changed.

A long cache lifetime still provides an additional fallback while allowing invalidation to remain the primary freshness mechanism.

Native preload

If your cache plugin includes its own preload feature, you can continue using it instead of Cache Warmup.

Before relying on it, verify that it actually preloads pages after individual URL purges. Behaviour differs between cache plugins.

Cache Warmup provides a predictable alternative by rebuilding the pages Cache Autopilot has just purged, using paced background requests with its own queue, progress tracking and logs.

We generally recommend using one preload system to avoid requesting the same pages twice unnecessarily.

Automatic purge rules

If your cache plugin automatically purges additional pages whenever content is published or updated, consider disabling or reducing those rules.

Cache Autopilot already determines which pages are affected and purges those target URLs directly. Additional broad purge rules can remove otherwise-valid cached pages unnecessarily.

Keep native purge behaviour that covers something Cache Autopilot does not manage.

Mobile cache variants

Some cache plugins can create separate cache entries for mobile and desktop visitors.

On responsive sites that serve the same HTML structure to both, we generally recommend leaving separate mobile caching disabled. Extra cache variants increase the number of cached entries that need to stay fresh and can leave additional copies behind after a targeted purge.

Enable a separate mobile cache only when the site actually serves different page output to mobile devices and the cache plugin requires it for correct behaviour.

LiteSpeed Cache

The following LiteSpeed Cache settings are recommended when Cache Autopilot is handling targeted cache refresh and warmup.

These settings have been tested successfully on shared LiteSpeed hosting, including cyon, where LiteSpeed Crawler is not available.

Cache TTLs

For sites relying on Cache Autopilot for freshness, we recommend:

Default Public Cache TTL: 31536000 seconds (1 year)
Default Front Page TTL: 31536000 seconds (1 year)
Default Feed TTL: 31536000 seconds (1 year)
Default REST TTL: keep the LiteSpeed default
403 / 404 TTL: around 3600 seconds (1 hour)
500 TTL: keep short, for example 600 seconds (10 minutes)

The long public-page TTL is intentional: valid cached pages can remain cached until a relevant change causes Cache Autopilot to refresh them.

REST responses and temporary error responses should remain more conservative because they are not part of the same page-refresh lifecycle.

Automatic purge rules

Under Purge → Auto Purge Rules For Publish/Update, disable the broad automatic purge targets when Cache Autopilot is responsible for content changes.

This avoids LiteSpeed independently purging pages beyond Cache Autopilot’s resolved target list.

We recommend keeping Purge All On Upgrade enabled. WordPress core, plugin and theme updates can affect frontend output in ways that cannot always be resolved safely to individual pages.

Purge All Hooks

The default LiteSpeed purge-all hooks can usually be removed when the corresponding changes are already handled by Cache Autopilot.

Keep any hook you still rely on for functionality outside Cache Autopilot’s supported triggers.

Cache logged-in users

For typical public websites, we recommend:

Cache Logged-in Users: OFF

LiteSpeed creates separate private cache entries for logged-in sessions. These are outside the normal public-cache lifecycle and usually provide little benefit on sites where editors primarily use the WordPress admin.

Sites with significant logged-in frontend traffic may have different requirements.

We recommend:

Cache Login Page: OFF

Caching the login page provides no benefit to Cache Autopilot’s public-page lifecycle.

Guest Mode

We recommend leaving Guest Mode OFF when using Cache Warmup. Guest Mode introduces an additional cache representation that LiteSpeed selects through a browser-side vary handshake after the initial page request.

Cache Warmup preloads public page URLs through HTTP requests and does not reproduce that Guest Mode handshake.

Serve Stale

We recommend leaving Serve Stale OFF by default.

After Cache Autopilot purges an affected page, Cache Warmup normally rebuilds it shortly afterwards. Leaving Serve Stale disabled gives the clearest freshness behaviour: once an old cache entry is removed, it is no longer served.

Serve Stale can still be useful on high-traffic sites where avoiding even a short cold-cache window is more important than immediately removing the previous cached response.

LiteSpeed Crawler vs Cache Warmup

LiteSpeed Crawler and Cache Autopilot’s Cache Warmup can both populate the page cache, but they approach the job differently.

For straightforward public-page caching, both ultimately rebuild cache entries by requesting URLs; the main difference appears when one URL can have multiple cache representations. LiteSpeed Crawler can proactively crawl configured cache variants, roles and cookie-based views, while Cache Warmup focuses on the public URLs selected for targeted refreshes or full warmups.

	LiteSpeed Crawler	Cache Warmup
Primary use	Proactively crawl the site and populate LiteSpeed Cache	Preload targeted pages after a cache refresh, or run a full-site warmup
Targeted refreshes	Operates independently of Cache Autopilot’s target list	Preloads the exact pages Cache Autopilot has purged
Full warmups	Crawls eligible site URLs according to its crawler configuration	Discovers site URLs and rebuilds the cache in paced background batches
Scheduling	Designed for recurring crawler runs	Supports targeted warmups as changes happen and manually triggered full warmups
Request pacing	Controlled by LiteSpeed’s crawler configuration	Controlled by Cache Warmup batch and pacing settings
Progress and logs	Managed by LiteSpeed Cache	Managed by Cache Autopilot
Hosting requirement	Must be enabled by the LiteSpeed server/hosting provider	Does not require LiteSpeed Crawler support
Cache variants	Can crawl configured cache variants, roles and cookie-based views	Primarily preloads the public page URLs selected for warmup
Resource control	LiteSpeed server-aware concurrency and load limits	Paced background batches controlled by Cache Warmup

Cache Warmup is usually the natural fit with Cache Autopilot because it directly preloads targeted refreshes and can also perform full-site warmups.

LiteSpeed Crawler remains useful when advanced cache variants, server-aware resource controls or broader proactive crawling are needed.

On LiteSpeed hosting where the crawler is not available, Cache Warmup can still preload the public page cache normally through paced HTTP requests.

Browser Cache

A long browser-cache lifetime is recommended for static assets:

Browser Cache: ON
Browser Cache TTL: 31536000 seconds (1 year)

LiteSpeed applies this to asset types such as images, CSS, JavaScript and fonts.

Do not apply a long browser-cache lifetime to HTML. A browser-cached HTML response can bypass the server entirely, which means a correctly purged LiteSpeed cache could still appear stale to the visitor.

If custom server or .htaccess rules are present, check that they do not contain a long-lived rule such as:

ExpiresByType text/html A31536000

or a broad ExpiresDefault rule that also applies to HTML.

Tracking query strings

Tracking parameters that do not change rendered page content should not create separate long-lived cache entries.

A useful baseline under Drop Query String is:

fbclid
gclid
utm*
_ga
gbraid
wbraid
dclid
gad_source
msclkid
srsltid

Add other parameters only when you know they are tracking-only.

Do not ignore query parameters used for filtering, search, languages, currencies, personalisation or other functionality that changes the rendered response.

QUIC.cloud

QUIC.cloud services, including Image Optimization, can continue to be used normally. Neither QUIC.cloud CDN nor LiteSpeed Crawler is required for Cache Autopilot.