The core purpose of DigiConsent is to manage tracking scripts and cookies according to user consent. When scripts aren’t loading correctly, your cookie consent management system isn’t working, which can lead to compliance violations and lost analytics data. This guide addresses every scenario where scripts fail to load or load incorrectly, explaining the underlying causes and providing comprehensive solutions.
Understanding how script blocking and consent management works is essential to troubleshooting these issues. DigiConsent intercepts tracking scripts, prevents them from executing until consent is granted, and then enables them based on user choices. This complex orchestration can fail at multiple points, and identifying exactly where the failure occurs is the first step to fixing it.
How Script Blocking Works
Before troubleshooting, you need to understand the mechanism DigiConsent uses to control scripts. When you add tracking scripts like Google Analytics or Facebook Pixel through DigiConsent, the plugin modifies how these scripts load. Instead of the normal script tag <script src="...">, the plugin changes the type attribute to <script type="text/plain"> and adds a data attribute indicating the cookie category.
Browsers don’t execute scripts with type="text/plain" because they don’t recognize it as JavaScript. This is the blocking mechanism. When a user provides consent for a specific category, DigiConsent’s JavaScript finds all scripts with the matching data-category attribute, changes their type back to text/javascript, and executes them. This happens dynamically in the browser after consent is given.
This approach is elegant but has several failure points. The initial script tags must be properly formatted, DigiConsent’s JavaScript must execute correctly to modify them, and the timing must be right so scripts execute after consent but not before. Any disruption in this chain prevents scripts from loading.
Scripts Loading Before Consent
If tracking scripts execute immediately when a page loads, before users have a chance to provide consent, your cookie management isn’t working. This is a serious compliance issue for GDPR and other privacy regulations. It typically means scripts are being loaded through a method that DigiConsent can’t control.
Multiple script sources: The most common cause is having the same tracking script installed through multiple methods. For example, you might have Google Analytics configured in DigiConsent, but it’s also being loaded by another plugin, hardcoded in your theme, or added through Google Tag Manager. DigiConsent can only control scripts it manages directly.
To diagnose this, view your page source (right-click on your page and select “View Page Source”). Search for your tracking IDs like your Google Analytics measurement ID (looks like G-XXXXXXXXXX or UA-XXXXXXXX) or Facebook Pixel ID. If you find these IDs in multiple places in your page source, you have duplicate installations.
Solution: Remove all alternative methods of loading tracking scripts. Check these common locations:
- Other plugins like MonsterInsights, ExactMetrics, or WPForms that have analytics integrations
- Your theme’s customizer or theme options panel where you can paste tracking codes
- The header.php or footer.php files in your theme where codes might be hardcoded
- Google Tag Manager if you’re using it to deploy scripts
- Header/footer script injection plugins
Consolidate all tracking script management into DigiConsent. This gives you centralized control and ensures consent management works correctly. If you must use Google Tag Manager, configure DigiConsent to block the GTM container itself until consent is provided, then deploy all your tracking tags through GTM.
Scripts Not Loading After Consent
The opposite problem is when users provide consent but tracking scripts still don’t execute. They accept cookies, but analytics don’t track, Facebook Pixel doesn’t fire, and other tracking functionality doesn’t work. This defeats the purpose of collecting consent in the first place.
Incorrect script format: DigiConsent requires scripts to be formatted in a specific way. When you add a script, it must include the correct data-category attribute that matches your cookie categories. For example, if you have an “Analytics” category, scripts for that category need data-category="analytics" (the exact name depends on your configuration).
A properly formatted tracking script should look like this:
<script type="text/plain" data-category="analytics">
// Your tracking code here
</script>If the type isn’t set to text/plain, the script will execute immediately regardless of consent. If the data-category attribute is missing or doesn’t match your categories exactly (including case sensitivity), DigiConsent won’t know which scripts to enable when consent is provided.
Category name mismatches: Check that the category names in your script tags exactly match the category names in your DigiConsent configuration. If your settings define a category called “Analytics” but your script uses data-category="analytics" (lowercase), they won’t match. Category names must match precisely, including capitalization, spaces, and special characters.
JavaScript execution errors: Even if scripts are properly formatted and consent is given, JavaScript errors can prevent the consent management system from enabling scripts. Open your browser console and provide consent while watching for errors. You should see DigiConsent’s code executing and modifying script tags. If you see errors during this process, they’re preventing scripts from loading.
Common errors include jQuery conflicts, where DigiConsent’s code uses jQuery but it’s not loaded correctly, or timing issues where DigiConsent tries to modify scripts before the DOM is fully ready. These errors stop the consent management code before it can enable your tracking scripts.
Automatic Script Blocking Not Working
DigiConsent Pro includes automatic script blocking features that scan your site and automatically block known tracking scripts without manual configuration. When this doesn’t work, scripts that should be blocked automatically continue to execute.
Scanning limitations: Automatic blocking works by scanning your page’s HTML for known tracking script patterns. However, it can only block scripts that are in the initial HTML. Scripts loaded dynamically through JavaScript after the page loads can’t be caught by the initial scan. Many modern tracking implementations use dynamic loading, which bypasses automatic blocking.
For example, if a plugin uses JavaScript to inject Google Analytics after the page loads, the script tag isn’t in the HTML when DigiConsent scans, so it can’t be blocked automatically. The script appears only after JavaScript executes, which is too late for the blocking mechanism to intercept.
Solution: For dynamically loaded scripts, you need manual configuration. Identify which plugins or themes are loading scripts dynamically and either configure them to not load those scripts (letting DigiConsent manage them instead), or add custom code to block the dynamic loading until consent is provided. This often requires JavaScript knowledge to hook into the dynamic loading process and make it consent-aware.
Script variants and updates: Tracking scripts frequently change their code structure. Google Analytics has had multiple versions (analytics.js, gtag.js, GA4), and automatic blocking relies on recognizing specific patterns. If a tracking service updates their code structure, DigiConsent might not recognize it until the plugin is updated to include the new pattern.
Check if you’re using the latest version of DigiConsent. Updates often include improved detection for new script variants. If you’re using a tracking script that isn’t being detected, report it to DigiConsent support so they can add detection for it in future updates.
Third-Party Script Loading Issues
Many tracking scripts work by loading an initial snippet that then fetches additional scripts from third-party servers. Google Analytics, for instance, loads an initial gtag.js file which then loads configuration and additional functionality. When you block the initial script, you must ensure the entire chain is properly managed.
External script references: Scripts with src attributes that load external files need special handling. A script tag like <script src="https://www.googletagmanager.com/gtag/js?id=G-XXXXXX"></script> loads code from Google’s servers. To block this, you change the type and add the data-category:
<script type="text/plain" data-category="analytics" src="https://www.googletagmanager.com/gtag/js?id=G-XXXXXX"></script>However, some scripts have inline initialization code that runs before the external file loads. This initialization code also needs to be wrapped in a blocked script tag with the same category. If only part of the script chain is blocked, you’ll have partial execution that doesn’t work correctly.
Async and defer attributes: External scripts often use async or defer attributes for performance. When you add type="text/plain" to block these scripts, the browser ignores the async/defer attributes because it’s not treating it as JavaScript. When DigiConsent re-enables the script by changing the type back, it needs to preserve these loading attributes.
Most modern cookie consent solutions handle this automatically, but if you’re manually configuring scripts, ensure that async and defer attributes remain on the script tag along with the type and data-category attributes. The complete tag should look like:
<script type="text/plain" data-category="analytics" src="script.js" async></script>Google Tag Manager Specific Issues
Google Tag Manager (GTM) is a popular tag management system that loads tracking scripts dynamically. It’s particularly tricky to manage with cookie consent because GTM itself loads before consent is given, then uses JavaScript to inject all your tracking tags. Those tags execute immediately when GTM loads them, bypassing consent.
The GTM container must be blocked: Instead of trying to block individual scripts loaded by GTM, you need to block the GTM container script itself. The GTM installation includes a script tag that loads the container. This tag must be formatted with type="text/plain" and the appropriate data-category attribute.
Your GTM installation looks like this by default:
<script>(function(w,d,s,l,i){w[l]=w[l]||[];w[l].push({'gtm.start':
new Date().getTime(),event:'gtm.js'});var f=d.getElementsByTagName(s)[0],
j=d.createElement(s),dl=l!='dataLayer'?'&l='+l:'';j.async=true;j.src=
'https://www.googletagmanager.com/gtm.js?id='+i+dl;f.parentNode.insertBefore(j,f);
})(window,document,'script','dataLayer','GTM-XXXXXX');</script>To block this properly, modify it to:
<script type="text/plain" data-category="analytics">(function(w,d,s,l,i){w[l]=w[l]||[];w[l].push({'gtm.start':
new Date().getTime(),event:'gtm.js'});var f=d.getElementsByTagName(s)[0],
j=d.createElement(s),dl=l!='dataLayer'?'&l='+l:'';j.async=true;j.src=
'https://www.googletagmanager.com/gtm.js?id='+i+dl;f.parentNode.insertBefore(j,f);
})(window,document,'script','dataLayer','GTM-XXXXXX');</script>GTM consent mode: Google Tag Manager has its own consent mode that integrates with cookie consent solutions. When configured correctly, GTM consent mode allows GTM to load but prevents individual tags from firing until consent is given. This is more sophisticated than blocking the entire container.
DigiConsent may include GTM consent mode integration. If enabled, you load GTM normally but configure consent mode settings that tell GTM which tags to hold back until consent is provided. This requires configuration both in DigiConsent and in your GTM container, mapping your cookie categories to GTM’s consent types (analytics_storage, ad_storage, etc.).
Cookie Setting vs Script Execution
Understanding the difference between cookies and scripts is important for troubleshooting. Scripts are JavaScript code that executes in the browser. Cookies are small data files stored by the browser. Scripts often set cookies, but blocking scripts doesn’t automatically prevent all cookies.
Some cookies are set by the server in HTTP headers, not by JavaScript. These server-side cookies can’t be blocked by a JavaScript-based consent management system like DigiConsent. For example, if your WordPress install sets session cookies through PHP, DigiConsent can’t prevent those because they’re set before any JavaScript runs.
First-party vs third-party cookies: First-party cookies are set by your domain. Third-party cookies are set by other domains, typically through embedded content like ads or social media widgets. DigiConsent can block scripts that set first-party cookies by preventing the scripts from executing. Third-party cookies are trickier because they’re often set by iframes or pixel tracking images, not JavaScript.
To block third-party cookies effectively, you must block the iframes, images, and other resources that set them. This often means blocking social media embeds, advertisement iframes, and external widgets until consent is provided. DigiConsent may include features to automatically block known third-party cookie sources, or you may need to manually configure blocking for specific embeds.
Testing Script Blocking Effectiveness
Properly testing whether scripts are being blocked requires systematic verification. Simply accepting cookies and seeing analytics work isn’t sufficient. You need to verify scripts are blocked before consent and enabled after consent.
Testing procedure:
- Open your site in a private browsing window to start with no existing consent cookies
- Open browser developer tools (F12) and go to the Network tab
- Load your page and observe what network requests are made before you interact with the consent banner
- Look for requests to analytics services, ad networks, or social media platforms – these should NOT appear yet
- Open the Application tab (Chrome) or Storage tab (Firefox) and check cookies – you should only see essential cookies, not tracking cookies
- Accept analytics cookies through the consent banner
- Watch the Network tab for new requests to analytics services – these should appear now
- Check the Console tab for any errors during the script loading process
- Verify in the Application/Storage tab that analytics cookies are now set
- Use the Console to check if tracking objects are defined, like
typeof gtagshould return “function” after consent
This thorough testing process confirms scripts are truly blocked before consent and successfully enabled after consent. If you see tracking requests or cookies before providing consent, you have a blocking problem. If they don’t appear after consent, you have an enabling problem.
Debugging with Browser Console
The browser console is your most powerful tool for debugging script loading issues. Beyond just checking for errors, you can use it to inspect the state of your tracking scripts and consent system.
Checking script tags: In the console, you can query all script tags on the page with:
document.querySelectorAll('script[data-category]')This returns all scripts managed by DigiConsent. You can inspect each one to verify it has the correct type and category attributes. Before consent, they should have type="text/plain". After consent, they should have type="text/javascript".
Checking consent state: DigiConsent may expose consent state through JavaScript variables or functions. Check the documentation for how to query current consent status. Typically there’s a function like DigiConsent.hasConsent('analytics') that returns true if analytics consent has been granted. You can call this in the console to verify consent is being recorded correctly.
Manual script execution: For testing, you can manually execute blocked scripts in the console to verify they work when enabled. Copy the code from a blocked script tag and paste it into the console. If it executes without errors, the script code itself is fine and the issue is purely with the consent blocking/enabling mechanism.
Common Integration-Specific Issues
Google Analytics 4: GA4 has specific initialization requirements. The gtag.js library must load first, then configuration commands must run. If you’re blocking these as separate scripts with different categories or timing, initialization can fail. Keep the library load and configuration together in a single blocked script, or ensure they’re in the same category so they enable simultaneously.
Facebook Pixel: The Facebook Pixel has both the base pixel code and event tracking code. The base code must execute before any event tracking. If you’re blocking them separately or if other plugins try to fire Facebook events before the base pixel loads, tracking will fail. Ensure the complete pixel installation (base code and any events) is managed as a unit.
Hotjar and session recording: Session recording tools like Hotjar or Lucky Orange need to start recording at page load to capture the full user session. If they’re blocked until consent, they miss the initial page interactions. This is by design for consent compliance, but it means your recordings start mid-session. There’s no workaround that maintains compliance; it’s a trade-off of consent-first implementation.
Understanding these integration-specific quirks helps you configure script blocking correctly for each service. Always consult the official documentation for each tracking service to understand their loading requirements, then configure DigiConsent to honor those requirements while maintaining proper consent flow.