A website migration SEO checklist comes down to this: export every URL that gets traffic, map each one to its new address with a permanent 301 redirect, keep the content of ranking pages, update internal links and sitemaps, then watch Search Console for weeks. Most lost rankings come from skipping the map.
We see the same story often at 3R Core. A business launches a beautiful new site, and a month later calls and leads are down because the old URLs return 404 errors. This guide is the checklist our SEO agency team follows before, during and after a migration, whether you are moving to a new platform, a new domain, HTTPS or a new URL structure. Every Google recommendation below links to the official documentation.
What counts as a website migration for SEO?
For SEO, a website migration is any change that alters the URLs Google has indexed or the way it reaches them: a redesign with new URL paths, a platform switch (for example WordPress to Shopify), a new domain, an HTTP to HTTPS move, or a hosting change. Each type carries different risk.
| Migration type | URLs change? | SEO risk | Change of Address tool? |
|---|
| New hosting, same URLs | No | Low | No |
| HTTP to HTTPS | Protocol only | Low to medium | No |
| Redesign with new URL structure | Yes | Medium to high | No |
| New platform (CMS or store) | Usually | High | No, unless the domain changes |
| New domain | Yes | High | Yes |
A hosting move with identical URLs is the easy case. Google's guide to moving a site without URL changes mostly asks you to test the new servers, make sure firewalls do not block Googlebot, and lower your DNS TTL ahead of the switch. Everything else on this list applies to moves where URLs change.
What should you do before migrating a website?
Before migrating, collect a complete list of your current URLs, find which ones bring traffic and links, and save a benchmark of rankings and conversions. Without that inventory you cannot build a redirect map, and you will not know what you lost after launch.
- Crawl the live site with a crawler of your choice and export every URL, title, meta description and H1.
- In Search Console, export pages from the Performance report using the longest date range available, so seasonal pages are not missed.
- Pull landing pages with sessions and conversions from your analytics tool.
- Add URLs from your XML sitemaps and server logs. Google's site move guide names sitemaps, analytics and server logs as sources for finding old URLs.
- List pages with external backlinks. Losing those links is the quietest way to lose authority.
- Save a snapshot of current rankings for your main keywords and your monthly leads or sales.
Our rule at 3R Core: if a URL had a click, a link or a conversion in the last year, it goes in the map.
How do you build a 301 redirect map?
A 301 redirect map is a spreadsheet with two columns: every old URL and the single most relevant new URL it should point to. Redirect one to one wherever an equivalent page exists, avoid sending everything to the homepage, and never chain redirects through several hops.
Google recommends server-side permanent redirects (301 or 308) for site moves. Its redirects documentation explains that with a permanent redirect, the indexing pipeline treats the target as canonical, while temporary redirects (302, 303, 307) do not send that signal. JavaScript redirects are a last resort because they depend on rendering.
Practical rules for the map:
- Match by intent, not by keyword in the URL. A retired service page goes to the closest current service, not the blog.
- Redirect straight to the final URL. Google says Googlebot can follow up to 10 hops but advises redirecting directly to the final destination.
- Include old redirects already on the site, so you do not create chains of old to older to new.
- Keep the redirects for as long as possible. Google's guidance is generally at least one year.
- Test the map on staging with a crawler before launch. Every old URL should return one 301 and then a 200.
Should you change titles and content when migrating?
Keep the titles, headings and main content of pages that already rank, at least for launch. Changing URLs, design and content at the same time makes it impossible to know what caused a drop. Migrate first, measure for several weeks, then improve copy one page at a time.
This is where redesigns usually go wrong. A new design team trims text to look cleaner, merges three service pages into one, or rewrites titles for brand voice. Each of those can be fine on its own. Done together, on launch day, on pages that bring your leads, it is a gamble. Our opinion is simple: a redesign should change how the page looks before it changes what the page says.
If you are budgeting a redesign rather than planning its SEO, our guide on how much a website redesign costs covers pricing.
How do you set up staging, canonicals and hreflang?
Build the new site on a staging environment that search engines cannot index, then remove the block at launch. On the new site, every page should carry a self-referencing canonical tag, and multilingual sites need hreflang annotations that point to the new URLs, not the old ones.
Staging is a common launch-day trap. We prefer password protection for staging because it keeps both people and crawlers out. If you use noindex, remember Google's noindex documentation: the rule only works if the page is not blocked by robots.txt, because the crawler has to see it. Whatever you use, put "remove staging block" as a line item on the launch checklist and verify it on the live domain.
Google's site move guide also recommends self-referencing canonical tags on the new pages. Check that canonicals were not copied from staging with the staging domain in them, and that hreflang pairs (for example English and Spanish versions) point to live, final URLs.
What do you update after the new site goes live?
Right after launch, update internal links to point directly at new URLs, submit fresh XML sitemaps in Search Console, confirm the new properties are verified, and use the Change of Address tool if the domain changed. Then crawl the old URL list to confirm every redirect works.
- Internal links: menus, footers, buttons and links inside blog posts. Relying on redirects for your own links wastes crawl and slows pages.
- Sitemaps: submit the new XML sitemap with only final, indexable URLs.
- Search Console: verify the new property and keep the verification file or tag in place.
- Change of Address: Google's Change of Address tool is for moves from one domain or subdomain to another. It is not for HTTP to HTTPS, www to non-www, or moving pages within the same domain, and you must own both properties with the same account.
- External links: ask partners and directories with links to your top pages to update them.
- Tracking: check that analytics, ad conversion tags and forms fire on the new site.
How long does it take to recover rankings after a migration?
Some ranking movement after a migration is normal. Google states that you may experience ranking fluctuations while it recrawls and reindexes the site, and that for a medium-sized site it can take a few weeks or more before the new URLs replace the old ones in results.
How fast it goes depends on how quickly your server responds and how many URLs are involved. Plan to monitor for at least two to three months:
- Check the Search Console Page indexing report weekly for "Not found (404)" and "Page with redirect". Google notes that 404s are worth fixing mainly when you link to them yourself or list them in a sitemap.
- Compare clicks and impressions for your top pages against the benchmark you saved.
- Fix stray 404s with new 301s as they appear.
- After a domain move, keep the Change of Address and redirects in place. Google says the tool forwards signals for 180 days and redirects should stay at least that long, longer if old URLs still get search traffic.
A drop that keeps growing after four to six weeks is not normal fluctuation. That is usually a missing redirect, a leftover noindex or a removed page that held your rankings.
If you would rather not run this alone, the 3R Core SEO agency can audit your current site, build the redirect map and monitor the launch, and our web development team can build the new site with the migration plan from day one.
Frequently asked questions
Will I lose SEO if I redesign my website?
Not if URLs are preserved or redirected one to one with 301s and ranking pages keep their content. Most losses come from missing redirects, removed pages and staging blocks left on after launch. Expect some temporary fluctuation while Google reprocesses the site.
How long should I keep 301 redirects after a migration?
Google recommends keeping redirects as long as possible, generally at least one year. For domain moves using the Change of Address tool, keep them at least 180 days, and longer if the old URLs still receive traffic from Google Search.
Do I need the Change of Address tool for an HTTPS migration?
No. Google's Change of Address tool is only for moving from one domain or subdomain to another. HTTP to HTTPS, www to non-www and moves within the same domain are handled with 301 redirects, updated internal links and a new sitemap.
Should I redirect all old pages to the homepage?
No. Redirect each old URL to the most relevant equivalent page. Send a URL to the homepage only when nothing related exists, and accept a 404 for pages that were removed with no replacement and have no traffic or links.
Is a 302 redirect bad for SEO during a migration?
For a permanent move, yes, it is the wrong tool. Google treats 302, 303 and 307 as temporary, so the redirect is not used as a signal that the new URL should be canonical. Use 301 or 308 for permanent changes.