The US privacy landscape is different from Europe's, and the architecture that satisfies it is different too. Where GDPR demands explicit opt-in before tracking, US state laws (CPRA, VCDPA, CPA, and the rest of the patchwork) generally permit tracking by default but require a working "Do Not Sell or Share My Personal Information" mechanism and require sites to honor the Global Privacy Control browser signal. For WordPress sites that depend on third-party marketing pixels and intent-data tools, satisfying both requires more than a banner: it requires the technical plumbing to genuinely block scripts when the user opts out.
WordPress sites in markets exposed to GDPR have spent the last several years figuring out how to remove third-party trackers entirely, because the EU model defaults to “no tracking without consent.” The US model is genuinely different. Most US state privacy laws (CPRA in California, VCDPA in Virginia, CPA in Colorado, and a growing list of others) default to “tracking is allowed unless the user opts out.” That makes the compliance architecture different in two important ways:
- A “Do Not Sell or Share My Personal Information” mechanism must exist on the site, must be persistent (typically a footer link), and must actually work.
- The site must detect and honor Global Privacy Control (GPC), a browser-level signal that says “this user has opted out by default” and must do so without requiring an explicit click.
The “must actually work” and “must do so without an explicit click” parts are where most WordPress implementations fail. A banner alone is decorative; it satisfies a checkbox but not a regulator. Real compliance requires the underlying tracking scripts to genuinely stop firing when the opt-out is in effect.
Why this is harder than it looks.
The typical WordPress site loads third-party tracking through Google Tag Manager (GTM). The site dropped one GTM container snippet in the header; everything else (Facebook Pixel, LinkedIn Insight Tag, Google Ads conversion tags, intent-data tools like Visual Visitor or 6sense, session-replay platforms like Hotjar) gets added inside GTM by the marketing team. The site code has no idea what tags are in there.
A naive “Do Not Sell” implementation that just adds a footer link and updates a setting in a CMP plugin does nothing to those GTM-loaded tags. The marketing pixels keep firing. The intent-data tool keeps resolving the visitor’s IP to a company. The session replay keeps recording. The user opted out; the trackers didn’t notice. That’s the kind of gap that turns into an enforcement action under the laws that have teeth.
The architecture that actually works has to bridge two parts of the stack that don’t naturally talk to each other: the consent layer (which knows the user’s preference) and GTM (which controls the firing of the tags). The bridge is the GTM Data Layer.
The architecture in one diagram.
The working pattern, conceptually:
- The user visits the site.
- A Consent Management Platform (CMP) initializes and checks two things: any stored preference from a prior visit, and whether the browser is broadcasting a GPC signal.
- The CMP writes the user’s effective consent state into the GTM Data Layer.
- GTM tags are configured with trigger conditions that check the Data Layer. Tags only fire if the consent state permits them.
- If the user later clicks the “Do Not Sell” link, the CMP updates the Data Layer in real time. GTM tags that were already loaded stop firing for subsequent events; tags that hadn’t fired yet never do.
Four moving parts here, none of them WordPress-specific, all required for the system to actually work:
- A CMP that knows how to read GPC signals (the major ones — OneTrust, Cookiebot, Termly, Iubenda — all do, but not all do it well by default).
- A GTM Data Layer schema that the CMP writes to and the tags read from.
- Tag-by-tag trigger configuration in GTM so the right tags respect the right consent categories.
- A footer link or button that surfaces the user’s current state and lets them change it.
Skipping any one of these creates a gap that regulators (or a plaintiff’s lawyer) will eventually find.
What Global Privacy Control actually is.
GPC is a browser-level signal that says “this user has, in general, opted out of selling or sharing their personal information.” Several US state laws (California, Colorado, Connecticut) explicitly require regulated businesses to honor it. The user enables it once in their browser (Firefox, Brave, and Privacy Badger all support it; Chrome via extension). After that, every site they visit receives a Sec-GPC: 1 request header.
What that means in practice: the site can’t wait for the user to click an opt-out link if the browser already said “opt me out.” The CMP has to detect the GPC header on first request and apply the opt-out state automatically. The footer “Do Not Sell” link then becomes a way for users without GPC to opt out individually. Both mechanisms work in parallel.
The detection is handled client-side by the CMP reading the browser’s navigator.globalPrivacyControl property (avoiding server-side PHP checks that break under page caching). Applying that detected state to client-side trackers via GTM is the harder part, and it’s the part most implementations get wrong.
The Phase-1-through-Phase-4 build.
The realistic project arc:
- CMP deployment and GPC configuration. Pick a CMP that fits the site’s needs and budget; configure it to detect GPC and to surface the Do Not Sell mechanism per state requirements.
- GTM Data Layer integration. Modify GTM trigger rules so every tag’s firing is gated on the Data Layer consent variables the CMP writes. Tags shift from “fire on All Pages” to “fire when consent state permits.”
- QA and interception testing. Use the browser’s Network and Application tabs to verify three states: default tracking (consent given), manual opt-out via the footer link, automatic opt-out via GPC. The verification proves the scripts actually stop, not just that the banner state changed.
- Handoff documentation. A short brief for the marketing team explaining how to add new tags to GTM going forward without breaking the consent architecture. Every new pixel needs to be mapped to the right Data Layer trigger; otherwise it bypasses the system.
The optional ongoing add-on most clients accept: an annual audit. GTM is dynamic; marketing teams add tags, swap vendors, integrate new tools. Without periodic review, the consent architecture drifts as new untracked tags accumulate.
The legal context, briefly.
The laws that drive this work, as of mid-2026:
- CPRA (California). Explicit GPC requirement. Active enforcement by the CPPA.
- CPA (Colorado). GPC required as of July 2024. Enforcement by the AG.
- CTDPA (Connecticut). GPC required.
- VCDPA (Virginia), UCPA (Utah), and several others. Opt-out mechanism required; GPC handling varies.
- New 2025-2026 state laws (Tennessee, Florida, Texas TDPSA, others) extend the same general pattern across more of the US population.
The patchwork is real and growing. Architecting the site to a single high-water-mark standard (CPRA’s, typically) covers most of the country without building per-state logic.
When this matters and when it doesn’t.
This entire architecture is necessary when:
- The site uses third-party marketing pixels, intent-data tools, session-replay, or any other “selling or sharing” data flow under the relevant state laws.
- The site serves visitors from California, Colorado, Connecticut, Texas, Virginia, or any of the growing list of states with GPC requirements.
- The site’s compliance posture matters (the business is named in the privacy policy, the brand is recognizable, the regulator could plausibly find them).
It’s overkill when:
- The site has zero third-party trackers. That’s the architecture in the consent banner WordPress sites don’t actually need — no tracking, no opt-out problem to solve.
- The site is genuinely small and unlikely to attract regulatory attention.
For everyone in between — sites that need their marketing pixels but operate in states with opt-out laws — the CMP + Data Layer + GTM integration is the only architecture that defensibly satisfies the law. The footer link alone is decoration; the architecture is what holds up.
See privacy built into the platform for what this looks like as part of a broader practice.