Webflow markets itself as a design tool first, which is exactly why its cookie footprint gets overlooked. There's no plugin list to scroll through the way there is on WordPress, and no App Market notification badge nagging you to review permissions the way Wix's does. What a Webflow site actually sets comes from three quieter places instead: Webflow's own built-in features (Analyze, Optimize, Ecommerce, forms), whatever you've pasted into the Custom Code panel, and whatever a CMS-driven embed pulls in on a given page. A cookie policy copied from a generic template describes none of that, because none of it is visible from the outside.
Here's what a Webflow site actually sets, where the rest comes from, and where the finished policy needs to be linked so it's not just a page nobody can find.
The cookies Webflow's own features set
A published Webflow site doesn't set much on its own if you're only using the visual designer and a static page, but the moment you turn on one of Webflow's built-in growth or commerce features, that changes. A few worth naming specifically:
- Webflow Analyze, Webflow's own first-party site analytics add-on, sets a cookie to track visits and behavior across your pages, similar in purpose to Google Analytics but running as a first-party Webflow feature rather than a third-party script you added yourself.
- Webflow Optimize, the platform's built-in A/B testing tool, sets a cookie that keeps a given visitor assigned to the same test variant across their session, so someone doesn't see the control on one page load and the variant on the next.
- Webflow Ecommerce, if your site sells anything, sets cart and checkout session cookies the same way any ecommerce platform does, keeping items in a cart persistent between page visits and verifying a checkout session as it moves through payment.
- Forms, Webflow's native form element, doesn't require a cookie by itself for a basic submission, but if you've turned on reCAPTCHA under form settings to block spam, that adds Google's reCAPTCHA cookies to the page the form sits on.
- Password-protected pages and Memberships, if enabled, set a session cookie to keep a visitor authenticated after they enter a password or log in, separate from anything else running on the site.
None of these show up in a plugin directory or an app list the way they would on WordPress or Shopify, since they're toggles inside Webflow's own Project Settings and Site Settings rather than separately installed software, which is exactly why they're easy to leave out of a policy written by someone assuming "we didn't add any tracking apps" means the site sets nothing at all.
Webflow's own feature cookies vs custom code and embed cookies
| Webflow feature cookies | Custom code cookies | |
|---|---|---|
| Set without adding any script yourself | ||
| Typical source | Analyze, Optimize, Ecommerce, Forms | Head/footer code, CMS embeds |
| Where it's configured | Project Settings and per-element toggles | Site Settings > Custom Code |
| Changes when you | Enable or disable a built-in feature | Add, remove, or edit a script or embed |
Third-party embeds: where the rest comes from
The larger and more variable source of cookies on most Webflow sites is whatever you've added through the Custom Code panel or pasted into an embed element, since Webflow itself has no restriction on what a Head Code, Footer Code, or page-level Embed block can load.
Analytics and advertising tags are the most common: Google Analytics (GA4), Google Tag Manager, and the Meta Pixel are typically added as raw script snippets under Site Settings > Custom Code, either in the sitewide Head Code and Footer Code fields or scoped to an individual page's own Custom Code section under that page's settings. Marketing tools like HubSpot's tracking script or Intercom's and Drift's chat widgets follow the same pattern, a snippet pasted into Custom Code that then sets its own cookies independent of anything Webflow's designer touches directly.
CMS-driven embeds are the part unique to Webflow's structure. If your CMS Collection template includes a Rich Text field where editors can paste embed codes (a YouTube video, a Calendly booking widget, an embedded Google Map, a Typeform), every published Collection item using that field can carry a different embed, which means the third-party cookies a visitor picks up can vary page to page rather than being fixed sitewide the way a Head Code script is. A cookie policy that only covers your Site Settings custom code and ignores what individual CMS items embed is describing an incomplete site, the same gap a WordPress policy that skips post-level embeds would have.
Webflow has no native consent banner
Unlike Wix's built-in Cookie Consent Banner setting or Shopify's Customer Privacy panel, Webflow doesn't ship a native cookie consent tool. Getting a banner on a Webflow site means adding one yourself, either as a third-party consent management platform's script (Cookiebot, Termly, iubenda, and similar tools all offer a snippet built for this) pasted into Site Settings > Custom Code, or as a custom-built banner using Webflow's own interactions and a bit of code if your needs are simple enough not to warrant a dedicated tool.
This matters for more than just having a banner. Consent management platforms typically need to load before your other tracking scripts so they can block or defer them until a visitor responds, which usually means the consent script goes in Head Code rather than Footer Code, and any analytics or advertising snippets you've added need to be reviewed against whatever gating method the platform you chose actually supports. A Google Analytics snippet pasted directly into Footer Code, running independent of the consent tool sitting in Head Code, defeats the point of having a banner at all.
If you're weighing whether your site needs a banner in the first place, not just how to add one, do you need a cookie banner if you don't use cookies walks through that separate question directly.
Writing the policy by category, not as a flat list
A Webflow cookie policy reads clearest organized by category rather than as a running list of every cookie name, the same structure that works for any platform:
- Strictly necessary: session cookies from password-protected pages or Memberships, and Ecommerce cart and checkout cookies if you sell anything, explained as cookies the site can't function without.
- Analytics: Webflow Analyze if it's enabled, plus Google Analytics or any similar tool added through Custom Code, named specifically rather than lumped into one line.
- Marketing and advertising: the Meta Pixel, Google Ads tag, and any other pixel pasted into Custom Code, each named by vendor since these are what a consent banner actually needs to gate.
- Functional: Webflow Optimize's variant-assignment cookie, chat widgets, and CMS-embedded tools like Calendly or Typeform that aren't strictly necessary but aren't advertising either.
For each category, note roughly how long the cookies persist and how a visitor can opt out, through your consent banner for the categories it covers, and through browser settings as a fallback for anything the banner doesn't reach.
- We may use cookies and similar technologies on our website.
- Doesn't name Webflow's own features or which third-party scripts are actually running.
- We use Webflow Analyze for analytics and Webflow Optimize for A/B testing on our website.
- We also use Google Analytics (GA4) and the Meta Pixel, added through our site's custom code.
Where to link the policy in a Webflow footer
Most Webflow sites build their footer as a Symbol, a component reused across every page rather than a separate element on each one, which is the fastest way to get a cookie policy linked sitewide without editing every page individually. Open the footer Symbol from any page it appears on, add a text link inside it pointing to your Cookie Policy page, and the change propagates automatically to every other page using that same Symbol.
Create the Cookie Policy itself as a regular static Page (Pages panel, not a CMS Collection item, since it's a single fixed document rather than repeating content), publish it, and link it from the footer Symbol the way you would any other footer page. If you're running a third-party consent banner, most of them also add their own "Cookie Settings" or "Manage Preferences" link automatically, which reopens the consent panel; that's a separate, useful control, not a substitute for the always-visible link to the actual policy page sitting in your footer.
Keeping it current as your site changes
A Webflow site's custom code and CMS embeds tend to change more often than its built-in feature toggles do. Adding a new marketing script to Head Code, connecting a new CMS field for embedded content, or enabling Ecommerce for the first time all add entries a cookie policy needs to reflect. Treat your Site Settings > Custom Code panel and your CMS Collection templates as the two places to check each time you revisit the policy, rather than waiting for an annual review to catch drift between what's disclosed and what's actually running.
Get a Webflow-accurate cookie policy without starting from scratch
Writing an accurate cookie policy for a Webflow site means separating what Webflow's own features set from what your custom code and CMS embeds add, then keeping both current as the site changes. Our Cookie Policy Generator builds a policy organized by category and named vendor from your actual answers, so the document your consent banner links to matches what's really running on your site instead of a generic list borrowed from a platform you're not even using.
If you're also deciding whether cookies belong in your general privacy policy or deserve a standalone page at all, privacy policy vs cookie policy covers that separate decision in more depth.
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.