Theme changes are the quiet consent killer on WordPress. Header scripts move, plugin hooks change, and the banner that worked in January is firing after the analytics by March. A post-theme consent checklist prevents it.
Nobody changes a theme to break privacy compliance. They change it for a redesign, a performance fix, a rebrand. The consent setup is collateral: it lived partly in the old theme's files, partly in hooks the new theme orders differently, and the breakage announces itself nowhere. The settings page still shows everything switched on.
Where consent hides inside a theme
WordPress consent setups sprawl. The plugin holds the banner and the categories, but the actual scripts often live elsewhere: analytics pasted into the theme's header template by a developer in 2022, a marketing pixel added through the customizer, a tag manager snippet in a child theme's functions file. A theme switch takes every one of those placements with it, or orphans them.
The dangerous outcomes are asymmetric. Scripts vanishing is a marketing problem someone notices. Scripts surviving but loading earlier, because the new theme prints the head differently or a caching plugin reorders, is a compliance problem nobody notices. That asymmetry is why theme changes need a consent check and not just a visual one.
The four-point post-theme check
First, script order: in a clean browser, confirm the consent mechanism initializes before any non-essential script fires, exactly as you would on a new install. Second, inventory: list every third-party script on the new theme and match it against your consent categories; anything unmatched is either removed or categorized.
Third, display: banners inherit theme CSS more often than owners realize, and a redesign can leave the reject button low-contrast, off-screen on mobile, or styled as plain text. Fourth, continuity: confirm that consent stored before the change still resolves to the same categories, especially if the redesign came with a plugin update that renamed any of them.
Child themes and the customizer trap
Sites that put snippets in a child theme lose them when the redesign activates a fresh theme without the child. Sites that put them in the customizer's additional CSS or a header-footer plugin keep them, sometimes too well: the snippet survives into a setup whose consent plugin changed, and now an unmanaged tag fires outside the banner's control entirely.
The durable fix is consolidation. Every third-party script should be loaded through the consent tool or a tag manager the consent tool gates, never through theme files. A redesign then becomes a visual event for the consent setup, which is what it should have been all along.
Make it a checklist item, not a memory
Add the four-point check to the same list as broken layouts and missing fonts after any theme activation or major update. It takes fifteen minutes: clean profile, network order, script inventory, banner on mobile, one stored-choice revisit. Fifteen minutes against the alternative, which is discovering the gap from a visitor's complaint with your own network log as the evidence.
Note the check in your consent records with the date and the theme version. If the question ever comes, 'we re-verified consent after the redesign on this date, here is what we checked' is a complete answer. Silence in the records reads as what it usually is.
Related reading
These earlier guides go deeper on connected questions: WordPress Cookie Banner Accessibility: Keyboard, Focus, and Contrast Checks A consent banner that keyboard users cannot reach or read fails twice. This guide covers the accessibility checks every WordPress banner should pass, from focus order to contrast., WordPress Consent API Basics: How Plugins Agree on Consent State The WordPress Consent API lets plugins share one consent state instead of each guessing. This guide explains the categories, the functions, and why it reduces conflicting banners., and Consent on WordPress Multisite: Why Each Site Needs Its Own Settings Multisite networks tempt owners to copy one consent setup everywhere. Different audiences, tools, and legal duties per site mean a single copied banner is usually wrong somewhere..
Frequently asked questions
Can changing a WordPress theme break cookie consent?
Yes, indirectly. Consent settings live in the plugin, but scripts are often placed in theme files or load in an order the theme controls. A new theme can remove placements, reorder loading, or restyle the banner, each breaking a different part of the setup.
What should I check first after a theme change?
Script order in a clean browser profile: does the consent tool initialize before analytics and pixels fire? Then inventory every third-party script against your consent categories, and check the banner's appearance and buttons on mobile.
Why do my consent settings look fine but tracking starts immediately?
Because settings screens show configuration, not load order. A caching plugin, a new theme's head structure, or a surviving hard-coded snippet can all fire tags before the consent tool runs while every setting appears correct.
Where should tracking scripts live to survive redesigns?
In the consent platform or a tag manager it controls. Scripts placed there are independent of theme files, so a redesign changes how the site looks without changing what loads, in what order, under whose permission.