Configure advance-cache.php only through a trusted caching plugin unless you fully understand WordPress bootstrap order, file permissions, and cache invalidation. This file is not a normal plugin file. It is a drop-in loaded very early by WordPress, before themes, most plugins, and many safety checks.

TLDR: advance-cache.php helps WordPress serve cached pages before the full application stack runs, which can cut response time sharply. For example, a content site with 120,000 monthly visits might reduce average TTFB from 780 ms to 240 ms after enabling page caching through this drop-in. The safe path is simple: enable WP_CACHE, let a reputable caching plugin create the file, then test logged-out pages, mobile views, carts, and forms. Never copy a random advance-cache.php file from another site.

What advance-cache.php actually does

advance-cache.php sits in the wp-content directory. WordPress loads it when the constant WP_CACHE is set to true in wp-config.php. Because it runs early, it can inspect a request and return a cached HTML file before WordPress loads the database, theme, widgets, and most plugins.

That early exit is the whole point. A normal uncached WordPress request may trigger dozens of PHP files and database queries. A cached request can be served as a plain file. That usually means lower CPU use, faster page delivery, and fewer crashes during traffic spikes.

The catch is that early loading also makes mistakes more painful. If the file is stale, broken, or tied to the wrong plugin, visitors may see outdated pages, broken layouts, or white screens. It drives me crazy that some sites keep old drop-ins after changing cache plugins, then spend hours blaming the theme.

Where the file lives and how WordPress loads it

The expected path is:

/wp-content/advance-cache.php

The switch that enables it is usually placed above the “stop editing” line in wp-config.php:

define('WP_CACHE', true);

When a request starts, WordPress checks that constant. If caching is enabled and the drop-in exists, WordPress includes advance-cache.php. From there, the caching plugin decides whether the request can be served from cache.

Common reasons a page may not be cached include:

  • The visitor is logged in.
  • The request uses POST data.
  • The URL contains tracking or preview parameters.
  • The page is a cart, checkout, account, or admin page.
  • A cookie marks the visitor as excluded from cache.
  • The cache has expired or was purged.

Safe configuration checklist

Use this checklist before touching production. It is boring, but it prevents most cache incidents.

  1. Back up files and database. Include wp-config.php and the full wp-content directory.
  2. Pick one page caching plugin. Do not run multiple full-page cache systems at the same time.
  3. Confirm server compatibility. Check whether the host uses Apache, Nginx, LiteSpeed, or a managed WordPress stack.
  4. Enable caching in the plugin settings. Let the plugin create or update advance-cache.php.
  5. Verify WP_CACHE. Make sure define('WP_CACHE', true); exists in wp-config.php.
  6. Check file ownership. The web server must be able to read the file. Some plugins also need write access.
  7. Test as a logged-out visitor. Use a private browser window or command-line request.
  8. Purge and retest. Confirm cache clearing works after editing a post or page.

Recommended file permissions

Permissions vary by host, but the usual safe baseline is:

  • wp-content/advance-cache.php: 644
  • wp-content directory: 755
  • wp-config.php: 600 or 640, depending on host rules

Avoid setting files to 777. That may seem like a quick fix when the plugin cannot write its drop-in, but it creates an avoidable security risk. If a plugin cannot create the file, fix ownership or ask the host to correct permissions.

What a good configuration should exclude

Full-page caching is excellent for public content. It is risky for user-specific pages. A serious configuration should exclude anything that changes per visitor.

  • WooCommerce: cart, checkout, my account, order received pages.
  • Membership sites: dashboards, profile pages, private lessons, gated downloads.
  • Forms: confirmation pages, nonce-protected flows, payment forms.
  • Admin and preview URLs: /wp-admin/, ?preview=true, custom preview links.
  • REST or AJAX endpoints: unless your cache plugin handles them safely.

Cookie exclusions also matter. E-commerce plugins often set cookies such as cart hashes or session identifiers. If your cache ignores those cookies, users can see the wrong cart count or stale pricing. That is not just annoying. It can damage trust.

How to verify that it works

Do not trust a green toggle in the admin screen. Test the site from outside WordPress.

First, open a private browser window and visit a public page twice. The second load should be faster. Then inspect response headers in browser developer tools. Many cache plugins add headers such as:

  • x cache: HIT
  • x wp cache: HIT
  • cf cache status: HIT
  • server timing values showing cache behavior

You can also test with curl:

curl -I https://example.com/

Run it twice. If the second request still shows MISS, check exclusions, cookies, query strings, and whether the page is allowed to be cached.

For a healthy setup, expect measurable gains. On a modest VPS, a heavy WordPress homepage might drop from 1.2 seconds server response time to under 300 ms when served from page cache. Results vary, but the direction should be obvious.

Common problems and practical fixes

Problem: WordPress says the drop-in is missing.
Check that WP_CACHE is true and that the file exists in wp-content. If it does not, disable and re-enable page caching in your cache plugin.

Problem: The site shows a blank page after enabling cache.
Rename advance-cache.php using SFTP or file manager. Then set WP_CACHE to false. Reload the site and check PHP error logs.

Problem: Old content keeps appearing.
Purge all caches. Include plugin cache, object cache, CDN cache, and host-level cache. Expect to waste time on this if several cache layers are active and undocumented.

Problem: Logged-in users see cached public versions.
Review cookie and role-based exclusions. Logged-in sessions should usually bypass full-page cache.

Problem: Mobile layout is wrong.
Some sites need separate mobile cache files. Enable mobile-specific caching only if your theme serves different HTML for mobile visitors.

How caching plugins use the file

Most major caching plugins generate their own version of advance-cache.php. The file may include plugin paths, constants, cache directory references, and request checks. This is why copying the file between sites is unsafe. The paths may not match. The plugin may not exist. The cache rules may be wrong.

When switching caching plugins, follow a clean removal process:

  1. Disable page caching in the old plugin.
  2. Delete old cache files if the plugin provides a safe purge option.
  3. Deactivate the old plugin.
  4. Check whether advance-cache.php remains.
  5. Install and configure the new plugin.
  6. Let the new plugin write its own drop-in.

This avoids mixed configuration, which is one of the most common causes of strange cache behavior.

Linguise plugin settings

Security and maintenance advice

Treat advance-cache.php as infrastructure code. It affects every public request. Keep the caching plugin updated, monitor error logs after changes, and document the active cache layers. If your host has server-side cache, write that down too.

For busy sites, set a review schedule. Check cache headers monthly. Test checkout and forms after every major plugin update. Review exclusions after adding personalization, geolocation, pricing rules, or membership features.

A well-configured advance-cache.php setup can make WordPress feel much lighter. A careless setup can serve the wrong page very quickly, which is worse. Use one trusted caching system, keep exclusions strict, test from outside the admin area, and remove stale drop-ins when changing plugins.