Setting Up Analytics for Webflow Sites: GA4, GSC, and Beyond
Webflow ships with no built-in analytics beyond basic hosting stats. Here is the full setup for GA4, Search Console, form tracking, and the Webflow-specific gotchas that break tracking.
Updated 6 min read
Webflow makes it easy to build a polished site and hard to instrument it properly. The platform has no built-in analytics beyond basic hosting stats, so you need to bring your own measurement stack. Pasting a GA4 tag into the custom code section is the beginning of the setup, not the end.
This guide covers the full analytics stack for a Webflow site: GA4 configuration, Search Console verification, form submission events, CMS collection tracking, and the Webflow-specific issues that silently break your data if you do not know about them.
Installing GA4 on Webflow
Webflow has two places to add custom code: site-wide (Project Settings, Custom Code) and per-page (Page Settings, Custom Code). GA4 goes in the site-wide head section so it loads on every page.
You have two options: raw gtag.js or Google Tag Manager. For most Webflow sites, GTM is the better choice because it lets you manage tags without editing Webflow's custom code section every time you add a tracking pixel.
If you are using GTM, paste the GTM container snippet in the site-wide head section. Then manage your GA4 tag, conversion tracking, and any other pixels through GTM's interface. If you are using gtag.js directly, paste the full GA4 snippet in the head section. Do not put it in the body section. It needs to load before the page renders to capture the initial pageview.
Enhanced Measurement
Once the tag is installed, verify that enhanced measurement is enabled in your GA4 data stream settings. This auto-collects several event types without custom configuration:
- Page views including Webflow's client-side page transitions
- Scrolls at the 90% scroll depth threshold
- Outbound clicks on links to other domains
- File downloads for PDF, DOCX, and XLSX links
- Form interactions for native Webflow forms (form_start and form_submit)
That last point is critical. Enhanced measurement's form tracking works with native Webflow forms out of the box. But it has limitations with third-party embeds, which we cover in the forms section below.
Search Console Verification
Webflow sites need Search Console verification to access query data, index coverage, and manual action notifications. Three methods work with Webflow.
DNS TXT record (recommended)
If the client manages their DNS through Cloudflare, Route 53, or their registrar, add the Google verification TXT record to the domain. This verifies the entire domain and all subdomains, and it survives site redesigns.HTML meta tag
Add the Search Console verification meta tag to Webflow's site-wide head custom code section. This works but breaks if someone removes the custom code during a redesign.Submit the sitemap
Webflow auto-generates a sitemap at sitemap.xml. After verification, submit it through Search Console's Sitemaps section and verify it returns valid XML.
Form Submission Tracking
Webflow forms are the primary conversion mechanism for most Webflow sites. Getting form tracking right is the difference between guessing your lead count and knowing it.
Native Webflow forms are handled by enhanced measurement's form tracking. It fires form_start when a visitor first interacts with a form field and form_submit when the form is submitted. No custom configuration needed.
The catch: enhanced measurement relies on the HTML form element and its submit event. If the client adds a form through a third-party embed (Typeform, Calendly, HubSpot forms), those embeds render in iframes or use JavaScript submission handlers that enhanced measurement cannot detect.
For embedded third-party forms, you need a custom event. The most reliable approach is configuring the embedded form to redirect to a Webflow thank-you page on submission, then firing a generate_lead event when that page loads. Alternatively, some form providers offer JavaScript callbacks you can use to push events to the dataLayer through GTM.
Mark form_submit or generate_lead as a key event in GA4 so submissions appear in conversion reports. Do not mark form_start as a key event. It fires on field interaction, not on submission, and will inflate your conversion count significantly.
Webflow-Specific Gotchas
Several Webflow behaviors silently corrupt your analytics data if you are not aware of them.
Filter staging traffic by blocking tags when the hostname contains .webflow.io
Verify client-side page transitions re-execute custom tracking code in the body section
Set up internal traffic filters for the client's office IPs and your agency's IPs
Confirm the custom domain has a working SSL certificate and HTTP redirects to HTTPS
Check that draft pages with forms do not inflate conversion counts in production data
Tracking CMS Collections
Webflow's CMS lets you build dynamic content: blog posts, case studies, team members, product pages. Each collection has a template page that renders dynamically. From GA4's perspective, these are regular page views with different URLs.
To measure collection-level engagement, create a custom report or Explore analysis that groups pages by URL path structure. If blog posts live under a /blog/ prefix and case studies under /case-studies/, you can group them by path prefix to compare engagement across collections.
For blog-heavy sites, the metrics that matter are scroll depth, engagement time per page, and internal navigation rate. These are all available from GA4's standard data without custom events. The common mistake is building custom tracking for things GA4 already measures. If your CMS template includes CTAs like a demo request button, those need to be tracked as custom events through GTM if they are not native Webflow form submissions. For a deeper look at auditing your GA4 setup, see how to run a GA4 implementation audit.
Connecting to SyncingBeam
Once GA4 and Search Console are properly configured on a Webflow site, SyncingBeam can collect from both sources on a daily schedule. SyncingBeam pulls GA4 metrics and dimensions through the GA4 Data API and GSC query and page data through the Search Console API, then surfaces them together with per-source timestamps so you always know how current each number is.
The foundation described above matters because everything downstream depends on it. If forms do not fire events, reports undercount leads. If staging traffic is not filtered, engagement metrics are wrong. If the tag loads after a page transition, the first pageview of every session is missed. Get the foundation right and the reporting layer can do its job. For more on structuring reports that pull from multiple sources, see SEO reporting for clients and GA4 conversion tracking.