Prevent Browser Caching

You changed the site, but a client or visitor still sees the old version and you have to say “please clear your browser cache”? This plugin makes that conversation unnecessary.

Prevent Browser Caching makes sure browsers always load the current version of your site — without disabling browser caching and slowing the site down.

What it does

• CSS & JS versions. WordPress loads assets with a “ver” URL parameter (e.g. style.css?ver=4.9.6). Browsers cache the file until this parameter changes. In the recommended automatic mode the plugin sets the version from the file’s own modification time: browser caching works at full strength, and the moment you update a file every visitor gets the new one.
• Image versions. When you edit or replace a file in the Media Library, visitors get the new image instead of the cached one.
• HTML page freshness. Asks browsers to check for a newer version of a page before showing a cached copy — fixes “I still see the old page on my phone”.
• One-click update. The “Update versions” toolbar button forces fresh copies of all assets for every visitor — and shows a short report of what exactly happened.
• Page cache stays in sync (opt-in). If a page-cache plugin is active, updating versions can also clear its cache — so cached HTML stops referencing the old file versions and every visitor sees the new site immediately. One checkbox turns it on, and after every update the plugin reports what was refreshed and what happened to the page cache. Works with WP Rocket, LiteSpeed Cache, W3 Total Cache, WP Super Cache, WP Fastest Cache, WP-Optimize, Breeze, Cache Enabler, Hummingbird, SiteGround Optimizer, Swift Performance and Comet Cache.
• Faster repeat visits (opt-in, new in 3.2). Because versioning guarantees freshness, the plugin can safely serve your static files with one-year browser caching headers — the exact fix for the Lighthouse audit “Serve static assets with an efficient cache policy”. It writes the rules through WordPress’s own .htaccess API on Apache/LiteSpeed (removed again on deactivation), shows a ready-to-copy snippet for nginx, and then actually fetches one of your CSS files to verify the headers really work — the result is shown on the settings page.
• Auto refresh after updates (opt-in, new in 3.2). Plugin, theme and WordPress updates change CSS and JS files. With this option every update — including automatic background updates — is followed by a version refresh (and a page-cache clear when that option is on), so visitors never see a broken layout after an update.
• CLI & AI agents. WP-CLI commands (wp pbc update, wp pbc status) and WordPress Abilities let deploy scripts and AI agents update versions safely.

Safe by default

• External URLs (payment scripts, CDNs, third-party services) are left untouched — some of them break when an unexpected “ver” parameter is added. You can turn external versioning back on with one checkbox.
• Specific files (by part of the URL) or script/style handles can be excluded from versioning — CSS, JS and images alike.
• If a page-cache plugin is active, the HTML freshness headers step aside automatically.
• Another plugin’s page cache is never cleared unless you enable that yourself — the purge-on-update integration is opt-in, and the report after every update tells you whether the page cache was cleared or left alone.
• The long-caching headers are opt-in too, and only available while CSS/JS versioning is on — the plugin never lets browsers hold files for a year without a way to bust them. Disabling the option (or deactivating the plugin) removes the rules completely.

Update modes

• Automatically, when a file changes (recommended) — version = file modification time. Zero clicks, full caching.
• Every time a page loads — development mode: CSS & JS are never cached (images and pages are unaffected). Use it only while actively developing.
• Manually — versions change only when you press the “Update versions” button.

For developers

The recommended way to set the CSS/JS version from code is the pbc_assets_version filter. Add this to the functions.php file of your theme and change the value whenever you need to update assets:

add_filter( 'pbc_assets_version', function( $ver ) {
    return '123';
} );

Because it uses WordPress’s own add_filter(), it keeps working safely even if the plugin is ever deactivated — your site won’t break.

Filters for fine-tuning:

• pbc_skip_src( $skip, $src, $handle ) — return true to leave a given asset URL untouched.
• pbc_assets_version( $ver, $src, $handle ) — change the version applied to a given asset.
• pbc_purge_page_cache( $purge, $plugin_name ) — return false to prevent the page-cache purge on version updates.
• pbc_after_bump( $result ) — action fired after every version update, with the new timestamp and the purge outcome.
• pbc_cache_policy_rules( $rules, $options ) — change the generated long-caching rules before they are written to .htaccess (or shown as a snippet).
• pbc_after_auto_bump( $context ) — action fired after an automatic post-update refresh, with the update type and the purge outcome.
• PBC_DISABLE_HTACCESS_WRITE — define this constant as true (e.g. in wp-config.php) and the plugin will never write to .htaccess itself; the settings page shows the rules for manual setup instead.

Wp-cli

• wp pbc update — updates the versions (and clears the detected page cache when the settings option is on). Add --skip-purge to leave the page cache alone for that run.
• wp pbc status — shows the mode, what is versioned, the last manual update and the detected page-cache plugin. Supports --format=table|json|yaml.

Read the full description on the official page →