Fix WordPress "Are You Sure You Want to Do This?" Nonce Errors

You click "Update" on a post, submit a WooCommerce checkout form, or try to save a settings page — and instead of it working, WordPress throws up a plain white confirmation screen: "Are you sure you want to do this?" with a single link to go back. No real explanation, no error code you can Google confidently. Just a dead end. Here's what's actually happening and how to stop it from recurring.

What This Error Actually Means

That message is WordPress's generic response when a nonce check fails. A nonce ("number used once") is a short-lived security token WordPress embeds in forms and admin-ajax requests to confirm the request really came from the page it claims to, from a logged-in session that's still valid. When the nonce submitted doesn't match what WordPress expects, it refuses the action outright rather than guessing what you meant.

It's a security feature working as designed — the problem is almost always that the nonce went stale or got served from the wrong context before you ever clicked submit.

Common Causes

Fix 1: Rule Out Page Caching First

This is the cause behind the vast majority of nonce errors we see, so check it before anything else. Every serious caching plugin has a setting to never cache pages for logged-in users — make sure it's actually on:

• WP Super Cache: Settings → WP Super Cache → Advanced → enable "Don't cache pages for logged in users."
• W3 Total Cache: Performance → Page Cache → under "Never cache the following pages" confirm logged-in users are excluded, and check the "Don't cache pages for logged in users" box under Advanced.
• LiteSpeed Cache: Cache → Excludes → "Do Not Cache Roles" — add Administrator, Editor, and any role that edits content.
• WP Rocket: logged-in users are excluded from cache by default, but double-check under Cache settings if you've customized anything.

If you're on cPanel and using LiteSpeed's server-level cache alongside a plugin, confirm both layers agree — a server-level cache can override plugin settings if it isn't configured to respect the same exclusions.

Fix 2: Exclude Cookies From CDN/Edge Caching

If you're running Cloudflare or another CDN in front of your site, an edge cache can serve the same HTML — nonce included — to every visitor regardless of login state. In Cloudflare:

1. Go to Caching → Configuration and check your caching level isn't set to cache everything including cookies.
2. Under Rules → Cache Rules, add a rule to bypass cache when the wordpress_logged_in_ cookie is present.
3. If you use "Cache Everything" page rules for performance, exclude /wp-admin/* and any front-end pages with forms (checkout, login, comment forms) explicitly.

A CDN caching a logged-in page is the one scenario where clearing your browser cache won't help at all — the stale copy is sitting on Cloudflare's edge servers, not your laptop.

Fix 3: Flush the Object Cache

If you're running Redis or Memcached object caching and just updated a plugin, theme, or WordPress core, flush it:

wp cache flush

Or from cPanel → phpMyAdmin, you can manually clear the wp_options transients table if WP-CLI isn't available:

DELETE FROM wp_options WHERE option_name LIKE '_transient_%';

Take a quick backup of the table first — deleting transients is safe, but it's good practice before running any bulk delete against a live database.

Fix 4: Check Server Time

Nonce validation depends on the server's clock being accurate. If your VPS clock has drifted, tokens can look expired before their actual lifetime is up. Check current time and sync via NTP:

timedatectl status
chronyc tracking

If the reported time is off by more than a minute or two, restart chronyd or install it if it isn't running. Clock drift causes a handful of other odd symptoms too (cron jobs firing at the wrong time, SSL handshake failures), so it's worth fixing regardless.

Fix 5: Extend the Nonce Lifetime (Use Sparingly)

If your team genuinely needs longer editing sessions — say, someone drafts a long post over several hours without saving — you can extend the default nonce lifetime with a filter in your theme's functions.php or a site-specific plugin:

add_filter( 'nonce_life', function() {
    return 12 * HOUR_IN_SECONDS;
});

Default is 24 hours split into two 12-hour "tick" windows, so this rarely needs touching. Treat it as a last resort, not a first fix — the caching and clock issues above are almost always the real culprit.

Fix 6: WooCommerce-Specific Nonce Failures

If the error shows up specifically at checkout or when applying a coupon, WooCommerce's cart/checkout fragments are often cached separately from the rest of the page via AJAX. Make sure your caching plugin excludes:

• /cart/, /checkout/, and /my-account/ pages entirely
• Requests to ?wc-ajax= endpoints
• admin-ajax.php calls in general, if your plugin caches AJAX responses

Most WooCommerce-aware caching plugins (LiteSpeed Cache, WP Rocket) detect and exclude these automatically — but if you built custom cache rules at the server or CDN level, they won't know to skip WooCommerce's dynamic fragments unless you tell them.

Prevention Checklist

• Exclude logged-in users from page caching — plugin level and CDN level, both
• Keep server time synced with NTP/chrony
• Flush object cache after every plugin, theme, or core update
• Avoid regenerating NONCE_SALT/AUTH_SALT in wp-config.php while people are actively working in wp-admin
• If you use a security plugin that rotates keys automatically, schedule rotations for low-traffic hours

Frequently Asked Questions

Does clearing my browser cache and cookies fix this?

Sometimes, if the stale nonce is only sitting in your own browser's cached copy of the page. Log out, clear cookies for the site, and log back in. If the problem is a server-side or CDN-level cache, though, clearing your own browser won't help — every visitor gets served the same stale page until the server-side cache is cleared or excluded correctly.

Is a nonce error a sign my site has been hacked?

Not on its own. It's a routine security check failing, almost always due to caching, timing, or session mismatches — not evidence of compromise. If you're also seeing unfamiliar admin users, unexpected file changes, or the error appears alongside other odd behavior, that's worth investigating separately, but the nonce message by itself isn't a red flag.

Why does this happen more after I install a new caching plugin?

Because the previous plugin's exclusion rules don't carry over. Every caching plugin has its own settings for what to exclude from logged-in caching, and switching plugins resets those choices to that plugin's defaults, which may not exclude the same pages your site actually needs excluded.

Can I just disable nonces to stop the error?

No — nonces are a core WordPress security mechanism (CSRF protection) baked into core, not something you can safely turn off. Fix the underlying cause instead; disabling nonce checks via a plugin or code hack opens your site to cross-site request forgery attacks.

I fixed my caching settings but the error still happens occasionally. Why?

Check if multiple people share the same login, or if you have long-idle admin sessions (a tab left open overnight). Also check that any staging-to-production sync tools aren't overwriting wp-config.php salts on a schedule, which invalidates every active session's nonces at once.