WordPress Nonce Error: Fix "Are You Sure?" for Good

You click Update, Publish, activate a plugin, or confirm a WooCommerce order in wp-admin, and instead of the result you expected you get a plain white box that says "Are you sure you want to do this?" with a link back. Nobody hacked your site. You just hit an expired or mismatched WordPress nonce.

What a Nonce Actually Is

Despite the name, a WordPress nonce isn't a one-time password. It's a short-lived token WordPress bakes into every admin form, AJAX call, and action link to confirm the request really came from you, in your current session, and not from a forged link on some other site (that's the CSRF protection it exists for). Every nonce is tied to your user ID, the specific action it's protecting, and a rolling time window.

When that token doesn't match what WordPress expects, core doesn't guess — it just blocks the action and shows the generic confirmation screen. It's a safety net doing exactly its job, but it's unhelpful about telling you why it fired.

Where You'll See It

• Saving or publishing a post after leaving the editor tab open overnight
• Activating, deactivating, or updating a plugin from the Plugins screen
• Running a WordPress importer (WXR/XML import, Duplicator, etc.)
• Confirming a WooCommerce order status change or refund
• Clicking a page builder's save/publish button (Elementor, Divi, Beaver Builder)
• Submitting a form right after a caching plugin clears or rebuilds its cache

Cause 1: The Nonce Simply Timed Out

By default, a WordPress nonce is valid for roughly 24 hours, split into two 12-hour "ticks." If your session straddles that boundary — you opened the editor at 9 AM and tried to save at 10 AM the next day — the token you're submitting no longer matches. This is the most common cause and the easiest to fix: reload the page, log back in if asked, and try again.

Cause 2: Page Caching Is Serving a Stale Nonce

This is the cause that actually costs people time. Full-page caching plugins (LiteSpeed Cache, WP Super Cache, W3 Total Cache) and edge caches like Cloudflare are built to cache HTML — and the nonce is embedded right in that HTML, either as a hidden form field or a JavaScript variable used for AJAX calls. If wp-admin or wp-login.php ever gets swept into that cache, or if a logged-in page gets cached and served to a different visitor, you end up submitting a nonce generated for someone else's session, or one that was baked into a page hours before the cache last refreshed.

The tell: the error shows up right after a cache clear, right after a plugin update, or seemingly at random for different admin users on the same site.

Cause 3: Session or Cookie Mismatch

Nonces are hashed against your user ID and a session token stored in your login cookie. A few things break that pairing:

• You're logged into wp-admin in two tabs or two browsers, and one session got invalidated after you changed your password or another admin forced a logout
• The AUTH_KEY, AUTH_SALT, or related secret keys in wp-config.php were just regenerated — this instantly invalidates every existing session and nonce, forcing everyone to log in again
• Server clock drift — if the box running PHP has the wrong system time, the time-window calculation behind the nonce comes out wrong even though the token itself is otherwise valid

Cause 4: Something Between the Browser and PHP Is Stripping Cookies

Less common, but it happens: a WAF rule (ModSecurity, an aggressive Cloudflare security level) or a security plugin strips or rewrites the login cookie or the _wpnonce field before it reaches PHP. If this is the cause, you'll usually see it fail consistently for every action, not just occasionally.

The Fix, in Order

1. Hard-refresh and log back in. Ctrl/Cmd+Shift+R the wp-admin page, and if you're prompted, re-enter your credentials. This clears roughly 80% of cases because it forces a fresh nonce tied to a fresh, valid session.
2. Purge every layer of cache. Clear the page cache plugin, any object cache (Redis/Memcached), and if you're behind Cloudflare, purge the edge cache too. Then reload wp-admin before retrying the action.
3. Exclude wp-admin and wp-login.php from page caching. This is the actual permanent fix if caching is the cause — see the table below for where to set it per plugin.
4. Check the server clock. SSH in and run date. If it's off by more than a minute or two, fix NTP/chrony sync (see our VPS clock drift guide) before blaming WordPress.
5. Confirm nobody just rotated the salts. Open wp-config.php and check if AUTH_KEY / AUTH_SALT / LOGGED_IN_KEY etc. were recently changed. If so, everyone needs to log out and back in once — that's expected, not a bug.
6. Rule out a WAF. Check /home/username/logs/domain.com_error_log or your ModSecurity audit log for a 403 tied to the same request. If you find one, whitelist the specific rule ID for wp-admin rather than disabling the whole ruleset.

Where to Exclude wp-admin From Cache

Note: WordPress core doesn't cache wp-admin by default — these exclusions are almost always about a plugin or CDN doing it unintentionally.

Prevention

• Keep wp-admin and wp-login.php permanently excluded from every caching layer you add later — write it into your site's setup checklist so the next plugin swap doesn't reintroduce the bug
• Sync server time with NTP/chrony and leave it running, don't just fix it once
• Avoid leaving editor tabs open across days; save drafts and close them
• Update WordPress core and plugins together rather than letting one lag — nonce-related hooks occasionally change between major versions
• If you run a security plugin that limits concurrent sessions, document that behavior so it isn't mistaken for a caching bug next time