Understand the public cache file layout
The static HTML tree follows public URLs. Knowing that mapping lets you verify a particular page without guessing from the aggregate cache count.
Start from Cache Location
Open POM Cache → Advanced → Storage and read Cache Location. The default base is:
wp-content/cache/POM Cache adds its own pom-cache/ subdirectory. Do not enter that subdirectory in the field itself.
With the default setting, all static HTML begins below:
wp-content/cache/pom-cache/URL-to-file examples
| Public URL | Relative static file |
|---|---|
https://example.com/ |
pom-cache/example.com/index.html |
https://example.com/contact/ |
pom-cache/example.com/contact/index.html |
https://example.com/news/page/2/ |
pom-cache/example.com/news/page/2/index.html |
https://fr.example.com/contact/ |
pom-cache/fr.example.com/contact/index.html |
https://example.com/fr/contact/ |
pom-cache/example.com/fr/contact/index.html |
Every entry uses index.html. The host and path directories are the cache key.
POM Cache does not add an HTTPS folder, query-string hash, cookie variant, .gz sibling, or PHP metadata file.
Multisite behavior
The same structure supports the common network models:
- subdomains and mapped domains separate by hostname;
- subdirectory sites separate by the site path;
- language prefixes separate when they are part of the canonical URL.
Current-site tools derive their branch from the site’s WordPress home URL. A canonical-host mismatch can therefore create unexpected parallel directories. Redirect aliases before cache delivery.
Temporary files during generation
POM Cache writes a uniquely named .tmp file in the final page directory, checks that it is non-empty, and renames it to index.html.
A temporary file may appear briefly during an active request. Repeated orphan .tmp files are not normal steady-state cache entries and may indicate an interrupted write or filesystem problem. Investigate permissions and process ownership before deleting broadly.
Contents of index.html
The file is the complete response document plus POM Cache comments. It should contain the same public page structure a signed-out visitor receives, followed by generation timing and timestamp information.
It does not preserve a serialized set of WordPress response headers. Delivery layers construct the headers used for a hit. This is why headers that exist only during the original PHP render must not be assumed to reappear on a static response.
Filesystem safety
Before reading, writing, or purging a path, POM Cache resolves the real filesystem location and confirms that it belongs below Cache Location. It also protects the cache root and the pom-cache root from being treated as an individual page target.
Choose a location that:
- exists on every origin node that must serve the same pages;
- is writable by the PHP process for generation;
- is readable by the web server for direct delivery;
- is not a broad system or WordPress root;
- matches the path used in native server rules.
Changing Cache Location
Treat a location change as a migration:
- disable or isolate direct server delivery;
- record the current path and rewrite assumptions;
- set the new base under Advanced → Storage;
- create it with the correct owner and permissions;
- update and review Apache/Nginx configuration;
- purge obsolete edge objects;
- generate a fresh page and verify its exact new path;
- remove old cache data only through an approved, recoverable deployment process.
POM Cache does not move old files automatically. A server rule pointing to the old tree can continue serving them.
For host details, see How cache files stay isolated by host and site.