One thing I would really love to see improved in Sitely is the whole privacy / consent handling situation. At the moment it feels a bit limited, especially for European websites and DSGVO requirements.
It would be great to have more built-in options directly inside Sitely, without having to rely on external third-party consent tools for relatively standard use cases.
That said, I’m still a huge Sitely fan and use it for many projects. It’s honestly one of my favourite pieces of software.
What do you find is missing?
At the moment, it seems that scripts placed in the page head are not controlled by Sitely’s privacy settings. For GDPR-compliant integration, this currently requires external consent tools or workarounds using embed blocks.
It would be great to have an integrated way to:
add external scripts,
assign them to consent categories,
load scripts only after user consent,
and allow more flexibility in styling the consent banner.
I’m still a big Sitely fan, but I believe this would be a very valuable improvement, especially for European users.
What scripts are you adding to the page head specifically? Generally their need to be placed in the page head is not a technical requirement.
What sort of flexibility is missing in designing the cookie banner?
I understand that scripts do not technically need to live in the page head. The actual issue is more about GDPR-compliant handling of certain analytics and visitor-tracking tools.
Some of these tools are designed to load globally and as early as possible. In practice, many users place them in the page head because that is exactly how the providers document the integration.
The problem is that once a script is added there, Sitely’s current privacy system cannot really control it. If a visitor declines tracking consent, the script may already be active unless external consent tools or custom workarounds are used.
Especially for European projects, and particularly in B2B environments, this becomes difficult because website owners need a reliable way to:
block scripts before consent,
load them only after consent,
and manage everything centrally inside the website builder.
Regarding the banner itself, the current solution is absolutely fine in principle because it is clean and simple. I just miss a bit more flexibility in layout and behavior — for example more control over positioning, styling, categories, and conditional script execution.
I also do not really like the current checkbox design. Toggle switches or additional layout options would feel more modern and flexible.
And that’s part of why we don’t include the tools to add content to the page head in the base product, but you need to buy the developer tools. You need to understand what you’re doing from a technical and compliance point of view.
The analytics tools these days should have a cookieless mode, e.g. consent mode 2 in google analytics. That’s GDPR compliant because google has many lobbyists and because they state they don’t track anything personal until the user consents. And Sitely supports this google analytics and tag manager.
That said integrating third party cookie banners is tricky, they generally are all a little different and Sitely is more advanced than mosts CMSs in how it blocks third party content and unblocks it as needed.
What scripts other than analytics/visitor tracking are you thinking of?
The “load as soon as possible” for something like say hotjar (heatmaps) is solved by either:
About the cookie banner:
Checkbox design is a separate issue and I agree we need to improve that.
My main concern is less about where scripts are placed, but about being able to reliably control when they are executed. Especially with B2B tracking tools, it’s important that they are only loaded after explicit user consent.
As I understand it, the most practical approach in Sitely right now is:
– integrating via Google Tag Manager
– and triggering scripts only after a consent event
Is that correct?
Regarding the cookie banner:
The approach with a transparent background and a freely positioned content box is a nice idea — I’ll definitely try that in my next project.
Where I still see some limitations is:
– clearly defining consent categories (e.g. analytics vs. marketing)
– and centrally controlling script execution depending on consent
For European B2B projects, this is quite an important aspect.
And honestly, this whole data protection topic is a pain for everyone involved — which makes it even more valuable if Sitely could handle more of this natively within the system.
Overall, I really enjoy working with Sitely and appreciate how lightweight it is — it would just be great to have a bit more built-in flexibility here without relying on external tools.
The categories are essentially pre-defined and uniform across all cookie banner providers, in my opinion they’re already overspecified, what would you want to further define?
Could you clarify what “central control” of script execution would look like? Right now Sitely implements a straightforward mechanism (and logical interpretation) where if a component requires analytics and marketing cookies, it will be unblocked only if the user consented to both analytics and marketing cookies.
What is inadeguate about this? What further nuance is required? Sorry but I’m not seeing it.
One additional point is that some of these tools explicitly require this kind of integration.
Their documentation typically recommends:
loading the script globally,
as early as possible (often in the page head),
and not delaying execution.
This creates a real conflict:
On one side, the technical requirements of the tool (early, global loading),
on the other side, GDPR requirements (no loading before consent).
That’s exactly where the practical problem comes from.
If I follow the provider’s integration guidelines, I lose control over when the script runs. If I want to stay GDPR-compliant, I have to “rebuild” the integration (for example by injecting the script after consent or using external consent tools).
So the issue is not that Sitely is doing something wrong — it’s that there is currently no way to properly integrate these kinds of scripts into a consent-controlled flow without workarounds.
And that’s what I mean by “central control”:
Being able to integrate even those scripts that are designed to load globally, but still control them within Sitely in a GDPR-compliant way — without needing custom solutions.
Clearly the analytics tools will do what they need to do to get you to use the tool as they want it. The real world doesn’t really allow that, not in Europe with GDPR, and other jurisdictions as well.
So loading globally is fine, of course. In the case of the embed, make it visible on all pages. Tag manager would already be global.
As early as possible generally means not before the </body> close, which is where scripts were traditionally placed by web developers, in order to not slow down delivery of the page and be penalized for slow page loading. Putting it just after the <body> open is mostly equivalent to putting it in the <head>, it’s probably milliseconds apart in most cases, and that can be done with the embed element. Tag manger is certainly going to be slower, as it itself has to load before injecting additional scripts in the page.
Delaying the execution is clearly also going to be inevitable in the case of lack of consent.
There’s only a conflict if you believe those are requirements. The script builders want their product to shine, not your client to not be sued.
I don’t think using the embed is a “workaround” or a custom solution in any way. It’s mainly for visual content, but it works fine for non-visual code integration, and correctly respects the user preference.
But I hear your request for consent-gated script loading in the page head. Loud and clear 
Also all the discussion over cookie categories and granular consent and details about what the individual cookie flavors do or how individual third parties handle your data (they sell it duh) is frankly overkill. I don’t think anybody who can avoid it ever clicks “agree” for any reason. Why would you not deny third party cookies?
