Install the supplied Apache rules safely

This procedure installs the static HTML block shown by POM Cache. It assumes that PHP generation and early PHP delivery already work and that you can restore the previous server configuration immediately.

The plugin displays the current recommendation; copy it from the interface instead of reusing a block from an older article or another site.

Prerequisites

Confirm:

• Apache mod_rewrite is enabled;
• the site permits .htaccess FileInfo overrides;
• pretty permalinks work;
• POM Cache → Advanced → Storage → Cache Location is correct;
• the default HTML path exists after a controlled page generation;
• you have a tested configuration backup;
• you can run the host’s Apache syntax/reload validation;
• the CDN can be bypassed for the origin check.

If .htaccess overrides are disabled, install equivalent directives in the virtual-host configuration through the server administrator. Apache documents the required override behavior in Per-directory rewrites.

Copy the current block

1. Open POM Cache → Advanced → Apache rules.
2. Locate Recommended .htaccess rules.
3. Copy the complete content from # BEGIN POM Cache through # END POM Cache.
4. Open the main WordPress .htaccess.
5. Place the block before the standard WordPress front-controller rules.
6. Preserve every unrelated rule and marker.
7. Save through the deployment’s controlled configuration process.

POM Cache does not confirm that the block was copied and does not keep the file synchronized after plugin updates.

Review paths before activation

The displayed HTML block assumes the standard layout:

{DOCUMENT_ROOT}/wp-content/cache/pom-cache/{SERVER_NAME}/{URL path}/index.html

Compare that expression with the actual generated file.

Adapt the deployment if:

• WordPress or wp-content is outside the document root;
• Cache Location is not wp-content/cache/;
• a reverse proxy changes the host seen by Apache;
• SERVER_NAME differs from the public cache directory;
• WordPress is mounted below a subdirectory;
• a mapped-domain or multisite path needs a different namespace.

Do not make the file test broader. It must point only to the POM Cache tree.

Review the request boundary

The effective server configuration must reproduce the PHP safety outcome:

• permit static HTML only for safe read methods such as GET and HEAD;
• reject meaningful query strings;
• reject WordPress login, password, comment-author, WooCommerce session, and cart state;
• reject malformed or unexpected path shapes;
• require the exact target file to exist;
• fall through to WordPress for every non-match.

The recommendation also checks legacy mobile profile headers and expects the page URL to have the trailing-slash shape used by the generated tree.

The HTML rule also requires the per-host .country-zone-pricing-shared-cache-safe sentinel created by POM Cache. Do not remove or replace this file test. Its absence deliberately sends the request to WordPress when the universal country-pricing contract is uninitialized, pending, or unsafe. The recommended rule excludes REST and WordPress AJAX paths before testing a cached page file.

If another application adds a personalization cookie, extend the upstream bypass policy before enabling direct delivery. POM Cache cannot inspect that cookie after Apache has answered.

Validate syntax and ordering

Run the hosting platform’s supported Apache configuration check. Do not reload a production server merely because WordPress can still edit .htaccess.

After activation:

1. request the site homepage;
2. request WordPress administration and login;
3. confirm media and static assets still resolve;
4. request a URL that does not have a cache file;
5. confirm that it reaches WordPress instead of returning a server error;
6. inspect redirect behavior and make sure the rule does not loop.

<IfModule mod_rewrite.c> can cause the block to be skipped when mod_rewrite is unavailable. A clean syntax check therefore does not prove a cache hit.

Install Progressive JSON separately

Do not assume the HTML block covers JSON. If the site uses compatible progressive archives:

1. open Advanced → Progressive JSON Apache rules;
2. review its routes, host/path mapping, cache-control value, and language prefixes;
3. add that complete block before the WordPress rules;
4. verify JSON content type and response headers independently.

The JSON block accepts GET, requires an empty query string and no listed bypass cookie, and only rewrites when the corresponding file exists.

Roll back

If behavior changes unexpectedly:

1. restore the last known-good server configuration;
2. validate and reload it through the approved host process;
3. clear or bypass the CDN;
4. confirm the PHP early fallback still serves a cached page;
5. compare the stored file path with the rule before trying again.

Removing the Apache block does not disable POM Cache generation. It returns eligible hits to the PHP path.

Continue with Verify that Apache serves cached pages.