01 · The symptom
Three things make it maddening.
A user fills in a form, submits it, and gets an error: your nonce did not verify. Or are you sure you want to do this, or a silent failure where the form just does not submit. It affects job applications, registration forms, checkout flows, comment submissions and anything else that posts data. It is most expensive on recruitment and job board sites, where a candidate who hits an error simply leaves and never tells you.
You cannot reproduce it
You test the form, it works perfectly. Every time.
It comes in clusters
Nothing for weeks, then six reports over a weekend.
The obvious advice does not help
Clearing the browser cache, trying a different browser, disabling extensions: users try all of it and still hit the error.
02 · What a nonce is
A one-time token, and it is doing its job.
A nonce is a one-time token WordPress puts in a form to prove the submission came from your site and not from somewhere else. It is a legitimate security feature, defending against a class of attack where a malicious site tricks a logged-in user browser into submitting a request.
- •The token is tied to a specific user session and a specific action.
- •It expires. By default, within about 24 hours, and it changes halfway through that window.
So when the token in the form does not match what WordPress expects on submission, WordPress correctly refuses the request. The error is the security layer working as designed. The problem is that something upstream has handed the user the wrong token.
03 · The cause
A full-page cache serves everyone the first visitor token.
A full-page cache saves the complete HTML of a page the first time it is requested and serves that saved copy to everyone afterwards. That is exactly what you want for a blog post. It is a disaster for a page with a form on it.
The saved copy includes the nonce that was generated for the very first visitor. Every subsequent visitor receives that same token. By the time the tenth person submits the form, that token is stale, belongs to someone else session, or has expired outright. WordPress rejects it.
Symptom 1
You cannot reproduce it
You are almost certainly logged in, and most caching layers bypass the cache for logged-in users. You are being served a fresh page with a valid token. Your users are not.
Symptom 2
It clusters
It depends on when the cache was populated and how long it lives. A page cached at 2am serves a token that is already hours old by the time your morning traffic arrives.
Symptom 3
Clearing the browser cache does nothing
The stale copy is not in their browser. It is on a server, or on a CDN edge node, between you and them.
05 · The fix
Four steps, in this order.
List every page with a form on it
Job application pages, registration and account creation, checkout and cart, contact forms, comment forms, anything posting data. Include listing pages if the form is embedded there too.
Bypass the cache on those pages at every layer
At the CDN or proxy, create a cache rule that bypasses caching for those URL patterns. At the host, do the same in whatever panel controls server-level page caching, and if you cannot find the setting, ask their support directly whether server-level caching is active on your plan. In your caching plugin, add the same paths to the exclusion list.
RuleBypass, not shorten. A short cache lifetime reduces the frequency of the error rather than eliminating it, which is worse than either extreme because it makes the problem intermittent and unattributable.
Expect a short tail
Pages already cached will keep serving stale tokens until the cache is purged or expires. Purge the cache explicitly after making the change rather than waiting it out, otherwise you will get reports for another day and conclude the fix did not work.
Accept a residual rate
Even with caching fully bypassed, one cause remains: a user who opens a form, leaves the tab open for hours, and then submits. The token legitimately expired. That is WordPress working correctly and there is no configuration that removes it without weakening the security the nonce exists to provide.
RuleThe realistic target is not zero. It is a handful of reports a year instead of several a week.
06 · What not to do
Three tempting mistakes.
Do not
Extend the nonce lifetime indefinitely
You can filter nonce_life to a longer value, and it will reduce the error, and it will also widen the window in which a stolen token is usable. If you do change it, change it deliberately and modestly, and understand you are trading security for convenience.
Do not
Disable caching site-wide
You will fix the forms and wreck your performance. Bypass the pages that need it, cache the rest aggressively.
Do not
Blame the plugin first
Form and job board plugins get blamed for this constantly. In most cases the plugin is generating perfectly valid tokens and the infrastructure is serving stale copies of them. Check your caching layers before you open a support ticket.
One more thing worth doing: improve the error message. Your nonce did not verify means nothing to a candidate uploading a CV or a customer at checkout, and the natural interpretation is that the site is broken and their data went nowhere. Where the plugin allows it, replace it with plain language: explain that the page has been open too long, tell them to refresh, and confirm that nothing was lost. If chasing this across a stack you did not build is not a good use of your week, it is part of our WordPress security work.
This guide is reference material behind our WordPress security work. If you would rather not chase every caching layer yourself, that is where the same work is done for you.
Common questions
Why can I never reproduce this myself?+
Because you are logged in. Nearly every caching layer serves logged-in users a fresh, uncached page, so you get a valid token every time. Test in a private browsing window, logged out, on a page that has already been cached by earlier traffic.
Could it be a plugin conflict?+
It can be, but it is much less common than caching, so check caching first. If you have bypassed every caching layer on the affected pages, purged, and the error rate has not moved, then it is worth looking at the plugin and at anything modifying session handling or cookies.
Does this only affect Cloudflare?+
No. Any full-page cache causes it: any CDN, any host-level page cache, any caching plugin. Cloudflare comes up most often because it is the most widely deployed, and because its default caching behavior on some configurations is more aggressive than people expect.
We are on a managed host that says caching is handled for us. Is that the problem?+
Possibly. Managed hosts commonly run server-level page caching that is invisible in your WordPress admin, and it is a frequent second cause after people have already fixed the CDN layer. Ask your host directly whether server-level caching applies to your plan and how to exclude specific paths.
Can a nonce error mean the site is compromised?+
Very unlikely. A nonce failure means a token did not validate, which is the security layer doing its job. A pattern of failures across many users points to caching. If you have other reasons to suspect a compromise, investigate those separately.
How many reports should I expect after fixing it?+
On a site with significant form traffic, a handful a year from genuinely expired sessions. If you are getting several a week, a caching layer is still serving stale tokens somewhere.
