Google Search Console for a site migration: before, during and after

verify every property you will need — Google’s site move documentation says to verify both the old and the new site, “all variants” of both. A Domain property, verified through DNS, covers http, https, www and other subdomains at once. For a domain change the Change of Address tool requires that you are an owner of both properties — sort out access now, not on launch day.

export the performance data — the old site’s clicks and impressions per page, for the longest useful period. The report keeps 16 months, and the old property keeps its data after the migration, but an export you made before the switch is what you will compare against, and what feeds the redirect map.

note the top linked pages — the Links report lists the pages other sites link to most. Those need a precise one-to-one target even if their own search traffic is small. Google’s move guide names this report as a source for the url mapping.

record the Page indexing baseline — how many pages are indexed, and how many urls sit under Not found (404) and Page with redirect before anything changes. After the launch you compare against these numbers, not against zero.

list the sitemaps — the Sitemaps report shows which sitemap files Google knows about. Keep a copy of the old sitemap files themselves — once the old site is gone, so are they.

Of everything Search Console offers, the performance export is the most useful for the redirect map. Open the Performance report, set the date range, and export. The download contains one file per tab — queries, pages, countries, devices and more (Google on the export format). The pages file is a list of urls that Google showed in search, each with its clicks and impressions.

That gives it two roles at once:

• a url source. It contains pages a crawl of the old site may not reach — old posts and campaign pages nothing links to any more, but that Google still shows.
• a priority list. It says which urls actually carry traffic. On a site with 2 000 old urls, a few dozen usually account for most clicks, and those are the rows to check by hand.

The limit to plan around: the export in the interface caps at 1 000 rows. On a larger site it is the best-performing part rather than every url. Two ways past it: filter the report by page — url contains /blog/, then /shop/ — and export each slice separately; or use the Search Console API, which returns up to 25 000 rows per request. The export is a supplement to a crawl and the sitemaps, not a replacement (finding orphan urls).

In Silentfrog the export goes in twice. As a url list on the crawl form, it adds its urls to the old site’s pages next to the crawl and the sitemaps — a csv with the url in the first column is read as it is (starting a run). As traffic data after the crawl, it adds a clicks column to the results table to sort by, and lists separately any url with clicks that no source found, so it can be added as a row (traffic data). English and German exports, comma- or semicolon-separated, are both recognised.

The generic csv download then keeps clicks and impressions next to each redirect — a record of which urls mattered, useful when you check the migration later. The first 50 old pages are free.

• submit the new sitemap in the new property (or in the same one, if the domain stays). Google’s move guide suggests submitting the old urls’ sitemap at first as well, so Google recrawls them and sees the redirects; it can be removed later.
• file the Change of Address request if the domain changed. It is started from the old property’s settings, needs a 301 from the old homepage to the new one, and runs for 180 days. It does not move subdomains below the property, so file it for the www and the non-www variant of the old domain alike; it is not used for http to https, www changes on one domain or path changes.
• inspect a handful of important urls with URL Inspection: an old url (does the live test see the redirect?) and its new target (is it indexable, which canonical does it declare?). URL Inspection only checks urls inside the property you are in.
• check robots.txt and noindex on the new site. Google’s move guide reminds you to remove blocks that were only there for staging.

How a domain move works end to end is covered in changing your domain name without losing SEO.

The Page indexing report is the one to open first. Its reasons map directly onto migration mistakes: Not found (404) is a missing redirect, Soft 404 is often a redirect to an unrelated page, Redirect error is a loop or a chain that is too long. The example table is limited to 1 000 urls per reason, so treat it as a sample: a pattern in the examples — all under /downloads/, all with a trailing slash — usually names the source the map was missing.

In the Performance report, compare the weeks after launch with the same number of weeks before, on the pages tab. Sorting by the difference in clicks shows the old urls that lost the most; for each, check that it redirects and that its target is gaining. Google’s move guide expects exactly that pattern — old urls losing, new urls gaining — and warns that rankings fluctuate temporarily while it happens.

Google’s move guide says a medium-sized site can take a few weeks or more before the new urls are shown in place of the old ones, and a large site longer. Check the reports above weekly for the first month, then monthly. Rarely visited urls are recrawled last, so a 404 that turns up two months after launch is still a missing redirect.

Keep the redirects for as long as possible — Google says generally at least a year, and the Change of Address help at least 180 days, longer while old urls still get traffic from Google. Keep the old property verified for as long as the redirects run: it is where the old urls’ problems show up.

• Before: verify both sites and every variant, export performance and links, record the indexing baseline.
• The pages export is a url source and a priority list; it caps at 1 000 rows, so export per folder or use the api.
• Launch day: submit the new sitemap (and the old one at first), file Change of Address for a domain change, inspect key urls.
• Afterwards: Page indexing for 404s, soft 404s and redirect errors; Sitemaps and Performance for old-to-new movement.
• A pattern in the 404 examples usually names the source the redirect map was missing.