Squarespace is one of the few website builders that ships a built-in cookie consent banner as a native feature rather than something you bolt on with a third-party script. That's genuinely useful, but it solves the consent-collection problem, not the disclosure problem. Turning the banner on doesn't generate a cookie policy, and the banner's own categories don't automatically cover every cookie a Squarespace site actually sets. Here's what's happening under the hood and what still needs writing by hand.
The cookies Squarespace sets on every site
Independent of anything you configure, Squarespace's platform itself drops a handful of cookies on every site built on it:
crumb: a session cookie that expires when the browser closes, used to prevent cross-site request forgery (CSRF) attacks on forms and checkout. This is a strictly necessary cookie; it can't be disabled without breaking core site functionality.SS_MID: a performance cookie that assigns a unique identifier to a visitor, used to support Squarespace's own analytics.ss_cvr: identifies unique visitors and tracks sessions for Squarespace Analytics, with a roughly two-year expiration.ss_cvt: a shorter-lived companion cookie for the same visitor-tracking purpose, expiring after about 30 minutes.SS_cookieAllowed: records the visitor's cookie banner choice itself, so the banner doesn't reappear on every page load, expiring after about 30 days.
Notice that the consent-tracking cookie is itself a cookie. That's normal (most consent management setups work this way) but it means even a fully "reject all" visitor still has one cookie set, which your cookie policy should explain rather than leave as an apparent contradiction.
The built-in Cookie Banner feature
Squarespace's native cookie banner, available on 7.1 sites, sorts cookies into three categories: Necessary (always on, can't be disabled, covers things like crumb), Performance and Analytics (covers Squarespace Analytics and, if connected, Google Analytics), and Advertising (covers whatever third-party ad or retargeting integrations you've connected, such as a Meta Pixel or Google Ads tag).
Site owners choose a banner style. In the "Opt In and Out" style, a "Disable Analytics Cookies" toggle defaults to on, meaning non-essential Squarespace Analytics and Google Analytics cookies don't fire until a visitor actively accepts, which is the opt-in behavior GDPR and the ePrivacy Directive expect. Owners can also choose which buttons appear: a "Decline all" button for a one-click rejection, and a "Manage cookies" button that lets visitors set preferences at a more granular category level.
Squarespace cookie banner categories
| Covers | Default state | |
|---|---|---|
| Necessary | crumb, checkout functionality | Always on, not toggleable |
| Performance and Analytics | Squarespace + Google Analytics | Blocked until visitor accepts |
| Advertising | Connected pixels/retargeting | Blocked until visitor accepts |
What the banner does not cover
This is the part that trips up most Squarespace site owners: the built-in banner categorizes Squarespace's own analytics and whatever ad pixel you've formally connected through Squarespace's own integration settings. It does not automatically discover or categorize cookies set by things embedded into your page content, which on a typical Squarespace site is a longer list than people expect:
- Embedded third-party content. A YouTube video block, an Instagram feed embed, a Calendly scheduling embed, or a Typeform survey all load their own scripts and can set their own cookies the moment the page renders, independent of the Squarespace banner's category toggles.
- Installed apps and extensions. Review widgets, abandoned-cart recovery tools, live chat plugins, and similar third-party apps connected to a Squarespace store or site typically bring their own tracking, which needs to be identified and disclosed separately.
- Anything loaded before consent. If an embed isn't wired into Squarespace's consent-aware loading, it can fire before the visitor makes a choice at all, which is the exact scenario GDPR's opt-in requirement is meant to prevent.
Version matters: 7.1 vs older 7.0 sites
The native Cookie Banner feature described above is a Squarespace 7.1 feature. Sites still running on the older Squarespace 7.0 platform, which Squarespace no longer sells to new customers but still hosts for existing sites, don't have this built-in banner at all, and need a third-party consent management plugin injected through Squarespace's code injection settings to get equivalent opt-in behavior. If you're not sure which version your site runs on, the presence (or absence) of a "Cookie Banner" option under your site's settings is a reliable tell: 7.1 sites have it as a native panel, 7.0 sites don't, and a 7.0 site with no third-party banner installed is very likely running with zero cookie consent mechanism at all, regardless of what its cookie policy document claims.
Commerce sites carry an extra layer
A Squarespace Commerce store sets additional cookies beyond the base analytics set: cart-session cookies that remember items added before checkout, and checkout-flow cookies that carry a customer through payment without losing their order. These generally qualify as strictly necessary, the same way crumb does, since checkout functionally breaks without them, but they're still worth naming individually in a cookie policy rather than folded silently into "necessary cookies" as an unexamined category. A visitor who reads "necessary cookies keep the site working" reasonably wants to know what that actually means for a store handling their payment details.
The banner doesn't handle US opt-out signals either
Squarespace's cookie banner is built around the EU/UK opt-in model, accept or decline before analytics and advertising cookies fire. It doesn't automatically detect or honor California's Global Privacy Control (GPC) signal, the browser-level "don't sell my data" setting the CPRA requires covered businesses to treat as a valid opt-out request. A Squarespace site with meaningful California traffic and a CCPA obligation needs a manual plan for GPC, typically a small script that checks for the signal and adjusts tracking accordingly, since the built-in banner's opt-in flow doesn't substitute for an opt-out mechanism the law specifically names.
Writing the actual cookie policy
The banner UI is a consent mechanism, not a document. Squarespace doesn't generate a written cookie policy page for you, and a compliant one needs to list, by name, every cookie category in play: Squarespace's own necessary and analytics cookies, any connected advertising pixel, and every embed or app you've added that sets its own cookies. It should also state plainly what happens when a visitor declines (which categories stop firing) and roughly how long each cookie persists, since "session" versus "two years" is a meaningful difference to disclose, not a technical detail to skip.
Our Cookie Policy Generator builds this document with Squarespace's own cookie set already accounted for, plus fields for the embeds, apps, and ad pixels specific to your site, so the finished policy actually matches what your banner is (and isn't) blocking. Pair it with our Privacy Policy Generator to cover the rest of what a Squarespace site collects beyond cookies, form submissions, account data, and checkout information if you're running Squarespace Commerce.
For the implementation side of a consent banner outside Squarespace's built-in one, see our guide on adding a cookie banner to a Next.js site, and for the platform-adjacent question of whether a banner is required at all when a site sets no cookies of its own, see do you need a cookie banner if you don't use cookies.
The information in this article is for informational purposes only and should not be construed as legal advice on any matter, and does not create a lawyer-client relationship.
