The distinction between consent mode vs tag blocking sounds like a technicality and is the single most consequential thing on this subject. One is a message sent to a script that has already loaded, is already executing, and has in most configurations already contacted its server. The other decides whether that script exists on the page at all.
A great many practice websites carry a banner, a policy page and a consent management platform, and transmit to four advertising domains before the visitor has moved the mouse. Nobody involved is being dishonest. The banner is doing what banners of that type do, which is not what the people who installed it believed.
Consent mode vs tag blocking, in one paragraph each
Consent mode is a set of parameters your page declares. Tags that support the standard read those parameters and adjust their behaviour: whether to write a cookie, whether to include an identifier, whether the data may be used for personalisation. The tag is present, loaded and running the entire time. Google documents the behaviour directly, including that a denied signal still permits cookieless pings carrying page context.
Tag blocking means the script never enters the page until a condition is satisfied. The source is held, typically by rewriting it to an inert type or withholding injection, and released only after a visitor agrees. Before that point the vendor's server has received nothing, because nothing contacted it.
The confusion between the two is not anyone's fault. Both are sold under the word consent, both produce a banner, and both are configured by people with the same job title. A product page describing a consent management platform is usually accurate about what it does and is read by a buyer who assumes the stronger of the two meanings, because the stronger meaning is what the words suggest in ordinary English. Nobody misrepresents anything and the buyer still ends up with a different thing than they thought they bought. That failure of communication, rather than any failure of engineering, is why this article exists.
The same ambiguity runs through how the question gets asked internally. When a practice owner asks whether the site blocks tracking until consent, the marketing agency, the web developer and the platform vendor can each answer yes in good faith while meaning three different things: that a preference is recorded, that Google's tags are instructed, and that scripts are withheld. Only the third is what the owner meant. Asking instead what requests leave the page before a visitor clicks anything removes the ambiguity entirely, because it is a question about observable behaviour rather than about intent.
Why consent mode vs tag blocking decides a healthcare outcome
For an ordinary business the left column is often adequate. The regulatory question is usually about cookies and personalisation, and consent mode addresses both.
For a medical practice the question is different in kind. It is not primarily whether a cookie was set. It is whether a vendor received information relating to a person's health, because 45 CFR 164.502 restricts disclosure rather than storage. A request that arrives at an advertising vendor carrying a page path naming a treatment is a transmission, and a subsequent instruction about how to handle it does not retract it.
Whether that transmission actually matters depends on whether what was sent meets the definition of protected health information, which is a narrower question than most practices assume and is worked through element by element in what counts as PHI on a website. The relevant point here is that the definition turns on what arrived, and by the time a consent signal is read, something has already arrived. The vendor's own records will show it, dated and timestamped, whether or not you kept a copy.
There is also a scope limit that catches people out. Consent mode is a standard supported by Google's tags and by vendors who have chosen to implement it. The chat widget, the scheduling embed, the call-tracking script and the heat-mapping tool on a typical practice site are generally not participating in it at all. Blocking operates on the page rather than on a vendor's cooperation, which is why it covers the tools nobody remembered installing as thoroughly as the ones they did. Which tools those are, and where they enter the page, is the subject of analytics on patient-facing pages.
The asymmetry
Consent mode reduces what a vendor may do with what it received. Tag blocking determines whether it received anything. Only the second is capable of producing the sentence a practice actually wants to be able to say, which is that nothing left the page before the visitor agreed.
There is a second reason the distinction matters, and it is about failure modes rather than mechanics. Consent mode is an instruction that has to be correctly wired and stay correctly wired. When it breaks, it breaks silently: the banner still appears, the site still works, the tags simply behave as though consent were granted. Nothing surfaces. Blocking fails in the opposite direction. When it breaks, the tag does not load and someone notices missing data within a reporting cycle.
How to tell which one you have in two minutes
You do not need to read anyone's implementation to answer this. The browser will tell you.
Open your site in a private window. Open the developer tools network panel before the page loads. Filter for the vendor domains you expect: analytics, advertising, chat, scheduling, call tracking. Load a treatment page. Then do nothing at all, and specifically do not touch the banner.
If requests to those domains appear while the banner is still sitting there unanswered, you are running behaviour control, not presence control. If the panel stays quiet until you click accept, tags are being blocked.
Two details worth knowing before you draw conclusions. Use a private window, because a previously stored consent decision will produce a misleadingly clean result on your own machine. And check more than the homepage, since the pages that carry forms are frequently built differently from the rest of the site, which is the subject of where tracking tags actually load.
Why this is not actually a choice between them
The framing invites picking a side, and that is the wrong conclusion. These are complementary layers addressing different questions, and a healthcare configuration generally wants both.
Blocking answers whether a vendor hears from you at all before a visitor agrees. Consent mode answers how Google's tags behave after they load, which still matters, because a visitor who accepts analytics but declines advertising personalisation has expressed a preference that only consent mode can express. Dropping consent mode in favour of blocking loses that granularity and damages measurement for no benefit. The configuration guidance is in Consent Mode v2 for healthcare advertisers.
What blocking adds is a property the other layer cannot provide: a default of nothing. Before any decision has been made, the answer is that no third party has been contacted, and that answer holds regardless of whether anyone remembered to wire up a signal, regardless of which plugin updated last night, and regardless of who has access to the tag manager. It is the only version of this that survives staff turnover.
That last clause is not rhetorical. Most practice websites outlive several of the arrangements that shaped them. The agency that installed the tag manager is replaced, the developer who wrote the theme moves on, the marketing coordinator who knew which container was live leaves, and the site keeps running exactly as configured by people nobody can now ask. A control that depends on institutional memory degrades on that timeline. A control expressed as a default does not, because there is nothing to remember.
The last point is the one that decides it for a practice rather than for a general business. Ask what evidence exists that a given visitor's data did not leave before they consented. Under a behaviour-based control the honest answer is that the tags were configured to behave a certain way and are believed to have done so. Under blocking, the answer is a timestamped record that the gate was closed and when it opened. That is what consent gating produces, and the difference between believing and recording is the whole of the difference between a policy and a paper trail.
Key takeaways
- Consent mode instructs a script that has already loaded and, in most configurations, has already contacted its server. Tag blocking prevents it loading at all.
- For a medical practice the governing question is disclosure, not storage, and a transmission cannot be retracted by a later instruction.
- Behaviour controls fail silently. The banner still appears, the site still works, and the tags behave as though consent were granted.
- Two minutes in a private window with the network panel open tells you which one you have. Do not touch the banner.
- Check pages with forms separately. They are frequently built differently from the homepage.
- Use both. Blocking sets the default to nothing; consent mode carries the granular preference of a visitor who agreed to some things and not others.
Common questions
What is the difference between consent mode and tag blocking?
Consent mode is a signal read by a script that has already loaded and is already running, telling it how to behave. Tag blocking prevents the script from loading at all until a condition is met. The first governs behaviour, the second governs presence, and only the second guarantees that nothing was transmitted.
Does a cookie banner block tracking?
Often not. Many banners record a preference and display a message without preventing anything from loading, because the tags were placed directly in the page template or in a tag manager container the banner does not control. Whether a banner blocks is an implementation property, not something the presence of a banner tells you.
How can I tell which one my site is doing?
Open the site in a private window with the browser network panel open, and do not interact with the banner. If requests to analytics and advertising domains appear before you click anything, tags are loading and the banner is not blocking them, whatever it says.
Sources
- Consent mode overview, Google Tag Platform documentation Documents that tags continue sending cookieless pings when consent is denied
- Set up consent mode on websites, Google Tag Platform documentation Implementation reference for default and update calls
- 45 CFR 164.502, uses and disclosures of protected health information Electronic Code of Federal Regulations
See which of the two your site is actually doing
The free scan loads your pages the way a visitor does and reports every request that leaves before anyone consents to anything.