Then you launch and discover that tracking scripts fire before consent is obtained, your cookie banner doesn't block half your integrations, and the compliance assumptions from your old site no longer apply. Welcome to the most common—and expensive—oversight in website redesigns.

Cookie compliance during website redesigns requires treating the migration as a data processing change, not a cosmetic update. New CMSs, tracking scripts, and integrations fundamentally alter cookie behavior, creating compliance risks that teams consistently underestimate until regulators or audits reveal the gaps.

Why Website Redesigns Trigger Cookie Compliance Risk

Website redesigns disrupt the established relationship between your site and its tracking technologies. What worked on your old platform rarely transfers cleanly to new infrastructure.

New Frontend = New Cookie Behavior

Changing your frontend stack changes how and when cookies are set. A WordPress site using PHP-based session management behaves completely differently from a React-based headless site using JavaScript for state management. Cookie timing, storage mechanisms, and script execution order all change — often breaking existing consent logic.

Tracking Scripts Move, Change, or Multiply

Redesigns typically introduce new tracking tools while attempting to preserve historical data from old ones. Marketing adds GA4 alongside legacy Universal Analytics. New heat mapping tools join existing session recording. A/B testing platforms get upgraded. Each addition multiplies the cookies your site sets, but consent mechanisms rarely get updated to reflect this expansion.

CMS Plugins Inject Cookies Automatically

Modern CMS platforms come with native features that automatically set cookies. WordPress plugins like WooCommerce and Jetpack add extensive tracking. Shopify uses a suite of session management cookies. Webflow's new Analyze feature uses local storage for engagement data. Development teams focused on functionality often don't realize these native features create compliance obligations.

Legacy Consent Logic No Longer Applies

Your old site's cookie banner was configured for specific scripts in specific locations. The new site has different scripts loading from different places through different mechanisms. Assuming the old consent configuration still works is the primary cause of post-launch compliance failures.

Key insight: A redesign is not cosmetic, it's a data processing change that requires re-evaluating your entire consent architecture.

The Hidden Compliance Reset Most Teams Miss

Redesigns create a "clean slate" moment that teams mistake for a fresh start when it's actually a compliance reset requiring deliberate reconfiguration.

What Actually Changes

New CMS: Migrating from WordPress to Webflow, Shopify, or headless architectures changes how cookies are set, how scripts load, and where consent logic must be implemented.

New analytics stack: GA4 replacements, updated heat mapping tools, and modern session recording platforms all set cookies differently than their predecessors.

New marketing pixels: Updated versions of Meta Pixel, TikTok Pixel, LinkedIn Insight Tag, and other tracking codes have different technical requirements and cookie behaviors.

New A/B testing tools: Modern optimization platforms like VWO or Optimizely handle consent differently, requiring specific configuration to respect user choices.

What This Impacts

Consent scope: Your old banner's "analytics" category may not cover new tools. Your "marketing" category may need subdivision for different ad platforms.

Cookie classification: New tools may set cookies in different categories than you documented. A tool you thought was "strictly necessary" may actually be "functionality" or "analytics."

Legal basis: The legal justification for processing data through new tools must be documented. Consent obtained for old tools doesn't automatically cover new ones with different purposes.

Proof of consent: If you're switching CMPs or consent mechanisms, existing consent records may not transfer, requiring re-prompting users or implementing consent migration logic.

Cookie Compliance Requirements You Must Re-Evaluate

Multiple privacy regulations apply to most global websites, each with specific technical requirements that redesigns must address.

GDPR & ePrivacy (EU/UK)

Prior consent required: No non-essential cookies can be set before users actively consent. This means your site must technically block scripts until consent is obtained—not just show a banner and hope users click.

Granular choices: Users must be able to accept analytics while rejecting marketing, or approve functional cookies while declining everything else. Bundled "accept all or reject all" choices violate GDPR.

Easy withdrawal: Cookie preference settings must be accessible on every page through prominent links or floating icons, allowing users to change their mind at any time.

Proof of consent: You must maintain timestamped records of who consented to what and when. If your redesign changes CMPs, you need mechanisms to preserve or migrate these records.

CPRA & US State Laws

Opt-out mechanisms: California requires prominent "Do Not Sell or Share My Personal Information" links. Your redesign must implement these links functionally, not just display them.

GPC recognition: Global Privacy Control browser signals must be detected and honored. Your new site needs technical capability to recognize these signals and adjust tracking accordingly.

Notice at collection: Privacy disclosures must be presented before or at the point of collection. If your redesign changes where data is collected, notices must move too.

LGPD (Brazil)

Explicit consent: Brazilian users need clear, specific consent requests explaining exactly what data is collected and why.

Rights mechanisms: Your redesigned site must provide functional ways for users to access, correct, or delete their data.

Purpose Limitation Across All Frameworks

Every framework requires limiting data processing to specified purposes. Your redesign's new tools must align with documented purposes. Using data collected for "site functionality" to power new "marketing analytics" violates purpose limitation unless you obtain additional consent.

CMS & Platform Considerations

Different CMS platforms handle cookies and consent differently, creating platform-specific compliance requirements.

WordPress

WordPress sites depend heavily on plugins, each potentially injecting its own cookies and tracking. Common issues:

Plugin bloat: Each plugin added—for SEO, performance, contact forms, commerce—may set its own cookies. Teams assume a global consent banner covers all plugins, but unless plugins are explicitly integrated with your CMP or routed through Google Tag Manager, they fire immediately on page load.

Jetpack and WooCommerce: These popular plugins add extensive tracking (tk_*r cookies, WooCommerce session cookies, analytics) that must be governed by consent mechanisms.

Theme-based tracking: Many premium WordPress themes include built-in analytics or social sharing features that set cookies independently of your consent framework.

Shopify

Shopify provides a managed privacy approach through its Customer Privacy API:

Centralized control: The Customer Privacy API manages consent decisions across all Shopify-managed surfaces including pixels, audiences, and checkout.

Strict limitations: Developers must never read or modify Shopify cookies directly to avoid processing failures during platform updates.

Headless complexity: Transitioning from traditional Shopify themes to headless implementations (Hydrogen, custom React) requires re-implementing the Customer Privacy API in your custom frontend.

Built-in localization: Shopify's cookie banner localizes through the "Translate & Adapt" app, but localization is limited to text — underlying legal logic for different regions requires enabling "Automated Settings."

Webflow

Webflow positions itself as increasingly privacy-conscious:

Cookie-free analytics: Webflow Analyze uses local storage rather than cookies for engagement tracking, reducing immediate privacy risk for native analytics.

Custom code requirements: Implementing professional CMPs requires Webflow's paid "Site Plan" to access custom code injection features.

Third-party integration: Despite cookie-free native tools, any Webflow site using Meta Pixel, GA4, or other third-party tools still requires comprehensive consent management.

Headless CMS

Headless architectures (Next.js, Astro, custom React/Vue) offer maximum control but maximum responsibility:

No native tracking: All cookie behavior is defined by your custom frontend and API calls—nothing happens automatically.

Custom data layer: You must build consent logic, data layers, and CMP integration manually rather than relying on platform defaults.

Complete flexibility: While complex, this approach allows implementing exactly the consent architecture your compliance needs require without platform limitations.

Why CMS-Agnostic CMPs Matter

CMS-agnostic Consent Management Platforms integrate with any CMS through JavaScript or API, preventing vendor lock-in and enabling consistent consent governance across platform migrations. When redesigning involves changing CMSs, CMS-agnostic CMPs ensure consent logic persists regardless of underlying platform.

Integrations: Where Compliance Quietly Breaks

Redesigns typically add new integrations without updating consent governance to account for them.

Analytics

GA4 and alternatives: Modern analytics platforms set multiple cookies for session management, user identification, and conversion tracking. Google Consent Mode v2 allows adjusting behavior based on consent state, but requires specific implementation.

Heat mapping and session recording: Tools like Hotjar, Clarity, or FullStory record user sessions and set cookies for replay functionality. These require explicit consent under GDPR's requirement for informed permission.

Marketing Pixels

Meta Pixel, TikTok, LinkedIn: Each platform's tracking pixel sets cookies for conversion tracking and audience building. Your redesign must block these pixels until marketing consent is obtained.

Retargeting platforms: AdRoll, Criteo, and other retargeting vendors drop cookies to track users across sites. These absolutely require prior consent in GDPR jurisdictions.

CRMs and Customer Data

HubSpot, Salesforce Marketing Cloud: CRM integrations often include tracking scripts that identify returning visitors and associate them with CRM records. This processing requires clear disclosure and consent.

Chat Tools

Intercom, Drift, Zendesk: Live chat widgets typically set cookies for conversation continuity and user identification. These must load only after appropriate consent is obtained.

A/B Testing Platforms

VWO, Optimizely, Google Optimize: Testing tools must be configured to handle consent properly. VWO offers "Completely Block," "Partially Block," or "Do Not Block" modes—choosing wrong creates compliance violations.

Partially Block mode: Shows variations using session storage without sending tracking data to servers until consent is granted—balancing UX and compliance.

Why "We'll Add It Later" Breaks Compliance

Each integration added post-launch without updating consent mechanisms creates violations. The "soft launch then add tracking" approach seems safe but actually creates a window where unconsented tracking occurs, leaving evidence that audits and regulators will find.

Cookie Banner vs Consent Governance

A critical distinction that redesign teams consistently miss: cookie banners are UI elements; consent governance is infrastructure.

Cookie Banner = UI

The visible banner asking for consent is just the interface. By itself, it does nothing to stop cookies from being set.

Consent Governance = Infrastructure

True consent governance includes:

Scanning: Automatically detecting what cookies your site sets, including those from third-party scripts, plugins, and integrations.

Classification: Categorizing cookies as strictly necessary, functional, analytics, marketing, or other categories based on actual purpose.

Blocking logic: Technically preventing non-essential scripts from executing until consent is obtained—not just showing a banner and hoping.

Jurisdiction handling: Showing different consent experiences based on user location (opt-in for EU, opt-out for California, etc.).

Recordkeeping: Maintaining timestamped logs of who consented to what categories and when, creating audit trails for regulatory inquiries.

Preference management: Allowing users to change their minds through accessible settings on every page.

Most "cookie banner" solutions are just UI without the governance infrastructure behind them.

Agencies vs In-House Teams: Who Owns Compliance?

Redesign projects typically involve agencies, internal teams, and legal—but responsibility for compliance often falls through gaps between them.

Common Failure Modes

Agency assumes legal handles it: Development agencies focus on building functionality and assume client's legal team manages compliance requirements.

Legal assumes agency handles it: Legal teams review policies and notices but assume technical implementation of consent is the agency's responsibility.

Marketing just wants launch: Marketing stakeholders prioritize launch dates and features over compliance requirements they don't fully understand.

Checklist: Cookie Compliance During a Website Redesign

✔ Cookie audit before redesign: Document every cookie currently set, its purpose, category, and source. This baseline shows what must be replicated or replaced.

✔ Compliance requirements mapped: Identify which privacy regulations apply to your audience (GDPR, CPRA, LGPD, etc.) and document specific technical requirements.

✔ CMS-level consent integration: Choose and configure CMP with native support for your target CMS or implement CMS-agnostic solution.

✔ Script blocking pre-consent: Verify that non-essential scripts actually don't fire until consent is obtained. Test in incognito/private browsing to confirm.

✔ Jurisdiction logic validated: Test that users in different locations see appropriate consent experiences (opt-in vs opt-out, different legal text).

✔ Consent migration planned: If changing CMPs, implement logic to preserve existing consent or plan for re-prompting users appropriately.

✔ Integration inventory complete: List every third-party integration (analytics, marketing, chat, testing) and verify each is governed by consent.

✔ Tag Manager configured: If using GTM or similar, ensure tags fire based on consent state through proper triggering and consent mode configuration.

✔ Mobile and accessibility tested: Verify consent interface works on mobile devices and meets WCAG accessibility standards.

✔ Staging environment parity: Ensure staging site implements same consent logic as production to catch issues before launch.

✔ Post-launch rescan: Within 1 week of launch, run fresh cookie scan to catch any scripts that slipped through during deployment.

✔ Documentation updated: Update privacy policies, cookie policies, consent records, and internal documentation to reflect new site architecture.

✔ Preference center accessible: Verify cookie preference settings are accessible from every page through footer links or floating icons.

✔ Withdrawal mechanisms tested: Confirm users can easily revoke consent and that their choice is respected across sessions.

✔ Legal sign-off obtained: Get explicit confirmation from legal team that technical implementation meets compliance requirements.

Choosing the Right Cookie Compliance Partner During a Redesign

Redesigns are optimal moments to evaluate or switch Consent Management Platforms.

CMS-Agnostic Integration

Choose solutions that work regardless of underlying CMS, enabling consistent governance across platform migrations and future changes.

Multi-Law Support

Look for platforms that handle GDPR, CPRA, LGPD, and other frameworks simultaneously, adjusting consent experiences based on user location without manual configuration.

Easy Deployment Across Environments

Ensure the CMP can deploy to staging, development, and production environments easily, with separate configurations for testing without affecting live consent records.

Governance Features Beyond UI

Prioritize platforms offering automatic scanning, script blocking, consent record-keeping, and audit trails—not just attractive banner designs.

Performance Impact

Evaluate CMP script size and loading behavior. Heavy CMPs that block page rendering or degrade Core Web Vitals can hurt SEO and user experience.

Final Takeaway: Redesigns Are Compliance Opportunities

Website redesigns force re-evaluating technical infrastructure that's accumulated years of compliance debt. Rather than viewing compliance as a constraint slowing launch, treat redesigns as opportunities to:

Fix technical debt: Replace hard-coded tracking with properly governed tag management. Eliminate plugin bloat that created ungovernable cookie sprawl.

Future-proof compliance: Implement consent governance infrastructure that scales as you add tools, rather than patching banner configurations each time.

Build user trust: Modern users increasingly care about privacy. Demonstrating that your redesigned site respects their choices builds competitive advantage.

The cost of getting cookie compliance wrong during redesigns—measured in regulatory fines, legal costs, and reputation damage—far exceeds the incremental effort of implementing proper governance from the start. Organizations that treat consent as core infrastructure rather than last-minute compliance checkbox build more trustworthy digital experiences that regulatory scrutiny can't compromise.