Squarespace makes the Meta pixel a one-field setup, which is why so much of what these sites should be tracking never gets tracked. This is the audit we run before we touch a campaign: what the built-in connection actually covers, where it stops, and how to confirm the rest.
Squarespace has a built-in place to connect a Meta pixel. Depending on your plan it sits under the marketing or developer tools area of site settings, and it takes a pixel ID and nothing else. Paste the ID, save, done. The pixel loads on your site.
That simplicity is the trap. The field gives you a working base install, and a working base install is not the same as tracking your funnel. It fires PageView across your pages, and on commerce sites it covers a limited set of shop events. It does not let you say which events fire, attach parameters, or define an event for the action that actually matters to your business, whether that is a consultation request, a booking, or a newsletter signup that leads to a sale weeks later.
So people add code. That is where the second problem starts. Code injection on Squarespace is a paid feature that is not available on every plan, so some sites cannot add custom events at all, and the ones that can end up with a second pixel install sitting alongside the built-in field. Nobody removes the first one because the first one was a field, not code, and it is easy to forget a field.
The third issue is the checkout. Squarespace commerce orders complete on Squarespace's own hosted pages. You do not control the markup there, and neither does any tool looking at your site from outside. That places a hard limit on what a scan or a manual page check can prove about Purchase, which is exactly the event Meta optimizes hardest against.
None of this is exotic. It is the normal state of a Squarespace site that has been running ads for a while. That is why a Squarespace pixel audit is a specific job rather than a glance at whether the pixel loads on the homepage.
Five findings cover most of what we see. Work through them in order, because the first one changes what the rest of your numbers mean.
The most common finding. The pixel ID is in the built-in Meta pixel field, and the full pixel snippet is also in code injection, in a single page's header, or in a Google Tag Manager container. Both load on every page. PageView counts twice, and any event covered by both layers doubles with it.
Why it matters: your reported volume inflates and Meta optimizes against a signal that overstates how often people act. Deduplication does not help here. The event ID mechanism matches a browser event to a server event. Two browser pixels firing the same event are two real events as far as Meta is concerned.
The built-in connection gives you the base pixel and, on stores, a limited set of commerce events. On a service site, a portfolio, or a booking site, that means PageView is the only thing Meta ever receives. You can still run traffic campaigns and build audiences, but there is no conversion for Meta to optimize toward, so a conversion campaign has nothing to bid against.
Why it matters: a base-only install is the gap we find most often on Squarespace. The tracking is not broken, it is thin. Decide which action is your conversion, then make sure an event exists for it.
There is no interface in Squarespace for adding a Lead event to a form or a Schedule event to a booking. Custom and standard events require code, and code requires a plan tier that includes code injection. Check your own settings rather than trusting a plan name you read somewhere, because Squarespace revises its plan structure periodically and the setting in your account is the only reliable answer. If code injection is not available to you, your realistic options are a thank-you page or confirmation URL you can point a custom conversion at, or a plan change.
Squarespace commerce checkout runs on hosted pages behind a real cart and a real payment. No external scanner can walk that path, and neither can you by simply loading a URL. That means the Purchase event, its value and currency parameters, and anything the checkout adds cannot be proven from the storefront. Treat every claim about checkout tracking as needing verification until you have watched a real test order arrive in Events Manager.
Squarespace offers cookie and privacy controls, and many sites add a third-party consent tool on top. Either can hold marketing tags until a visitor accepts, and in some regional configurations they block by default. Whichever tool sits in front, it has been silent for you since the day you accepted it, so your own checks keep passing. The shortfall becomes visible only when you line up session counts against Meta's event volume and find the second number lower. Test in a private window from a region where your banner is enforced.
About an hour, on the live site, with a real test conversion at the center of it.
Check four places before testing anything. The built-in Meta pixel field in your site settings, and write down the ID it holds. Site-wide code injection, header and footer, searching for fbq and connect.facebook.net. Per-page code injection on your key pages, which is easy to forget because it lives inside individual page settings. And any Google Tag Manager container loading on the site. If the same pixel ID appears in more than one of those, you have your first finding.
Install the Meta Pixel Helper extension and visit a page of each type: homepage, a standard content page, a blog post, a product page if you run commerce, and any campaign landing page. It is fast at spotting a second pixel ID and at showing which events fire and what parameters are attached. If it shows only PageView everywhere, that is finding number two.
Open developer tools, go to the Network tab, and filter for facebook.com/tr. Each pixel fire is a request you can inspect. The ev parameter is the event name, the id parameter is the pixel ID that sent it, and the rest shows exactly what was attached. Two requests with the same ev value on one page load is a duplicate you can prove.
Submit your own form, book your own appointment, or place a real order you can refund. Watch the network tab as you go. If no new request to facebook.com/tr appears at the moment of conversion, the conversion event does not exist, regardless of what any settings screen says.
Open Events Manager, choose your dataset, and go to Test Events. Copy the test code, open your site in a private window, and repeat the path from step 4. This is the only way to see inside hosted checkout, and it is the most useful check on the list, because it shows what Meta received rather than what your page tried to send.
Back in Events Manager, look at event match quality on your conversion event, the diagnostics tab for warnings Meta has raised, and whether your commerce events carry value and currency. An event that fires but carries thin customer data is worth less than a clean one. For the cross-platform version of this scoring, our full Meta pixel audit guide covers the fixes in more depth.
Squarespace does not give you a native Conversions API connection, so server-side events have to come from elsewhere: a server-side Google Tag Manager container, a CAPI gateway, or your CRM or booking system sending the conversion once it receives the submission. For a service business that last route is often the practical one, because the CRM holds the email and phone number that lift event match quality and the browser does not.
The check that matters: once server-side events are live, confirm in Events Manager that the event shows both browser and server as connections and that deduplication is being recognized. Two channels sending the same conversion without a shared event ID is worse than one channel sending it well.
Server-side tracking is a second path for the same events, not a replacement for a clean pixel. If you want the longer comparison, we wrote it up in Meta pixel vs Conversions API. And once your events are trustworthy, expect your reported numbers to move, which is the subject of why your ROAS numbers are wrong.
Steps 1 through 3 can largely be done for you. Our free Meta pixel audit detects Squarespace automatically and scans your live site the way an outside browser sees it: which pixel IDs load, whether the same ID appears through more than one install path, which funnel events it can find across your key public pages, whether the events it can read carry value, currency, and content IDs, what else is in your tracking stack, and whether a consent banner is sitting in front of your tags. It opens your Google Tag Manager container if you have one and reads the Meta tags inside it, and it checks Meta's public config for each pixel ID it finds.
It is upfront about the Squarespace wrinkle. Hosted checkout, anything behind a form submit, and Conversions API internals cannot be verified from outside, so the scan marks them as needs verification instead of pretending. Those are the items you confirm with Test Events in step 5, and we spell out exactly where that line sits on the audit methodology page. The scan takes about 20 seconds, needs no login and no pixel ID, and gives you a prioritized fix list.
Other platforms fail in different ways. We have the same walkthrough for Shopify, Webflow, and Wix. And if you would rather someone else own the whole thing, that is what our interior design and eCommerce practices do: tracking verified before any campaign work, then kept verified while spend scales.
Almost always because the same pixel ID is in two places. Squarespace has a built-in field for a Meta pixel ID, and at some point the full pixel snippet also went into code injection, into a page header, or into a Google Tag Manager container. Both load on every page, so PageView counts twice. Keep one install path and remove the other. Deduplication by event ID matches a browser event to a server event, it does not cancel out two browser pixels.
No. The built-in connection loads the pixel and covers the base PageView across your site, plus a limited set of commerce events on stores. It gives you no control over which events fire, no way to add parameters, and no way to define custom events for the actions specific to your business. Anything beyond that list needs code, which means it needs a plan that allows code injection. Confirm what is actually arriving in Events Manager rather than assuming the field covers your funnel.
Code injection is a paid feature and it is not available on every plan, so check your own billing settings rather than trusting a plan name from an article. Open your site settings and look for the code injection area. If it is absent or shows an upgrade prompt, your current plan does not include it and the built-in pixel field is the only install path available to you. Squarespace changes plan structures periodically, so the setting in your account is the answer.
Only partially. Squarespace commerce orders complete on hosted checkout pages that an outside scanner cannot walk through, because reaching them requires a real cart, a real payment, and pages that are not publicly crawlable. A scan can tell you which pixel IDs load on your storefront, whether more than one install path exists, and which events it can see on public pages. Purchase itself has to be confirmed with a real test order in Events Manager Test Events.
Usually because PageView is the only event that exists. The built-in connection fires the base pixel on every page, and unless commerce events are enabled on a store or someone added event code, there is nothing else to see. It is the expected result of a base-only install, not a bug. Decide which action on your site is the conversion, add the event for it, and verify it in Events Manager.
Every Squarespace account we take on starts with tracking verified end to end: one install path, a real conversion event on the action that matters, checkout confirmed with a test order, deduplication checked. Scan your site yourself in 20 seconds, or have us walk it with you.