A site redesign is one of the highest-risk events for GA4 tracking. Developers are focused on the site — the design, the performance, the user experience. Analytics tracking is rarely on the critical path. Tags get missed. Data layers change. URL structures shift. Event triggers that relied on specific page elements stop firing because those elements no longer exist.
The break happens immediately. The discovery usually doesn't happen for weeks.
By the time someone notices that conversion data looks off, or that micro-conversion events have disappeared from reports, the damage is done. You have a gap in your data that can't be retroactively filled — and if a campaign was running during that period, you may not be able to accurately evaluate its performance.
The way to prevent this is an audit before the redesign goes live — ideally on staging — and a verification check immediately after launch. This post covers both.
What Actually Breaks
Understanding what typically breaks in a redesign helps you know where to look. Most tracking failures after a redesign fall into one of these categories:
Tags and triggers stop firing
GTM tags rely on triggers — conditions that tell the tag when to fire. Those triggers often reference specific page elements: a button with a particular CSS class, a form with a specific ID, a page URL that matches a pattern. When a redesign changes the markup, renames elements, or restructures pages, the trigger conditions no longer match and the tag silently stops firing.
This is the most common failure mode. A conversion tag that was working perfectly before the redesign stops firing on the new thank-you page because the URL changed from /thank-you to /order-confirmation. Nobody updated the trigger.
The data layer changes
Many GA4 implementations rely on a data layer — a JavaScript object that passes information from the site to GTM. If the redesign changes how the site populates the data layer — different variable names, different data structures, values passed at different points in the page lifecycle — GTM variables that read from the data layer stop returning the right values.
Tags keep firing. The data they send is wrong or empty. This is harder to catch than a tag that stops firing completely, because the event still appears in GA4 — it just has missing or incorrect parameters.
URL structure changes break event tracking
If your tracking relies on URL matching — page view events, conversion triggers, funnel steps — a URL restructure will break it. A redesign that changes /products/category/item to /shop/item will break any trigger or goal that was built around the old URL pattern.
This also affects UTM parameters. If the redesign changes how URLs are handled — redirects that strip query strings, JavaScript navigation that loses URL parameters between pages — UTM data disappears silently. Campaign traffic arrives, loses its attribution, and gets classified as Direct or Unassigned.
Micro-conversion events disappear
Micro-conversions — the smaller actions that indicate progression toward a primary goal — are often the first casualties of a redesign. They're not the primary KPI so they don't get the same verification attention. A video play event that relied on a specific video embed structure. A scroll depth trigger that was calibrated to the old page layout. A form interaction event tied to a form that was redesigned or replaced.
These events disappear quietly. You don't notice until you're trying to analyse the funnel and realise you have no data for half the steps.
Audit on Staging Before Launch
The best time to catch redesign tracking issues is before the site goes live. If your team has a staging environment, use it — walk through every critical user journey and verify that tracking fires correctly on the new version before it reaches production.
Staging has limitations. It doesn't always perfectly replicate the production environment — different domains, different data layers, different third-party integrations. But it catches the majority of obvious failures before they affect real data.
What to verify on staging:
- Every conversion event fires on the correct pages with the correct parameters
- Micro-conversion events are intact — form interactions, video plays, scroll events, CTA clicks
- Data layer variables are returning the expected values on the new page structure
- UTM parameters persist through the key user journeys — they don't get stripped by redirects or JavaScript navigation
- URL-based triggers have been updated to match the new URL structure
- Payment processor referral exclusions are still in place for any checkout flow changes
- The GA4 Measurement ID is correctly deployed on all pages — not just the home page
Use GTM's preview mode to walk through each journey in real time. Watch what fires, what doesn't, and what parameters are being sent. Don't rely on GA4's DebugView alone — it introduces a delay that makes it harder to correlate tag firing with specific user actions.
Verify Immediately After Launch
Even with a thorough staging audit, a post-launch verification is essential. Production environments have differences — real user traffic, live integrations, actual UTM parameters arriving from campaigns — that staging can't fully replicate.
Run these checks within the first 24-48 hours of a redesign going live:
- Conversion events are firing in GA4 DebugView and appearing in real-time reports
- Micro-conversion events are present and recording correctly
- Source/medium attribution looks normal — no unexpected spike in Direct or Unassigned traffic
- UTM parameters from any active campaigns are coming through correctly
- E-commerce funnel events are firing in the correct sequence (view_item → add_to_cart → begin_checkout → purchase)
- No duplicate event firing — redesigns sometimes cause tags to fire multiple times per interaction
- Internal traffic filter is still active — developers testing the new site shouldn't pollute production data
Compare the first few days of post-launch data against the equivalent pre-launch period. A significant drop in conversion rate, engagement rate, or specific event counts that can't be explained by normal variation is a signal that something broke in the launch.
The GTM Checklist for Redesigns
Most redesign tracking failures originate in GTM. Before a redesign launches, the analytics team should work through the container with the development team to identify everything that needs to be updated.
- Review all triggers that reference specific CSS selectors, element IDs, or class names — flag any that will be affected by markup changes
- Review all URL-based triggers and update them to match the new URL structure
- Review all data layer variable references — confirm variable names and structures are unchanged or update accordingly
- Test every tag in GTM preview mode against the new page structure before launch
- Document all changes made to the GTM container as part of the redesign — this becomes your changelog if something breaks later
If the development team is making data layer changes as part of the redesign, get the new data layer specification before they build it — not after. Retrofitting GA4 tracking to a data layer that wasn't designed with analytics in mind is significantly harder than being involved in the specification from the start.
Run a Full Audit Post-Launch
A manual verification covers the obvious failures. A full audit catches everything else — the issues that didn't break completely but are now returning incorrect data, the configuration drift that accumulated during the redesign process, the settings that nobody checked because they weren't part of the build.
Running a full GA4 audit in the week after a redesign goes live gives you a complete picture of the property's health on the new site — and a baseline to compare against in future. It takes 60 seconds with the automated tool.
Run your post-redesign audit — $79 →
