Summary
When the skill converts a Webflow site to TanStack Start, analytics that
relied on full page loads silently stop tracking client-side navigations.
GA4 only fires a page_view on the initial hard load — every subsequent
SPA route change sends nothing. The result is a large, easy-to-miss drop in
reported pageviews after go-live.
Why it happens
This is a classic MPA → SPA pitfall, not a Webflow-specific bug:
- In Webflow, every navigation is a fresh document load, so GA4 (whether via
GTM or gtag) fires a page_view automatically on each page.
- After migration to TanStack Start, navigations become client-side state
transitions — no new document, so no automatic page_view.
- GA4 is typically loaded via a deferred GTM container. Nothing in the
migrated app subscribes to TanStack Router navigation events to emit
virtual pageviews, so analytics quietly under-reports.
The same gap affects any pageview-on-load tracker carried over from the
Webflow export (GTM/GA4, and potentially others).
Fix that worked (for reference)
- Add
tanstack-router-ga4 (hooks into the router, emits page_view on
pathname changes).
- Mount
<GoogleAnalytics measurementId={...} /> inside RootDocument
in __root.tsx.
- Resolve the GA4 measurement ID per environment
(prod vs import.meta.env.DEV).
The package sets send_page_view: false on the gtag config and emits manual
page_view events on route change, so it stays compatible with an existing
GTM container and doesn't touch cookie consent code.
Suggested changes to the skill
- Add an "SPA analytics parity" item to the migration checklist
(checklists/cleanup-before-done.md): detect GTM/GA4 (or other pageview
trackers) in the Webflow export and wire up virtual pageviews on router
navigation.
- Document the pitfall in
gotchas.md: MPA → SPA means client-side
navigations no longer auto-fire page_view; carried-over analytics will
under-report until route-change tracking is added.
- Add a verification step: navigate 2–3 routes via link clicks (not hard
reloads) and assert a /g/collect request with en=page_view fires per
route with an updated page_location.
Environment
- Skill:
webflow-to-react (installed via npx skills@latest add dmenchaca/webflow-to-react)
- Target stack: TanStack Start (React, SSR) on Netlify
- Analytics: GA4 loaded via GTM
Summary
When the skill converts a Webflow site to TanStack Start, analytics that
relied on full page loads silently stop tracking client-side navigations.
GA4 only fires a
page_viewon the initial hard load — every subsequentSPA route change sends nothing. The result is a large, easy-to-miss drop in
reported pageviews after go-live.
Why it happens
This is a classic MPA → SPA pitfall, not a Webflow-specific bug:
GTM or gtag) fires a
page_viewautomatically on each page.transitions — no new document, so no automatic
page_view.migrated app subscribes to TanStack Router navigation events to emit
virtual pageviews, so analytics quietly under-reports.
The same gap affects any pageview-on-load tracker carried over from the
Webflow export (GTM/GA4, and potentially others).
Fix that worked (for reference)
tanstack-router-ga4(hooks into the router, emitspage_viewonpathname changes).
<GoogleAnalytics measurementId={...} />insideRootDocumentin
__root.tsx.(prod vs
import.meta.env.DEV).The package sets
send_page_view: falseon the gtag config and emits manualpage_viewevents on route change, so it stays compatible with an existingGTM container and doesn't touch cookie consent code.
Suggested changes to the skill
(
checklists/cleanup-before-done.md): detect GTM/GA4 (or other pageviewtrackers) in the Webflow export and wire up virtual pageviews on router
navigation.
gotchas.md: MPA → SPA means client-sidenavigations no longer auto-fire
page_view; carried-over analytics willunder-report until route-change tracking is added.
reloads) and assert a
/g/collectrequest withen=page_viewfires perroute with an updated
page_location.Environment
webflow-to-react(installed vianpx skills@latest add dmenchaca/webflow-to-react)