Plan an equivalent configuration on non-Apache servers

POM Cache only displays Apache .htaccess blocks. Nginx, Caddy, IIS, a managed reverse proxy, or another web server needs a separately reviewed equivalent. Do not paste Apache syntax into those products.

The safest unsupported-server configuration is to keep the PHP cache fallback. Native delivery is optional.

Define the mapping

For static HTML, the server needs to translate:

https://example.com/about/

into a conditional filesystem lookup:

{Cache Location}/pom-cache/example.com/about/index.html

The public host and path must resolve to the same directory that POM Cache used during generation. The mapping also needs to support subdomains, mapped domains, subdirectory multisite, and any canonical language prefix in use.

Do not expose Cache Location as a browseable directory or allow arbitrary user input to become a filesystem path.

Reproduce the safety contract

The native rule must serve a page file only when:

• the method is GET or HEAD;
• the request represents public HTML;
• no meaningful query string is present;
• no WordPress login, password, comment-author, WooCommerce session, or cart cookie is present;
• the canonical host and normalized path are valid;
• the exact index.html exists and is readable.

Every other request must fall through to PHP/WordPress. A non-match is not an error response.

Add any site-specific personalization cookies to that bypass policy. A web server cannot rely on DONOTCACHEPAGE because PHP has not started.

Preserve response behavior

For an HTML hit, configure:

• status 200;
• Content-Type: text/html with the site’s character set;
• normal HEAD semantics;
• the deployment’s approved cache and security headers.

The file does not contain a serialized copy of WordPress headers. Policies needed on every static response must be implemented by the web server or CDN.

Progressive JSON needs a different route map, the JSON content type, its configured Cache-Control value, and Vary: Accept-Encoding. Do not send JSON through the HTML rule.

Account for proxies and managed hosting

Clarify which layer owns each value:

If the origin never receives a bypass signal, its native rule cannot act on it. Correct the upstream policy rather than weakening application isolation.

Avoid an unconditional try_files

A rule equivalent to “if this path exists, serve it” is incomplete. It can return public HTML to a logged-in or cart request whose host and path happen to match.

Build eligibility first, then perform the file lookup. Keep the PHP fallback as the final target when any condition is uncertain.

Acceptance test

On staging:

1. prove the PHP hit first;
2. enable the native rule;
3. generate one known page;
4. confirm a clean anonymous request avoids PHP;
5. confirm a missing file reaches WordPress;
6. test login, password, cart, meaningful query, POST, PUT, and DELETE;
7. test HEAD;
8. verify a second multisite host or path remains isolated;
9. repeat with the CDN enabled.

Document the platform-specific configuration in the site’s infrastructure documentation, not as a claim that POM Cache installed it.