Title: Default page cache responses
Author: WordPress VIP Documentation
Published: November 19, 2025
Last modified: November 24, 2025

---

 1. [Caching](https://docs.wpvip.com/caching/)
 2. [Page cache](https://docs.wpvip.com/caching/page-cache/)
 3. Default page cache responses

#  Default page cache responses

By default, the following responses **are cached** by [the VIP page cache](https://docs.wpvip.com/caching/page-cache/)
for WordPress and Node.js environments:

 * Responses with an HTTP Status Code of `200 OK`, including WordPress posts, pages,
   archives, the home page, `/graphql`, etc., are cached at the [edge cache server](https://docs.wpvip.com/infrastructure/edge-servers/)
   locations for 30 minutes by default.
    - For browser cache control purposes these responses are sent with a [`cache-control` HTTP response header](https://docs.wpvip.com/caching/page-cache/customize-behavior/cache-control-headers/)
      of `max-age=300, must-revalidate` by default.
    - [Changes made to WordPress site content](https://docs.wpvip.com/caching/page-cache/purging/automatic-purging-for-wp/)
      will automatically notify the edge caches of the new data and trigger a purge
      of cached versions of that content. The next incoming request for that content
      will be sent to origin and the response will be served then stored in cache.
    - Because the rendered HTML for a request is cached for up to 30 minutes, the
      references to updated static asset files could be up to 30 minutes out of 
      date. The [version number](https://docs.wpvip.com/vip-go-mu-plugins/file-concatenation-and-minification/)
      on an enqueued asset must be updated to prompt VIP to use the new concatenated
      versions when JS or CSS has been edited.
    - [A stale response could be served by the page cache](https://docs.wpvip.com/caching/page-cache/http-headers/stale-responses/)
      up to 12 hours for a cached object outside of a resource’s set `max-age` while
      the page cache fetches an updated response from the origin to serve for future
      requests.
 * Redirects with a `301 Moved Permanently` HTTP status are cached for 30 minutes.
 * Responses with `302 Found` and `307 Temporary Redirect` HTTP status are cached
   for 1 minute.
 * Responses with `404 Not Found` HTTP status are cached for 10 seconds.
 * Responses with `410 Gone` HTTP status are cached for 1 minute.
 * All responses to unauthenticated, non-error, read (`GET` / `HEAD`) requests to
   the [WordPress REST API](https://docs.wpvip.com/wordpress-on-vip/wordpress-rest-api/)
   are cached for 1 minute. [The TTL Manager plugin](https://github.com/Automattic/vip-go-mu-plugins/blob/production/vip-cache-manager/ttl-manager.php)
   in VIP MU plugins sets the 1 minute caching rule for the WP REST API endpoint.

**Note**

Requests made with `HEAD` or `GET` HTTP request methods are cached. By design, incoming
requests to the origin that use [the HTTP `HEAD` method](https://developer.mozilla.org/en-US/docs/Web/HTTP/Methods/HEAD)
are transformed into `GET` requests by the page cache. As a result, the value of`
$_SERVER['REQUEST_METHOD']` for those requests will be `GET`. For this reason, avoid
logic at the origin that depends on detecting `HEAD` requests.

## HTTP status code responses that are not cached

The following responses **are not cached** by default for WordPress and Node.js 
environments:

 * `206 Partial Content`
 * `400 Bad Request`
 * `403 Forbidden`
 * `416 Range Not Satisfiable`
 * `429 Too Many Requests`
 * `431 Request Header Fields Too Large`
 * All `5xx` responses

## Uncacheable URLs

A URL will be marked as uncacheable for 10 seconds **if**:

 * it has a TTL less than or equal to 0 **AND** a response status code less than`
   500`
 * **OR** it has a `Set-Cookie` header (set with `setcookie()` )
 * **OR** it has a `Cache-Control` header with a private value
 * **OR** it has a `Vary` header with a value of `*`.

## Cache bypass

The following types of requests made to a WordPress or Node.js environment will 
bypass the page cache:

 * All requests sent with an [HTTP `Authorization` header](https://developer.mozilla.org/en-US/docs/Web/HTTP/Headers/Authorization).
 * All requests made with `POST`, `PUT`, or `DELETE` HTTP request methods.
 * All requests made to an environment with [Basic Authentication](https://docs.wpvip.com/security-controls/basic-authentication/)
   enabled.
 * All requests made to WordPress environments by logged-in users.
 * All requests made by a user with a [PHP session](https://docs.wpvip.com/wordpress-on-vip/php/php-sessions/).

Additional cache bypass behavior:

 * [The presence of certain cookies](https://docs.wpvip.com/caching/page-cache/cookies/)
   will cause the page cache to be bypassed.
 * `no-cache` headers are respected via `nocache_headers()`. However, use `no-cache`
   headers cautiously as they will result in a poor cache hit rate.
 * Responses with `401 Unauthorized` and  `431 Request Header Fields Too Large` 
   HTTP status codes are not cached.

Logged-in users, commenters, requests to modify state (such as `POST` requests),
and requests for pages not actively cached at the edge will be routed to the WordPress
site’s [origin servers](https://docs.wpvip.com/infrastructure/origin-servers/), 
which run the site’s code and database.

Last updated: November 24, 2025