Localised pages don’t work - elements un-clickable - when the Consent Pro script is installed.
My client is currently traveling in the US and noticed that all clickable elements on localised pages were not able to be clicked. The sites primary locale is Turkish. When they switch to EN (the only other locale), nothing can be clicked… menu items, buttons, links.. nothing.
Site URL
Required: Please provide a staging/production URL where we can see the issue
I’ve removed the Consent Pro site settings script for now as we can’t have the site not working.
Video/Screenshots
Required: Please provide a short screen recording showing the issue
Appreciate your help as we’ve had to disable Consent Pro till the issue is resolved.
Best regards,
Mustafa
NDA Notice: If you’re under an NDA, please feel free to send us a Direct Message/Email with the above information.
Hey @Rock_n_Roll_CEO!
Good debugging on your end — the fact that removing the Consent Pro script immediately resolved the click-blocking confirms the script is the source of the problem, which makes this a lot easier to narrow down.
A couple of things worth flagging while we dig in:
The consent preferences panel includes a full-page overlay element with fs-consent-element=“close” that sits over the entire page and is designed to close the panel when a user clicks outside it. If that overlay isn’t being properly hidden — meaning it stays visible with pointer events active — it would block every click on the page, which matches exactly what you’re describing. That’s our leading candidate right now.
We also noticed your HTML includes both a consent_opt-in and a consent_opt-out structure on the same page simultaneously, each with their own preferences panel and overlay. Worth confirming whether that’s the intended setup or something that could be contributing to the conflict.
One hypothesis we want to verify: Webflow’s Per Page CSS feature may be stripping the styles that control how that overlay is hidden on localized/secondary locale pages. This would cause the overlay to stay active across the full page on your EN locale, blocking all interaction. We’ve seen Per Page CSS cause issues with dynamically injected consent elements on non-primary pages before — but we want to confirm before drawing any conclusions.
To help us nail this down, could you temporarily re-enable the Consent Pro script on your staging site, navigate to a localized English page where the issue occurs, and share the URL? 
If you can also open DevTools → Elements, find the consent_prefs_overlay div (look for fs-consent-element=“close”) and check what styles are applied when the issue is active, that would be really helpful.
We’re flagging this to the team as well — the Consent Pro engineers should take a look at this edge case.
Hi guys, thanks for the reply.
per page css is not switched on.
I have added the script back and published it on the staging site. Here’s a url: FL PR & Communications: Leading PR Agency for Brand Growth
And here’s a sharelink again: Webflow - FL PR and Communications**
consent_opt-in** and a consent_opt-out were intentional and set differently for different o-locales.. or have we made a mistake there?
Hey @Rock_n_Roll_CEO
Thanks for the published url, this has been passed over to the team, will keep you posted!
Hey @Rock_n_Roll_CEO
Unfortunately the dev team couldn’t finalize their troubleshoot as the consent pro script is off the site, which is understandable if y’all need to make further updates
Will have to work a way to have the script on a test site if possible
Keep me updated, thanks
Hi Jesse, I’ve re-added the script to the staging domain I provided. Would the team be able to look again please?
Best regards,
Thanks @Rock_n_Roll_CEO
The team is back on it!
Hi Jesse, any news on this please…
Hello @Rock_n_Roll_CEO The issue affecting your configuration is a custom style that overrides the Consent Pro preferences show/hide styles.
Please check this recording to see the explanation and behaviour: ** Fix Localization Style Overlay on Preferences | Loom**
You can remove this custom style and let Consent Pro handle your preferences elements rendering logic.
.consent_opt-out_prefs:lang(en-us) {
display: flex;
}
Please let us know how it goes 
Hey Robert, thanks so much for the reply. Will try the fix and let you know.
Warmest regards,
Mustafa
Hi Robert,
This is to confirm the fix worked. Thanks so much.!
Warmest regards,
Mustafa
Hi Robert,
One additional question. Just wondering, do we know why this issue was only occurring when US-EN (the secondary locale) was selected when in the US? Because it obviously didn’t happen when the locale was selected here in Türkiye on the LIVE site.
And was it an issue unique to being in the US? i.e. would it also have happened in any other jurisdictions, are you able to tell?
Thanks so much again.
Hey Mustafa,
The issue occured only when us-en was selected cause there was a stray, English-only override :lang(en-us) re-asserting display:flex on the .consent_opt-out_prefs as @robert.kibet pointed out
It was the only locale-specific override targeting the consent system & could most likely be an artifact of someone in the Webflow designer unintentionally editing the display styles of .consent_opt-out_prefs while the English locale was selected
This can happen since Webflow auto-scopes style edits made under a secondary locale to a :lang() override in its stylesheet
The change could’ve gone quite easily gone unnoticed considering the main locale,Türkiye remained unaffected
Glad it’s now resolved!
