---
title: "SEO migration checklist with a redirect checker | SEO Skill"
description: "A site migration checklist for before, during and after launch, with a free redirect checker that flags chains, loops, 404s and homepage redirects."
canonical: "https://seoskill.dev/tools/seo-migration-checklist"
language: "en"
---

# 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.

-   Change one thing at a timeMove the domain, then redesign, not both on the same day. Google asks for this, and when traffic drops you will know which change caused it.
-   List every old URL that mattersStart with the pages that get clicks in Search Console, then add the sitemap, pages with backlinks and URLs from server logs. Include PDFs and images that rank or get linked.
-   Save a baselineExport Search Console clicks and impressions by page and query for the last 16 months, and crawl the old site. After launch, every comparison starts from this.
-   Map each old URL to its closest new pageOne old URL to one new URL with the same content. Content you are dropping should return 404 or 410, not redirect to the homepage.
-   Check the map for chains, loops and homepage redirectsPaste it into the [redirect map checker](#redirect-map-checker) below. It finds problems in the map itself before anything is live.
-   Keep titles, headings and content on moved pagesUnless changing them is the point of the project. Every difference gives Google one more thing to reassess.
-   Crawl the staging siteCheck for broken internal links, missing titles and canonicals that point at the old domain. Keep staging out of Google with a password, not just robots.txt.
-   Lower the DNS TTL a week before a hosting moveGoogle suggests a few hours, so the switch reaches everyone quickly on launch day.

### Launch day

Allow a full working day, with someone who can change server rules on hand.

-   Remove the staging noindex and robots.txt blockThis is the most common launch mistake, and it can take a whole site out of Google. Run the homepage and a few templates through the [noindex checker](https://seoskill.dev/tools/noindex-checker).
-   Put the redirects live as 301 or 308Server-side and permanent. A 302 or 307 tells Google the move is temporary, so it may keep the old URL indexed.
-   Run the redirect map checker against the live siteEvery row should take one hop to the right page, and that page should return 200 and be indexable.
-   Point canonicals, hreflang and internal links at the new URLsEach new page needs a self-referencing canonical. Internal links that go through a redirect waste a hop on every crawl.
-   Check robots.txt on the new siteUse the [robots.txt validator](https://seoskill.dev/tools/robots-txt-validator) on the new domain. Leave the old domain's robots.txt open so Google can follow its redirects.
-   Submit the new sitemap and keep the old one for a whileThe old sitemap helps Google find the redirects sooner. Search Console warnings about redirecting URLs in it are expected.
-   Use the Change of Address tool for a domain moveIn the old domain's Search Console property. It is only for moving domains, not for http to https or a path change.

### After launch

Watch daily for the first week, then weekly for three months.

-   Compare clicks before and after the launch dateBy page and by query, in equal periods, so a drop points at the pages that lost it. `seo compare --date` does this from Search Console.
-   Fix new 404s and soft 404sCheck the Pages report in Search Console and crawl the new site. Old URLs you missed in the map show up here first.
-   Update your best backlinksAsk the sites that send the most links or traffic to point at the new URL. The redirect works without it, but a direct link is one hop less.
-   Keep the redirects for at least a yearGoogle says at least one year and suggests keeping them for good. Keep paying for the old domain too.
-   Set a weekly check until traffic settlesThe same comparison and the same redirect check each week, so a regression after a later deploy gets caught.

## 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](https://developers.google.com/search/docs/crawling-indexing/site-move-with-url-changes) and its [redirects guide](https://developers.google.com/search/docs/crawling-indexing/301-redirects).

-   **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 --json
```

Save 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.csv
```

## Compare 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-02
```

A 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 worse
```

Install the CLI and run setup:

```
npm i -g seo && seo start
```

Or 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.

## SEO migration questions