Check tracking signals on your Squarespace website

Squarespace makes tracking feel handled: you paste your GA4 or Meta Pixel into Code Injection, load a product page, and a scan sees the tag — so tracking looks done. But on Squarespace the storefront and the checkout are two different worlds. Code Injection Header/Footer applies to your storefront pages, but the checkout and the order-confirmation page are hosted by Squarespace on a separate surface your site-wide injection doesn't reach. A pixel in Code Injection can appear present on every product page while the purchase event — the one that fires on the confirmation page — never happens.

That gap is exactly where revenue data goes quiet. The tag loads on the storefront, so GA4 shows pageviews and Meta shows activity, and everything looks alive. But the purchase and conversion events ad platforms optimize against fire on the order-confirmation page, and a site-wide tag doesn't automatically reach it — on Squarespace that needs the separate Order Confirmation Page injection. Campaigns keep spending against a tag that appears healthy while the revenue event it needs is missing.

The free check works at the visible layer: it looks for whether tracking signals appear on the public Squarespace pages it can crawl and flags the product and checkout-intent paths. It does not complete an order or prove the purchase event fires; that still needs GA4 realtime or a test order. It tells you what appears present on the storefront and where the checkout-side events are worth confirming.

The most-searched Squarespace tracking pain is specific: on 7.1, GA4 shows traffic but ecommerce purchases and revenue don't show up. The usual cause is the split above — GA4 loads site-wide and counts pageviews, but the purchase event with the order value often isn't sent to GA4 from the confirmation page without additional setup. Sessions look tracked; the money doesn't.

Tracking also breaks in ordinary ways. A template change or a move from 7.0 to 7.1 can drop a tag that lived in an old code block. A built-in integration and a Code-Injection tag can both fire and double-count. A cookie-consent banner can hold tags until the visitor accepts. None of these leave a visible mark on the storefront.

The free check reads the public Squarespace pages and flags whether the expected tracking signals still appear and which lead and commerce paths are visible. It can't see your checkout settings, your Order Confirmation Page injection, or your consent tool — so it points you to where to look rather than declaring a setup fixed. On a store where money moves through the Squarespace checkout, that first outside read is a fast way to catch a signal that has quietly gone missing.

The thorough way to verify Squarespace tracking is from inside: open the admin, check the GA4 connection and any Code Injection, place a test order, and watch the purchase event land in GA4 realtime or Meta Events Manager. That's the right way to confirm a specific event fires — but it needs admin access and a test order to reach the confirmation page.

TrackCanary takes the opposite approach for the first look. Paste a public URL — no login, no install — and the check reviews whether tracking signals appear on the storefront alongside the product and checkout-intent paths, in one pass. It's the preflight you can run on any Squarespace site, including a client's, before more ad budget goes through it — a way to see whether the storefront even appears to carry the tags before anyone opens the admin.

It doesn't replace a test order in GA4 or Events Manager — those confirm the purchase event, and on Squarespace they're where you catch the 7.1 ecommerce gap. TrackCanary is the step before that, and the step that keeps watching: a quick outside read of what appears on the storefront, and a way to be told when a signal that used to be there is no longer visible after a template change.