Title: WARNING* This plugin breaks functionality for wordpress editors after EVERY scan
Last modified: July 31, 2025

---

# WARNING* This plugin breaks functionality for wordpress editors after EVERY scan

 *  Resolved [neodan](https://wordpress.org/support/users/neodan/)
 * (@neodan)
 * [10 months, 2 weeks ago](https://wordpress.org/support/topic/warning-this-plugin-breaks-functionality-after-every-scan/)
 * I want to highlight a critical issue with the CookieYes plugin for WordPress 
   that could seriously undermine your site’s compliance efforts and documentation.
   Every time you run a new cookie scan, CookieYes **completely overwrites your 
   existing cookie list** with only the cookies discovered in that specific scan.
   This means any cookies you manually added—such as those set for logged-in users,
   WordPress admins, or added via page builders and plugins—are instantly wiped 
   out if the scanner doesn’t detect them during that session. There is no warning
   before this happens and no built-in way to merge, import, or bulk re-add cookies
   after a scan.
 * For websites hosted on WPEngine or similar providers with a CDN, or for sites
   built with a pagebuilder, this isn’t just a compliance risk—it’s a **major operational
   threat**. Running a CookieYes scan can instantly remove cookies that are essential
   for site stability, login access, and backend management. One automated scan 
   can break your admin workflows or even your staging environment. If we had known
   this limitation before purchasing, we would have never chosen CookieYes. This
   is a serious issue that needs urgent attention!
 * You lose the ability to reliably track cookies that aren’t visible to guest users
   or the scanner, making it nearly impossible to maintain a complete, compliant
   record without painstaking manual work after every scan. Other cookie compliance
   tools like Complianz and OneTrust **do preserve manual cookie** **entries**, 
   but CookieYes currently offers no such protection. If you rely on manual entries
   for compliance, be extremely cautious—**a single scan can erase hours of work
   and break website functionality**.
 * We set the scan frequency for weekly. **After the scan ALL cookies were wiped
   that we manually added.** Why does CookieYes assume those cookies are no longer
   required? We manually added and labeled several necessary cookies that are critical
   for operating our website and managing updates. These included:
    1. A load balancing cookie set by AWS, directing traffic to healthy backend instances.
    2. A cookie that maintains login authentication for WPEngine staging and development
       sites.
    3. A cookie similar to AWSALB but dedicated to ensuring CORS requests are routed
       properly.
    4. A security cookie for logged-in WordPress users.
       Every one of these cookies 
       is vital for functionality, yet all were deleted from our CookieYes cookie manager
       after running a scan. This is not just an inconvenience—it’s a direct threat
       to maintaining compliance and operational stability. Luckily we have accurate
       documentation and we were able to manually add in the cookies that are necessary
       from a webhosting and wordpress perspective. **CookieYes does not have ability
       to mass import cookies back!** OneTrust keeps manual cookies; supports manual
       import/export and merge. This is not on the roadmap for CookieYes at the time
       of writing this post.In the dashboard there is a banner that says “We continuously
       monitor our scanning software to ensure its ongoing effectiveness, security,
       and accuracy. However, we advise you to run a quick manual check to determine
       if there are any cookies on your site that our scanner couldn’t detect. Instructions
       on [how to check cookies on your website manually](https://www.cookieyes.com/how-to-check-cookies-on-your-website-manually/).”
       CookieYes tries to cover themselves with a warning telling users to “run a quick
       manual check” for any cookies the scanner couldn’t detect. But this advice is
       honestly **unrealistic **for any real-world website. Manual checks are not a
       viable solution—there is no practical way to catch every cookie across every
       user type, page, and scenario. Critical cookies for admins, editors, staging
       environments, or complex integrations simply won’t appear in a guest session
       scan. Expecting site owners to manually re-add these every time is unrealistic,
       especially for large or enterprise sites. This is not just an inconvenience—
       it’s a design flaw that puts sites at risk and undermines the entire purpose
       of automated compliance tools. **The whole point of a cookie scanner is to avoid
       this manual, error-prone work—not force it on users after every scan!**
 *  -  This topic was modified 10 months, 2 weeks ago by [neodan](https://wordpress.org/support/users/neodan/).
    -  This topic was modified 10 months, 2 weeks ago by [neodan](https://wordpress.org/support/users/neodan/).

Viewing 2 replies - 1 through 2 (of 2 total)

 *  Thread Starter [neodan](https://wordpress.org/support/users/neodan/)
 * (@neodan)
 * [10 months, 2 weeks ago](https://wordpress.org/support/topic/warning-this-plugin-breaks-functionality-after-every-scan/#post-18580912)
 * Nevermind tthe issue was copying configuration from staging to main site. It 
   copies the banner configuration not the cookie manager configuration as well.
 *  Plugin Support [Nick](https://wordpress.org/support/users/nickcysupport/)
 * (@nickcysupport)
 * [10 months, 2 weeks ago](https://wordpress.org/support/topic/warning-this-plugin-breaks-functionality-after-every-scan/#post-18581543)
 * Hi there,
 * Thanks for raising this concern and for sharing the details of your experience.
 * To clarify, the plugin does not delete cookies that are manually added to your
   cookie list. Those entries will remain unless you remove them yourself.
 * The issue you experienced may be related to cookies that are temporary or not
   present on the website at the time of the scan. If a cookie is not active during
   the scan session, it won’t be detected and therefore will not appear in the automatically
   discovered list. 
   However, if you want to ensure that a specific cookie remains
   in your list even when it isn’t detected in a scan, the best approach is:
    1. Add the cookie manually in the cookie list from the **Cookie Manager **section
       of your account.
    2. Delete the auto-detected entry for that cookie (if present) from the** **cookie
       list.
 * Manually added cookies in the cookie list of your account will not be overriden
   or rewritten by future scans, even if they are not active on the site at that
   time.
 * .

Viewing 2 replies - 1 through 2 (of 2 total)

The topic ‘WARNING* This plugin breaks functionality for wordpress editors after
EVERY scan’ is closed to new replies.

 * ![](https://ps.w.org/cookie-law-info/assets/icon.svg?rev=3007243)
 * [CookieYes – Cookie Banner for Cookie Consent (Easy to setup GDPR/CCPA Compliant Cookie Notice)](https://wordpress.org/plugins/cookie-law-info/)
 * [Frequently Asked Questions](https://wordpress.org/plugins/cookie-law-info/#faq)
 * [Support Threads](https://wordpress.org/support/plugin/cookie-law-info/)
 * [Active Topics](https://wordpress.org/support/plugin/cookie-law-info/active/)
 * [Unresolved Topics](https://wordpress.org/support/plugin/cookie-law-info/unresolved/)
 * [Reviews](https://wordpress.org/support/plugin/cookie-law-info/reviews/)

## Tags

 * [major issue](https://wordpress.org/support/topic-tag/major-issue/)

 * 2 replies
 * 2 participants
 * Last reply from: [Nick](https://wordpress.org/support/users/nickcysupport/)
 * Last activity: [10 months, 2 weeks ago](https://wordpress.org/support/topic/warning-this-plugin-breaks-functionality-after-every-scan/#post-18581543)
 * Status: resolved