Why Google Tag Manager Wix Setups Fail Silently
Last month I audited a Wix ecommerce store spending EUR 3,400 per month on Google Ads. Their GA4 showed 22 purchases in June. The Wix Stores dashboard showed 41. That is a 46 percent gap. The founder had been scaling campaigns based on a cost-per-acquisition that was more than double reality.
The cause was a combination of three problems, all common on Wix. The site used the built-in GTM integration field, which only injects the <script> snippet and skips the <noscript> fallback. A developer had also pasted the container into a Velo custom code block months earlier, creating a duplicate container that double-fired pageviews on the homepage but missed checkout entirely. And because Wix renders most templates as a single-page application, internal navigations never triggered GTM's default Page View trigger after the first load.
None of these produced a visible error. Pages looked fine. The store kept selling. The tracking just quietly stopped reflecting reality.
This is the pattern I see on roughly five out of ten Wix sites that come through my inbox: GTM is "installed," but the data flowing into GA4 and the ad platforms is incomplete or inflated.
Two Ways to Add Google Tag Manager to Wix
Wix offers two paths to install GTM. Understanding where each one fails is the difference between tracking that works and tracking that looks like it works.
Path 1: The built-in GTM integration field
Wix has a native integration under Marketing Integrations > Custom > Google Tag Manager. You paste your container ID (e.g., GTM-XXXXXXX), click Connect, and Wix injects the GTM <script> snippet into the <head> of every page.
This is the fastest way to add Google Tag Manager to Wix. It is also incomplete.
The built-in field only injects the <script> portion of the GTM snippet. It does not add the <noscript> iframe fallback that Google's installation instructions specify should go immediately after the opening <body> tag. For most modern browsers with JavaScript enabled, this does not matter. But it means you are not following Google's documented installation spec, which can cause issues with GTM's diagnostics and with environments where JavaScript is blocked or delayed.
More critically, the built-in field gives you zero control over snippet placement priority. You cannot guarantee it loads before your consent management platform, which matters if you are implementing Google Consent Mode v2.
Path 2: Wix Velo custom code
Wix Velo (formerly Corvid) lets you add custom code through Settings > Custom Code. You can paste the full GTM snippet -- both the <script> and the <noscript> -- and control whether it loads in the head, body-start, or body-end position.
This gives you the control the built-in field lacks. But it introduces a risk: if you use both the native GTM field and a Velo custom code block with the same container ID, the container loads twice on every page. Every pageview fires double. Every event duplicates. GA4 sessions inflate, bounce rate drops to suspiciously low levels, and conversion counts are wrong.
Pick one path. Not both. I recommend the Velo custom code approach because it lets you place both snippet parts correctly and control load order. Most Google Tag Manager Wix installs I audit have gone wrong at exactly this step -- choosing both paths without realizing it.
My recommended setup
In Settings > Custom Code, add a new code block. Set the placement to Head and pages to All pages. Paste:
<!-- Google Tag Manager -->
<script>(function(w,d,s,l,i){w[l]=w[l]||[];w[l].push({'gtm.start':
new Date().getTime(),event:'gtm.js'});var f=d.getElementsByTagName(s)[0],
j=d.createElement(s),dl=l!='dataLayer'?'&l='+l:'';j.async=true;j.src=
'https://www.googletagmanager.com/gtm.js?id='+i+dl;f.parentNode.insertBefore(j,f);
})(window,document,'script','dataLayer','GTM-XXXXXXX');</script>
<!-- End Google Tag Manager -->
Then add a second code block. Set placement to Body - start and pages to All pages:
<!-- Google Tag Manager (noscript) -->
<noscript><iframe src="https://www.googletagmanager.com/ns.html?id=GTM-XXXXXXX"
height="0" width="0" style="display:none;visibility:hidden"></iframe></noscript>
<!-- End Google Tag Manager (noscript) -->
Replace GTM-XXXXXXX with your container ID. Confirm the native GTM integration field under Marketing Integrations is disconnected. Save and publish.
The SPA Problem: Why Pageviews Stop After the First Load
Most Wix templates use single-page application (SPA) routing. When a visitor clicks from your homepage to a product page, Wix does not perform a full page reload. It swaps content dynamically via JavaScript. The URL in the browser bar changes, but the document never reloads.
This means GTM's built-in Page View trigger fires exactly once -- on the initial load. Every subsequent navigation is invisible to it.
The fix is a History Change trigger. In GTM, create a new trigger of type History Change. This fires on gtm.historyChange events, which GTM generates whenever the browser's History API pushes a new URL -- exactly what Wix does during SPA navigations. Use this trigger for your GA4 pageview tag instead of (or in addition to) the default Page View trigger, following Google's SPA tracking guidance.
Without this, your GA4 reports show one pageview per session regardless of how many pages the visitor browses. Bounce rate looks artificially high. Engagement metrics collapse. And any trigger that depends on page path -- like firing a conversion tag on your /thank-you page -- never fires on subsequent navigations.
I cover trigger misconfiguration patterns in depth in Google Tag Manager Triggers: 5 Silent Misconfigurations. The SPA routing issue is one of the most common.
Wix Stores and the Missing Data Layer
If you run Wix Stores (Wix's native ecommerce), here is the hard truth: Wix does not push a standard ecommerce data layer for purchases. There is no built-in purchase event in the dataLayer that GTM can read. Unlike Shopify's Customer Events or Squarespace's order confirmation template variables, Wix gives you nothing out of the box.
This means your GA4 purchase tag, your Google Ads conversion tag, and your Meta pixel Purchase event have no data to fire on -- even though GTM is loading correctly on every page.
What you need to build
To track purchases on Wix Stores with GTM, you need custom Velo code that listens for the order completion event and pushes a dataLayer object in the GA4 ecommerce format:
// In your Wix Velo thank-you page code
import wixWindow from 'wix-window';
$w.onReady(function () {
// Retrieve order data from the page or your backend
const orderId = /* your order ID source */;
const orderTotal = /* your order total source */;
const currency = 'EUR'; // your store currency
wixWindow.trackEvent('CustomEvent', {
event: 'purchase',
ecommerce: {
transaction_id: orderId,
value: orderTotal,
currency: currency,
items: []
}
});
});
A note on the code above: wixWindow.trackEvent is Wix's built-in tracking API and does not push to the GTM dataLayer directly. If you need your GTM tags to fire on this data, you should instead use a dataLayer.push() call from a Velo HTML component or a custom element that has access to the page's window object. The exact implementation depends on how your Wix store surfaces order data on the thank-you page. In most setups, you will query the order via Wix's backend APIs and push the result into dataLayer. I wrote a detailed breakdown of why the data layer is foundational to conversion tracking in What Is a Data Layer and Why Tracking Breaks Without One.
Without this custom work, your GTM container loads, your tags are configured, and everything looks correct in the GTM workspace -- but zero purchase data flows to GA4 or your ad platforms. This is the most frustrating part of any Google Tag Manager Wix installation: everything appears correct, yet conversions never register. If your conversion numbers in GA4 do not match your Wix Stores orders, this is almost always the cause. I fix these gaps for a living -- the Wix data layer is one of the most common issues I see on the platform.
Content Security Policy Pitfalls on Wix
If your Wix site uses Velo extensively, you or your developer may have configured Content Security Policy (CSP) headers through Velo's HTTP functions. An overly restrictive CSP can block GTM entirely.
For Google Tag Manager to load, your CSP must allow:
| Directive | Required domain |
|---|---|
script-src | https://www.googletagmanager.com |
img-src | https://www.googletagmanager.com |
connect-src | https://www.google-analytics.com https://analytics.google.com |
frame-src | https://www.googletagmanager.com (for Preview mode) |
If any of these are missing, the browser silently blocks the resource. There is no visible error on the page. GTM simply does not load, and your tracking goes dark. Check the browser console (F12 > Console) for CSP violation messages if you suspect this is happening.
Validating Your Google Tag Manager Wix Installation
Once your Google Tag Manager Wix setup is live, validate before you walk away.
View page source
Load your Wix site, right-click, and view page source. Search for your container ID. You should find it twice: once in the <script> block in <head>, and once in the <noscript> block near the top of <body>. If you see it three or four times, you have a duplicate container -- check for both the native integration and a Velo code block.
GTM Preview mode
Click Preview in GTM, enter your Wix site URL, and navigate through several pages. Confirm that gtm.historyChange events fire on each navigation. If you only see the initial Page View and nothing on subsequent clicks, your History Change trigger is missing or misconfigured.
GA4 DebugView
In GA4, open Admin > DebugView. Browse your site with debug mode enabled. Confirm page_view events arrive for every page navigation, not just the landing page. For ecommerce, place a test order and verify the purchase event appears with transaction_id and value populated.
For a systematic verification process beyond these checks, I maintain a step-by-step Google Tag Manager Checker: Tools and a Debug Checklist.
Cross-check with Wix analytics
Compare GA4 session counts and purchase counts against Wix's built-in analytics for the same period. In my experience, a gap under 10 percent is normal -- consent, ad blockers, and bot filtering create some expected variance. A gap above 15 percent, in my experience, means something is broken in the chain.
Common Wix GTM Failures at a Glance
| Failure | Symptom | Fix |
|---|---|---|
| Duplicate container (native field + Velo code) | Every event fires twice, bounce rate near zero | Remove one installation path |
| No History Change trigger | GA4 shows one pageview per session | Add a History Change trigger for your pageview tag |
| Missing data layer for purchases | Purchase tag configured but zero conversions in GA4 | Build custom Velo code to push purchase events |
| CSP blocking GTM | Container does not load, no visible page error | Add googletagmanager.com to your CSP directives |
| Native field only (no noscript) | GTM loads but does not follow Google's full spec | Switch to Velo custom code for both snippet parts |
When Browser-Side Tracking Is Not Enough
A correct Google Tag Manager Wix setup captures most of your data. But browser-side tracking still loses events to Safari's ITP cookie caps, ad blockers, and consent requirements.
If your Wix site drives meaningful ad spend, a server-side GTM container on your own subdomain recovers what the browser path drops. Your web container sends events to the server container, which forwards them to GA4, Google Ads, and Meta server-to-server. No ad-blocker interference. Durable first-party cookies. Clean conversion data for Smart Bidding.
FAQ
Does Wix support Google Tag Manager natively?
Yes. Wix has a built-in GTM integration field under Marketing Integrations where you paste your container ID. However, this field only injects the head script snippet and does not add the noscript fallback. For a complete installation that follows Google's full specification, use Wix Velo custom code to add both the script and noscript portions manually.
Why does GA4 show only one pageview per session on my Wix site?
Most Wix templates use single-page application routing, which swaps page content without a full browser reload. GTM's default Page View trigger only fires once on the initial load. You need to create a History Change trigger in GTM that fires on gtm.historyChange events to capture subsequent page navigations as separate pageviews.
Can I track Wix Stores purchases with Google Tag Manager?
Yes, but it requires custom development. Wix Stores does not push a standard ecommerce data layer for purchases like some other platforms do. You need to write custom Velo code that captures order completion data and pushes it into the dataLayer in GA4 ecommerce format so your GTM purchase tags have data to fire on.
What happens if I use both the Wix GTM integration field and Velo custom code?
Your GTM container loads twice on every page. This causes every tag to fire twice, doubling your pageview counts, inflating event metrics, and potentially double-counting conversions in GA4 and your ad platforms. Always use one installation method or the other, never both simultaneously.
Do I need server-side tracking for a Wix site?
If your Wix site runs paid advertising and you depend on accurate conversion data for bidding decisions, server-side tracking significantly improves data quality. Browser-side tags lose data to ad blockers, Safari cookie caps, and consent restrictions. A server-side container on your own subdomain sends data server-to-server, recovering conversions that the browser path misses.
Not sure your Wix tracking is actually capturing what it should? Get in touch -- I will audit your setup and tell you exactly what is broken and what to fix first.