You keep analytics and conversion tracking through a migration by making sure the tracking tag is present on every page of the new site, reconfiguring your events and conversion goals to match the new structure, and keeping the same analytics property so your historical data stays continuous. The reason this needs deliberate attention is that tracking breaks for predictable reasons. The new platform may not carry over the tracking tag, so pages stop being measured. The events and conversion goals were tied to old page paths, button identifiers, or form locations that changed, so conversions stop registering. Or a new property or measurement identifier is created, splitting the history. Your past data is not lost, it lives in the analytics property where it was collected, but new data only flows if the tag is in place and the goals are rebuilt. This matters beyond reporting, because accurate measurement is how you verify the migration held and diagnose any drop. WPBuildAI scans your site and returns the URL list and page types, so you can confirm the tracking tag is present on every kind of page after the move.
Budget for a channel that classic analytics reports poorly: SE Ranking measured AI referral traffic growing sixteenfold from 2024 to 2026, with those visitors spending 67.7 percent longer on site than organic-search visitors, so tagging that treats it as generic referral traffic will understate it.
Why measurement matters during a migration
It is tempting to treat analytics as a reporting nicety you can fix later, but during a migration it is your instrument panel. A migration is exactly when you most need to know whether traffic and conversions held, and broken tracking blinds you at the worst moment. If the tag falls off and you do not notice, you cannot tell whether a quiet week is a real drop or just missing data, and you lose the ability to react. Traffic and conversions concentrate on a minority of pages, as the Ahrefs study shows, so losing measurement on the wrong pages hides the most important signal. Keeping analytics working is therefore not separate from a safe migration; it is part of being able to confirm the migration was safe.
Cause one: the tracking tag is missing
The most basic failure is the tag simply not being on the new pages. Your analytics relies on a snippet that loads on each page, and when you rebuild on a new platform, that snippet has to be added again, usually in a template so it appears everywhere. If it is added to some templates but not others, you measure some page types and miss others; if it is forgotten entirely, measurement stops. Web Almanac 2024 (HTTP Archive) is a reminder of how many scripts and page types a site has, so confirming the tag on every template, not just the homepage, is the first and most important check. Reinstall the tag deliberately and verify its presence across all page types before and after launch.
Cause two: events and goals point at the old structure
The subtler failure is conversion tracking that breaks even when the basic tag is present. Conversions are usually defined as events or goals tied to specific things: a visit to a thank you page at a certain URL, a click on a button with a certain identifier, a submission of a form in a certain place. A migration changes those paths and elements, so the goal that watched for the old thank you URL never fires because the new one has a different address, and the event tied to an old button identifier never triggers because the button was rebuilt. The fix is to inventory your conversion definitions and reconfigure each to the new structure, so they watch for the new URLs, the new elements, and the new flows. This is the part most often forgotten, because the tag is present and basic pageviews work, masking that conversions have gone silent.
Cause three: a new property splits the history
The third failure is accidental fragmentation of your data. If the migration creates a new analytics property or a new measurement identifier rather than reusing the existing one, new data flows into a fresh, empty property while your history sits in the old one, so you lose continuity. Like Search Console, analytics data is bound to the property it was collected in, the same principle as in keeping Search Console data after a migration. So unless you have a deliberate reason to start fresh, reuse the same property and measurement identifier on the new site, so before and after sit in one continuous record. If a new property is unavoidable, keep the old one for its history and annotate the changeover so the seam is documented rather than confusing.
Verify tracking before and after launch
Because tracking failures are invisible until you check, verification is the whole discipline. Before launch, on staging, confirm the tag loads on every page type and that test conversions register against the reconfigured goals, the same pre launch rigor as testing a migration before going live. After launch, watch real time data to confirm pageviews and conversions are flowing, and check that the numbers are plausible rather than zero or wildly off. Annotate the migration date in your analytics so future analysis knows where the change happened. This before and after verification turns tracking from an assumption into a confirmed fact, so when you look at post migration performance, you are reading real data, not a measurement gap pretending to be a traffic drop.
Separate analytics from Search Console
It helps to keep two kinds of data straight, because they answer different questions and break differently. Analytics, your tag based measurement, tells you what visitors did on your site, including conversions, and depends on the tag and goals being correct. Search Console tells you how you appear in search, and depends on property setup and verification. A migration can break either or both, and the fixes differ: re install the tag and rebuild goals for analytics, verify the property and use change of address for Search Console. Keeping both working gives you the full picture, what search sent you and what those visitors did, which together let you judge whether the migration preserved not just rankings but the outcomes that matter, and to diagnose any SEO drop with real numbers.
Steps to keep tracking through a migration
- Re-add the tracking tag to every template and page type on the new site.
- Reuse the same analytics property so history stays continuous.
- Inventory your conversion goals and what each is tied to.
- Reconfigure each goal to the new URLs, elements, and flows.
- Verify on staging that the tag loads and test conversions register.
- Watch real time after launch and annotate the migration date.
Worked example: preserving conversion tracking
Imagine a business migrating a site that tracks form submissions and a checkout completion as conversions. The team adds the tracking tag to every template on the new site, reusing the existing analytics property so history is unbroken. They inventory their goals and find the form submission goal watched for a specific thank you URL and the checkout goal watched for a button identifier, both of which change in the rebuild. They reconfigure the goals to the new thank you URL and the new button, then test on staging by submitting the form and completing a test checkout, confirming both register. After launch they watch real time data, see conversions flowing, and annotate the migration date. When they later review performance, the numbers are trustworthy because measurement never lapsed, so they can confirm the migration held rather than guessing through a data gap.
Limitation: tracking measures the migration, it does not protect rankings
It is fair to be clear about scope. Keeping analytics working preserves your ability to measure the migration; it does not, by itself, protect your rankings or traffic, which depend on redirects, content, and the rest of the migration fundamentals. Perfect tracking on a botched migration will faithfully record the decline, which is useful but not a remedy. So treat tracking continuity as your instrumentation, the thing that lets you see whether the real protective work succeeded, rather than as protection itself. The two go together: do the migration carefully to preserve rankings, and keep tracking intact to confirm that you did and to catch anything that slipped, with measurement as the witness rather than the safeguard.
Common mistakes
- Adding the tag to some templates but not all page types.
- Assuming basic pageviews working means conversions are tracked.
- Leaving goals pointed at old URLs, buttons, or forms that changed.
- Creating a new analytics property and splitting the history unnecessarily.
- Not verifying tracking on staging and after launch, so gaps go unnoticed.
Key points
You keep analytics and conversion tracking through a migration by re-adding the tracking tag to every page, reconfiguring events and conversion goals to the new structure, and reusing the same analytics property so history stays continuous. Tracking breaks when the tag is missing from some templates, when goals still point at old paths or elements, or when a new property splits the data, and your history is never deleted, only interrupted, since it lives in the property. Verify on staging and after launch, and annotate the migration date, because broken measurement hides whether the migration held. Remember that tracking is your instrument, not your safeguard: it measures the migration rather than protecting rankings, so pair it with the real protective work. WPBuildAI scans your site and returns the URL list and page types, so you can confirm the tracking tag is present on every kind of page after the move. Send your web address for a free analysis.
Not affiliated with WordPress, Lovable, Webflow, Shopify, Wix, or Squarespace.