Caching behavior for errors and 404 pages

An error page can look like a complete HTML document. Storing it under a valid route would turn a temporary failure into a durable response, so POM Cache applies error and status guards during generation.

Ordinary 404 pages

WordPress identifies a missing route with is_404() and status 404. POM Cache does not write that response by default, even if the theme supplies a polished, complete 404.php template.

This prevents:

• an accidental missing route from occupying storage;
• a newly published URL from remaining hidden behind an old 404 file;
• high-volume random paths from growing the page-cache tree.

Developers can change the 404 policy with the documented filter, but must then design invalidation and storage controls for arbitrary missing URLs.

Redirects

POM Cache tracks the common WordPress redirect statuses 301, 302, 303, and 307 and excludes those responses from HTML generation. A redirect should remain a status plus Location header, not become a reusable HTML page at the source URL.

For other custom non-200 flows, the integration should define DONOTCACHEPAGE explicitly and verify the result. Do not assume that a visually complete error template is sufficient protection.

wp_die() and interstitial errors

WordPress uses wp_die() for permission failures, confirmation screens, and other error/interstitial responses. POM Cache marks these requests with DONOTCACHEPAGE by default.

That protects content whose markup may include request-specific messages, nonces, or administrative context.

Fatal and incomplete output

Before writing, POM Cache checks for fatal PHP error types. It also requires non-empty output with a recognized closing marker.

Examples that should not become a page file:

• PHP stops before </html>;
• the output buffer is empty;
• a fatal error interrupts template rendering;
• a component deliberately defines DONOTCACHEPAGE.

The current visitor may still receive an error or partial response. The cache protection prevents that buffer from being promoted to index.html.

Previously cached pages during a failure

Generation and delivery are separate:

• if a valid static file is served before WordPress, the failing dynamic code may never run;
• if the request bypasses or misses, WordPress can fail, but the rejected buffer is not intentionally published;
• a CDN may continue serving its own older object regardless of the origin’s current state.

Decide operationally whether stale-but-valid content or an immediate dynamic failure is preferable. POM Cache HTML files do not expire by age, so purging during an outage removes that protection.

Test without affecting real error routes

Use a staging site:

1. delete the HTML cache;
2. request a known nonexistent URL and confirm status 404;
3. verify no corresponding index.html appears;
4. test a normal redirect and confirm its source path is not stored;
5. generate a valid page;
6. simulate an approved incomplete-output condition;
7. confirm the existing valid file was not replaced by a truncated one;
8. restore normal behavior and recheck the page.

Do not introduce fatal errors on production merely to test caching.

When an error file already exists

If visitors repeatedly receive an old error:

1. determine whether it comes from the CDN, Apache/POM Cache, another page-cache product, or the application;
2. inspect the stored file and its generation timestamp;
3. fix the underlying route or response first;
4. delete the affected origin cache;
5. invalidate the matching CDN object;
6. request the canonical URL and confirm the correct status, headers, and body.

Developer controls are documented in Error and 404 filters.