Somebody lands on your site, the consent box appears, and they hit reject. What happens to the ad slot?
For a lot of independent publishers the honest answer is nothing at all. The slot stays empty, that reader is worth zero, and nobody ever looks at how often it happens. It is worth looking, because the empty slot is usually a configuration choice rather than a legal requirement.
First, what actually happened to the cookie deadline
Some context, because a fair number of publishers have quietly concluded that this whole subject went away.
Google spent years promising to remove third party cookies from Chrome, then stopped promising it. The removal plan was abandoned in July 2024. The replacement user choice prompt was scrapped in April 2025. On 17 October 2025 Google retired the main Privacy Sandbox APIs, Topics, Protected Audience and Attribution Reporting among them, after adoption never arrived. The UK competition regulator released Google from its Privacy Sandbox commitments the same day, saying it had reasonable grounds for believing that its competition concerns no longer arise.
So third party cookies are staying in Chrome, and the thing that was going to replace them is the thing that died.
None of that changed what you owe a reader
Here is where the misreading creeps in. If cookies are safe and the Sandbox is gone, the pressure is off, surely.
Consent was never owed to Chrome. The rules about storing things on somebody's device and profiling them sit in GDPR, UK GDPR and the ePrivacy rules, and not one of them was amended on any date in that timeline. A browser vendor changing its product plans has no bearing on what a publisher in the EEA or the UK is required to do.
If anything the retreat made the obligation more visible, because the industry can no longer point at a future technical fix and say the problem is being handled.
The part that is actually worth money
Now the useful bit. A consent tool asks about a long list of purposes, but only a handful decide whether an ad appears at all, and they do not all work the same way.
Purpose 1 is the make or break one. Store and or access information on a device, consent only. Without it, partner code that sets cookies has no business running, and a network worth dealing with will refuse rather than run it anyway.
Purposes 3 and 4 are about building and using a profile. Losing them costs you rate. A non personalised impression pays less than a personalised one, sometimes a lot less. It does not pay nothing.
Purpose 2 is the one people forget. Use limited data to select advertising. Unlike the others it can rest on consent or legitimate interest, which is precisely the mechanism by which somebody who rejected everything can still be shown a contextual ad chosen from the page rather than from them.
Whether that is available to you in practice depends on how your consent tool is configured and what each partner has declared, and it is a question worth putting to both of them rather than assuming either way. The point is that a blank slot on every refusal is not the only possible outcome, and if that is what your setup does, somebody chose it.
A banner is not a control
The other half of this is less comfortable. Plenty of sites carry a consent box that records an answer and then loads exactly as it would have anyway.
That is worse than having no banner at all. A banner that does not gate anything leaves you with a record of having asked the question and ignored the answer, which is a good deal easier to hold against you than never having asked.
Worth testing on your own site: open it in a private window from an EEA or UK connection, reject everything, then watch the network tab. If partner domains are still being contacted, your banner is decoration.
Four things to check this week
- Reject on your own site and watch what loads. Not what the consent dashboard claims. What the browser actually requests.
- Find out what share of your EEA and UK readers refuse. Most consent tools report this. If a fifth of your European traffic is rejecting and earning nothing, that is the number to work on.
- Ask your partners what they serve on a Purpose 2 only signal. Some will serve contextually. Some will serve nothing. Knowing which is which changes who you route that traffic to.
- Check the refusal actually persists. A tool that forgets the answer and asks again next page view is both irritating and not much of a record.
None of this is legal advice, and a publisher with real European volume should be taking proper advice rather than reading a network's blog. What it is, is a revenue question that usually gets filed under compliance and then never opened.
How we handle it
We decide server side, before a partner is chosen, from the visitor's country, and we only relax that decision for a signal we can actually check. The list covers the EEA plus the UK. Purpose 1 is what governs whether partner code is handed over at all. Purposes 3 and 4 are passed through to the partner rather than used to refuse, so a reader who declined personalisation can still be served something rather than nothing.
We do it on our side rather than trusting the page because query strings can say anything, and because the obligation does not stop at the publisher. We choose the partner and we hand over the request, so refusing when consent is absent is our job too, not something to assume somebody upstream took care of.
If you run an independent site and want to know what your inventory is worth with consent handled properly, you can apply as a publisher or read how we work with publishers first. Our earlier piece on the ads.txt mistakes that cost publishers money covers the other half of the diligence a buyer will do on you.
