Back up and review server rules before deployment
Server rules affect every request before WordPress can recover from a mistake. A cache rollout needs a known-good backup, a narrow change, a syntax check, and an explicit rollback owner.
This guide covers the review itself. Use Install the supplied Apache rules safely for the interface and placement steps.
Capture the current behavior
Before editing:
- save a recoverable copy of the active configuration;
- record where the main WordPress rewrite block begins;
- confirm homepage, one inner page, login, administration, media, REST, and a 404 currently work;
- prove one cached page through PHP;
- record the cache location and the generated file path;
- identify the CDN bypass or invalidation procedure.
The backup must belong to the same virtual host and deployment version that will be changed.
Review order and scope
The POM Cache block must be evaluated before WordPress rewrites a public route to index.php. It must not be placed:
- inside another plugin’s generated marker;
- after an unconditional WordPress front-controller rule;
- in a directory where its relative paths mean something different;
- in a broader virtual host that serves unrelated applications.
Preserve the # BEGIN POM Cache and # END POM Cache markers so the block can be identified without guessing.
Review every input to the cache key
Use this checklist:
| Input | Required decision |
|---|---|
| Method | Only safe reads may use static HTML |
| Host | Must select the correct site/domain tree |
| Path | Must be canonical, normalized, and within the cache namespace |
| Query | Meaningful state must fall through |
| Cookies | Authentication, passwords, comments, carts, sessions, and custom personalization must bypass |
| Representation | JSON and other formats must not receive HTML |
| File state | The exact target must exist; no directory listing or guessed fallback |
Review proxy behavior too. An origin rule cannot evaluate a cookie, host, or query that the upstream layer removed or replaced.
Review filesystem assumptions
Confirm:
- the cache tree is not the filesystem root or WordPress root;
- Apache can read files but does not need to write them;
- PHP can write temporary files and rename them;
- the rule’s path matches Advanced → Storage → Cache Location;
- every origin node sees the generated file;
- symlinks and mounts resolve to the intended cache root;
- domain aliases cannot select another customer or site tree.
Do not use a wildcard search across the filesystem to compensate for an incorrect mapping.
Validate before reload
Use the hosting platform’s supported configuration test. A successful test proves syntax, not correctness.
After reload, check:
- no internal redirect loop;
- no unexpected 403/404/500 response;
- WordPress login and administration remain dynamic;
- media files still use their normal handlers;
- misses reach WordPress;
- cached public hits return the expected document;
- security and cache headers remain present on static responses.
Rollback trigger
Restore the previous configuration immediately if:
- authenticated or cart traffic receives the anonymous file;
- hosts or subsites cross;
- state-changing methods return cached HTML;
- WordPress routes stop reaching
index.php; - assets receive the wrong content type;
- the origin begins looping or returning server errors.
After rollback, invalidate any unsafe edge copy before retesting.
Keep changes separable
Deploy HTML cache rewrites, Progressive JSON rewrites, WebP negotiation, and compression as separate changes. Each has a different cache key and header contract. Combining all four in one unverified block makes failures difficult to isolate and rollback.
Finish with Verify that Apache serves cached pages, then test CDN behavior independently.