A cookie banner that visitors can decline means nothing if the scripts it’s supposed to block keep running in the background regardless — which happens more often than site owners realise, since most tracking scripts are simply added to a page with no awareness of consent status at all unless specifically configured to check for it.
Consent-gated script blocking configuration
Scripts still running after a decline — found and genuinely gated behind real consent.
- Full backup taken before we start
- If we can’t fix it, you get your money back
- We never ask for your own password
What we need from you
- Access to your existing consent banner or plugin
- A complete list of scripts and tags that should be gated behind consent
- Confirmation of any scripts that should run regardless (genuinely essential, non-tracking functionality)
This or something else?
| You have a consent banner but scripts still run before or after a decline | This fix covers it |
| You don’t have a consent banner set up at all yet | Cookie consent banner implementation, the prerequisite step |
| You’re not sure which scripts even need gating in the first place | Cookie audit & categorisation report, worth doing first |
| Scripts are gated through Google Tag Manager specifically and something’s misconfigured there | This fix covers Tag Manager-based gating specifically, among other methods |
What we do
- Audit which scripts currently run regardless of consent status
- Categorise each script as essential or requiring consent
- Configure technical gating so non-essential scripts wait for actual consent
- Test that declining consent genuinely prevents the relevant scripts from loading
- Test that accepting consent correctly allows them to load
- Verify no essential site functionality is accidentally blocked
What is included
- Technical consent gating configured for all specified scripts
- Verified blocking on decline and correct loading on accept
- A check that essential functionality remains unaffected
- A written note on what’s gated and how
Not included
- Implementing the consent banner itself, if not already in place — a separate, related fix
- A full cookie audit identifying every script in the first place, a separate fix if needed
- Ongoing configuration as you add new scripts or tags later
- Legal advice on which specific scripts require gating under your applicable regulations
Questions about this fix
How would I know if my scripts are actually being blocked correctly?
We test both paths directly — declining and confirming the scripts genuinely don't load, then accepting and confirming they do — rather than relying on the banner's own claim that it's working.
Is this the same as just deleting the tracking code from my site?
No — this keeps your tracking and analytics functional for visitors who consent, while genuinely respecting the choice of those who don't, rather than removing the functionality entirely.
What counts as an 'essential' script that doesn't need gating?
Generally anything required for the site to function at a basic level — session handling, shopping cart functionality — as distinct from analytics, advertising, or other tracking-purpose scripts.
Will this slow down my site for visitors who do consent?
Not meaningfully — the gating logic itself is lightweight; any script that was already running still runs the same way once consent is given, just conditionally rather than unconditionally.
Do I need to redo this every time I add a new tracking pixel?
Yes, in principle — a newly added script needs to be deliberately included in the gating configuration, or it will run unconditionally by default, undermining the setup already in place.
Related fixes
If this is the second time this year
A bad update breaking the site is a symptom of updates not being tested first. Care plans run every update on a staging clone before it reaches your live site, which is the actual fix for this happening again.
Your access, your rules
Create a separate admin account for us and delete it when we are done. For anything else, we get in touch and agree a method — never a form field on this site, never by reply to an email.
We back up first, always
Before anything is touched we take a full backup and keep it for 30 days. If a fix goes wrong, we put the site back exactly as it was.
If it is not what you bought
If the problem turns out smaller than what you ordered, we refund the difference. If it is bigger, we stop and send a quote before doing any extra work.
If we cannot fix it
You get back what we received. Diagnosis is on us — you only pay when the problem is actually solved. The payment processor takes its fee before the money reaches us, so we never hold it and it is not ours to return. That is true here as everywhere else.
If it comes back
Reply within seven days of delivery and we put it back on the bench at no cost. The fix is not finished until it holds.
What we are responsible for
If something goes wrong with a fix, our responsibility is limited to what you paid for it. We take a full backup first so mistakes can be undone, and we tell you before doing anything outside what you bought.