Website Migration SEO Checklist: Redirects, URL Mapping and What to Watch After Launch
A website migration is the one SEO task where a small mistake can undo years of work in an afternoon. A new site goes live, the old addresses stop working, and the pages that brought in enquiries vanish from Google. The cause is rarely exotic. It is usually a missing list of old URLs, redirects pointing at the home page, or a “do not index” setting left on from the build.
Most migration checklists online are written by agencies for large sites, with log file analysis and phased rollouts. If you run a business site of 20 to 200 pages and you are changing platform, domain or host, you need something different: a way to work out which kind of move you are making, a plan sized to it, and clear signs that something has gone wrong. This guide relies on Google’s own migration documentation for the rules, and says where a step is our judgement.
First, work out which kind of move you are making
Google separates site moves with URL changes from moves that do not change your URLs, and the work differs a great deal. Use this table to size the job before you do anything else.
| What is changing | Do URLs change? | Redirects needed? | Risk |
|---|---|---|---|
| Hosting provider or CDN only | No | No | Lower, but DNS and access need care |
| Platform or CMS (for example to a new theme or builder) | Often yes | Yes, wherever a URL changes | Medium to high |
| Page paths (for example /services/ becomes /what-we-do/) | Yes | Yes | Medium |
| Domain name | Yes | Yes, and the Change of Address tool | High |
| HTTP to HTTPS, or www to non-www | Yes | Yes, but no Change of Address | Low if done cleanly |
Google also advises changing one thing at a time. A domain move combined with a redesign and a new CMS makes it almost impossible to tell which change caused a drop. If you can, split them into separate projects a few weeks apart.
Step 1: Take a snapshot before you touch anything
You cannot judge a migration without a “before”. Record these on the day you decide to go ahead:
- A list of every live URL. Take it from your sitemap, your CMS and the Pages data in Google Search Console. Include images, PDFs and downloads that bring in visitors or links.
- Your top pages by clicks. Export the Performance report from Search Console for the last three months, the default period, and mark the pages that bring most clicks.
- Your top pages by links. The Links report in Search Console shows which pages other sites link to. Those addresses must redirect cleanly.
- Rankings and enquiries. A short list of the ten searches that matter most, and the monthly number of calls or forms. This is how you will later know whether things are normal.
- A copy of the old site. A full backup, plus screenshots of your key pages, so you can compare titles, headings and copy.
Verify the old site and the new site in Search Console, including all the variants, before the move starts. Google also reminds site owners to check that verification will survive the move.
Step 2: Build the URL map
This is the step that decides the outcome. For every old URL that mattered, decide what happens to it.
| Old URL | Decision | New URL |
|---|---|---|
| /services/boiler-repair/ | Redirect | /boiler-repair/ |
| /blog/2022/10/boiler-tips/ | Redirect | /guides/boiler-tips/ |
| /services/old-offer/ | Retire | 410, or redirect to the nearest equivalent |
| /about-us/ | Keep | /about-us/ |
Rules from Google’s guidance on site moves with URL changes:
- Map each old URL to its closest new equivalent. Google advises against redirecting many pages to an unrelated page, such as the home page.
- Use server-side permanent redirects (301 or 308) wherever possible. Client-side redirects are a last resort.
- Avoid chains. Redirect straight to the final address. Googlebot can follow up to 10 hops, but Google recommends keeping chains to no more than 3, and fewer than 5 where you can.
- Return 404 or 410 for content you are not moving, rather than redirecting it to something irrelevant.
- Update the new pages themselves: a self-referencing canonical tag, hreflang if you use it, and internal links that point to the new addresses, not to old ones that now redirect.
Google’s redirect documentation explains the difference between permanent and temporary redirects: with a permanent one it treats the target as the canonical URL, and with a temporary one the old page may stay in results. For a migration you want the permanent kind, which is why a plugin set to “302” by default is a common cause of trouble.
How RankMaster helps with migrations
RankMaster is a Brazilian SEO and GEO agency, with its site at rankmaster.com.br, that works remotely and in British English with UK businesses. For a migration we usually work as a safety net around whoever builds the site: we review the URL map before the build is finished, check the staging site for leftover blocks, and watch the first weeks after launch. The work is delivered in three recurring parts:
- Monthly plan. A written plan before each month: which pages to build or improve, what to fix on the new site, and which technical fixes come first, each with the reason.
- Monthly report. What was published, what Google Search Console shows for old and new URLs, and how the business appears in AI answers, including what did not change.
- Daily monitoring. Ongoing checks for pages leaving the index, broken links, failing forms and robots.txt changes that could hide the site, which is exactly what goes wrong after a launch.
We do not promise rankings or citations, because no one can guarantee them, and a migration always carries some risk. If your pages seem to have vanished, start with our guide on why your website may not be showing up on Google. You can also learn more about RankMaster or ask for a free analysis through the contact page.
Step 3: Test on a staging site without letting Google in
Build the new site on a temporary address. Google suggests using a temporary hostname with a noindex setting so you can test without risking indexing. Then check these before launch:
- Googlebot can reach the site. Use the URL Inspection tool in Search Console, and check that a firewall or bot protection is not blocking Googlebot.
- The robots.txt file is the live one. Remove any “disallow everything” rule used in development.
- The noindex tags are gone. This is the classic launch-day error: a staging setting copied to the live site.
- Redirects work. Test a sample of old URLs, especially your top pages by clicks and links. Check that each lands on the right page in one step.
- Titles, headings and copy match. If you rewrote key pages, compare them with the old ones. A page that no longer mentions the thing people searched for may lose its place whatever the redirects do.
- Forms, phone links and tracking work. Submit a test enquiry and check it arrives.
If you are only changing host, Google adds two practical points. Lower your DNS TTL at least a week before the move so changes spread faster, and keep the old hosting running until traffic to it reaches zero.
Step 4: Launch day
Choose a quiet period if you can. Google notes that moving during a lower-traffic period limits the impact on users. Then, in order:
- Turn on the redirects and confirm the canonical tags and robots rules on the live site.
- Check the home page, your top ten pages and your contact page in a browser, on a phone as well.
- Submit the new sitemap in Search Console and remove the old one.
- If you changed domain, use the Change of Address tool. Google says to submit it only when changing domains or subdomains, and not for HTTP to HTTPS, www to non-www, or moving paths within a domain.
- Update your Google Business Profile, social profiles, email signatures and any advertising to the new addresses.
- Keep the old site and its redirects in place. Google says to keep redirects generally for at least one year, and users may benefit if you keep them indefinitely.
Step 5: The first 30 days
Expect movement. Google says to anticipate temporary changes in ranking and visibility while it recrawls and reindexes, and that for small and medium sites most pages may take a few weeks to move. A dip does not by itself mean the migration failed. These checks help you tell the difference:
| When | Check | Worry if |
|---|---|---|
| Day 1 | Home page and top pages return 200 and load | Any of them returns an error or a blank page |
| Day 1 to 3 | Search Console Page indexing report | New pages are marked noindex or blocked by robots.txt |
| Week 1 | Sitemap status | The new sitemap shows “Couldn’t fetch” |
| Weeks 1 to 2 | Redirect sample test | Old URLs redirect to the home page or chain through several hops |
| Weeks 2 to 4 | Clicks on top pages against your “before” list | Top pages have disappeared, not just moved down |
| Weeks 2 to 4 | Enquiries against your baseline | They fall and stay down while the site is otherwise fine |
Google also notes that redirect-related warnings about the sitemap in Search Console are normal after a move. Do not panic over them. Do act on spikes in crawl errors, redirects to nonexistent URLs, and leftover noindex or robots.txt blocks.
Plan the way back
Before launch day, agree what you will do if something is badly wrong. A rollback plan costs an hour to write and may save weeks. It should state who has the authority to call it, how to restore the old site and DNS, and which checks decide the matter. A site with a catastrophic bug on launch day is a rollback. A site that has dipped by a modest amount in week two is usually not.
Common mistakes
- Redirecting everything to the home page.
- Leaving a staging “noindex” or robots.txt block on the live site.
- Using temporary redirects for a permanent move.
- Changing domain, design and CMS together.
- Redirect chains from earlier migrations that nobody cleaned up.
- Not keeping the old verification in place in Search Console.
- Switching off the old redirects after a few months.
- No baseline, so nobody can say whether things got worse.
Frequently asked questions
Will I lose rankings in a migration?
Google warns of temporary fluctuations while pages are recrawled and reindexed. A clean migration aims to keep them short, and no one can promise zero change.
How long should I keep the redirects?
Google says generally at least one year, and indefinitely if you can.
Do I need the Change of Address tool?
Only when changing domain or subdomain. It is not needed for HTTP to HTTPS, www to non-www, or path changes.
Can I redirect all old pages to the new home page?
Google advises against redirecting many pages to an unrelated page. Map each old page to its closest equivalent.
How long until the new site is fully processed?
For small and medium sites Google says a few weeks for most pages, and it cannot give fixed crawl dates. Any exact promise is a guess.
What to do this week
Open a spreadsheet and list every live URL on your site, with clicks from the last three months beside the top ones. That single sheet is the base of the whole project, and it takes an hour. If the list shows you are about to change more than one thing at once, split the project now. If you would like a second pair of eyes on a migration plan before you commit, ask for a free analysis through the RankMaster contact page.