# Checking a site migration in the first week

> Take a baseline before a migration, then crawl, check ranks and read Search Console after it. The audit issues and the order that catch a broken move early.

Source: https://netweft.com/blog/checking-a-site-migration
Updated: 2026-10-15

**Before a migration, audit the old site and run a rank check so there is a baseline. After it, crawl the new site and fix Broken internal link, Redirect chain, Page returns an error, Conflicting canonical and noindex first, then compare a fresh rank check and Search Console with the baseline.**

A migration moves URLs, templates or domains in one release, and most of the
traffic it loses is lost to a handful of mechanical faults. Every one of them
shows up in a crawl within an hour of the release, which makes the first week
the cheapest time to find them.

## Before the release: take a baseline

1. **Audit the old site.** Run a [site audit](/docs/site-audit) at the plan's
   page limit. Export the issues as CSV and keep the **Pages crawled** list:
   it is the inventory of URLs that must still answer, directly or through a
   redirect, after the move.
2. **Run a rank check.** On each tracker, choose **Run check now**. The
   positions it stores are the baseline the post-migration checks are read
   against.
3. **Note the Search Console figures.** On [Search
   performance](/docs/search-performance), the 28-day clicks, impressions and
   average position are the traffic baseline.

## After the release: crawl first

Crawl the new site the day it goes live. These issues explain most migration
losses, in the order to fix them:

| Issue | What it usually means after a migration |
| --- | --- |
| Page is set to noindex | a staging setting shipped to production |
| Server error, Page returns an error | an old URL with no redirect, or a template that fails |
| Broken internal link | navigation or content still points at old URLs |
| Redirect chain | old URL to interim URL to new URL; point the first hop at the last |
| Conflicting canonical | canonicals still name the old URLs or the staging host |
| Crawler was blocked | a firewall or bot-protection rule from staging answering 401, 403, 429 or 503 |

Then compare the **Pages crawled** count with the baseline. A new site that
crawls far fewer pages from the same start URL has lost internal links, or its
`robots.txt` disallows paths the crawler now skips; the **Orphan page** and
**Page links nowhere** issues help locate the first.

If the domain itself changed, update it under **Project settings**. The
project keeps its history, so earlier audits and rank checks stay recorded
against the old domain. A tracker keeps the domain it was created with, so
create a tracker for the new domain and add the same keywords to it.

## In the first week: watch ranks and Search Console

- Run a rank check two or three days after the release and again at the end of
  the week. Movement of a few places is normal while Google recrawls; a
  keyword that falls to **not ranking** and stays there points at a URL that
  was not redirected.
- On Search performance, compare the 7-day window with the 28-day baseline you
  noted. Impressions recover before clicks do, so falling impressions in the
  second week are the signal to act on.

## What it costs

A crawled page costs 1 credit, so the two audits cost the
pages they crawl. A rank check at the default depth costs
40 credits per keyword per device, and Search Console reads
cost nothing. The audits count toward the plan's monthly audits:
60 on Pro.