<- Back to blog
Platform11 min readUpdated May 1, 2026

Webflow Analytics: Track Visitors Without Cookies

Install analytics on a Webflow site in 2026: Project Settings custom code, page-level snippets, native Webflow form submit tracking, GDPR-friendly setup, and the limits of Webflow Analyze.

webflow analyticswebflow analytics guidewebflow trackingwebflow privacy analyticswebflow form trackingwebflow custom code

TL;DR

  • 1.Webflow ships its own product called Webflow Analyze — useful but limited and gated to higher plans.
  • 2.For real analytics, paste a snippet into Project Settings → Custom Code → Head. It loads on every page automatically.
  • 3.Webflow forms emit a `submit` event on the form element — hook it to fire a `form_submit` track call.
  • 4.Per-page custom code (Page Settings → Custom Code) overrides project-level when you need page-specific events.
  • 5.Cookieless analytics tools work natively with Webflow and remove the consent-banner overhead that kills GA4 setups.

What Webflow gives you natively in 2026

Webflow shipped its own analytics product called Webflow Analyze in 2024. It lives inside the Designer / Site dashboard and gives you visitor counts, top pages, top sources, and basic device breakdowns. For marketing sites built on Webflow it is a reasonable starting point.

The catch is that Webflow Analyze is gated to higher Site plans (CMS and above) and the dashboard does not go past the basics. There is no real-time funnel, no event tracking, no web vitals, no public dashboards, and no AI chat. For a serious daily growth review, it is the floor — not the ceiling.

Webflow also exposes basic visitor counts in the project dashboard regardless of plan, but those numbers are server-side aggregates, not analytics. They are useful for capacity planning ("are we close to the bandwidth limit?") and not much else.

The limits of Webflow Analyze

For a marketing site running paid ads, doing weekly growth reviews, or measuring conversion through a multi-step contact flow, Webflow Analyze is too thin. That is when you bring in a second analytics tool.

  • Plan gating. Most useful Analyze features require Site CMS plan or higher.
  • No custom events. Form submits, button clicks, scroll depth — none of it is tracked beyond pageviews.
  • Shallow attribution. Source / medium / campaign reporting is basic; UTMs are surfaced but not segmented well.
  • No public dashboards. You cannot share live numbers with stakeholders without giving them Webflow seats.
  • No real-time. The dashboard has a "today" view but it is not a live funnel.
  • No web vitals. Webflow does not surface LCP / CLS / INP, even though those affect Google ranking on Webflow-hosted sites.

Install via Project Settings → Custom Code → Head

Webflow has a clean place to drop a sitewide analytics snippet: Project Settings → Custom Code → Head Code. Anything you paste here is rendered inside `<head>` on every page of the site, both staging (`webflow.io`) and production. Save and publish.

Project Settings → Custom Code → Head Code
<!-- Sleek Analytics — privacy-friendly, cookieless, no consent banner needed -->
<script async src="https://getsleek.io/v1.js" data-site="YOUR_SITE_KEY"></script>
tip:You must hit Publish in the Webflow Designer for Custom Code changes to go live. "Save" alone updates the staging build only. If your snippet is not firing on production, this is almost always why.

Per-page custom code for special pages

Webflow lets you add custom code at the page level too: Page Settings → Custom Code. Use this for events that only matter on one page — for example, a "thank you" page after a contact form, or a pricing page where you want to track plan-card clicks.

A common pattern: project-level snippet for the analytics script; page-level snippet for the conversion event. The page-level snippet runs after the project-level one, so `window.sleek` is available.

On Webflow CMS Collection pages, the same Page Settings Custom Code applies to every CMS item generated from that template. If you need per-item event data (like the slug of the post a visitor is reading), read it from `location.pathname` at runtime — Webflow does not expose CMS field values to inline JS directly.

Page Settings → Custom Code → Before </body> tag (on /thank-you page)
<script>
  // Fire a conversion event when the thank-you page loads.
  (function () {
    function fire() {
      if (typeof window.sleek === 'function') {
        window.sleek('track', 'lead_submit', {
          source: new URLSearchParams(location.search).get('utm_source') || 'direct',
        });
      } else {
        setTimeout(fire, 200);
      }
    }
    fire();
  })();
</script>

Track Webflow form submissions

Webflow forms work two ways: the default behavior shows a success message inline (the "form success state" in the Designer), and the optional behavior redirects to a custom page. Both can be tracked, but the listener is different.

For inline success states, listen for the form's `submit` event and fire your analytics call before the default behavior finishes. Webflow does not provide a "form success" JS event natively, so you fire the track call on submit and accept that it represents an attempt — not a guaranteed success.

For form-to-redirect (the cleaner pattern for tracking), set the form to redirect to a `/thank-you` page and fire the conversion event from that page's custom code.

Project Settings → Custom Code → Before </body> tag
<script>
  // Track every Webflow form submit attempt on the site.
  document.addEventListener('submit', function (e) {
    var form = e.target;
    if (!(form instanceof HTMLFormElement)) return;
    if (!form.matches('form[data-name], .w-form form')) return;

    if (typeof window.sleek === 'function') {
      window.sleek('track', 'form_submit', {
        form_name: form.getAttribute('data-name') || form.id || 'unnamed',
        page: location.pathname,
      });
    }
  }, true); // capture phase, so we fire before Webflow's own handler
</script>
note:Webflow forms are wrapped in `.w-form` elements. The selector `form[data-name], .w-form form` matches both classic Webflow forms and forms inside CMS templates. Adjust if you have a custom form library.

Attribution: keep UTMs working through Webflow

Webflow does not strip UTMs from the URL — they survive through the page lifecycle and are visible in `location.search`. The two attribution gotchas on Webflow are: hash-anchor links inside the same page (`#pricing`) blow away your UTMs on click, and Webflow Forms do not capture URL parameters by default.

For paid ad campaigns where you want to associate the original UTM with a form submission, add hidden fields to the form and populate them from the URL on page load. Then your CRM (HubSpot, Pipedrive, Notion, etc.) sees the UTM as part of the form payload, not just a one-time analytics event.

A second pattern worth using: persist the first-touch UTM in `localStorage` on the first pageview, and read it back when the form submits. This survives a multi-page browsing session — the visitor lands from a Google Ad, browses for 5 minutes, then submits the form on a different page. Without persistence, you lose the original source.

Form custom attributes — populate hidden UTM fields
<script>
  document.addEventListener('DOMContentLoaded', function () {
    var params = new URLSearchParams(location.search);
    ['utm_source', 'utm_medium', 'utm_campaign', 'utm_term', 'utm_content'].forEach(function (key) {
      var input = document.querySelector('input[name="' + key + '"]');
      if (input && params.get(key)) input.value = params.get(key);
    });
  });
</script>

Pitfalls that bite Webflow sites

  • You forgot to Publish. Custom Code changes require a Publish, not just a Save. This is the #1 reason Webflow analytics installs "do not work."
  • Staging vs production keys. The `webflow.io` subdomain and your custom domain look like two different sites to most analytics tools. Either filter staging traffic or use a different site key for staging.
  • Webflow Ecommerce checkout. Webflow's native ecommerce checkout is hosted on a separate flow that does not always inherit your project-level head code. Test the order-confirmation page explicitly.
  • CMS-driven pages share the same Head Code as their template. You cannot easily fire different events for different CMS items without reading the slug from the URL at runtime.
  • Symbol / component-level scripts can fire multiple times if the symbol is reused on a page. Wrap event calls in a "fired once" guard.
  • Webflow's built-in cookie banner does not actually block scripts. It is purely cosmetic — if you need real consent enforcement you must build it.

GDPR, cookies, and Webflow

Webflow is popular with marketing teams, and marketing sites are usually international. EU traffic on a typical Webflow site is 20–40% of total. That makes the analytics-and-consent question real, not optional.

If you install GA4 on Webflow, you need a real consent management platform (Cookiebot, Iubenda, Termly, Complianz). Webflow's built-in cookie banner element does not actually block analytics scripts — it just shows a banner. Without real blocking, your GA4 install is non-compliant in the EU.

A cookieless privacy-first analytics tool sidesteps all of this. There are no cookies set, no personal data collected, no banner required, no scripts to block. The install is a single line of code in Project Settings and the compliance story is over.

There is also a competitive angle worth naming: Webflow itself sets a few first-party cookies for the Designer and for IX2 interactions, but those are functional and do not require consent under GDPR. The cookies that trigger consent obligations are the ones from the analytics, ads, and chat tools you add — which is exactly the layer this guide is replacing.

warning:Webflow's native cookie consent component is a UI element only. It does not gate scripts in `<head>`. If you keep it on a site that runs GA4 or Meta Pixel, you are showing visitors a banner that does not actually do anything — that is a bigger compliance problem than not having a banner at all.

Alternatives and what to install

For Webflow sites in 2026, the strong picks are: Sleek for marketing-driven sites that want a real-time view and AI chat, Plausible for the open-source minimalist option, and Fathom for EU-hosted compliance. All three install via a single line in Project Settings.

Webflow Analyze has a place — it is right there in your Webflow dashboard and the basics are free or cheap. The right pattern for most Webflow teams is Webflow Analyze for the in-Designer convenience, plus one privacy-first analytics tool for the daily growth review and conversion tracking.

  • Sleek — real-time, AI chat, public dashboards, native Stripe revenue tracking
  • Plausible — minimal, open source, popular in the Webflow community
  • Fathom — privacy-first, EU-hosted option for GDPR-sensitive teams
  • Simple Analytics — single-page dashboard, very lightweight
  • GA4 — only if you need it for Google Ads conversion tracking; the consent overhead is real

Frequently asked questions

Where do I add analytics to a Webflow site?

Project Settings → Custom Code → Head Code. Paste the script tag, save, and Publish. The snippet renders inside `<head>` on every page of the site automatically. For page-specific events, use Page Settings → Custom Code on the relevant page.

Does Webflow have built-in analytics?

Yes — Webflow Analyze, available on Site CMS plans and above. It covers pageviews, top pages, top sources, and devices. It does not cover custom events, real-time funnels, web vitals, or public dashboards. Most serious teams pair it with a privacy-first analytics tool.

How do I track Webflow form submissions?

Listen for the `submit` event on `.w-form form` (or `form[data-name]`) and fire your analytics SDK's track call. For higher accuracy, set the form to redirect to a `/thank-you` page and fire the conversion event from that page's custom code — that way you only count actual successful submissions.

Why is my Webflow analytics not showing data?

The most common cause is forgetting to Publish — Custom Code changes only go live after Publish, not Save. The second most common cause is staging vs production confusion: the `webflow.io` subdomain shows up as a different site to your analytics tool. Filter or exclude it.

Do I need a cookie banner on Webflow?

Only if you use cookies for tracking. GA4, Meta Pixel, and Hotjar all set cookies and require consent in the EU. Cookieless analytics tools (Sleek, Plausible, Fathom) do not require a banner. Webflow's built-in cookie consent element is cosmetic and does not actually block scripts.

Can I use Google Analytics on Webflow?

Yes, you can paste GA4's tag into Project Settings → Custom Code. The tradeoffs are real: 30+ KB of script weight, a mandatory consent banner for EU traffic, and 20–40% of EU users opting out and degrading your data. For most Webflow marketing sites, a privacy-first tool is a better fit.

Does Webflow Analyze track conversions?

Webflow Analyze tracks pageviews and basic source attribution. It does not track form submits, button clicks, or custom conversion events. For conversion tracking on Webflow, fire custom events from your form submit handler or from a thank-you page using a third-party analytics tool.

Track your own growth loop

Sleek Analytics gives you visitors, sources, pages, devices, and real-time behavior with one lightweight script. No cookies, no GDPR banners.

Related reading