It was a Tuesday afternoon update. A WordPress store switched from an older theme to a newer version of the same theme family. Cleaner code, faster load times, better mobile layout. The update took about 20 minutes.
By Wednesday, the cookie consent banner that had been showing for 18 months was gone. Analytics was still running. Facebook Pixel was still firing. Google Tag Manager was still loading everything it was supposed to load. But the consent mechanism—the thing that was supposed to gate all of that—had disappeared without anyone noticing.
The store owner found out four weeks later, from a customer support ticket. "I never got asked about cookies anymore. Did something change?" Something had changed. It just hadn't changed in any of the ways anyone was watching.
Why Theme Updates Kill Cookie Banners
Cookie consent banners aren't magic. They're code—usually a short JavaScript snippet that loads a third-party consent management platform (CMP), or a plugin's custom banner logic. That code lives somewhere in your theme's HTML.
That "somewhere" is the problem.
Most consent implementations get added to the site once, manually, by whoever set them up. The snippet goes into a theme template file—a header partial, the main layout file, a footer include. It works reliably, so nobody thinks about it again.
Then a theme update happens. The update ships new versions of those same template files. The old file, with your manually added snippet, gets replaced by the new clean file that doesn't have it.
Your tracking scripts survived the update because they're loaded by Google Tag Manager, which lives in its own container script—also in the theme, but usually in a separate location that's less likely to get overwritten. Your consent banner didn't survive because it was added directly to a template that the theme update replaced.
Tracking fires on every page load. Consent is never collected. Under GDPR, this means every analytics event, every ad pixel impression, and every session recording after the update is data collection without a lawful basis. This isn't an edge case interpretation—it's the scenario that generates the bulk of cookie consent enforcement complaints.
How This Plays Out on Each Platform
Shopify
Shopify themes are self-contained. When you switch to a new theme or update an existing one, you're working with a fresh copy of the theme files. Any code you added manually to theme.liquid—the main layout file that wraps every page—doesn't carry over.
Cookie consent snippets installed via Shopify apps are usually more resilient: the app re-injects its code via Shopify's ScriptTag API rather than directly into your theme files. But "usually" isn't "always." Some apps do write directly to theme.liquid during setup, or require manual snippet placement. If yours did, a theme switch removes it.
How to check: open your current theme.liquid in the Shopify theme editor and search for your consent platform's code or any reference to a cookie banner. If it's not there, it's not loading.
WordPress
WordPress consent banners typically come from plugins. This seems more resilient—plugins survive theme updates. But there are several failure modes:
Child theme updates: If your banner code is in your child theme's header.php or functions.php, updating the child theme can overwrite those files, depending on how the update was applied.
Plugin conflicts: New theme versions often include updated JavaScript. Occasionally these updates conflict with consent management plugins, causing the banner to load but not render, or to render and immediately dismiss itself.
Plugin deactivation during testing: Redesigns often involve a staging environment where plugins get deactivated to test the base theme. When the new theme goes live, not everything that was deactivated gets re-enabled. Consent plugins are easy to miss because the site "works" without them—there are no errors.
Caching: WordPress caching plugins sometimes serve old versions of pages for weeks after a theme update. Some visitors see the consent banner (cached pre-update), others don't (live post-update). This creates inconsistent consent collection that's hard to audit.
Webflow
Webflow lets you add custom code in two places: site-wide "Custom Code" settings (in Site Settings → Custom Code), and per-page custom code blocks. Both are separate from the visual design.
Site-wide custom code usually survives publishing updates because it lives in settings, not in a page template. Per-page code is more vulnerable: if you copy a page as a starting point, the custom code comes along. If you replace a page entirely with a new template, it doesn't.
The hidden risk in Webflow is template imports. If you import a new template section or replace a layout with one from the Webflow component library, and your consent banner was in a custom code block attached to the old layout, it's gone. Webflow won't warn you.
Why Nobody Notices Immediately
Cookie banners are seen by first-time visitors. Returning visitors, whose browser already has the consent cookie set, never see the banner regardless of whether it's working. Developers testing a new theme are usually logged in or visiting from the same browser they've used before—their consent cookie is already set.
The result: everyone involved in the theme update sees the site working exactly as expected. The banner doesn't appear for them because it appeared for them months ago. It's only new visitors—the people who most need to give consent—who find it missing.
And new visitors don't report missing cookie banners. They're barely aware of what a cookie banner is. They just interact with your site. Their data gets collected without consent, and you have no idea it's happening.
The Regulatory Exposure Window
From the moment your theme update removes the consent banner to the moment you discover and fix it, you're collecting data without consent. That window tends to be long.
If you check manually, you're checking when someone thinks to look—which may be the next compliance review, which may be three months away. If you have automated monitoring, the check happens the next day.
The difference isn't just time. GDPR enforcement considers the duration of a violation when determining fines. A one-day exposure because your monitoring caught it immediately is a very different conversation than a 47-day exposure because nobody was watching.
How to Prevent It
Use a consent management platform that injects via tag manager, not theme code
If your consent banner loads through Google Tag Manager or another tag management system, rather than being hardcoded into theme templates, theme updates can't remove it. GTM loads from a snippet in your <head>—and your tag manager container is where the consent banner lives, not in the theme files that get replaced.
This is the most robust approach. Set up your CMP so it fires from GTM, not from a snippet someone pasted into theme.liquid or header.php three years ago.
Add a consent banner check to your pre-launch checklist
Before pushing any theme update to production, test on a staging environment from a fresh browser window—not incognito mode of your regular browser, but a different browser profile that has no prior consent cookie for your site. If the banner appears, it's working. If it doesn't, find out why before the update goes live.
This takes two minutes and catches 100% of the cases where your banner would have gone missing.
Document where the consent code lives
In your site documentation—even a simple text file—record exactly where your consent implementation is: which file, which platform section, which plugin. When someone does a theme update six months from now, they'll know to check it. Right now, that knowledge probably lives only in the head of whoever set it up.
Set up automated monitoring
A scanner that checks your site for the presence of a consent mechanism—and alerts you when it disappears—removes the dependency on someone remembering to check. It won't prevent the banner from going missing; it will make sure you find out within 24 hours instead of 47 days.
This matters not just for regulatory exposure. It matters because the fix, once you know about it, is usually a 10-minute task. The expensive part is never knowing.
If It's Already Missing
If you've just realized your cookie banner has been missing since your last theme update:
First, restore the consent mechanism. Re-inject the script, re-enable the plugin, check that it renders for first-time visitors from a clean browser session.
Second, document the gap. Note the dates—when the theme was updated, when you discovered the issue. This matters if you ever need to demonstrate remediation to a regulator.
Third, don't delete the analytics data collected during the gap. Deleting data you collected without proper consent sounds like it would help; in practice, it creates additional problems and doesn't undo the collection event.
Fourth, consider whether you need to notify users. If you collected significant amounts of personal data through analytics or tracking during the gap, some jurisdictions require notification. This is worth a quick call with legal if the window was long.
The situation is recoverable. The common thread in cases that escalate to enforcement is not that a banner went missing, but that the site kept collecting data after discovering it was missing, or couldn't demonstrate when the gap occurred.