Setting up Borlabs Cookie in a GDPR-compliant way

Borlabs Cookie (borlabs.io) is a widely used consent plugin for WordPress. It can reliably block scripts until consent is given — but its effectiveness depends entirely on every tracker being covered by the blocker.

Borlabs Cookie works with two mechanisms: the script blocker, which holds back known tracker scripts based on their handle or a URL fragment, and the content blocker, which replaces embedded content (YouTube, Maps, social embeds) with a preview that has a consent button. Both have to be actively maintained — Borlabs does not detect new scripts automatically. Anyone who only configures the banner after installation ends up with a visual banner without a real block.

The most common mistake is an incomplete script blocker. Analytics plugins such as Google Site Kit, marketing plugins with pixel integration or font loaders often write their code directly via wp_head, without a handle that Borlabs can catch. Such cases need either a URL fragment pattern (e.g. “googletagmanager”) in the blocker, or the plugin's own integration has to be disabled in favour of a manual integration through Borlabs.

Since version 3, Borlabs supports Google Consent Mode v2. For Google Ads campaigns in the EEA this is practically mandatory, but it does not replace the script block: Consent Mode only adjusts the behaviour of the Google tags to the consent status, while the tag itself is still loaded. For genuine data minimisation, the Google scripts should additionally be listed in the blocker and only fire after consent.

Is this a risk?

A consent plugin alone does not make a site GDPR-compliant. If an analytics or marketing script is not registered in Borlabs as a “cookie” with a matching blocker pattern, it keeps loading despite a rejection — and then there is no legal basis for that processing under Section 25(1) TDDDG. Frequently overlooked: scripts that themes or other plugins write directly into the head, as well as server-side tags.

What you can do

• Create a Borlabs “cookie” entry with the correct script blocker pattern (handle or URL fragment) for every service in use and assign it to a group (statistics, marketing, etc.).
• Enable the content blocker for all embeds: YouTube, Vimeo, Google Maps, Instagram, Twitter/X — otherwise they load on page view.
• Enable Google Consent Mode v2 in the Borlabs settings if Google Ads/Analytics is used; map the consent signals to each group.
• After every theme or plugin change, test in a private window: after clicking “Reject”, does nothing really load from google-analytics.com, connect.facebook.net and the like?

Häufige Fragen

Does Borlabs Cookie automatically make my WordPress site GDPR-compliant?

No. Borlabs provides the banner and the blocker infrastructure, but every tracker has to be registered manually as a “cookie” with a blocker pattern. Without this maintenance, scripts that are not covered keep loading despite a rejection.

What is the difference between the script blocker and the content blocker?

The script blocker holds back JavaScript from trackers (analytics, pixels). The content blocker replaces embedded content such as YouTube or Maps iframes with a preview that only loads the real content after a click.

Do I need Google Consent Mode v2 in Borlabs?

If you use Google Ads or Google Analytics for campaigns, Consent Mode v2 is effectively required in the EEA. But it does not replace the script block — both should be configured together.

How do I check whether Borlabs is really blocking?

Open the page in a private window, developer tools, “Network” tab, click “Reject” and reload. If requests to known tracking hosts appear, a blocker entry is missing for those services.

How consentglass helps

The free scan checks the delivered HTML and shows which services are embedded, whether a cookie banner is detected and whether privacy-policy and legal-notice links are present — with context for each finding. It is not a substitute for legal advice.