Description:
The Opt-Out Banner instance’s config is not updating on publish. I’ve toggled “Disable Scroll” off (and back on again to test) in the Configurator and clicked “Update Banner” each time, but the live site’s config never changes — disableScroll stays stuck at true, which is locking page scroll for all visitors (US/Global region) until they interact with the cookie banner.
Site URL: https://www.securitymetrics.com
Webflow site: sm-marketing-site (staging: marketing-webflow.securitymetrics.com)
Affected instance: “Opt Out Banner” (Global region)
Steps to Reproduce:
- Open Consent Pro app > Banners tab
- Edit the “Opt Out Banner” instance
- Toggle “Disable Scroll” (tried both off and on)
- Click “Update Banner”
- On the live site, check window.FinsweetConsentPro.config.instances[‘opt-out’]
Expected Behavior:
After clicking “Update Banner,” the live/published config for that instance should reflect the new disableScroll value, and instance.metadata.lastupdate should advance.
Actual Behavior:
disableScroll remains true on the live site regardless of what’s set in the editor. instance.metadata.lastupdate is stuck at 2026-05-27T20:39:40.670Z and has not changed across multiple save attempts. Meanwhile the sibling “Opt In Banner” (EU) instance publishes fine and has a more recent lastupdate/repairedAt timestamp.
Happy to share screen-recordings or Webflow read-only link if helpful.
NDA Notice: If you’re under an NDA, please feel free to send us a Direct Message/Email with the above information.
Hey @erica.cuell
Could you try again, the config shows live & recent
opt-out now shows:
"disableScroll": true, "lastupdate": "2026-07-30T17:12:25.561Z", "createdAt": "2026-07-21T15:41:45.267Z"
The lastupdate is yesterday, not 2026-05-27T20:39:40.670Z
It might have started working again & a recent Update Banner click did actually successfully save
Please confirm on your end
Thanks
Could you also share an actual staging link with a .webflow.io
http://marketing-webflow.securitymetrics.com/ is just a sub-domain of prod
Hey @erica.cuell!
Your diagnosis is spot-on — the HTML looks correct (v2 attributes properly applied, both opt-in and opt-out instances present), so this isn’t an implementation issue. The behavior you’re seeing — metadata.lastupdate stuck while your sibling opt-in instance publishes fine — strongly suggests an app-side sync issue with this specific opt-out instance.
We’ve seen similar Consent Pro bugs where instance updates weren’t persisting correctly, and the fix typically involved regenerating the affected instance. Worth trying before we escalate.
Here’s the workaround:
- Note your current settings (if you have custom tracker categorizations, jot those down for reference)
- Delete the Opt Out Banner instance in the Configurator
- Republish the site
- Recreate the Opt Out banner with your desired settings, including the Disable Scroll toggle
- Click Update Banner and republish
This has resolved similar instance-level issues in previous cases, so it’s a solid first step.
If that doesn’t work — or you’d rather skip straight to a deeper look — we can loop in the team to investigate your instance state directly. Your diagnostic evidence is really helpful here. The frozen metadata.lastupdate timestamp combined with the working sibling instance does a great job isolating the problem.
Let us know how the regeneration goes, or just say the word if you want us to escalate right away 
Hi Jesse, Support-Finn,
I went ahead and tried the regeneration workaround — deleted the Opt-Out Banner instance, republished, recreated it, clicked Update Banner, and republished again.
After all that, the live config still shows the exact same frozen timestamp: lastupdate: “2026-05-27T20:39:40.670Z” — unchanged, byte-for-byte identical to before the regeneration. Hard-refreshed and pulled window.fs_consent_pro_config.instances[‘opt-out’] directly to rule out caching on my end.
One more thing I noticed comparing instances: our opt-in instance’s metadata has a repairedAt field (“repairedAt”: “2026-06-02T23:05:43.506Z”) that opt-out doesn’t have at all. Looks like opt-in already went through whatever repair process fixes this exact kind of sync issue, back in June — opt-out never has.
Also, here’s the staging link you asked for: https://sm-marketing-site.webflow.io
Given the regeneration didn’t change anything on our end, can you run that same repair against our opt-out instance? I’d like to skip further workarounds on my side at this point and get this in front of the team that handles it directly.
Thanks,
Erica
Hi Erica,
I’ve escalated this to the team & will keep you updated with their feedback
Thanks
Hi Erica,
This is what ConsentPro devs had to say
I can confirm I also see disableScrollBehavior: "banner-or-preferences" on their site securitymetrics.com, lemme check when their last webhook for publish action was fired
Also to confirm I can see their EU disable scroll is false and Global disable scroll is true, so based on this US will get disabled scroll behaviour enabled until they disable that feature for their opt out banner
It’s working fine on my end. Also I can see their webhooks are firing correctly so the configurations should be synced to their live site correctly.
This is the expected behavior:
• The Disable Scroll setting should be independent for each banner type.
• You should be able to:
- Enable Disable Scroll for Opt-in and disable it for Opt-out.
- Enable it for both banner types.
- Disable it for both banner types.
• Changing the setting for one banner type should not affect the other.
Confirm with them, they need to disable, save changes and publish for their opt out setup
Hi Jesse,
Thanks for confirming the current state — but to be clear, disabling Disable Scroll for the Opt-Out/Global instance and publishing is exactly what I’ve already done, multiple times:
- Toggled disableScroll off in the Configurator, clicked Update Banner, republished the site.
- Deleted the Opt-Out instance entirely, republished, recreated it, updated, republished again.
After both attempts, the live config still shows disableScroll: true. I verified this directly via window.fs_consent_pro_config.instances[‘opt-out’] on the live page with a hard refresh and cache-busting param, so this isn’t a caching artifact on my end.
So “webhooks are firing correctly” doesn’t match what I’m seeing for this specific instance — can your team check whether a webhook actually fired for the opt-out instance at the timestamps of my two save/regenerate attempts, rather than confirming webhooks are firing in general? If nothing fired for those specific events, that’s the bug.
Happy to jump on a call or share screen recordings of both regeneration attempts if that helps move this along.
Thanks,
Erica
Ok noted @erica.cuell
I’ve forwarded all this, thanks
Hey @erica.cuell
Turns out prod is not in the publish event list of domains
The logs confirm that the recent publish event was done for marketing-webflow.securitymetrics.com
So it seems theres a proxy in use
marketing-webflow.securitymetrics.com -- PROXIED TO --> securitymetrics.com
Webflow publishes updates to marketing-webflow.securitymetrics.com correctly, but the live site runs on www.securitymetrics.com, which has no configs of its own
So the CDN falls back to the raw configurator.json and caches that
The cached copy is never purged, since publish only purges hostnames named in the publish event
We’ve cleared the cache for now & it’s loading fine on the site
The issue should now be resolved
If you happen to update the configs later on, make sure to hit us up so we can manually clear the cache
A proper solution for reverse proxies is in the works though & you can follow it up here
