Check tracking signals on your Webflow website

Most Webflow sites are built to capture leads — a contact form, a demo request, a booking. Adding the form in the Designer is easy; measuring it is a separate job. The form sits on the page and submits, but for that submission to count as a GA4 event, a Meta Lead event, or a Google Ads conversion, a tracking event has to be wired to the form's success. Webflow forms submit without a page reload and show an inline success state — and if nothing fires a tracking event on that success, the lead is captured while analytics and the ad platform never hear about it.

That gap is silent. The form works, the success message shows, the lead lands in your inbox — everything looks fine. But if the submit event the ad platform optimizes against never fires, campaigns keep spending against a form that appears to work while measurement stays blind. The result: you can neither attribute nor optimize the real leads your Webflow site is generating.

The free check works at the visible layer: it looks for whether the tracking tags (GA4/GTM/Meta) and the form and other lead paths appear to load on the public Webflow pages it can crawl. It does not submit the form or prove the submit event fires — that still needs a test submission in GTM Preview or GA4. It tells you what appears present on the page and where to confirm.

The most common cause is a republish or redesign. When you rework a page in the Designer, the form, its wrapper, or a button can get a new class or structure; if a GTM trigger was targeting the old selector, it no longer matches and submissions quietly stop being counted. The page looks the same to a visitor — the breakage is invisible.

The others are ordinary too: custom tracking code in Site Settings gets replaced or moved to a page that no longer includes it; a page-level embed and a site-wide tag both fire and double-count; a consent banner holds tags until the visitor accepts. None of these leave a visible mark, and Webflow's Designer doesn't warn you that a downstream tracking trigger just stopped matching.

The free check reads the public Webflow pages and flags whether the expected tags still appear and whether the form and lead paths are visible. It can't see inside your Designer, your custom code settings, or your consent tool — so it points you to where to look rather than declaring a setup fixed. For a lead-gen site running paid traffic, that first outside read is a fast way to catch a signal that has quietly gone missing after a republish.

The thorough way to verify Webflow tracking is from inside: open the Designer and Site Settings, check the custom code, submit a test form, and watch the event fire in GTM Preview or land in GA4 realtime. That's the right way to confirm a specific event fires — but it needs Designer or account access and a test submission.

TrackCanary takes the opposite approach for the first look. Paste a public URL — no login, no Designer — and the check reviews whether the tracking tags and the form and lead paths appear on the page, in one pass. It's the preflight you can run on any Webflow site, including a client's, before more ad budget goes through it — a way to see whether the page even appears to carry the tags and the lead paths before anyone opens the Designer. For an agency running several client Webflow sites, it's a fast outside sanity-check across all of them.

It doesn't replace a test submission in GTM Preview or GA4 — those confirm the form event fires. TrackCanary is the step before that, and the step that keeps watching: a quick outside read of what appears on the page, and a way to be told when a signal that used to be there is no longer visible after a republish.