SEO migration checklist
Twenty checks for moving a site without losing search traffic, in the order you do them, with a redirect map checker that tests every old URL against the live site.
Most site migrations lose traffic for longer than the people running them expect. SALT.agency tracked 1,052 domain migrations and published the results in June 2026: 22.8% had recovered their traffic after 90 days, 59.5% after a year, and the median took 304 days. Those numbers come from third-party traffic estimates of domain moves, so a redesign that keeps its URLs usually does better.
The pattern behind the slow ones is the same: old URLs that redirect to the wrong place, through a chain, to the homepage or to nothing. So this checklist has a redirect checker built in. Tick the steps as you go (ticks stay in this browser), and run your redirect map through the checker before and after launch.
0 of 20 done. Ticks are saved in this browser.
Before launch
Start four to eight weeks out. Most migrations that lose traffic lose it here.
Launch day
Allow a full working day, with someone who can change server rules on hand.
After launch
Watch daily for the first week, then weekly for three months.
Check a redirect map before and after launch
Paste old and new URL pairs, or upload the CSV from your mapping spreadsheet. First the checker reads the map itself and flags old URLs listed twice, rows that point at another old URL, three or more pages sent to one place, and pages sent to the homepage. Then it traces each old URL on the live site, hop by hop, and checks where it lands.
Problems in the map itself
Found by reading the rows, before any URL is fetched.
| Result | Old URL and path | Lands on |
|---|
Six redirect results and what to do about each
| Result | What happened | Fix |
|---|---|---|
| One hop, right page | A single permanent redirect to the URL in your map, which returns 200 and can be indexed. | Nothing. |
| Chain | Two or more hops, often http to https, then a trailing slash, then the new page. | Point the old URL straight at the final URL. Map to the exact final form, slash and all. |
| Wrong page | It lands somewhere other than your map says. Often a catch-all rule that runs before the specific one. | Check the order of the server rules. Specific rules go first. |
| No redirect | The old URL still loads, or returns 404. | Add the rule. A 404 on an old URL with links or traffic is lost value. |
| Loop or too many hops | The redirects never reach a page, or take more than 10 hops. | Find the two rules that point at each other and replace both with one. |
| Lands on a 404, noindex or another canonical | The redirect works but the new page cannot rank. | Fix the new page. A redirect only passes signals to a page Google can index. |
Google's redirect rules, in its own words
Every number in the checker comes from Google's site move guide and its redirects guide.
- Permanent redirects keep link value. "301 and other permanent redirects don't cause a loss in PageRank."
- Chains. "While Googlebot can follow up to 10 hops ... we advise redirecting to the final destination directly. If this is not possible, keep the number of redirects in the chain low, ideally no more than 3 and fewer than 5."
- Homepage redirects. "Don't redirect many old URLs to one irrelevant single URL destination, such as the home page of the new site. This can confuse users and might be treated as a soft 404 error."
- How long to keep them. "Keep the redirects for as long as possible, generally at least 1 year."
- The most common mistake. "We frequently see people redirecting to the wrong (non-existent) URLs on the new site."
Find the URLs that matter from Search Console
A redirect map built from the new site's sitemap misses the old URLs that earn traffic. Build it the other way round, from the pages Google sends visitors to. With SEO Skill your agent pulls every page with clicks from Search Console for the last 16 months, before you touch anything:
seo data --site example.com --dimensions page --detail full --jsonSave that list. It is your baseline, and the top of it is the part of the redirect map you cannot afford to get wrong. After launch, trace the whole map from your own machine, up to 1,000 rows at a time. Each line is an old URL and the new URL it should land on, the same file you paste above:
seo redirect-trace --map redirects.csvCompare before and after the launch date
After launch, the question is which pages lost clicks, not whether the total dipped. The compare command takes the launch date and splits Search Console into equal periods before and after it, with the pages and queries that moved most:
seo compare --site example.com --date 2026-11-02A drop spread evenly across the site in week one is Google moving URLs. A drop concentrated on one folder or template is a redirect, noindex or canonical problem on those pages, and it will not fix itself.
Run the checks weekly with your agent
This is one of the few SEO jobs where a scheduled task pays for the setup. For the first three months, ask your agent to run the same comparison against the launch date each week, trace the top old URLs again, and report only what changed. A later deploy that breaks a redirect rule gets caught in days instead of at the next quarterly review. Ask:
Every Monday until February, compare example.com before and after 2026-11-02, run seo redirect-trace --map redirects.csv, and tell me only what got worseInstall the CLI and run setup:
npm i -g seo && seo startOr add the hosted MCP server to your agent and sign in with Google:
Run it in a terminal, then sign in with Google.
Or run it on your machine
Installs the CLI, signs you in and adds the skill to your agents. Site crawls and Bing data run this way, on your own machine. A crawl fetches many pages, and Bing blocks our hosted server.