Borlabs Cookie (WordPress): Reject Path Leaks Trackers
Borlabs Cookie is widely used in the DACH WordPress market. If the dsgvochecker.de reject-path test reports trackers despite the banner being present, the cause is almost always one of these four — all WordPress-specific, all solvable in the Borlabs backend.
TL;DR: The four most common reject-path leaks on Borlabs Cookie: (1) tracker script not registered as a Borlabs cookie entry, (2) cache serves an un-blocked version, (3) iFrame embeds bypass the Content Blocker, (4) theme scripts outside wp_enqueue_script.
Cause 1: Is the tracker registered as a Borlabs cookie entry?
Borlabs only blocks what is configured under Cookies in the backend. Plugin scripts without an entry run unblocked.
Borlabs only blocks trackers that are configured as a dedicated entry under Cookies in the backend. If a plugin (or the theme's functions.php) injects tracker scripts directly via wp_enqueue_script or as inline <script>, Borlabs does not see them and cannot gate them on consent. They run before and after reject.
Fix: In the Borlabs backend under Cookies, audit every active tracker. For each external service (Google Analytics, Meta Pixel, Hotjar, etc.) there must be a cookie entry with Opt-in code (executed on consent) and Fallback code (often empty). If a plugin enqueues a tracker, additionally add the plugin's script handle under Settings → JavaScript as a script to block.
Source: Borlabs KB — Setting up Borlabs Cookie
Cause 2: Does a cache plugin serve an un-blocked version?
Cache plugins store output before Borlabs filters. Clear the cache fully after every change.
Borlabs filters WordPress output at runtime. If a caching plugin (WP Rocket, W3 Total Cache, LiteSpeed Cache) cached a page before the Borlabs filter took effect, the cache serves a version with un-blocked tracker scripts — and the banner is later injected via JavaScript, but the scripts have long since loaded.
Fix: Clear the entire cache in the caching plugin after every Borlabs config change. Borlabs has hook integrations for WP Rocket, LiteSpeed, and Cache Enabler — in the Borlabs backend under Settings → General → Compatibility, enable the matching option. Also verify that the caching plugin doesn't set a Browser-Cache header that's too long.
Source: Borlabs KB — Common Issues
Cause 3: Do iFrame embeds bypass the Content Blocker?
YouTube/Vimeo/Maps need the Borlabs wrapper. Directly inserted iFrames load without consent.
Borlabs has a separate Content Blocker for iFrames (YouTube, Vimeo, Google Maps, Facebook embeds). If a plugin or Gutenberg block inserts iFrames directly without the Borlabs Content-Blocker wrapper, the iFrame loads — and with it all external cookies of the embedded service — without consent.
Fix: In the Borlabs backend under Content Blockers, audit or create a Content-Blocker entry for every embedded service. In the editor, embed iFrames either via the Borlabs shortcode [borlabs-cookie type="content-blocker" id="youtube"]...[/borlabs-cookie] or via the Borlabs block. Directly inserted <iframe> tags without a wrapper are the main problem.
Source: Borlabs KB — Setting up Borlabs Cookie (Content Blocker)
Cause 4: Does the theme load trackers outside wp_enqueue_script?
Page builders often inject trackers via theme options. Borlabs cannot see such scripts.
Some themes (e.g. full page builders like Elementor Pro, Avada, Divi) ship their own performance or marketing scripts that are wired in directly via theme options or custom-code fields — outside the classic wp_enqueue_script path. Borlabs does not see them because they are not registered as WordPress scripts.
Fix: Search the theme/page-builder backend for Custom JavaScript, Tracking Code, Header/Footer Scripts options. Remove tracker code from these theme fields and instead create a Borlabs cookie entry with opt-in code. If the theme does not allow this: create a JavaScript Blocker entry in Borlabs targeting the specific theme script handle.
Source: Borlabs KB — JavaScript Blocker
How do I verify the fix worked?
Clear all caches, then re-scan. If the test reports "Reject path clean", you are GDPR-compliant.
After every change in the Borlabs backend: fully clear the caching plugin cache (this is the single most-forgotten step on WordPress + Borlabs), clear the browser cache, and start another reject-path scan at dsgvochecker.de.
As of: 2026-04-29 · Sources from borlabs.io are linked at each point.