Apache rules do not match

Optional Apache rules can serve existing POM Cache files before PHP. Diagnose them only after PHP generation and PHP cache hits work correctly.

Establish the baseline

Temporarily test without the optional direct rule:

1. clear the relevant current-site store;
2. request a clean public URL once;
3. confirm that the expected HTML or JSON file appears;
4. request it again;
5. verify the PHP hit header.

If PHP does not generate or reuse the file, the Apache rule is not the first problem.

Check where the rule is installed

The rule must be active in the virtual host or .htaccess context that receives the tested hostname. Confirm:

• Apache allows the required override directives when using .htaccess;
• the file is below the effective document root;
• another virtual host is not handling the request;
• the POM Cache block runs before the normal WordPress rewrite block;
• syntax validation and server reload completed successfully.

Back up the configuration before changing it.

Match the generated path

Compare the actual cache artifact with the path constructed by the rule:

• cache root;
• pom-cache HTML or progressive JSON subtree;
• request hostname;
• multisite subdirectory, when applicable;
• trailing slash behavior;
• locale and archive segments for JSON;
• canonical HTML filename index.html.

The supplied rules commonly use the request's server name. Host aliases, www redirects, ports, proxies, or a different public/origin hostname can therefore point at a different directory.

Check request conditions

A safe direct HTML hit is intentionally narrow. Confirm that the request:

• uses an allowed read method;
• has a clean query string;
• does not carry a WordPress login or application bypass cookie;
• maps to a regular public path;
• has an existing readable file.

For JSON, confirm that the URL maps to the configured progressive JSON route and exact .json artifact.

Do not relax cookie, query, or method checks merely to make the rule match. A PHP fallback is safer than a broad static rule.

Distinguish a direct hit

Apache delivery does not execute PHP, so it will not add:

X-POM-Cache: Served static cache from PHP; phase=early

Use server access logs, handler information, or controlled tracing to prove static delivery. Test the origin without CloudFront so an edge hit does not obscure the result.

Configuration changes require copied-rule changes

The settings screen provides rules to deploy; Apache runs the copy installed on the server. Disabling a WordPress switch or changing the cache location does not automatically rewrite that server copy.

After a path, host, multisite, or route change:

1. generate the current rules;
2. compare them with the installed block;
3. deploy through the normal configuration process;
4. validate syntax;
5. test anonymous and logged-in requests;
6. clear or retire old origin paths only after the new mapping works.

If the origin serves correctly but the public response remains stale, diagnose CloudFront still serves old content.