A WordPress nonce helps confirm that a request came from an expected page and time window. It is not a permanent token. Serving old cached HTML or mixing asset versions can make a valid visitor submit a nonce the server no longer accepts.
Prove the mismatch before excluding the entire site from cache.
Capture the failed response
Submit synthetic data while logged out and inspect the request status and redacted response. Record whether WordPress reports an invalid or expired nonce, security check failure or generic 403.
Match the timestamp with PHP and security logs. A Cloudflare or ModSecurity 403 can look similar but has a different owner.
Do not share the nonce itself; treat it as temporary security data.
Compare cached and uncached visitors
Test a private window, a cache-bypass preview available to administrators and the normal public URL. Inspect response headers such as cache status and page age.
If the public page fails while the uncached copy works with the same form, cache age or variation is strong evidence. Do not conclude from one logged-in administrator test because logged-in users are commonly excluded.
Record desktop, mobile and geographic/CDN variants where used.
Check the page-cache lifetime
Compare the nonce lifetime expected by the plugin with page-cache and CDN TTL. A page must not serve a token beyond the period WordPress accepts it.
Use the form plugin or cache provider’s documented compatibility method. Some forms refresh tokens through AJAX; confirm that refresh request is not cached or blocked.
Exclude only pages or fragments that genuinely contain per-session dynamic state.
Verify the origin server clock as well, because significant time drift can make freshly generated security state appear outside its accepted window.
Prevent caching of endpoints
POST, AJAX and REST responses for form processing must not be stored as reusable success or error pages. Review CDN and server rules for the exact endpoint.
A cached success response can tell a visitor a lead was sent when WordPress never processed it. Purge existing endpoint cache after fixing the rule.
Do not bypass all WordPress REST security as a cache workaround.
Review JavaScript optimisation
Minification normally changes formatting, but combination, delay and dependency reordering can prevent token refresh or initialise a form with stale data.
Inspect console errors and script versions. Exclude the smallest proven script handle from delay or combine, then regenerate optimised assets.
Avoid hard-coding a nonce into a static JavaScript file; generate or retrieve it through the supported WordPress mechanism.
Look for multiple form copies
A page builder may output separate mobile and desktop forms with duplicate IDs and different cached tokens. One script can update only the first copy while the visitor submits the second.
Inspect the rendered DOM and network requests. Prefer one responsive instance or assign unique form identifiers.
Clear stale page-builder CSS/JS only after correcting the duplicate structure.
Keep security intact
Do not disable nonce validation, extend tokens indefinitely or accept every anonymous request. The repair should serve fresh state and let the legitimate validation continue.
If a form is intentionally public, combine correct nonce handling with server-side validation, spam controls and rate limits.
Provide a monitored fallback while a critical form remains unreliable.
Verify across cache states
After repair, purge the affected page/CDN object and submit once from a fresh public session. Repeat after the normal cache has warmed and near the relevant TTL where practical.
Confirm one request, one entry, one notification and final mailbox arrival. Test mobile cache variants and consent states.
Request urgent repair when several cache layers disagree or the endpoint returns cached success. Share URLs, cache headers and redacted statuses—never nonces, cookies or form contents.