The ConsentPro installation looks correct
The tracking scripts on the site however need to be wired to work with ConsentPro
First of all, move the two ConsentPro installation <script> tags to be the very first scripts in <head> ahead of the Facebook Pixel and Intellimize snippets
Your tracking scripts then need to look something like this
Yes, I can confirm that this is what I have been doing, but the dashboard still isn’t working. We currently have approximately 30% of our pages showing that they do not have cookie consent.
We do have some draft pages, but none of them are password-protected. We have had draft pages in the past, and everything worked fine, so I don’t believe that should be causing this issue, especially since every website is going to have pages that are in draft.
I have sent multiple emails to Support regarding this issue and have also attached a message from our engineer with additional details. I would appreciate it if you could review the information there as this issue seems to go beyond our set up.
Webflow indicated that the issue is likely related to the ASN blocking feature and mentioned that they have worked with your team to determine a workaround. Could you please look into this and let me know what the next steps are?
Also, the two ConsentPro scripts are the first 2 tags in the code already. I am also trying to run a scan on the dashboard and it is stuck in a loop and won’t finish. We had another company do an audit and they found that 30% of our pages aren’t showing any form of Cookie consent and that a ton of tags aren’t actually firing the way they should and are sometimes firing before consent is given in regions where that can’t be the case. This needs to be resolved ASAP.
I sent a response yesterday, and the day before. What you sent was already tried by our team on Friday and we are still having issues.
We really need to get a response on this as soon as possible. At this point, we are seriously considering switching to a different software solution.
This does not appear to be a setup issue. Based on what we’re seeing, it appears to be a compatibility issue between ConsentPro and our reverse proxy configuration. Using a reverse proxy is not an unusual setup, and plenty of companies operate this way, so we need to understand why this configuration is not working with ConsentPro and, more importantly, how we can resolve it.
We need a clear response and a viable solution ASAP. Please escalate this issue.
Hey Holland, could you please checkout the solution on Crisp
Pasting it here again
Hello Holland,
An issue with the User-Agent that your team allowed, you’ve used the following name,
ConsentProBot/1.0
The correct User-Agent should be simply
ConsentProScanner
Another thing, we have pushed an update that supports reverse-proxied sites.
Inside Consent Pro’s configurator, you can access the domain editor, and you should now see three fields available: the first one will have the staging domain, the second will have the Webflow custom domain and the third will allow for a custom domain.
Once you’ve added the domain, a fresh scan will be triggered. After this, you should be able to see the information from this domain land in the Consent Logs tab.
Also, it’s important to note that the User Agent is a browser-shaped string like:
Mozilla/5.0 (Macintosh; Intel Mac OS X 10_15_7) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/120.0.0.0 Safari/537.36 ConsentProScanner
The agent string may change, but it will always contain ConsentProScanner. So the WAF rule should look for ConsentProScanner in the string instead of trying to match it.
Can you please try this and let us know if it resolves the issue?
