Squarespace includes a cookie banner out of the box, which leads a lot of owners to assume they're covered. For a simple brochure site that only uses Squarespace Analytics, they might be. But the native banner has real limits, and if you have added Google Analytics, a Meta Pixel, or marketing embeds, those gaps can put you offside of the GDPR and ePrivacy rules.

What the native Squarespace banner does

You enable it under Settings › Cookies & data privacy (labelled Cookie banner). You can toggle it on for all visitors or only in the EEA and UK, choose which buttons appear (including a Decline all and a Manage cookies button) and customize the disclaimer text and button labels. Squarespace explains the options in its cookie banner help article.

That's a genuine improvement over having no banner: it presents a clear accept/decline choice and, for Squarespace's own cookies, honours it.

Where the native banner falls short

Squarespace itself is candid that the built-in notice is a starting point, not a full compliance solution. The gaps that matter under GDPR:

No prior blocking of non-essential scripts. If you added Google Analytics or a pixel through Analytics › External API keys or Code Injection, they generally load regardless of the banner choice. GDPR requires consent before non-essential cookies are set.
No granular categories. Visitors get accept/decline, not per-purpose control (analytics vs marketing vs preferences).
No consent audit log. There's no exportable, timestamped record of who consented to what: the proof-of-consent regulators ask for.
Limited third-party vendor disclosure. The banner doesn't enumerate the third parties that may set cookies.

Squarespace's own GDPR help page points owners toward additional measures for exactly these reasons.

Adding a real CMP with Code Injection

To block non-essential scripts before consent, keep an audit log, and offer granular choices, add a consent management platform. On Squarespace that goes in via Code Injection, a premium feature on the Business and Commerce plans. Go to Settings › Advanced › Code Injection and paste the CMP loader at the top of the Header box so it runs before your other tags:

<!-- Settings > Advanced > Code Injection > Header (first line) -->
<script async src="https://cdn.cookiebeam.com/banner/YOUR_BANNER_ID/default/loader.js"></script>

Then route Google Analytics and any marketing tags through the CMP (or through GTM that the CMP controls) instead of Squarespace's native analytics key field, so a single consent gate governs everything. Note that Squarespace support doesn't troubleshoot custom code, so test carefully yourself.

Consent Mode v2 for Google tags

If you run Google Ads or GA4, set Consent Mode v2 defaults to denied in the Header injection, then let the CMP send the update on acceptance. Consent Mode v2 has been required for EEA and UK traffic since March 2024, and Google's consent APIs documentation covers the signal names. A CMP like CookieBeam wires this update automatically once installed.

What Squarespace itself sets

Even a bare Squarespace site sets cookies. Strictly necessary ones keep the site working: security, session, and on Commerce plans the shopping cart. Squarespace Analytics adds its own first-party analytics cookies, and if you connect Google Analytics or Google Ads through the built-in fields, those third-party cookies become your responsibility to gate. Squarespace itemizes what it uses in its cookies reference. The practical takeaway: "strictly necessary" is a narrow category, so most analytics cookies and all marketing cookies need consent first, and the native banner doesn't enforce that for third-party tags.

Route analytics through the gate, not the native field

Squarespace lets you paste a Google Analytics measurement ID or connect Google Ads directly in its settings. The catch is that those native connections fire independently of the cookie banner, so the tag loads before the visitor chooses. Once you add a CMP, remove the ID from Squarespace's native field and load Google tags only through the CMP (or a GTM container the CMP controls). Then a single decision governs whether GA4, Google Ads, and any pixel may run, and "Decline all" genuinely means nothing non-essential loads, which is the behavior the SHEIN and Sephora cases show regulators actually test for.

Keep proof you can show

If a data protection authority or an individual asks, you may have to demonstrate that a specific visitor consented, to what, and when. Squarespace's native banner keeps no such record. A CMP logs each decision with a timestamp and the consent string, the evidence regulators expect, covered in proof of consent documentation. For a low-traffic personal site that may be more than you need; for anything commercial it's the difference between a defensible position and a shrug.

Native banner or CMP: how to decide

Use the native banner alone only if your site sets no non-essential cookies beyond Squarespace's own and you serve a low-risk audience. Add a CMP the moment you introduce Google Analytics, advertising pixels, embedded video, chat widgets, or any tool that tracks, or if you need documented proof of consent. When in doubt, the safer and audit-ready choice is a CMP.

Two more triggers push you firmly toward a CMP. If you target visitors across several countries, you likely need geo-specific behavior (opt-in in the EEA and UK, opt-out in US states) which the native single accept/decline banner can't vary. And if your site runs on the Personal plan, remember Code Injection is unavailable there, so a script-based CMP requires at least the Business plan.

Not sure whether you need a banner at all? Start with Do I need a cookie banner? and then run the GDPR cookie compliance checklist.