Tracking on Wix and Squarespace: What You Can and Cannot Do
Both platforms restrict what tracking you can install. Here is what actually works, what does not, and when to stop fighting it.
Every few months someone asks me to fix tracking on a Wix or Squarespace site, and the honest first answer is a question: how much are you spending on ads?
Under a certain level, these platforms are fine. Above it, you will spend more time working around the limits than the tracking is worth.
Here is what genuinely works on each, what does not, and how to tell which side of the line you are on.
The thing both platforms share
You do not control the page. You control a box where you can paste code into a page you do not control.
That difference matters because tracking depends on three things being predictable: when your script loads, what is on the page when it loads, and whether the URL changes on navigation. On Wix and Squarespace, all three are decided by the platform and can change without notice.
So the rule is: build tracking that depends on as little of the page as possible.
Wix: what works
GTM via the built in integration. Wix has a Google Tag Manager field in its marketing integrations. Use it. It loads the container properly across the site.
Custom code in Settings. You can add head and body scripts sitewide or on specific pages, and choose whether they load on page load or after.
Wix Forms. These fire a real event you can catch. Wix also lets you set a thank you page redirect per form, which is the more reliable route.
Wix Stores ecommerce events. Wix pushes ecommerce data to the data layer if you enable it in the advanced marketing settings. It covers product views, add to cart and purchase with values.
Wix: what does not work
Consistent behaviour on Wix Studio versus classic Wix. The two products behave differently and most tutorials do not say which one they mean. Check which you are on before you follow any guide.
Server side tracking on Wix hosting. You cannot run a container there. You can point a subdomain at a server side container hosted elsewhere, and that is the usual answer.
Reliable single page navigation tracking. Wix navigates without full page loads in places. Page view tags that assume a reload will undercount. Use a history change trigger instead.
Editing checkout. Wix checkout is closed. What Wix gives you on the thank you page is what you get.
Squarespace: what works
Code Injection. Settings, then Advanced, then Code Injection gives you a sitewide header and footer. This is where GTM goes. Note that on some plans Code Injection is not available, which is worth checking before you promise anyone a setup.
Form submission events. Squarespace forms trigger a DOM change you can listen for, and forms can redirect to a URL after submission. Use the redirect.
Squarespace Commerce order confirmation. There is an Order Confirmation Page injection point specifically for this, and Squarespace exposes order data to it. This is the one genuinely good tracking feature on the platform.
Squarespace: what does not work
Anything on the Personal plan. Code Injection and commerce features are gated by plan. Check first.
Ajax loading. Some templates load pages without a reload. If your page views look low and your bounce rate looks impossible, this is why. Turn off Ajax loading in the template settings or switch to history change triggers.
Reliable element based triggers. Squarespace class names change between template versions.
Server side tracking. Same answer as Wix. Subdomain pointing to a container hosted elsewhere.
The single biggest win on either platform
Use thank you page redirects for forms.
It is not sophisticated. It does not need a single line of JavaScript. It survives template updates, platform changes and redesigns, and it gives you a page URL that any ad platform can track without help.
Give each form its own thank you page. Then a page view on /thanks/demo is a demo request and a page view on /thanks/newsletter is a newsletter signup, and you never have to debug a DOM listener again.
How to tell when you have outgrown the platform
You are past the limit when any of these are true:
You are spending more than a few thousand a month on ads and the data quality is now a real cost.
You need server side tracking to recover events that browsers are blocking.
You need custom checkout events, subscription tracking or product level data the platform does not expose.
You are sending offline conversions back from a CRM and need reliable click ID capture at form submission.
Two separate people have now spent a week each working around a platform limitation.
If none of those are true, stay where you are. The platform is not your problem and moving will cost more than it returns.
What to do if you are staying
Get the most out of what you have.
Install GTM sitewide through the official integration or code injection. Nothing goes in directly.
Use thank you page redirects for every form, one page per intent.
Turn on whatever native ecommerce data layer the platform offers.
Enable Enhanced Conversions in Google Ads using the email captured at submission. This recovers a meaningful share of what the browser loses, and it works on any platform.
Accept that you will undercount, and compare trends rather than absolute numbers.
That last point is not defeatism. Undercounting consistently is much less damaging than counting inconsistently, and most decisions you make with the data are relative anyway.
The migration conversation
If you do decide to move, move for product reasons rather than tracking reasons, and plan the tracking migration properly so you do not lose your conversion history.
Here is the sequence that keeps reporting intact while you switch: migrating to a clean GA4 and Google Ads stack.
Need this built properly?
Sometimes the right answer is to get the most out of the platform you have. I set up and repair tracking for ecommerce stores and lead generation businesses, so the numbers in your ad accounts match the money in your bank account.
Have a look at what I do, or book a call and we can go through your setup together.
