Google Consent Mode on Squarespace: what the platform gives you and what it does not

All posts

Squarespace's native banner blocks its own and Google's analytics cookies until a visitor accepts, but it does not emit Consent Mode signals on its own. Google documents a code injection block that declares denied defaults and then reads the banner's choice through a Squarespace helper. That route needs a plan that includes code injection.

What the native banner actually does

It is worth starting with credit, because the native banner is not a token feature. Squarespace ships one under Website tools, and with the opt in and out style it genuinely holds cookies back: Google's own setup page states that the disable analytics cookies toggle stays on, which stops non essential Squarespace Analytics and Google Analytics cookies dropping until the visitor accepts. That is more than several hosted platforms give you without a plugin.

The limit is not the blocking, it is what the banner tells Google. Holding a cookie back and declaring a consent state are different jobs, and the native banner only does the first.

The two signals that go missing

Consent Mode v2 added ad_user_data and ad_personalization on top of the older ad_storage and analytics_storage. Those two are what Google Ads reads when deciding whether a denied visit can still contribute to modelled conversions. The difference is in what each of the two controls, and the wider picture in Consent Mode v2 in plain English.

Google's Squarespace instructions handle the gap with a code injection step, and the detail worth getting right is that its default block denies three signals rather than all four: ad_storage, ad_user_data and ad_personalization. analytics_storage is not in it, because the native banner is already holding the analytics cookies back. That step is easy to skip, because the page reads as though the banner setup was the main event and the injection is a footnote for advertisers. It is the other way round. Without it the site is not sending a denied signal, it is sending no signal, and an absent signal and a denied one are read differently at the other end.

The part most summaries miss is that the injected code does not replace the banner. Squarespace exposes a helper, window.getSquarespaceCookies, and Google's snippet calls it to read what the visitor chose, then issues the consent update from that. The banner stays the place the choice is made; the injection is the translation layer. That is why running a second banner on top creates a conflict rather than a backup.

Getting it working, in order

1. Check the plan before anything else

   Squarespace's own documentation puts code injection on the Core, Plus and Advanced plans and some legacy billing plans. Every set of instructions on the open web, including Google's, assumes you can reach Settings, then Advanced, then Code Injection. Below that tier the route does not exist, which makes this a billing question rather than a configuration one. Check the plan name in billing rather than going by an older guide, because the tiers have been renamed.

2. Put the denied defaults at the very top of the header box

   Consent Mode works by declaring a denied state before any measurement tag loads, then updating it when the visitor chooses, so the defaults block goes at the top of the header injection box. Google's Squarespace snippet denies ad_storage, ad_user_data and ad_personalization, leaving analytics_storage to the native banner. Get the order wrong and the tags load granted for the few hundred milliseconds that matter.

3. Install the consent tool above your tag manager, in the same box

   The header injection box is one plain text area, so the order you paste things in is the load order the browser sees. The consent platform goes above the tag manager snippet.

4. Turn the native banner off if you are running a consent platform

   Two banners means two records of what the visitor chose, and they will disagree. Pick one: if the site needs Consent Mode v2 for advertising, the platform survives and the native banner goes off in Website tools.

5. Verify on the published page, because there is no preview

   Squarespace has no staging view for injected code. Save is publish, which makes the verification below part of the install rather than an afterthought, and a reason to do this outside your busiest hours.

Four things the platform does not give you

These are the ones that cost time on audits, and none of them appears in the official instructions.

There is no preview for injected code. Squarespace applies these changes on save, with no staging view or draft state for the box, so the first time your consent defaults run is the first time a real visitor loads the page. Plan the change accordingly and verify immediately.

Member areas do not receive site wide custom code by default. Those pages are served through a different path, so injected code does not reach them unless the scope includes them. The site then looks correctly gated everywhere you check, with no consent layer where visitors are signed in.

The site version changes the answer. Older 7.0 sites handle code injection differently enough that instructions written for one version can fail silently on the other, so establish which one you are on first. Version also decides the navigation question: on 7.0 sites with Ajax loading enabled, and on certain templates, moving between pages does not reload the document, which suppresses the page view refires a tag manager expects. It is not universal, so check rather than assume. Where it applies, a history change trigger catches the transitions.

The mistake we see most

Squarespace offers code injection per page as well as site wide, and the per page box is the one people find first while working on the page that needs fixing. A consent platform installed there loads on that page and nowhere else, and it reports itself as working, because it is, on the one page it exists on. Both belong in the site wide box under Settings. It is among the most common errors we find on Squarespace audits, and it is invisible unless you check a second page.

Checking that it holds

Because there is no preview, verification happens on the live page and it happens twice. Load the site in a clean profile, decline everything, then check that the gated tags are absent from the page and from the browser's resource timing entries. Repeat with consent granted and confirm they appear. A setup that blocks in both directions is a broken tag rather than a compliant one. The tag manager side is in installing a cookie banner through Google Tag Manager.

Squarespace gives you one honest banner and one place to put code. What it does not give you is the signalling layer on top, which is the part Velo is built to carry.