Cookie consent is a different problem, and it is filed here

The obligation people mean when they say "cookie law" in Europe comes from the ePrivacy Directive, 2002/58/EC, as amended by 2009/136/EC. Its shape is simple and frequently misread: storing information on, or gaining access to information already stored on, a user's terminal equipment requires prior consent, unless it is strictly necessary to provide a service the user has explicitly requested.

Two words in there do most of the work.

Prior. Consent comes before the storage, not alongside it. A banner that appears while analytics has already fired has not obtained prior consent; it has announced a decision that was already made.

Strictly necessary. This is narrower than people want it to be. A login session, a shopping cart, a language preference the user chose — those are the shape of it. Analytics is not strictly necessary for delivering a page, which is why measurement scripts sit on the consent side of the line for the visitors this applies to.

What counts as consent is defined elsewhere, in GDPR Article 4(11): freely given, specific, informed and unambiguous, expressed by a statement or a clear affirmative action. A pre-ticked box is not a clear affirmative action. Neither is continuing to scroll.

Wix does not ship its own consent engine. It ships somebody else's, properly integrated: since June 2024 Wix's consent solution has been provided through a partnership with Usercentrics, available from the Wix App Market and surfaced inside Wix's own privacy settings.

Structurally this is the better arrangement, and it is worth understanding why. A consent management platform is a specialist product with a moving target — scanning a site for what it actually sets, maintaining a categorised cookie declaration, keeping a record of who consented to what and when, and emitting signals that downstream tag systems respect. A website builder that tried to maintain all of that as a side feature would do it badly. Wix decided not to try.

If you are on Wix and you need more than a notice, that route is Usercentrics, and CookieYes is the other integration people in this lane commonly reach for.

Squarespace has a native cookie banner. You can configure it to offer accept, decline, and a manage option, and it can restrict non-essential cookies from Squarespace itself and from some third-party integrations until a visitor accepts.

The honest reading is that this is a notice with some teeth, rather than a consent management platform. Squarespace's own documentation says the quiet part directly:

Cookie notice requirements vary depending on your location and cookie use. While we provide sample text you can use, you shouldn't assume that it satisfies your particular legal requirements.

Where the built-in banner tends to run out is at the edges a regulator looks at: granular per-purpose categories rather than one switch, a cookie declaration that stays current as you add integrations, geographic targeting so the right visitors see the right thing, and a retrievable record of consent. If you need those, you are adding a third-party platform via code injection regardless of the built-in banner.

Shopify's approach is the one most likely to be described as "Shopify doesn't have a cookie banner", and that description misses the point. Shopify's primary contribution is the Customer Privacy API — a browser-side JavaScript interface that records consent across four purposes: preferences, analytics, marketing and sale of data — alongside a bundled cookie banner asset that can be enabled.

The API is the interesting half. Because Shopify's own pixel handling checks those recorded signals, a marketing pixel that has not been granted marketing consent does not fire. That is the difference between a banner that displays a choice and a system that enforces one, and it is the thing most bolt-on banners on most platforms never achieve.

Shopify's documentation is also clear about where the merchant stands: consent should be recorded on a visitor interaction rather than assumed, and merchants are pointed at legal counsel rather than reassured.

WordPress.com has no native consent engine in the sense the others do; consent is handled by plugins, and the quality range in that ecosystem is enormous. The failure mode is specific and worth naming, because it is the most common defect in the whole category.

A plugin that renders a banner but does not stop scripts from executing is decoration. Analytics still fires on page load, the pixel still calls home, and the banner records a preference that nothing acts on. If you take one thing from this page: test your banner by declining, then look at what your browser actually loaded. Open the network panel, refuse everything, reload, and see whether the measurement scripts are still there. A large number of banners fail that test, including expensive ones.

Having spent this page separating them, there is one real intersection, and it is the one nobody tests.

Your consent banner is a modal that appears before anything else on the page, which makes it the first thing a keyboard user meets. So: can it be dismissed with a keyboard alone? Does focus move into it when it appears, and go somewhere sensible when it closes? Is the reject control an actual button, reachable by tab, rather than a low-contrast line of text styled to look discouraging? Do its own colours clear 4.5:1 for body text under SC 1.4.3, given that banners are routinely the greyest element on a site?

A consent banner that cannot be operated without a mouse is a device that prevents disabled visitors from reaching your site at all, while a compliance dashboard somewhere reports it as working. It is worth five minutes with the keyboard test pointed at your own banner.

1. Find out what your site actually sets. Most people are wrong about this, usually because an embed brought something with it.
2. Decide whether you need consent at all. A site with no analytics and no advertising pixels may have very little to ask about, and a cookieless measurement tool removes the question rather than answering it.
3. If you need a banner, make it enforce rather than announce. Declining has to prevent the script from running.
4. Test the banner with a keyboard. See above.
5. Keep the cookie declaration current. Every new embed is a new entry.
6. Ask a lawyer about your obligation, which depends on where your visitors are and what you are doing with the data — and which is not a question this page can answer for you.