I recently just upgraded Consent Pro to v2 and after my initial scan its showing several actions which don’t seem related to my page.
Several cookies appear in the ConsentPro scan that don’t actually display on the website. When I load the site and inspect the cookies none of these display. Below is the cookies loaded when you go to the live site.
Examples of cookies from the scan that dont seem to exist but display on the FS consent pro scan:
Statsig.stable_id.XXXXX [we never used statsig, there are also links to loom in the autodetect which we also dont use.]
SentryIO [we have never used SentryIO - also links to loom]
Sentry Replay tracker [we have never used SentryIO - also links to loom]
The font Monserrat is detected , even though I have no google fonts installed for this page, or any of the sub-environments (IE test/Beta) . I do however see this in the CSS so this may be more of a Webflow question on how its getting loaded.
Site URL
Required: Please provide a staging/production URL where we can see the issue
@support5 — good news here! We checked your page HTML and can confirm there are zero instances of Sentry, Statsig, Loom, or Google Fonts scripts in your code. What’s actually loading on your site is just Webflow’s JS chunks, jQuery, and your gec-components.js (which is correctly wrapped with type=fs-consent and fs-consent-categories="essential").
What’s likely happening is that the Consent Pro v2 scanner uses a knowledge database to auto-categorize and populate trackers proactively — meaning it can add tracker entries based on its database even if those scripts aren’t actually running on your site. We’ve seen this pattern before, and in those cases the flagged trackers were safely dismissible.
Here’s where things stand for each item:
Sentry / Sentry Replay / Statsig — Not running on your site based on the HTML inspection and the cookie check you already did. You should be able to dismiss or remove these from the Actions tab in the Consent Pro app.
Montserrat font — This is likely coming from Webflow’s default CSS font stacks rather than an actual Google Fonts import. Open DevTools, go to the Network tab, filter by fonts.googleapis.com, and reload the page. If no request fires, it’s just a CSS font declaration — not a real tracker, and safe to dismiss.
The loom.com URL in the resource field — We’re not 100% sure why that specific URL appears there. It may be a database reference artifact rather than something from your site. We’re checking with the team on that one.
In the meantime, go ahead and dismiss the confirmed false positives (Sentry, Statsig) from the Actions tab, and run that Network tab check for the font.
Thanks for the fast reply! That makes sense that its coming from Webflows default JS chunks and I will ignore those.
As for that Montserratt font - I was able to see that being loaded in network tab so it seems like it may be a real tracker. I’ll work with my FEE team to see if that’s hardcoded outside of Webflow (unlikely, but its my only other thought) . Keep me posted on that loom URL , guessing its just an issue with the DB reference from your end but curious what you find!
@Support-Finn I just went through all the publishing steps to get this updated properly. I went ahead and ignored those cookies described above, however as an end user I still see those displaying in the Analytics tab. How do I removed these from being visual as they aren’t cookies that apply to my site?
To add on to what @Support-Finn has said, Consent Pro v2’s auto-detect works by pattern-matching against its global tracker database and thus can flag entries that were never actually set on your site if the patterns match loosely. This is expected behavior with any consent management platform’s auto-discovery feature.
For instance, The loom.com resources link is not your site loading Loom. That field is a reference URL in Consent Pro’s own tracker database, it’s where they document information about the tracker, nothing to do with your site’s traffic.
In the Review and Confirm Tracker dialog, click Edit (not Confirm) for any tracker you know is a false positive and either delete it from your config or reclassify it.
Thanks for the extra detail Jesse! I ended up doing that.
From an end user standpoint, It would be interesting to see what caused that false flag so we could be sure that we are truly ignoring false flags and not actual unknown trackers. But I know this is more feedback for FS
