Consent Pro V2 — scan fails ("couldn't access any pages"), script not detected, and empty consent logs on a live, publicly-accessible site

Consent Pro
1

Consent Pro V2 on my published Webflow site is failing in three related ways — even though the consent banner itself works correctly on the live site:

  1. The site scan fails at the very end with “We couldn’t complete the scan — We couldn’t access any pages on your website.” It appears to find and crawl the pages during the scan, then errors out at the finish. I’ve run it several times with the same result.
  2. The app does not detect that the consent script is installed, although the banner renders and works on the live site.
  3. Consent Logs & Analytics show no entries at all — no accept/reject records — despite the banner functioning.

Site URL

https://www.tergar.de (published, public, no password protection)

Steps to Reproduce

  1. Open the Consent Pro app → Manager → Consent Manager.
  2. Run the site scan.
  3. The scan appears to find/crawl pages, then ends with “We couldn’t complete the scan / couldn’t access any pages.”
  4. The app continues to report the consent script as not installed.
  5. Consent Logs remain empty.

Expected Behavior

Scan completes and detects trackers; the app recognizes the installed script; consent logs record accept/reject events.

Actual Behavior

Scan fails, script not detected, logs empty.

What I’ve already ruled out (so we can skip the usual first steps)

  • The site is published and publicly reachable — it loads fine in any browser, no password protection.
  • robots.txt is clean: it contains only the Sitemap: directive, no Disallow. Crawlers are not blocked.
  • sitemap.xml is complete and valid — 74 URLs, all consistently on https://www.tergar.de.
  • The consent banner DOES render and work on the live site (verified in a clean Chrome incognito window).
  • Google Consent Mode signals are flowing correctly client-side: gcs=G100 (denied) before consent, gcs=G111 (granted) after clicking Accept — so the script is live and functioning.
  • No CSP issue: the browser console shows no “Refused to connect” / Content-Security-Policy errors, and the verification call to accounts.finsweet.com is not being blocked by a site-side CSP.
  • The “publish the site while the app is open” workaround (from another forum thread) did not resolve it.

Environment

  • Platform: Webflow (published to the production custom domain)
  • Consent Pro V2
  • Tested in Chrome and Firefox (macOS)

Given the above, this looks like a server-side scan/verification issue on Consent Pro’s side rather than a site-configuration problem. Happy to provide any additional details or grant access via DM. Thanks in advance!

2

Hey @marco1!

Since you’ve already ruled out the common culprits (sitemap, robots.txt, CSP, gcs signals, the publish-while-open workaround), let’s skip straight to the two things worth investigating in parallel here.

Incomplete V2 migration — check this first

The pattern of scan failing + script not detected + empty logs matches exactly what happens when the V2 migration isn’t fully complete. The Consent Pro v2 migration requires all three of these to be in place:

  1. The new V2 script installed in the custom code <head> section
  2. A banner created fresh inside the v2 app (the old v1 banner is not compatible with v2 logs or scan detection)
  3. The old legacy Consent Pro code block removed from “Code Added by Apps”

Even if the banner visually renders on the live site (it can pull from a v1 config), logs and scanner detection won’t work until the v2 setup is fully validated with a “You are all set” success message in the app’s Actions tab.

Was the banner generated fresh inside the Consent Pro v2 app, or was it originally created in v1?

Scanner-level access issue

Since client-side behavior is working fine, the “couldn’t access any pages” error points to a server-side access problem — not a browser issue. Is your Webflow site proxied through any CDN or security service (Cloudflare, Fastly, Sucuri, etc.) at the DNS level? Even with no rules configured, some services apply automated bot filtering by default.

One thing to fix regardless

The Google Tag Manager <noscript> iframe in your page footer needs to go. Consent Pro v2 explicitly requires removing it — noscript tags execute even when JavaScript is disabled, which can bypass consent controls entirely. In Webflow, it’s typically under Site Settings → Custom Code → Footer Code.

To move forward, it’d help to see the <head> section of your HTML so we can verify the V2 script format and siteid attribute. We’re flagging this to the team to look into the scanner-side behavior directly. :muscle:

3

Thanks for the fast reply! Let me address your points directly, because I think a couple of them don’t apply to my case — and I’ve since found the actual root cause.

On the “incomplete V2 migration”: There was no migration. This is a fresh V2 install — I never had v1 at all, so points 1–3 of your migration checklist don’t apply (there’s no legacy v1 banner and nothing in “Code Added by Apps” to remove). The banner was created fresh inside the V2 app. The Actions tab still does not show “You are all set,” but given there was never a v1 setup, the incomplete-migration explanation doesn’t fit.

On the CDN/proxy question: No. The site runs on plain Webflow hosting with no Cloudflare/Fastly/Sucuri or any proxy in front at the DNS level. So there’s no external bot-filtering layer that could be blocking the scanner.

On the noscript iframe: Already removed from the Webflow footer — thanks, done.

Now the key finding. I debugged the whole setup in GTM Tag Assistant, and there’s a concrete, reproducible problem with the Consent Mode default:

Consent Pro pushes the consent-mode default as “granted”, before any user interaction. In Tag Assistant, the very first gtag("consent", "default", ...) event on page load already shows every consent type — including analytics_storage and ad_storage — as Granted. This is the case even though:

  • The banner’s “Analyse” category is toggled OFF by default (opt-in) in the Configurator.
  • I have a separate GTM Custom-HTML tag setting all consent types to denied on the “Consent Initialization – All Pages” trigger — which Consent Pro’s own “granted” default overrides.

So no gating is possible: GA4 is free to fire before consent. For a German e.V. (GDPR) this is a blocker.

Important nuance vs. my first post: the consent update on accept does work — Tag Assistant shows the consent-updated event, and after accepting, analytics_storage is granted. It’s the initial default that’s wrong (granted instead of denied). My earlier gcs=G100 → G111 observation was measured while a direct gtag was still in the <head>; now that everything runs through GTM, the Tag Assistant clearly shows the default coming in as “granted.”

My question: Where do I set Consent Pro’s consent-mode default to denied, or disable Consent Pro’s consent-mode default entirely so my own GTM default applies? I can’t find any Google Consent Mode / default-value option in Global Settings or the Banner Configurator.

And the two original issues remain unexplained given there’s no migration and no proxy:

  • Script not detected: Install tab shows “Implementation issues detected,” Validate Script fails — yet the script is present exactly once in <head>, correct v2 format, siteid matches, and the runtime loads with HTTP 200 live. I did one full clean reinstall before; it worked temporarily and then recurred.
  • Scan fails / empty logs: unchanged from my first post.

Happy to share a Webflow read-only link via DM so you can verify the <head> and siteid. Given no migration and no proxy are involved, could you please escalate all three to the team — especially the consent-mode default, which currently blocks compliant use. Thanks!

4

Hey @marco1

Thanks for the pretty detailed debug of the actual problem & I’ve already escalated to the relevant devs

Yeah you can share the read-only link in the DM so I can pass it on to the team

I will keep you updated

5

Hey @marco1

Your ConsentPro configs apparently point to staging tergar-de.webflow.io
Instead of production tergar.de

consent-pro-configs
consent-pro-configs793×886 58.5 KB

Please configure your domain to prod
Staging shows a 404
It’s likely that was the initial config & now just needs an update to prod

Here’s how to make the switch

switch-from-staging-to-prod
switch-from-staging-to-prod310×224 9.04 KB

Let us know

Thanks

6

Thanks, that’s very helpful. The origin is indeed pointing to tergar-de.webflow.io! But I can’t locate the ‘Change Domain’ option anywhere in the UI though (checked Manager → Consent Manager, Scan History, Schedule Scan). Could you point me to the exact menu, or just update it on your end?

Bildschirmfoto 2026-07-22 um 09.34.09
Bildschirmfoto 2026-07-22 um 09.34.091590×1280 103 KB

7

Hey @marco1

It’s inside the Manager view, good to know where it is exactly for next time, you never know

Change-domain-section
Change-domain-section1684×1412 247 KB

8

Hi Jesse
Thanks for your reply! Since the project scan can never be completed, I have no access to “Scan Settings”. As you see in my last screenshot I sent, there is no “Scan Settings” Dropdown.

9

Hey @marco1 sorry this took a while

Please re-run the scan, the configs have been manually edited to set prod www.tergar.de in place of staging

Let us know, thanks

10

Thank you Jesse, one step further. That worked. But now it looks like my licence can’t be found.

Bildschirmfoto 2026-07-26 um 14.35.57
Bildschirmfoto 2026-07-26 um 14.35.57596×994 58.7 KB

11

Hey @marco1 please share the full url with debugger params so we can troubleshoot

12

Hold off a lil bit @marco1 the team needs to update the runtime configs

Will keep you in the loop, thanks

13

Hi Jesse, do you have any news for me?

14

Still no updates unfortunately, let me get back to you asap

15

@marco1 try rescanning & confirm if it’s resolved :folded_hands:

16

Hi Jesse, I’ve rescanned it but it still can’t found the licence:

Bildschirmfoto 2026-07-31 um 12.27.23
Bildschirmfoto 2026-07-31 um 12.27.23604×1004 70.4 KB

17

Jesse, is it possible to bring this consent working today? We planed to start our new communication campaign by mid of july and it’s all on hold since more than 14 days because of the broken cookie consent.

18

Hey @marco1 good news!

It should be fixed now

license-fixed
license-fixed1314×1397 288 KB

Let us know how it pans out