How to add analytics to a Webflow site

A freshly published Webflow site records nothing about its visitors. There's no default counter, no traffic tab waiting in the Designer - analytics is something you add, and Webflow gives you three ways in: its own Analyze product, an integrations field for Google Analytics, and a custom-code box for everything else. Which of the three you can actually use depends on your plan, so this guide flags the gates as it goes.

Webflow Analyze is the built-in option, added in 2024: a paid per-site add-on that works on any plan, including the free Starter tier. It's cookieless, needs no code, and shows the core numbers - pageviews, visitors, traffic sources, top pages - plus click maps and goal tracking inside the Webflow dashboard. For a designer who lives in Webflow and wants visitor numbers without opening another tool, it's a reasonable first stop.

Its ceiling is the same as any platform built-in, and it's worth naming before you pay for it. The data lives in Webflow and describes this one site; the pricing is per site, so a portfolio of client projects multiplies the cost; and the deeper questions - funnels, a visitor's history across sessions, anything joining the marketing site to a product or billing - sit outside what a site-scoped tool can answer. The pattern is the one we've seen on Lovable and Replit: built-in analytics answers "did anyone come?", and the day your question changes to "what did they do, and did it work?" is the day you outgrow it. Buying Analyze first and adding a standalone tool later is a fine path; just know which day you're in.

Here's the quirk that shapes Webflow analytics decisions: the Google Analytics integration is free on every plan, while the general custom-code box is not. Webflow's docs put the GA field in Site settings > Integrations - paste your GA4 Measurement ID (the G- code) and Webflow injects Google's tag on every page for you. No paid site plan required.

So on a free Starter site, Google Analytics is effectively the only full analytics tool you can install. That's worth knowing before you fall in love with an alternative: the moment you want any other tool's snippet, you're on the custom-code route, and that needs a paid site plan.

Why does Webflow single out Google Analytics for special treatment? History, mostly - the field predates the custom-code gating and removing it would break half the internet's Webflow tutorials. Whatever the reason, the practical effect is a two-tier world: GA4 for everyone, everything else for paying site plans. Keep that in mind when a tool's marketing page says "works with Webflow" - it's true, with an asterisk about your plan.

Everything else about the Google side - the settings worth changing on day one, verification details, the consent question - is the same as on any platform, and lives in the GA4 setup guide. What to do once data flows is the tutorial's territory.

Set expectations correctly from day one: whatever tool you install will undercount. Adblockers and privacy browsers stop a meaningful share of tracking scripts before they load, and design-literate audiences - common for Webflow sites - block more than average. The numbers are a floor, useful for trends and comparisons rather than a census.

The whole flow, assuming nothing exists yet:

• Create the GA4 property and web data stream - the full walkthrough is in our setup guide, but the short version is analytics.google.com > Start measuring > Web.
• Copy the Measurement ID from the stream details (starts with G-).
• In Webflow: Site settings > Integrations > Google Analytics, paste the ID, save.
• Publish the site. Settings changes don't reach the live site until you publish - the most common reason Webflow tracking 'doesn't work'.
• Open your site in one tab and GA4's Realtime report in the other, and watch yourself show up.

On a paid site plan, Site settings > Custom code opens up: a head-code box that injects whatever you paste onto every page. This is the door for everything that isn't Google Analytics - Google Tag Manager if your marketing stack wants it, and any lighter analytics tool's snippet.

That includes Bigdelta: the snippet goes into the custom-code box, and from there it tracks pageviews, clicks, form submissions and CMS interactions, with custom events defined from the dashboard rather than in code. The same one-snippet mechanism covers the rest of the lightweight category - the honest comparison of what's genuinely free is a separate post. If you're choosing between GA4-in-the-free-field and a-better-tool-on-a-paid-plan, weigh the plan cost against how much GA4's complexity costs you - for many Webflow sites the marketing site is the business, and the analytics deserve the upgrade.

Webflow also has a dedicated integrations field for Google Tag Manager, and it deserves a short honest paragraph rather than a hard sell. GTM is a container that loads other tags - GA4, ad pixels, consent tools - so marketers can add and change tracking without editing the site. If your Webflow site is part of a marketing operation that already runs GTM everywhere, use the field and manage GA4 inside the container as usual.

If you're one person with one site, GTM adds a layer of indirection you don't need yet: another interface, another place things can be misconfigured, and no data you couldn't get from the plain GA field. The honest trigger for adopting it is the third time someone asks you to add a tag - before that, simpler wins.

Every Webflow project publishes to a staging subdomain - yoursite.webflow.io - alongside your real domain, and your analytics tag fires on both. Every preview you show a client, every check-the-change visit of your own on staging, lands in the same reports as real traffic. On a small site that's enough to distort everything.

The fix in GA4 is a filter: Admin > Data collection and modification > Data filters, excluding traffic whose hostname is the webflow.io domain (the same screen handles internal traffic by IP). Do it early - filters only apply forward, and staging visits already recorded stay in your history. Webflow's own Analyze sidesteps this by keeping staging traffic out of the way by default, one genuine point in its favor.

Webflow's native forms submit in place - the visitor stays on the page and sees an inline success message. Tidy for the visitor, awkward for analytics: there's no thank-you page load to count, so the classic form-conversion setup has nothing to observe, and a plain GA4 install will show form-page traffic but not submissions.

Three ways out. Redirect the form to a thank-you page (a form setting), and count that page as the conversion - simplest, and it makes attribution obvious. Or wire the submission event properly: GA4's enhanced measurement includes a form-interaction event, and Google Tag Manager has a dedicated form trigger, though Webflow's in-place submit is exactly the pattern that makes generic form events flaky - test before trusting. Or use a tool that captures Webflow form submissions natively, which is one of the concrete reasons the custom-code route earns its plan fee. Whichever you pick, submit a test entry and confirm it lands before the form matters.

This is also the moment to think one step past the submit. A form that converts poorly is rarely mysterious once you can see it: form analytics shows which field loses people, and a session replay of an abandoned attempt shows the how. On a site whose whole job is producing form fills, that pairing pays for itself fast.

If a check fails, the fix is almost always one of three things: not published, snippet in the wrong box, or an adblocker on your own browser eating the test visit. Try a private window before debugging anything deeper.

Five minutes of checking saves a month of quietly broken data. After any analytics change on Webflow:

• Publish. Nothing you changed in Site settings reaches the live site until you do, and unpublished changes are the top cause of 'tracking not working' threads.
• Visit your live domain (not the .webflow.io one) and watch yourself appear in the tool's realtime view.
• Submit a test form entry and confirm it shows up wherever you decided form conversions live.
• Check the staging filter by visiting the .webflow.io domain and confirming that visit does not appear.
• Come back in two days and confirm the standard reports filled in - GA4 in particular processes data on a lag, so an empty report hours after setup is normal, not broken.

Combinations are normal, too. Plenty of Webflow sites run the free GA field for the ad-platform plumbing and a lighter tool for the numbers someone actually reads each week. The snippet cost of a second tool is small, and the two datasets will disagree a little - that's expected, not broken.

By plan and appetite:

• Free Starter site - the GA field is your option; take it, filter staging traffic, and redirect forms to a thank-you page.
• Paid plan, happy in Google's world - GA field plus the setup guide's day-one settings, GTM only if other marketing tags are coming.
• Paid plan, want simpler than GA4 - a lightweight tool's snippet in custom code; forms and clicks tracked without the ceremony.
• Living entirely inside Webflow, simple questions - Analyze, with the knowledge that harder questions will eventually want more.

A Webflow site is usually a marketing site, which narrows the metrics that matter. Traffic and its sources tell you whether the promotion works. The top-pages report tells you which pages carry the load. And whatever the site exists to produce - form fills, signups started, demo bookings - is the number the rest should serve, which is why the form-tracking gotcha above is worth solving properly rather than someday.

Give the data a quiet week before reading much into it, then set a routine: a short weekly look beats a monthly deep dive that never happens. And if the site is new and the numbers are small, resist the urge to refresh the dashboard hourly - small-number swings mean less than they appear to.

Webflow analytics comes down to one free field, one paid box, and one add-on - plus two traps that catch nearly everyone once. Paste the GA4 ID or your tool's snippet, publish, and then spend the five minutes the traps deserve: a filter for the staging domain, and a real decision about how form submissions get counted. A Webflow site with those two handled has cleaner data than plenty of sites with far fancier setups.