How to Exclude a Page from Cache in Code

Some WordPress pages contain dynamic or personalized content that should not be cached. These include account dashboards, custom checkout flows, and API endpoints.

While RunCache provides built-in options for excluding pages from caching, you can also manage exclusions using PHP. This guide explains how to exclude specific pages using code, why the timing of your code matters, and how to check that your exclusions work correctly.

Understanding the DONOTCACHEPAGE Constant

In WordPress development, the informal standard to prevent a page from being cached is defining the DONOTCACHEPAGE constant. When RunCache detects that this constant is defined and evaluates to true, it bypasses page caching for that request.

RunCache enables this behavior by default. You can confirm this setting directly inside your WordPress dashboard:

1. Log in to your WordPress admin dashboard.
2. In the left sidebar, navigate to RunCache > Rules.
3. Scroll down to the “Cookie Rules” card.
4. Locate the toggle named “Exclude DONOTCACHEPAGE constant”.
5. Confirm that the switch is enabled. If it is turned off, click the toggle to enable it, then click on Save Changes.

How Cache Engines Affect Code Timing

Whether your code successfully bypasses caching depends heavily on the cache type your application uses. The cache eligibility check occurs at different moments in the WordPress request lifecycle:

• NGINX FastCGI, LiteSpeed, and Cloudflare APO: The eligibility check runs on the WordPress send_headers action hook. This hook executes late in the request lifecycle, well after plugins, themes, and template files have loaded. In these environments, you can define DONOTCACHEPAGE inside your plugin code, theme functions, or hook callbacks such as template_redirect.
• PHP File Cache and Redis Page Cache: The eligibility check executes much earlier inside the advanced-cache.php drop-in file. This happens before standard plugins and themes are loaded by WordPress. If you define the constant inside an ordinary plugin or theme, the check has already completed, and your definition will be ignored.

Implementing Cache Exclusions in PHP

Depending on your server cache setup, you can choose the method that best fits your technical stack.

Method 1: Defining the Constant

If you are using NGINX FastCGI, LiteSpeed, or Cloudflare APO, you can define the constant inside standard hooks. If you are using PHP File Cache or Redis Page Cache, this snippet must be placed in wp-config.php or inside a Must-Use (MU) plugin so that it runs early.

Always guard the constant definition to avoid generating PHP notices if another plugin defines it first:

if ( ! defined( 'DONOTCACHEPAGE' ) ) {
    define( 'DONOTCACHEPAGE', true );
}

RunCache checks that the constant is both defined and evaluates to true. Setting define( 'DONOTCACHEPAGE', false ) will not force a page to cache; it simply prevents a manual bypass from being triggered.

Method 2: Sending No-Cache Headers (Recommended for PHP and Redis Cache)

When using PHP File Cache or Redis Page Cache, the cache engine stores response data in an output buffer. Before writing the output to storage, the engine inspects the HTTP response headers. If the Cache-Control header contains no-cache, no-store, or private, the response is immediately discarded.

Sending cache-control headers from PHP works regardless of when your code runs in the execution lifecycle:

add_action( 'template_redirect', function () {
    if ( my_custom_dynamic_check() ) {
        nocache_headers();
    }
} );

The standard WordPress core function nocache_headers() generates Cache-Control: no-store, no-cache, must-revalidate. Using this function provides a universal bypass that functions reliably across all RunCache configurations.

Additionally, RunCache refuses to cache empty responses or responses with an HTTP status code other than 200. This means redirects and error pages are never cached.

Managing Exclusion Rules via Filters

Instead of defining constants on every request, you can add persistent exclusion rules directly through code using the runcache_rules_settings filter.

Add the following snippet to a functionality plugin or your theme’s functions.php file:

add_filter( 'runcache_rules_settings', function ( array $settings ) {
    $settings['exclude_url_mch'][] = '/custom-portal';
    return $settings;
} );

The advanced-cache.php drop-in does not run WordPress filters on every request. Instead, it reads settings from a pre-compiled file located at wp-content/cache/runcache/config.php. This file is generated whenever you update settings in your dashboard.

To apply your filter to the active cache engine:

1. Deploy your PHP filter code to your site.
2. In your WordPress admin dashboard, navigate to RunCache > Rules.
3. Click on Save Changes to regenerate the configuration file.

For detailed instructions on URL-based and session-based rules, refer to our guides on URL path exclusions and Cookie rules.

Pre-defined Cache Exclusions

RunCache maintains a built-in layer of protection that excludes Core WordPress administrative pages, checkout paths, system cookies, and query parameters such as feed are from caching to keep your site functioning smoothly.

To review the entire list of protected paths and identifiers, read our Cache rules overview.