Your Search Console data is tied to the property it was collected in, so you keep it by understanding that it stays with the old property and by setting the new site up correctly alongside it, rather than expecting the history to move with you. This framing answers most of the worry at once: the data is not at risk of disappearing, it is anchored to where the URLs it describes lived. If your migration keeps the same domain and only changes URLs or platform, your existing property continues to collect data, so there is little to do beyond resubmitting your sitemap and watching the transition. If your migration changes the domain, your history remains in the old domain’s property and a new property must be created and verified for the new domain, so the data does not transfer but it is not lost either. In that case you also use the change of address tool to tell Google the site has moved. The practical advice is: verify the new site as its own property, keep the old property, use change of address for a domain move, and use both to compare before and after. WPBuildAI scans your site and returns the URL list, so you can line up old and new URLs when you compare the two properties.

There is more to preserve than there used to be: Google added Search Generative AI performance reports to Search Console on 3 June 2026, so a migration that loses property continuity now loses your AI Overviews and AI Mode visibility history alongside the classic performance data.

Data lives with the property, not the pages

The single fact that resolves this topic is that Search Console organizes data by property, and a property is tied to a specific domain or URL prefix. Your clicks, impressions, queries, and coverage history all sit in the property you set up, describing the URLs under it. So when you migrate, the question is not whether the data moves, it does not, but whether your migration changes the property the data belongs to. A same domain move stays within the same property; a domain change crosses into new property territory. Once you see that data is anchored to the property, the rest is just applying the right setup to your case, and the fear of losing your history mostly evaporates, because history is retained wherever it was collected.

Same-domain move: little to do

If your migration keeps the same domain, whether you are changing platform, redesigning, or restructuring URLs, your existing Search Console property keeps right on collecting, because the property still matches your site. Your history stays intact and continuous, and the new URLs under the same domain simply start appearing in the same property. The main action is to help Google discover the new structure by resubmitting your sitemap, as the sitemaps overview describes, and to watch coverage as the old URLs redirect and the new ones index. This is the easy case: there is no property to recreate and no history to worry about, just a transition to monitor within the property you already have, which is why a same domain move is reassuring on the data front.

Domain change: keep the old, verify the new

If your migration moves to a new domain, the picture changes but the data is still safe. Your history remains in the old domain’s property, which is exactly why you should keep that property rather than delete it. Meanwhile, the new domain needs its own property, which you create and verify so it starts collecting data for the new site. The history does not transfer into the new property, but it is preserved in the old one for reference. So the rule for a domain change is additive, not destructive: add and verify a new property, and retain the old one. Deleting the old property to tidy up is the one genuinely irreversible mistake here, because it discards the record of how your old URLs performed.

Use the change of address tool

For a domain move specifically, Search Console offers a change of address tool, which tells Google that the site on the old domain has moved to the new one. Used alongside your 301 redirects, it helps Google understand and process the move and migrate signals faster, complementing the redirects described in the site move and redirects guides. It does not replace the redirects, which do the actual work of carrying users and signals; it is the Search Console level signal that the two domains are connected by a move. Note that change of address applies to domain moves, not to same domain URL changes, where it is unnecessary. Set it up after the new property is verified and the redirects are in place, so all the signals agree.

Keep both properties to compare before and after

Whether or not the domain changed, having the right properties lets you do the most valuable thing after a migration: compare performance before and after. With the old property retained and, for a domain move, the new property collecting, you can line up the two periods and see whether clicks, impressions, and coverage held through the transition. This comparison is how you tell a normal recrawl dip from a real problem, the diagnosis behind how long SEO takes to recover. To compare like for like, it helps to map old URLs to new ones, since Web Almanac 2024 (HTTP Archive) is a reminder that sites have many URLs, and a full list, from your scan, lets you align the two views rather than eyeballing them.

Use Search Console to watch the transition

Beyond preserving data, Search Console is your instrument for watching the migration land. In the relevant property, monitor the coverage and pages reports for a spike in 404s or excluded pages, which points to missing redirects, the issue covered in fixing 404 errors in Search Console. Watch for pages dropping out via noindex or robots, the total deindexing risk in why a site is deindexed after a migration. And watch performance to see signals move to the new URLs. The data you kept is not just an archive; it is the live dashboard that tells you whether the migration is healthy, which is the real reason keeping your properties intact matters so much.

Steps to keep Search Console data through a migration

  1. Identify the case: same domain, or domain change.
  2. Same domain: keep the existing property and resubmit your sitemap.
  3. Domain change: create and verify a new property for the new domain.
  4. Keep the old property, never delete it, to retain history.
  5. Use the change of address tool for a domain move, with 301s in place.
  6. Compare both properties before and after, and watch coverage and performance.

Worked example: a domain change handled cleanly

Imagine a company moving to a new domain. Knowing the data is tied to the property, they do not panic about losing history. They keep the old domain’s property, which holds all their past performance, and create and verify a new property for the new domain so it starts collecting immediately. With 301s in place from every old URL to the new one, they use the change of address tool to tell Google the site has moved. Over the following weeks they watch the new property fill with data as signals migrate, while the old property shows the historical baseline. They map old URLs to new ones to compare the two periods and confirm clicks and impressions held. Nothing was lost, because the history stayed where it was collected and the new site was set up alongside it, the same careful approach as migrating WordPress without losing SEO.

Limitation: history does not merge, and Search Console is a record not a fix

It is honest to state two boundaries. First, on a domain change the old and new properties remain separate; the historical data does not merge into one continuous line, so long term comparison means looking across two properties rather than one unbroken history. That is a reporting inconvenience, not a data loss. Second, Search Console preserves and reports your data, but it does not fix migration problems; it shows you the 404s, the dropped pages, and the performance changes, and you still have to act on them with redirects, content fixes, and indexation fixes. So keep your properties intact to retain the record and the dashboard, but remember the actual recovery work happens on the site, guided by what the data reveals.

Common mistakes

  • Deleting the old property after a domain change, discarding the history.
  • Expecting historical data to transfer into the new domain’s property.
  • Forgetting to create and verify a new property for a new domain.
  • Skipping the change of address tool on a domain move.
  • Treating Search Console as a fix rather than a record that guides fixes.

Key points

You keep your Search Console data through a migration by understanding that it lives with the property it was collected in, then setting up the new site correctly alongside it. A same domain move keeps your existing property collecting, so just resubmit your sitemap and watch the transition. A domain change leaves the history in the old property, so keep that property, create and verify a new one for the new domain, and use the change of address tool with your 301s in place. Keep both properties to compare performance before and after, which is how you tell a normal dip from a real problem. The data is never lost, only anchored to where the URLs lived, and Search Console is the dashboard that guides your recovery rather than performing it. WPBuildAI scans your site and returns the URL list, so you can line up old and new URLs when you compare the two properties. Send your web address for a free analysis.

Not affiliated with WordPress, Lovable, Webflow, Shopify, Wix, or Squarespace.