Why did my tracking break after a website redesign?
Redesigns break tracking because tracking is almost never on the QA list. The container gets dropped from the new templates, URLs change so every URL-based trigger stops matching, the data layer is rebuilt with different key names, and forms move to a new library whose success event nothing is listening for. It usually goes unnoticed for weeks because the site looks fine and the conversion decline reads as a seasonal dip — which is why the first diagnostic is comparing your backend orders against reported conversions for the same dates.
Free30 minutesNo obligation
Tracking broke after redesign · what breaks
What this looks like when it's happening to you — Tracking broke after redesign
- 01
Conversions fell on the launch date
A step change rather than a slope.
- 02
Orders unchanged in your own store
The business is fine; the measurement isn't.
- 03
Some events still working
Which makes it look like a partial problem rather than a systematic one.
Tracking broke after redesign · the fix
What changes once it's fixed — Tracking broke after redesign
Tracking restored across the new site
Verified event by event rather than assumed from one spot check.
The authoritative events moved off URLs
So the next redesign can't break them the same way.
A pre-launch checklist
So this stops being a recurring cost.
Tracking broke after redesign · architecture
Why your conversion data was wrong in the first place — Tracking broke after redesign
Fixing this specific fault is worth doing. But it is worth understanding why it happened, because the same underlying weakness produces a different symptom every few months — and the reason your conversion data is wrong is almost never the tag itself.
- 1
Your conversion depends on a browser that is being restricted on purpose
A browser-side tag has to survive the page loading, the visitor staying, the script executing and the request leaving. Every one of those is now contested. The order in your database is certain; the browser event reporting it is not, and that gap is where wrong numbers come from.
- 2
Safari caps the cookie your attribution depends on
Intelligent Tracking Prevention limits cookies written by JavaScript to seven days, whatever expiry you set. Any customer who takes longer than a week to decide comes back as a stranger, so the sale is recorded and credited to nobody. A cookie your own server writes in an HTTP response is not subject to that cap — which is the single largest practical difference between browser-side and first-party server-side tracking.
- 3
Ad blockers remove the tag before it can run
A blocked pixel does not error, retry or warn anyone. The visitor buys, the order lands in your store, and no platform ever hears about it. First-party events sent from your own subdomain aren't filtered the same way, because they are not a third-party request.
- 4
Consent banners stop tags, sometimes when they didn't need to
Where consent is genuinely required, losing the event is correct. What is not correct — and what we find repeatedly on US-majority accounts — is an EU-style prior-consent banner applied to every visitor, discarding conversions no law asked you to discard. A server container enforces the real decision at the container rather than hoping each vendor script honours a flag.
- 5
The checkout can end somewhere your tag isn't
Wallets and hosted payment pages can be abandoned after the money moves. The customer paid; the confirmation page never rendered; the browser event never fired. Sending the purchase from the order record instead means the conversion arrives whether or not anyone came back to your site.
- 6
What that adds up to
Each of these is a separate route to tracking broke after redesign, and they compound. First-party server-side tracking doesn't patch them one at a time — it moves the money event off the browser entirely, so the order in your backend is what gets reported. That is why we reconcile against your own order records and put 95%+ accuracy in writing: with the event sourced from the order, the number is checkable rather than hopeful.
Tracking broke after redesign · normal or broken
Some of this is supposed to happen — Tracking broke after redesign
Half the time nothing is broken and the number is being read wrong. Knowing which is which stops you paying to fix something that was never a fault.
Normal, not a fault
A brief dip during migration
DNS and caching can cause a short genuine drop. A sustained one is a break.
Session counts shifting slightly
New URL structures and redirects change how sessions are counted.
Actually broken
Container missing from the new templates
The single most common redesign casualty.
URL structure changed
Every URL-based trigger silently stops matching.
Data layer rebuilt with different key names
Variables resolve to undefined and events send empty values.
Forms moved to a new library
The old success event no longer exists, so nothing fires.
Tracking broke after redesign · diagnose
How we find out why did my tracking break after a website redesign
Always in this order. Each step eliminates a class of cause, so by the last one there is usually a single explanation standing.
- 01
Compare backend orders to reported conversions for the launch dates
This separates a measurement break from a business change immediately.
- 02
Confirm the container is present on every key template
Home, product, cart, checkout, confirmation, and every form page.
- 03
Complete a live test transaction on the new site
Real device, real order, watching requests.
- 04
Check every URL-based trigger against the new structure
Most will need rewriting.
- 05
Check data layer key names against what the tags expect
A rename breaks values without breaking events.
Tracking broke after redesign · prove
How we prove it's actually fixed — Tracking broke after redesign
The tag firing again proves the tag fires. These prove the numbers are right.
Source of truth
Your backend orders for the dates around launch
- Every key event verified on the new site on a live transaction.
- Backend orders reconciled against reported conversions across the launch window.
- Authoritative events confirmed firing from records rather than URLs.
- Reconciled against your backend orders for the dates around launch for a fully closed window, matched on ID rather than on totals.
- No record counted twice, checked across the whole window rather than spot-checked.
- The same check repeated 30 days later, because a fix that holds once and drifts is the harder failure to catch.
Tracking broke after redesign · free audit
What we check in the free audit
- Compare backend orders to reported conversions for the launch dates
- Confirm the container is present on every key template
- Complete a live test transaction on the new site
- Check every URL-based trigger against the new structure
- Check data layer key names against what the tags expect
Checked against
Your backend orders for the dates around launch
Free30 minutesNo obligation
Tracking broke after redesign · when not to buy
When you don't need us for this — Tracking broke after redesign
Most of these you can do yourself, and we would rather you did.
- You have a staging site and can run the checks before launch — that is far cheaper than fixing it after.
- You know which template lost the container and can add it back.
- Your backend orders fell too, in which case this is a business change, not a tracking one.
Tracking broke after redesign · what we deliver
What we do about it — Tracking broke after redesign
Full inventory against the new site
Every event re-verified on the new templates, not just the ones someone remembers.
Purchase and lead events fired from records
Backend order and CRM record, so URL changes are irrelevant to them.
Tracking added to the release checklist
The cheapest fix available, and the one that prevents recurrence.
Pricing
Pick the package that fits your ad spend
Browser-side starter
$400One-time fee · lifetime ownership
We fix the fault in your existing browser-side setup and verify it on a live transaction. Honest disclosure: this repairs what you have, it does not make it durable. If you spend $1K+/month on paid media, the fault will recur the next time Safari, a consent banner or a checkout change moves under you — the server-side tier is what stops that.
- Root cause found and fixed, not worked around
- Verified on a live transaction, not in preview
- Reconciled against your own order records
- Written handover documenting what changed and why
1st-party server-side
Recommended$800One-time fee · most popular
The tier that removes the whole class of failure rather than this instance of it. Your money events stop depending on the browser: they are sent from your order records through a first-party server container on your own subdomain, so iOS, ad blockers, consent banners and interrupted payment redirects can no longer take them away. Built in 2–4 days. You own the stack outright — no monthly SaaS.
- First-party server container on your own subdomain
- Purchases sent from your order records, not the browser
- Meta, Google, TikTok, Microsoft and LinkedIn all fed server-side
- Deduplicated on a shared event ID, verified at every destination
- First-party cookies beyond Safari's 7-day cap on JavaScript-set cookies
- 95%+ conversion accuracy and 8+ Meta EMQ, guaranteed in writing
Full 1st-party stack
$1,800One-time fee · lifetime ownership
Every paid-media channel server-side, end to end, plus the offline loop. For advertisers whose spend makes an attribution leak more expensive than the build. Pay once, own everything.
- Everything in 1st-party server-side
- Pinterest, Snapchat, Reddit and LinkedIn CAPI
- CRM and offline conversion loop, so closed revenue reaches bidding
- Refunds and cancellations reversed at every destination
- Klaviyo identity stitching, BigQuery and Looker Studio
- Monitoring, so the next break surfaces in days rather than a quarter
FAQ
Tracking broke after redesign questions, answered
Only where click IDs were captured and can be imported offline. Otherwise those events were never recorded.
Put tracking verification on the pre-launch checklist, and fire your money events from backend records rather than page URLs.
Events tied to URLs break when URLs change; events tied to backend records don't. That difference is the whole argument for the latter.
Usually two to four days including verification, assuming the new site is stable.
More on Tracking broke after redesign
Free · 30 min
Get tracking broke after redesign diagnosed properly
Free30 minutesNo obligation
