Fix WordPress Nonce Errors and Forms Broken by Caching

A WordPress form that works after clearing the cache, then fails the next day, may be receiving an expired nonce. The page can still look normal and load quickly while submissions stop working. We’d call it nonce-sense, but a broken enquiry form is no joke.

The usual fix is to keep cached pages fresher than the tokens they contain, or exclude the affected page from caching. Here is how to check the cause and make the fix last.

Check whether caching is the cause

A nonce is a security token WordPress uses to help validate a request. Standard WordPress nonces last between 12 and 24 hours. If page caching stores HTML containing that token for longer, new visitors can receive an expired version.

1. Test while logged out. Open the affected page in a private browser window. Administrators often bypass the page cache, which can hide the problem.
2. Note the error. Messages such as “nonce verification failed”, “security check failed”, a 403 response or an AJAX response of “-1” are clues, not proof. Firewalls and other plugin issues can produce similar failures.
3. Clear the affected page from every cache layer. Check the WordPress plugin, hosting cache and any CDN that caches HTML. Reload the page in a new private window and repeat the action.

If clearing the cache temporarily fixes it, stale HTML is a strong suspect. Clearing an object cache alone will not necessarily remove cached pages. If the problem remains with page caching bypassed, investigate the form plugin, JavaScript errors, firewall rules and user session instead.

Fix cache expiry or exclude the page

Start with the affected page. For an enquiry form that must work reliably, excluding its page from the plugin, hosting and CDN page caches is often the simplest fix. Use the documented exclusion settings and purge existing copies afterwards.

If you keep caching the page, set an expiry or refresh interval comfortably below the shortest nonce lifetime in use. For standard WordPress nonces, a 6-hour refresh gives useful headroom. Plugins can use shorter or customised lifetimes, so check their documentation too.

These are defaults or starting points, not a guarantee. Scheduled refresh and expiry work differently, and every layer serving HTML needs a suitable limit. Check that scheduled tasks run reliably. With WP Super Cache, Preload Mode disables regular garbage collection, so review its refresh settings separately.

Content-change purging is not enough. Tokens expire even when nobody edits the page. Equally, a 12-hour or 24-hour refresh leaves too little margin for standard nonces.

For a development fix, use the form plugin’s supported method of fetching a fresh token from an uncached endpoint. Keep it tied to the correct session. Never share cached logged-in tokens between visitors, disable nonce checks or lengthen token validity simply to hide the fault.

Test the fix beyond the first visit

• After purging, load a fresh page while logged out and submit a clearly labelled test enquiry. Confirm it arrives.
• Repeat after the configured cache interval and again the next day, without manually clearing the cache.
• Test a form left open overnight too. Page-cache expiry cannot update HTML already sitting in a visitor’s browser; that needs token refresh or a helpful reload message.

A fast page is only useful if its forms keep working. Cache freshness was one reason we changed our own setup, covered in our FlyingPress review: https://thriveweb.com.au/blog/flyingpress-review/