WP Super Cache deleting all cached pages after WordPress updates

How to Stop WP Super Cache From Deleting All Cached Pages After Updates

by

A large WordPress website may have thousands of pages successfully stored in WP Super Cache. However, after editing a single page, publishing a post, or updating a plugin, the cached-page count may suddenly drop from more than 3,000 pages to almost zero.

This can happen even when the following settings are already configured:

  • Garbage Collection or Cache Timeout is set to 0
  • “Clear all cache files when a post or page is published or updated” is unchecked
  • Automatic cache expiration appears to be disabled

At first, this behavior can look like a WP Super Cache bug. In many cases, however, Garbage Collection is not causing the deletion. The cache is being removed by a WordPress action, a WP Super Cache invalidation rule, or another plugin that explicitly requests a complete cache purge.

This guide explains how to determine which process is clearing the cache and how to prevent a single content change from unnecessarily invalidating thousands of cached pages.

Quick Solution

Setting Garbage Collection to 0 only disables time-based cache expiration. It does not stop WordPress, WP Super Cache, a theme, or another plugin from explicitly deleting cached files.

To fix the problem:

  1. Confirm that the full-cache clearing option is disabled.
  2. Verify the generated WP Super Cache configuration file.
  3. Enable temporary cache debugging.
  4. Add a targeted-purge filter so normal page edits do not invalidate unrelated pages.
  5. Log complete cache purges to identify the responsible plugin.
  6. Rebuild the cache through WP Super Cache Preload after plugin or theme updates.

Do not permanently block every cache purge. Plugin, theme, and WordPress core updates can change frontend HTML, CSS, scripts, shortcodes, or templates. In those situations, a full purge may be necessary.

Why Garbage Collection Set to Zero Does Not Solve the Problem

WP Super Cache creates static HTML files from dynamically generated WordPress pages. Visitors can then receive those HTML files without WordPress executing all of its PHP code for every request.

The plugin has two different cache-removal mechanisms.

1. Time-based garbage collection

Garbage Collection removes cache files after they reach the configured expiration time.

When Cache Timeout is set to 0, WP Super Cache should not expire files based solely on their age.

2. Event-driven cache invalidation

Cache invalidation occurs when an event tells WP Super Cache that cached content may no longer be accurate.

Examples include:

  • Updating a published post or page
  • Deleting or publishing content
  • Changing a navigation menu
  • Switching the active theme
  • Updating content connected to category, author, taxonomy, or archive pages
  • Another plugin calling a WP Super Cache purge function
  • A frontend monitoring check deciding that the homepage is incorrect

Garbage Collection set to 0 does not disable these event-driven purges.

This is the most important distinction when troubleshooting the issue.

What the “Clear All Cache Files” Checkbox Actually Does

The option is located under:

WordPress Dashboard > Settings > WP Super Cache > Advanced

Its label is:

Clear all cache files when a post or page is published or updated.

When this option is enabled, WP Super Cache removes the main cache directories after a published post is edited.

When the option is disabled, WP Super Cache does not simply leave every cache file untouched. Instead, it runs its normal post-change invalidation process. That process can remove the edited page, homepage, page hierarchy, and related archive cache entries. The current plugin source confirms that disabling the checkbox switches from a complete directory purge to the standard wp_cache_post_change() process.

Therefore, unchecking the option is necessary, but it does not mean “never delete any cache.”

Why Thousands of Cached Pages May Still Disappear

There are several possible causes.

Another Plugin Is Calling WP Super Cache’s Full-Purge Function

WP Super Cache provides a public PHP function named:

wp_cache_clear_cache();

When this function is called without a specific site ID, WP Super Cache removes the Super Cache directory and the wider cache path. It then fires the wp_cache_cleared action.

Other WordPress plugins can call this function to ensure their frontend changes become visible immediately.

For example, current Yoast SEO code includes a cache-clearing utility that checks whether WP Super Cache is active and calls wp_cache_clear_cache(). Yoast uses that utility during certain activation and deactivation processes.

This does not mean Yoast is always the cause. Optimization, SEO, security, review, page builder, hosting, import, menu, and CDN plugins may also contain cache-integration code.

A Navigation Menu Is Being Updated

WP Super Cache intentionally connects the wp_update_nav_menu WordPress action to its full-cache clearing function.

A page builder, menu-sync plugin, translation plugin, or custom theme may update a navigation menu when a page is saved. The visible action may be “Update Page,” but a secondary menu update may trigger the complete cache purge.

The Saved Setting Does Not Match the Dashboard

WP Super Cache stores its generated configuration in:

/wp-content/wp-cache-config.php

The dashboard checkbox may appear unchecked while the generated configuration still contains an incorrect value because of:

  • File permission problems
  • A read-only configuration file
  • A failed settings save
  • A deployment replacing the file
  • A security plugin blocking file changes
  • Multiple WordPress environments sharing files incorrectly

The relevant configuration value should be:

$wp_cache_clear_on_post_edit = 0;

The standard WP Super Cache configuration sample uses 0 for this option.

The Homepage Monitoring Check Is Clearing the Cache

WP Super Cache includes an advanced debugging feature that can periodically check the homepage for specified text.

When “Clear cache on error” is enabled, a temporary homepage issue, firewall response, maintenance page, PHP error, or missing text can cause the plugin to clear the cache.

The plugin’s current Debug settings confirm that this check can be configured to clear cache when the expected homepage text is missing.

The Cache Statistics Are Out of Date

The cached-page number shown under the Contents tab is not always updated automatically.

Before concluding that every file was deleted, go to:

Settings > WP Super Cache > Contents

Then click:

Regenerate Cache Stats

Check the cache directory through File Manager or SSH as well:

/wp-content/cache/supercache/

If the directories and HTML files are still present, only the displayed statistics may have been outdated.

Step 1: Confirm the Correct WP Super Cache Settings

Go to:

Settings > WP Super Cache > Advanced

Use the following settings as a starting point:

  • Enable Caching: On
  • Cache Delivery Method: Simple
  • Cache Rebuild: Enabled
  • Clear all cache files when a post or page is published or updated: Disabled
  • Disable caching for logged-in visitors: Enabled
  • Cache Timeout: 0, only when you intentionally want no time-based expiration

Click Update Status or Save Settings after making changes.

Next, open:

/wp-content/wp-cache-config.php

Confirm that it contains:

$wp_cache_clear_on_post_edit = 0;

For a cache with no age-based expiration, also verify:

$cache_max_time = 0;

Do not edit the file first unless necessary. Save the settings through the WordPress dashboard and then verify whether the plugin wrote the correct values.

If the values do not change, check file ownership and permissions for:

/wp-content/wp-cache-config.php
/wp-content/cache/
/wp-content/advanced-cache.php

Step 2: Disable Unnecessary Related-Page Purging

WP Super Cache includes a filter named:

wpsc_delete_related_pages_on_edit

The plugin source describes this filter as a method to stop deletion of the homepage and other related pages during a post edit.

You can use the filter to keep most of the existing cache while still allowing WP Super Cache to invalidate the page that was actually edited.

Create this file:

/wp-content/mu-plugins/debugnexus-wpsc-targeted-purge.php

Create the mu-plugins directory if it does not already exist.

Add the following code:

<?php
/**
 * Plugin Name: DebugNexus WP Super Cache Targeted Purge
 * Description: Prevents normal post edits from purging unrelated WP Super Cache pages.
 */

defined( 'ABSPATH' ) || exit;

/**
 * Keep unrelated cached pages when a post or page is edited.
 *
 * The edited URL can still be invalidated, but WP Super Cache will not
 * automatically remove the homepage and other related page caches through
 * its standard post-change routine.
 */
add_filter(
	'wpsc_delete_related_pages_on_edit',
	'__return_false',
	PHP_INT_MAX
);

Because this is a must-use plugin, WordPress loads it automatically. It does not need to be activated from the Plugins page.

Important limitation

This filter only changes WP Super Cache’s normal content-edit invalidation behavior.

It does not prevent another plugin from directly calling:

wp_cache_clear_cache();

It also does not guarantee that category, taxonomy, author, or post-type archive caches will remain untouched, because WP Super Cache has separate archive invalidation routines.

Use this filter carefully when:

  • The homepage displays recently updated content
  • Category pages show post excerpts
  • A shared template appears across many pages
  • A page builder uses global widgets
  • Menus are generated dynamically
  • Product prices or inventory appear in multiple locations

In those cases, keeping related caches may cause visitors to see outdated content.

Step 3: Enable WP Super Cache Logging

Open:

Settings > WP Super Cache > Debug

Click:

Enable Logging

WP Super Cache writes its debugging information to a file inside the cache directory. The Debug page displays the exact filename and login information for viewing it.

After enabling logging:

  1. Regenerate the cache.
  2. Note the number of cached pages.
  3. Edit one test page.
  4. Check the cache count again.
  5. Open the WP Super Cache log.
  6. Search for messages containing:
    • Clearing all cached files
    • wp_cache_clear_cache
    • wp_cache_post_edit
    • Post change
    • deleting cache files

A normal targeted edit may contain a message similar to:

wp_cache_post_edit: Clearing cache for post 123

A complete purge may contain:

Clearing all cached files in wp_cache_clear_cache()

Disable WP Super Cache logging after troubleshooting. Leaving detailed logging active on a busy production website can create a large log file.

Step 4: Log the Code That Triggered the Full Purge

WP Super Cache’s regular log may confirm that a full purge happened, but it may not clearly identify which plugin called the purge function.

Add this temporary code to the must-use plugin created earlier:

/**
 * Log the PHP call stack whenever WP Super Cache completes a full purge.
 *
 * Remove this code after identifying the source.
 */
add_action(
	'wp_cache_cleared',
	static function () {
		$trace = debug_backtrace( DEBUG_BACKTRACE_IGNORE_ARGS, 25 );
		$lines = array();

		foreach ( $trace as $frame ) {
			$class    = isset( $frame['class'] ) ? $frame['class'] : '';
			$type     = isset( $frame['type'] ) ? $frame['type'] : '';
			$function = isset( $frame['function'] ) ? $frame['function'] : 'unknown';
			$file     = isset( $frame['file'] )
				? str_replace( ABSPATH, '', $frame['file'] )
				: 'unknown';
			$line     = isset( $frame['line'] ) ? (int) $frame['line'] : 0;

			$lines[] = sprintf(
				'%s%s%s at %s:%d',
				$class,
				$type,
				$function,
				$file,
				$line
			);
		}

		error_log(
			"[DebugNexus WP Super Cache full purge]\n" .
			implode( "\n", $lines )
		);
	},
	PHP_INT_MAX
);

Temporarily enable WordPress debug logging in wp-config.php:

define( 'WP_DEBUG', true );
define( 'WP_DEBUG_LOG', true );
define( 'WP_DEBUG_DISPLAY', false );

Place these lines before:

/* That's all, stop editing! Happy publishing. */

Now reproduce the problem by updating one page or plugin.

Open:

/wp-content/debug.log

Search for:

[DebugNexus WP Super Cache full purge]

The lines below it should show the PHP files and functions involved in the purge. Look for a path similar to:

wp-content/plugins/plugin-name/

or:

wp-content/themes/theme-name/

That path normally identifies the plugin or theme that requested the full purge.

Remove the call-stack logger and disable WordPress debugging after completing the investigation.

Step 5: Search Plugin and Theme Files Through SSH

Website owners with SSH access can search for direct WP Super Cache calls.

Run the following command from the WordPress installation directory:

grep -RIn \
  --exclude-dir=wp-super-cache \
  -E "wp_cache_clear_cache|wp_cache_clean_cache|wp_cache_cleared" \
  wp-content/plugins \
  wp-content/themes \
  wp-content/mu-plugins

This searches plugins, themes, and must-use plugins for common WP Super Cache purge integrations.

Finding the function name does not automatically mean the plugin is malfunctioning. Inspect the surrounding code to determine when the function is executed.

Possible triggers include:

  • Plugin activation
  • Plugin deactivation
  • Plugin database upgrade
  • Settings update
  • Content import
  • Menu regeneration
  • SEO metadata update
  • Theme option save
  • Translation synchronization
  • Scheduled maintenance task

Do not modify the third-party plugin directly. Any change made inside its plugin folder will be overwritten during the next update.

Instead:

  1. Look for a cache-clearing option in the plugin.
  2. Check whether the plugin provides a filter to disable its cache integration.
  3. Add a compatibility filter through an MU plugin.
  4. Report unnecessary full purges to the plugin developer.
  5. Replace the plugin when it provides no safe way to control the behavior.

Step 6: Test Plugins Individually

When logging does not reveal the cause, perform a conflict test on staging.

  1. Create or refresh a staging copy of the website.
  2. Preload the full cache.
  3. Record the cached-page count.
  4. Disable all plugins except WP Super Cache.
  5. Edit a test page.
  6. Regenerate the cache and repeat the test while activating plugins one at a time.
  7. Test plugin updates individually rather than updating everything together.

Focus first on plugins that handle:

  • SEO
  • Page builders
  • Performance optimization
  • Hosting integration
  • CDN services
  • Menus
  • Translation
  • Security
  • Database cleanup
  • Content synchronization
  • Imports and exports

When the cache begins clearing again, the most recently activated plugin is the likely trigger.

Step 7: Use Preload for Large Websites

A website with more than 3,000 posts and pages may take a significant amount of time and server resources to rebuild its cache through normal visitor traffic.

WP Super Cache’s Preload feature can generate cached versions in advance.

Go to:

Settings > WP Super Cache > Preload

Configure a controlled preload interval and include the content types needed by the website.

After a legitimate full purge:

  1. Start Preload.
  2. Monitor CPU, memory, and disk usage.
  3. Avoid using an extremely aggressive interval on shared hosting.
  4. Confirm that WP-Cron is working.
  5. Regenerate cache statistics after the preload completes.

For very large websites, a server cron job is generally more reliable than depending entirely on WP-Cron, especially when the site has inconsistent traffic.

Should Plugin Updates Clear the Entire Cache?

Sometimes, yes.

A plugin update may change:

  • Shortcode output
  • Blocks
  • Product templates
  • Schema markup
  • CSS classes
  • JavaScript initialization
  • Forms
  • Header or footer output
  • Navigation
  • Widgets
  • Structured data
  • WooCommerce prices or checkout elements

Serving cached HTML created by the previous plugin version could produce broken layouts or outdated functionality.

A safer maintenance workflow is:

  1. Copy production to staging.
  2. Update one plugin at a time.
  3. Test important pages and functionality.
  4. Update the live website.
  5. Allow one controlled cache purge when required.
  6. Immediately start cache preload.
  7. Confirm that important URLs are cached again.

The problem is not necessarily that a cache purge occurs after a major update. The problem is when every minor page edit or unrelated settings change unnecessarily deletes thousands of otherwise valid cached pages.

Recommended Configuration for a Large Mostly Static Website

For a large informational website where individual pages rarely affect one another, the following configuration is a reasonable starting point:

Caching: Enabled
Delivery Method: Simple
Cache Rebuild: Enabled
Cache Timeout: 0
Clear all cache files after post update: Disabled
Targeted-purge MU plugin: Enabled
Preload: Enabled with a conservative interval
WP Super Cache debugging: Disabled after testing
WordPress debugging: Disabled after testing

Continue allowing controlled full purges after:

  • Theme updates
  • WordPress core updates
  • Page builder updates
  • Major SEO configuration changes
  • Navigation redesigns
  • Global template changes
  • Sitewide CSS or JavaScript changes

Frequently Asked Questions

Does Garbage Collection set to zero disable every cache deletion?

No. It disables time-based expiration, but it does not stop WordPress actions or PHP functions from explicitly deleting cached files.

Why does updating one page remove homepage cache?

WP Super Cache assumes that a content update may affect the homepage, archives, taxonomies, page navigation, and other related URLs. It therefore invalidates related cache entries unless that behavior is changed with a filter.

Can I completely prevent WP Super Cache from deleting anything?

It is technically possible to block parts of the automatic invalidation process, but permanently blocking every purge is not recommended. Visitors may receive outdated pages after important content, plugin, or theme changes.

Will the targeted-purge filter stop plugin updates from clearing cache?

No. The filter controls the normal post-edit process. A plugin that directly calls wp_cache_clear_cache() can still trigger a complete purge.

Is it safe to leave cached files forever?

Not always. A permanent cache can consume significant disk space and serve outdated content. Monitor the size of:

/wp-content/cache/

and use a deliberate preload and purge strategy.

Why does the Contents tab show zero cached pages when files still exist?

The displayed statistics may be stale. Click Regenerate Cache Stats and inspect the actual cache directory before concluding that all cached files were deleted.

Final Recommendation

For a website with thousands of mostly static pages, do not rely only on Garbage Collection set to 0.

Use a combination of:

  • Correct WP Super Cache settings
  • Verification of wp-cache-config.php
  • Targeted page invalidation
  • Temporary purge logging
  • Plugin conflict testing
  • Controlled full purges after significant updates
  • Cache Preload to rebuild important pages

The best solution is not to prevent every cache deletion. It is to make routine content updates invalidate only the pages that actually need to be regenerated, while preserving full cache purges for changes that can affect the entire website.

Technical References

The solution is based on the current WP Super Cache settings interface, post-change invalidation functions, full-purge function, debug tools, and supported cache filters.

Other plugins can integrate with WP Super Cache by calling its public full-purge function, which is why conflict tracing is necessary when the WP Super Cache checkbox is already disabled.

Leave a Comment