Search Atlas Help Center

⚠️ OTTO Cache-Control Header Breaking WordPress Forms and Nonces on Non-WP-Rocket Sites

Open in
View as Markdown Open in ChatGPT Open in Claude
Camilo Aponte

Camilo Aponte

Last updated on Sep 30, 2026

If OTTO is enabled on your WordPress site without WP Rocket active, a misconfigured Cache-Control header causes CDNs to cache pages containing WordPress security tokens (nonces), silently breaking forms, checkout flows, and login pages. A fix is now released — follow the steps below to purge affected cache and restore full form functionality.

🔍 What Is Causing the Problem

When OTTO processes pages for non-logged-in visitors and WP Rocket is not active, it sets this HTTP response header on every processed page:

Cache-Control: public, max-age=3600

This instructs CDNs and edge servers — including Cloudflare and Pressable, plus any reverse-proxy or server-side cache that respects Cache-Control: public (for example, Nginx FastCGI cache) — to cache the complete HTML of each page and serve that identical copy to every visitor for up to one hour.

WordPress pages typically contain nonces — short-lived security tokens embedded directly in form HTML that WordPress generates uniquely per user session. When a CDN caches a page with a nonce baked in, every subsequent visitor receives that same stale token. WordPress rejects it on submission, causing the form to fail — usually without displaying an error to the visitor.

Any visitor who received a cached page can also read the nonce value directly from the HTML source and replay it to submit authenticated requests on behalf of the form owner before it expires (up to one hour). For WooCommerce and enterprise sites, this is a non-trivial security risk.

Operations broken by stale nonces include:

  • Contact and lead-capture forms (Contact Form 7, Gravity Forms, WPForms, etc.)
  • WooCommerce add-to-cart and checkout flows
  • Login and password-reset forms
  • Any WordPress AJAX action that uses a nonce for verification

🖥️ Configurations Affected by This Issue

You are affected if all three of the following are true for your site:

  • OTTO is enabled and actively processing your WordPress site
  • WP Rocket is not installed or is inactive
  • Your site sits behind a CDN or edge cache — Cloudflare and Pressable are the confirmed affected providers, plus any reverse-proxy or server-side cache that respects Cache-Control: public (for example, Nginx FastCGI cache)

When WP Rocket is active, it manages its own cache-control headers and OTTO defers to WP Rocket's configuration, preventing the conflicting public header from being set — your site is not affected by this issue.

🚨 Symptoms of CDN-Cached Nonces

Look for these signs that stale nonces are breaking your site:

  • Form submissions silently fail — the page reloads or nothing happens after clicking Submit
  • WooCommerce cart or checkout throws a security error or session warning
  • Login or password-reset forms return an "Invalid token" or similar nonce error
  • Forms work correctly immediately after purging your CDN cache, then begin failing again within an hour
  • Browser developer tools show form POST requests returning 403 errors or a -1 nonce-verification failure in the response body

🔬 How to Check If Your Site Is Currently Affected

Self-diagnose in under a minute using your browser's developer tools:

  1. Open your site in Chrome, Edge, or Firefox and press F12 to launch developer tools.
  2. Select the Network tab, then reload a page that contains a form.
  3. Click the top-level page request in the Network list and open the Headers panel.
  4. Under Response Headers, look for Cache-Control: public, max-age=3600.

If you see that exact header and WP Rocket is not active on your site, your site was affected before the fix was deployed — complete the remediation steps below.

🛠️ Remediation Steps After the Fix

The incorrect Cache-Control: public, max-age=3600 header has been corrected in the latest OTTO WordPress plugin release. Confirm your site is running the patched version before purging caches — without the update, newly generated pages will continue to receive the bad header. Complete all steps below to fully restore form functionality.

  1. Confirm OTTO is updated to the patched release. In your Search Atlas dashboard, open OTTO and verify you are running the latest version of the OTTO WordPress plugin. Apply any available update before continuing.

  2. Purge your CDN cache in full. Stale cached pages containing old nonces will continue causing failures until removed:

    • Cloudflare: Log in → select your domain → go to Caching → Configuration → click Purge Everything.
    • Pressable: Log in to the Pressable dashboard → select your site → click Clear Cache.
    • Other CDNs: Use the full-site purge option in your provider's control panel or API.

  3. Purge your WordPress server-side cache (if applicable). In your WordPress admin panel, use your caching plugin's Delete All Cache or equivalent option to remove any locally cached copies as well.

  4. Test all affected forms. Submit a test entry on each form type — contact, checkout, and login. Successful submissions confirm the fix is active.

Once the CDN cache is cleared, newly generated pages will carry the corrected headers and WordPress nonces will remain fresh for every visitor.

✅ How to Verify the Corrected Cache-Control Header

To confirm OTTO is no longer setting the problematic header on your pages:

  1. Open your browser's developer tools (press F12) and select the Network tab.
  2. Load a page on your site that contains a form.
  3. Click the page request in the Network tab and open the Headers panel.
  4. Under Response Headers, confirm that Cache-Control: public, max-age=3600 is no longer present.

If the header is still present after completing the remediation steps, confirm the OTTO update was applied successfully and repeat the full CDN cache purge before re-testing.

📌 Related Cloudflare Issue (OTTO-1931)

If you use the OTTO Cloudflare DNS integration and notice OTTO-deployed changes reverting shortly after being applied, that is a separate, already-resolved issue tracked as OTTO-1931 — not a return of the cache-control bug described in this article.

After updating OTTO to the latest WordPress plugin release, both issues should be resolved. If you continue to see Cloudflare DNS changes reverting after the update, contact Search Atlas Support so the team can investigate your specific deployment.

🎯 You now understand why OTTO's public Cache-Control header caused CDNs to serve stale WordPress nonces and silently break form submissions — and after updating OTTO and performing a full CDN cache purge, your forms should be fully operational. If you continue to see form failures after completing all steps, contact Search Atlas Support for hands-on assistance.