Global Privacy Control on WordPress: Most Sites Claim to Honour It and Never Test It

Global Privacy Control is a simple idea with legal teeth. The browser sends a signal, Sec-GPC with a value of 1, the site is expected to treat it as an opt out of sale and sharing of personal data under laws including California's, and the visitor never has to find an opt out link or fill in a form. Simple at the level of the specification. Messy at the level of a real WordPress stack.

A WordPress site has a theme, a consent plugin, a tag setup, caching, and possibly a separate ecommerce layer, any of which can receive, ignore or overwrite the signal's effect. Claiming to honour GPC because a plugin's feature list says so is not honouring GPC. Only the behaviour is.

What honouring actually requires

Honouring the signal means more than recording it. Sale and sharing for targeted advertising must stop for that browser, the opt out state must be respected across the session and on return where the signal persists, and the treatment should not require the visitor to also use the site's opt out form. Forcing a GPC user through a second process defeats the mechanism the law recognises.

The signal is browser scoped, not account scoped, and sites are not generally required to apply it to a logged in identity across devices. That boundary should be understood and, where you go beyond it voluntarily, documented. Overclaiming in the privacy policy, saying signals apply account wide when they apply per browser, creates the same verification problem as under honouring.

Where WordPress stacks drop the signal

The common failure points are predictable. A consent plugin that only applies GPC to its own banner behaviour while tags fire through a separate manager that never hears about it. A caching layer serving a page and script state generated for a non GPC visitor. A consent tool whose GPC handling covers cookies it controls and nothing server side, so conversion forwarding continues for a visitor who opted out in the only way the law requires a site to notice.

Each failure has the same shape: one component honoured the signal and the rest of the stack carried on as usual. That is why the test has to follow the data, advertising requests, analytics state, server side events, and not stop at the banner's confirmation message.

The test, in full, in a clean browser

Use a browser or profile with GPC enabled, or a tool that sets the Sec-GPC header, in a fresh profile with no prior consent state. Load the site and inspect: the opt out status should register without any form interaction, advertising and sharing related storage and requests should be suppressed or treated as opted out, and the privacy dashboard or preference centre, if any, should reflect the state accurately.

Return in the same profile, trigger the flows that normally share data, a purchase event, a newsletter signup, a video view, and verify the suppression holds in each. Then check what your records say: there should be an opt out record attributable to the signal, dated, that a regulator or the visitor themselves could be shown. If the behaviour is right and the record is absent, fix the record. Evidence is part of honouring.

Write the policy from the test, not before it

Privacy policy language about GPC should describe the tested behaviour: which laws and rights the signal is treated as exercising, what processing stops, and the browser scope of the opt out. Write it after the test passes, and retest after stack changes, plugin updates, a new tag manager container, a caching change, that alter how signals flow.

Regulators in several states have made clear they check these claims, sometimes with the same clean browser test described here. A site that tests itself first will meet that check with a record instead of a scramble, and that difference, more than any wording in the policy, is the compliance position.

Related reading

These earlier guides go deeper on connected questions: Headless WordPress Consent: The Banner Works, the API Ignores It Headless builds separate the banner from the backend. Consent choices made in the frontend may never reach the APIs feeding apps and partners., When Consent Mode Eats Your Traffic: Reading the Gap Between Clicks and Modeled Data Consent mode gaps get blamed on users. Often the signals are late, wrong, or never sent. How to tell refusal from breakage., and Global Privacy Control on a Small Site: Honouring the Signal Without a Legal Department.

Frequently asked questions

What is Global Privacy Control?

It is a browser or extension setting that sends a signal, Sec-GPC: 1, expressing the user's preference to opt out of the sale and sharing of their personal data. Several US state privacy laws, including California's, require businesses to treat it as a valid opt out request for that browser.

Does a WordPress plugin guarantee GPC is honoured?

No. A plugin may handle the signal only within its own consent behaviour, while tags, server side events, caching or ecommerce layers continue sharing. Honouring GPC is a property of the whole stack's behaviour, and it needs an end to end test with the signal actually sent.

How do I test whether my site honours GPC?

Use a fresh browser profile with GPC enabled, load the site, and verify that opt out status registers without form interaction, that sale and sharing related requests and storage stop, that suppression holds across key flows and return visits, and that an opt out record is created that you can produce.

Does GPC apply to logged in accounts across devices?

Generally the signal is browser scoped: it expresses the preference for that browser, and laws typically do not require it to be linked to an account identity across devices unless the user is known in that browser. Sites should document the scope they actually implement and avoid claiming broader coverage in their policy than they deliver.