A website migration can look completely successful while quietly damaging the data a marketing team depends on. Pages load, redirects work, rankings remain stable, and forms appear functional, yet conversions suddenly disappear from reports or paid campaigns start receiving incomplete signals. The problem is that analytics is often treated as something that will simply follow the website into its new environment. In reality, website tracking mistakes made during migrations can affect everything from GA4 events and advertising pixels to ecommerce revenue, campaign attribution, consent settings, and CRM data. Without careful preparation, teams can spend weeks trying to work out whether business performance changed or their measurement system did.
Migrating Without a Tracking Inventory
Before development begins, document what the existing website is measuring and how that measurement works.
Document Existing Analytics Tools
Create an inventory of GA4, Google Tag Manager, advertising pixels, heatmaps, call tracking, consent tools, CRM integrations, and any other systems receiving website data.
This exercise often uncovers tracking that nobody realized was still active. It also reveals tools that are no longer needed and should not automatically be transferred to the new site.
Record Important Events and Conversions
List the actions the business actually uses to evaluate performance. These may include purchases, form submissions, account registrations, downloads, demo requests, phone calls, or newsletter subscriptions.
For each action, document what triggers it and where the resulting data goes.
Identify Where Tracking Is Implemented
Tracking may live in GTM, a WordPress plugin, theme files, custom JavaScript, server-side configurations, or third-party applications.
Knowing where each component originates is essential because a migration may replace some of those systems entirely.
Do Not Assume Existing Tracking Will Transfer Automatically
A new site may use the same domain and analytics account while behaving very differently underneath.
Understand What Changes During Migration
A redesigned frontend can change buttons, forms, page templates, URLs, element IDs, CSS classes, and data layer behavior. Any tracking dependent on those elements may stop working even if the analytics tag itself still loads.
This is one reason pageviews can continue appearing normally while important conversion events disappear.
Review Hardcoded Scripts
Tracking scripts placed directly inside an old theme or template are particularly easy to lose. When the old files are replaced, the tracking disappears with them.
Audit hardcoded implementations before retiring the previous site.
Check Plugin-Based Tracking
Reinstalling the same analytics plugin does not necessarily recreate the previous configuration. Settings, integrations, exclusions, and event rules should all be checked in the new environment.
Establish a Pre-Migration Analytics Baseline
One of the most useful safeguards against website tracking mistakes made during migrations is a clear record of what normal performance looked like before anything changed.
Record Core Website Metrics
Capture traffic, leads, purchases, revenue, conversion rate, and other important KPIs. The goal is not to freeze performance at those levels but to create a reference point.
If reported conversions fall 60 percent immediately after launch while CRM lead volume remains stable, the baseline gives the team a reason to investigate measurement before assuming the website has stopped converting.
Document Channel Performance
Record how organic search, paid search, email, social, referral, and direct traffic normally contribute to sessions and conversions.
Large attribution changes after launch can then be spotted more quickly.
Preserve Historical Context
Consider seasonality, promotions, weekday patterns, and other factors that normally affect performance. A useful baseline provides context rather than a single snapshot.
Update Tracking When URLs Change
URL changes can break tracking rules that were built around the old site structure.
Review URL-Based Triggers
GTM triggers, audience definitions, content groups, and conversion rules may depend on specific paths or page names.
If /request-demo/ becomes /book-a-demo/, a trigger watching the old URL may never fire.
Update Thank-You Page Tracking
Many websites still use confirmation pages as conversion signals. When these pages move, disappear, or are replaced by inline form messages, the associated tracking needs to change as well.
Test Redirected URLs
Campaign links should be tested through the complete redirect chain. Confirm that UTM parameters and other important identifiers survive redirects rather than disappearing before analytics can record them.
Test Google Tag Manager After Migration
Seeing the GTM container in the source code is only the first check.
Confirm the Correct Container Is Installed
Make sure the production container appears on all required templates and that an old, staging, or duplicate container has not been introduced.
Review Triggers and Variables
Triggers based on clicks, CSS selectors, element IDs, URLs, or DOM structure can break after a redesign. Test them against the new interface rather than assuming their old logic remains valid.
Validate the Data Layer
If tracking relies on a data layer, confirm that expected events and variables are still pushed with the correct names and values. Development changes can alter the data structure without producing an obvious frontend problem.
Verify GA4 Events and Conversions
A working GA4 pageview does not prove that the analytics implementation survived the migration.
Test Core Events Individually
Trigger each important action manually. Submit forms, complete registrations, click tracked elements, and follow other conversion journeys.
Check that the expected events appear with the correct event names.
Review Conversion Configuration
Confirm that the events representing meaningful business outcomes are still configured appropriately in GA4 and any connected reporting systems.
Check Event Parameters
An event can fire while still losing useful information. Verify parameters associated with forms, products, pages, campaigns, transactions, or other reporting dimensions.
Test Ecommerce Tracking From Product View to Purchase
Ecommerce migrations deserve particularly careful QA because small tracking errors can distort revenue reporting significantly.
Test the Complete Purchase Journey
Follow the customer journey from product view through cart, checkout, payment, and purchase confirmation. Verify the expected ecommerce events at each important stage.
Validate Transaction Data
Check transaction IDs, product names, quantities, prices, currency, tax, shipping, and revenue values where applicable.
A purchase event that reports the wrong amount is not a successful implementation.
Watch for Duplicate Purchases
Reloading confirmation pages, returning from payment providers, or firing the same event through multiple implementations can duplicate transactions.
Compare analytics transactions with actual order records to catch discrepancies.
Do Not Forget Advertising and Remarketing Tags
A tracking failure can affect more than reporting. It can also change how advertising platforms optimize campaigns.
Audit Advertising Pixels
Verify the tags used by Google Ads, Meta, LinkedIn, and other relevant platforms. Check both basic page tracking and important event signals.
Verify Conversion Tracking
Test the conversions that paid campaigns use for optimization. If the website still generates leads but the advertising platform stops receiving them, automated bidding may begin working from incomplete information.
Check Remarketing Audiences
Audience rules may depend on URLs, events, or page categories that changed during migration. Review whether the intended visitors still qualify for relevant audiences.
Include Consent Management in Migration QA
Consent behavior can change when scripts, plugins, or templates are rebuilt.
Verify the Consent Platform
Check that the consent banner appears correctly and communicates with the tracking setup as intended.
Test Tag Behavior
Confirm which tags fire before consent and which require a particular user choice. The implementation should reflect the site’s configured consent requirements.
Test Multiple Consent Scenarios
Do not test only “accept all.” Check rejection, partial consent, and changing a previous selection to understand how tracking behaves in each state.
Protect Campaign Attribution
Some of the most expensive website tracking mistakes made during migrations are not missing events but incorrect attribution. Conversions continue to appear, yet the source responsible for generating them is lost.
Test UTM Parameters
Open campaign URLs containing UTM parameters and follow the actual visitor journey. Confirm that campaign information is retained and recorded.
Review Redirect Behavior
Redirect rules can accidentally strip query parameters. This is particularly important when large numbers of URLs are being redirected during a domain or structural migration.
Test Cross-Domain Journeys
If checkout, booking, payment, or account creation occurs on another domain or subdomain, test the complete journey. Cross-domain tracking should preserve the original acquisition source rather than creating an artificial new session.
Watch for Self-Referrals
Changes to domains, subdomains, payment providers, or third-party systems can introduce new referral problems.
A user might arrive through a paid campaign, move to an external payment system, and return to the website. If that journey is configured incorrectly, the payment provider can appear to be responsible for the conversion.
Compare referral and direct traffic before and after migration. Sudden unexplained increases can indicate an attribution problem rather than a real change in visitor behavior.
Test Every Important Form
Forms frequently change during redesigns, especially when a site moves to a new builder, CRM integration, or form plugin.
Verify Successful Submissions
Where appropriate, track successful submissions rather than simply clicks on the submit button. A button click does not necessarily mean that validation passed or that the lead reached its destination.
Check Different Form Types
Contact forms, quote requests, demo forms, newsletter subscriptions, registrations, and other lead sources should be tested separately.
One working form does not prove that every form uses the same tracking logic.
Verify CRM Data
Check whether campaign source, UTM values, landing page information, or other required fields still reach the CRM. Analytics and CRM reporting should tell compatible versions of the customer journey.
Keep Staging Traffic Out of Production Reporting
Migration testing can generate hundreds of artificial pageviews and events.
Make sure staging environments use the intended measurement configuration. Depending on the setup, that may mean separate measurement properties, blocked production tags, or another method of preventing test activity from contaminating business reports.
Developer and QA activity should also be handled appropriately so testing does not create artificial conversions immediately before launch.
Create a Formal Tracking QA Process
Tracking should have its own migration checklist rather than being tested casually while other launch tasks are underway.
Build a Test Plan
List critical pages, events, forms, conversions, ecommerce actions, advertising tags, consent scenarios, and integrations. For each one, define what should happen.
This gives developers, marketers, and analysts a shared reference for testing.
Test Across Devices and Browsers
Mobile and desktop experiences may use different layouts or interactions. A trigger that works on a desktop navigation element may fail on the mobile equivalent.
Important journeys should therefore be tested in the environments customers actually use.
Record Expected and Actual Results
Document failures, fixes, and retests. A structured record prevents the same issue from being repeatedly discovered by different people.
Continue Checking Tracking After Launch
Pre-launch QA happens in a controlled environment. Real users are much less predictable.
Monitor the First Hours
Watch for unusual drops or spikes in sessions, conversions, revenue, and events immediately after migration. Large changes deserve investigation while the launch is still fresh.
Compare the First Days With the Baseline
Review channel mix, conversion rates, lead volume, ecommerce revenue, and attribution against the pre-migration baseline.
Do not expect perfect continuity, especially after a substantial redesign, but investigate changes that are difficult to explain through user behavior alone.
Keep Monitoring
Some errors appear only on less common products, forms, devices, or user journeys. Continue tracking key metrics after the initial launch period instead of closing the analytics task after the first successful day.
Separate Measurement Loss From Performance Loss
A sudden decline after migration can trigger immediate concern, but the first question should be whether the underlying business activity changed.
Compare multiple sources. If GA4 reports half as many purchases but the ecommerce platform shows normal order volume, the problem is probably not customer demand. If analytics, CRM, advertising platforms, and sales systems all show a similar decline, a genuine performance issue becomes more plausible.
The same principle applies to apparent improvements. A sudden surge in conversions could result from duplicate event firing rather than a dramatically better website.
Build Tracking Into the Migration Process
Analytics works best when measurement requirements are defined before developers start rebuilding templates and user journeys.
Assign Ownership
Decide who owns the tracking inventory, technical implementation, QA, and post-launch monitoring. Without ownership, analytics tasks tend to fall between marketing, development, and external vendors.
Make Tracking Part of Launch Acceptance
Critical tracking should be treated like forms, redirects, or checkout functionality. If important conversion data is missing, the website is not fully ready simply because pages render correctly.
Document the New Setup
After launch, record how tags, events, triggers, conversions, consent logic, and integrations work.
This documentation becomes valuable during future redesigns, platform changes, and debugging.
Avoid Common Migration Tracking Mistakes
Checking only pageviews is one of the most common errors. A pageview confirms that some analytics code is running, but says very little about ecommerce, leads, attribution, advertising signals, or custom events.
Testing only the homepage creates a similar false sense of security. Most commercially important tracking occurs deeper in the customer journey.
Teams should also avoid reconstructing the previous analytics setup from memory after launch. An inventory created beforehand is much more reliable.
Finally, waiting for weekly or monthly reports to expose problems can result in significant gaps in historical data. Tracking failures are easier to correct when they are found during QA or immediately after launch.
Conclusion
A migration should preserve the ability to understand what users do just as carefully as it preserves content, URLs, functionality, and search visibility. That means documenting the existing measurement system, establishing a baseline, testing GA4 and GTM, validating ecommerce and lead journeys, protecting campaign attribution, checking consent behavior, and monitoring real traffic after launch. Most importantly, teams need to verify whether reported changes reflect actual customer behavior or simply a broken measurement system. Preventing website tracking mistakes made during migrations protects not only analytics reports but also the marketing, product, and investment decisions that rely on those reports being accurate.
