Have a question about WPConsent? This page covers the most common questions and issues users encounter while using the plugin. Browse the sections below to find quick, practical answers.

Table of contents

• Banner issues
• Blocking issues
• Scanner issues
• Compatibility
• Testing

Banner issues

Why isn’t my banner showing on my website?

There are several reasons the consent banner won’t appear. Work through these checks in order:

1. Banner is disabled. Navigate to WPConsent >> Banner Design and confirm that the Show Banner on Frontend option is enabled. Then click Save to apply any changes.
2. Consent is already saved. If you already interacted with the banner, your preferences are stored in a cookie called wpconsent_preferences. The banner won’t appear again until that cookie expires or is deleted. To clear it, open your browser’s developer tools, go to Application >> Cookies, delete the wpconsent_preferences cookie, and reload the page. You can also test in a private or incognito window.
3. A cached page is being served. If you use a caching plugin (WP Rocket, W3 Total Cache, LiteSpeed Cache, etc.) or a CDN, the cached version of your page may not include the banner. Purge all caches and reload. For more details, see the caching compatibility section below.
4. Page builder editor mode. WPConsent automatically hides the banner and disables script blocking inside the Bricks Builder and Divi Builder editors. This is intentional. To see the banner, preview the page or view it on the frontend.
5. Customizer preview. The banner doesn’t load in the WordPress Customizer preview to avoid interfering with the customization experience.
6. REST API or AJAX request. The banner only loads on standard frontend page requests. It doesn’t load on REST API endpoints, AJAX requests, or RSS feeds.
7. Theme or plugin conflict. In rare cases, a theme or plugin may interfere with WPConsent’s output. Try temporarily switching to a default WordPress theme (like Twenty Twenty-Four) to see if the banner appears.

Why does my banner appear unstyled or flash before loading?

WPConsent uses Shadow DOM to isolate its styles from your theme. The CSS loads asynchronously via JavaScript after the Shadow DOM is created. The banner container is set to display: none until the CSS fully loads, which prevents any unstyled flash. On very slow connections, there can be a brief delay before the banner appears, but it won’t show unstyled content.

If you see unstyled content, check that your server isn’t blocking requests to the WPConsent build/ directory. Also verify that no security plugin is blocking inline scripts or fetch requests.

Why does my banner show on every page load even after I accept?

This happens when the wpconsent_preferences cookie can’t be saved or is being cleared between page loads. Common causes include:

• Cookie consent duration is set to 0. Navigate to WPConsent >> Settings and confirm the consent duration is set to a value greater than 0 (the default is 30 days).
• Cookie domain mismatch. If you’re using the Shared Consent feature (under WPConsent >> Settings >> Advanced), confirm that the cookie domain is configured correctly for your subdomain setup.
• A plugin or server rule is clearing cookies. Check if any security or performance plugin is configured to strip cookies.

Blocking issues

Why aren’t my scripts being blocked?

If tracking scripts still run before consent is given, check the following:

1. Script blocking is disabled. Navigate to WPConsent >> Settings and confirm that the Script Blocking toggle is turned on. Script blocking requires the consent banner to also be enabled. If the banner is off, script blocking is automatically disabled.
2. Google Consent Mode is enabled. When Google Consent Mode is turned on, Google Analytics, Google Tag Manager, and Google Ads scripts aren’t blocked. Instead, they run in a restricted, cookieless mode until consent is granted. This is correct behavior. If you prefer full blocking, disable Google Consent Mode from WPConsent >> Settings on the Settings tab.
3. Clarity Consent Mode is enabled. Similar to Google Consent Mode, when Clarity Consent Mode is on, Microsoft Clarity scripts aren’t blocked but operate via consent signals. Disable Clarity Consent Mode if you prefer full blocking.
4. The script isn’t in the known scripts list. WPConsent blocks scripts from a remotely maintained list. If a particular service isn’t recognized, its scripts pass through unblocked. You can check whether a script is being blocked by viewing the page source and looking for type="text/plain" and data-wpconsent-src attributes on script tags.
5. The script is loaded dynamically by another script. If a script is loaded at runtime by JavaScript (for example, by Google Tag Manager), WPConsent’s server-side output buffering can’t detect it because it only exists in the initial HTML response. Google Consent Mode handles this case for Google services. For other services loaded through tag managers, consider using custom blocking rules in the paid version.
6. Caching is serving a pre-processed page. Page caching plugins may cache the HTML before WPConsent’s output buffer runs. For details, see the caching compatibility section below.
7. Debug mode is active. If the URL contains the wpconsent_debug query parameter, script blocking is intentionally disabled. The scanner uses this parameter internally. Remove it from the URL to restore normal blocking.

How do I block a script that isn’t automatically detected?

Pro Feature: Custom script and iframe blocking rules are available in the paid version. You can add a unique string that identifies the script (such as a URL fragment) and assign it to a service and cookie category.

In the free version, you can’t add custom blocking rules through the admin interface. However, WPConsent’s block list is updated remotely. You can contact the WPConsent team to request that a specific service be added to the automatic detection list.

Why aren’t my iframes or embedded content being blocked?

Iframe blocking is handled separately from script blocking and must be enabled independently:

1. First, navigate to WPConsent >> Settings.
2. Next, enable the Content Blocking toggle.
3. Then select which services you want to block from the multi-select list.
4. Finally, click Save Changes.

Only iframes from services in the known scripts list that have iframe patterns defined are blocked.

Scanner issues

Why didn’t my scan detect all services on my site?

The scanner identifies known services by analyzing your site’s HTML for script patterns and URL signatures. Here are the most common reasons it doesn’t catch everything:

• Scripts loaded by a tag manager. The free version scanner analyzes the raw HTML of your pages. If a tracking script is loaded dynamically through Google Tag Manager or another tag manager, it doesn’t appear in the HTML source and the scanner can’t detect it.

Pro Feature: The paid version scanner can also detect services added by plugins and scripts loaded through Google Tag Manager.

• The service only runs on specific pages. By default, the scanner checks your homepage. If a tracking script only loads on certain pages (for example, a checkout page or a landing page), the scanner won’t find it unless you include those pages. You can select additional pages to scan from WPConsent >> Scanner by choosing pages in the scanner settings.
• The service isn’t in the WPConsent database. The scanner relies on a server-side database of known services. If a service is very niche or new, it won’t be in the database yet. You can manually add missing services and their cookies using cookie data from cookielibrary.org. Navigate to WPConsent >> Settings, click the Cookies tab, add a new service, and enter the cookie details from the library.
• The scan encountered an error. The scanner makes an HTTP request to your own site to fetch its HTML, then sends that to the scanning API. If your site requires authentication, uses basic auth, or has a firewall blocking internal requests, the scan fails or returns incomplete results. Check the scanner response message for error details.

Can I re-scan my website after making changes?

Yes. Navigate to WPConsent >> Scanner and run a new scan at any time. We recommend rescanning after you add or remove plugins, switch themes, or add new tracking scripts to your site.

Compatibility

Does WPConsent work with my caching plugin?

Yes, WPConsent is compatible with most caching plugins, but you need to understand how they interact.

WPConsent’s script blocking works through PHP output buffering, which modifies the HTML before it’s sent to the browser. Page caching plugins (WP Rocket, W3 Total Cache, WP Super Cache, LiteSpeed Cache, etc.) store the final HTML output and serve it directly on subsequent requests, bypassing PHP entirely.

This means:

• The first uncached page load is processed by WPConsent’s output buffer. Scripts are correctly blocked in the resulting HTML, and this blocked version is then cached.
• Subsequent cached page loads serve the already-modified HTML, so scripts remain blocked as expected.

When things go wrong:

• If you enabled WPConsent after your pages were already cached, the cached pages won’t have blocked scripts. Purge all caches after enabling or changing script blocking settings.
• If your caching plugin serves different cached versions based on cookies, confirm it isn’t stripping the wpconsent_preferences cookie. WPConsent’s banner and unblocking logic run in JavaScript on the frontend, so they work regardless of caching as long as the initial HTML has the scripts properly modified.

WP Rocket specific: WPConsent includes a built-in compatibility file that excludes the banner container from WP Rocket’s lazy rendering feature. No extra configuration is needed.

Does WPConsent work with my page builder?

Yes. WPConsent includes built-in compatibility with the following page builders:

• Bricks Builder: WPConsent automatically disables the banner and script blocking while you’re editing in Bricks Builder to prevent interference. The banner works normally on the frontend.
• Divi Builder: Similar to Bricks, WPConsent disables the banner and script blocking inside the Divi visual builder editor. Everything works normally on the published page.

For other page builders (Elementor, Beaver Builder, WPBakery, etc.), WPConsent works on the frontend without any special configuration. The banner and script blocking only run on standard frontend page loads and don’t interfere with editor interfaces.

Does WPConsent work with the WP Consent API?

Yes. WPConsent integrates with the WP Consent API plugin. When WP Consent API is active, WPConsent automatically registers itself as the active consent plugin and communicates visitor consent choices for each category (functional, preferences, statistics, and marketing). This allows other plugins that support the WP Consent API to respect the consent preferences set through WPConsent’s banner. For details on the integration, see the WP Consent API guide.

Testing

How do I test if my consent setup is working correctly?

Follow these steps to verify that WPConsent is properly blocking and unblocking scripts:

1. First, open a private or incognito browser window. This ensures no existing consent cookie is present.
2. Next, open your browser’s developer tools (usually F12 or right-click then Inspect).
3. Go to the Elements tab and search for data-wpconsent-src. You should see blocked script tags with type="text/plain" and their original source stored in data-wpconsent-src. This confirms script blocking is working.
4. Check the Network tab. Before accepting consent, requests to tracking services (such as google-analytics.com or connect.facebook.net) should not appear. If Google Consent Mode or Clarity Consent Mode is enabled, those specific services will load in restricted mode instead.
5. Click the Accept All button on the banner.
6. Check the Network tab again. You should now see requests to the tracking services as their scripts are unblocked and executed.
7. Go to the Application tab. Under Cookies, you should see the wpconsent_preferences cookie with a JSON value listing each category and its consent status (true or false).
8. To test revoking consent, click the floating preferences button (if enabled) or add the class wpconsent-open-preferences to any link on your page. This opens the preferences panel. Uncheck a category and save. The page reloads, and the revoked category’s scripts are blocked again.

Is there a debug mode I can use?

Yes. Add ?wpconsent_debug to any URL on your site to temporarily disable script blocking for that page load. This is useful for troubleshooting and is the same parameter the scanner uses when fetching your site’s HTML. Debug mode only affects script blocking. The banner still appears normally.

Note that debug mode isn’t a persistent setting. It only applies to the specific page load where the URL parameter is present.

Does WPConsent guarantee full compliance with privacy laws?

WPConsent expressly disclaims all representations and warranties that WPConsent will comply with applicable data privacy laws and regulations. It is your sole responsibility to comply with applicable data privacy laws and regulations. WPConsent does not provide legal advice and you should consult legal counsel for advice on this topic. Please see our Terms of Service.

Conclusion

This FAQ covers the most common questions about WPConsent, from banner display issues and script blocking to scanner behavior and caching compatibility. If your question isn’t answered here, check the related guides below for deeper coverage of specific topics.

For a complete overview of the plugin and its features, read our guide on what WPConsent is and how it works.

Related guides

• Automatic script blocking
• Scanning your website
• Banner layout options
• General settings
• What is WPConsent?