Static publication changes how a representation is delivered. It does not change which source content is eligible, and it does not by itself prove that the public response is correct.
One publishing model, two delivery paths
Dynamic requests use the WordPress publication handler. Optional static materialization writes eligible representations to a configured publication root so a web server or CDN can serve the bytes without executing PHP for every request.
The registry coordinates fixed publication metadata. Settings changes invalidate the current generation and schedule reconciliation. The publisher checks recorded ownership hashes before overwriting or deleting files; a conflicting file must be surfaced rather than silently replaced.
Choose the mode for the site
| Mode | Architectural role |
|---|---|
| Off | Dynamic publication when the server routes requests to WordPress |
| Essential compatibility publication | Small registered targets to address common direct-file routing behavior |
| Full eligible publication | Materialize supported enabled output while preserving ownership checks |
Multisite is dynamic-only because sites can share a web root. A separately rooted headless frontend needs an explicitly configured publication root. A writable directory and equivalent origin/CDN routing are operational requirements.
Bytes and headers are separate evidence
Public verification needs to inspect availability, body validity, media type, and protocol headers. A canonical well-known path can fail even when an alias works. A cache or server can deliver correct bytes with incorrect headers.
Static requests can also bypass WordPress analytics. Use server or CDN observations when the question concerns traffic that never reaches PHP.
Configure the Static File Engine and run publication verification.