How to migrate a website without losing SEO, step by step

To migrate a website without losing SEO, keep everything Google already trusts and change only what you must. Every old URL redirects with a 301 to its closest new page. The titles and content of ranking pages carry across. The new site is crawlable and at least as fast. And you watch Search Console daily for the first weeks. Done this way, most sites see a short dip and recover. Done carelessly, a migration can cost months of traffic.

The nine steps below follow Google's own guide to site moves with URL changes, in the order we run them on website redesign and migration projects.

How risky is your migration?

"Migration" covers several different moves, and the risk depends on how much changes at once.

Google's advice is to plan changes one after the other, not all at the same time. In practice a platform change often brings a new design with it, because the old templates cannot move. If so, keep URLs and content the same where you can, and do not add a domain change on top. If a rebrand forces a new domain, our domain change checklist treats it as a separate step.

Moves where only the hosting changes follow a shorter process, which Google covers in its guide to changing hosting without URL changes.

What do you do before the move?

Step 1: Crawl and export every old URL

Most sites have two to three times more URLs than anyone remembers. Build one list from all of these sources, then remove duplicates:

• The XML sitemap.
• Search Console: the Pages report and the Performance report (pages with impressions).
• Analytics: every landing page with sessions in the last twelve months.
• Server logs, which show URLs that real visitors and bots still request.
• The Links report in Search Console, for pages other sites link to.
• A crawl of the live site, which also finds images, PDFs and other files.

Step 2: Record a baseline

For each URL, save clicks and impressions for the last twelve months, landing-page sessions and conversions. Record Core Web Vitals for the main templates. Without a baseline, "traffic feels lower" after launch cannot be checked. How to audit your current website covers the spreadsheet in detail.

Step 3: Build the redirect map

Every old URL gets a row: its new URL and a status code. Pages that keep their URL need nothing. Pages that move or merge get a 301 to their new home. Pages removed with no close equivalent should return 404 or 410, as Google's guide recommends, rather than redirect to the homepage. Google treats mass redirects to an irrelevant page as soft 404s.

Redirect mapping has a copyable template and the matching rules. For which status code to use, see 301 vs 302 redirects.

Step 4: Prepare the new site for search

On the staging site, before launch:

• Every new URL has a self-referencing canonical tag. The canonical tag generator shows the correct format.
• Internal links point at new URLs directly, not at old URLs that redirect.
• Hreflang annotations, if you have them, use the new URLs.
• Titles, meta descriptions and headings of ranking pages are carried over, or deliberately improved.
• Images, PDFs and downloads are on the new site.
• The production robots.txt is written and ready. Check it with the robots.txt tester before launch, not after.

Step 5: Verify Search Console and analytics

Verify the new site in Search Console before launch. Google recommends verifying all variants of both the old and new sites; a Domain property covers www, non-www, HTTP and HTTPS in one. If you ever uploaded a disavow file, upload it again to the new site's property. Install analytics on the new site so data starts on launch day.

Google also warns that it crawls a moved site more heavily than usual for a while. On cheap shared hosting with a large site, ask your host whether the server can take it.

What happens on launch day?

Step 6: Turn on redirects and remove staging blocks

Deploy the redirects as server-side permanent redirects (301 or 308). Client-side redirects in JavaScript are a last resort. At the same moment, remove every noindex rule and robots.txt block that kept the staging site out of search. A staging noindex carried into production is one of the most damaging launch mistakes, and one of the easiest to make.

Step 7: Test the redirects

Test every row of the map, not a sample. Each old URL should return one permanent redirect to a page that loads with a 200. Watch for chains: Google advises redirecting straight to the final destination, and keeping any unavoidable chain short. Start with the top twenty pages by clicks and every URL with backlinks, then run the full list with a crawler or the script in redirect mapping. The URL Inspection tool in Search Console confirms what Googlebot sees for individual pages.

Step 8: Submit the sitemaps

Submit the new XML sitemap in Search Console; the XML sitemap generator can build one if your platform does not. Google's guide also suggests submitting a sitemap of the old URLs for a while. Google then recrawls them, finds the redirects sooner, and you can watch the old sitemap's indexed count fall as the new one rises.

If the domain changed, submit the Change of Address in Search Console now. It is not needed for path changes, HTTP to HTTPS, or www changes on the same domain.

What do you watch afterwards?

Step 9: Monitor for at least four weeks

Daily in the first week, then weekly:

• Pages report: a rising "Not found (404)" count means missing redirects. "Page with redirect" rising is expected.
• Performance report: clicks and impressions for your top pages, compared with the same pages before launch.
• Server logs: old URLs returning 404, which show up here days before Search Console reports them.
• Enquiries: form submissions and calls. A drop with steady traffic is a form or tracking problem, not SEO.

Google says it can take a few weeks or more for a medium-sized site to show the new URLs in results. A dip in that window is normal. A drop concentrated in a few pages, or one still there after four to six weeks, has a cause worth finding. The week after a migration is the day-by-day checklist.

Keep the redirects for at least a year, as Google recommends, and longer if you can. Old links on other sites never update themselves. Ask the sites that send you the most traffic to update their links, and change your own profiles and campaigns to the new URLs.

When should you not migrate?

A migration is worth its risk when the current platform is costing you: insecure, slow by construction, impossible for your team to edit, or unable to do what the business needs. It is not worth it to get a new look on a platform that works. A refresh on the same platform keeps every URL and most of the risk disappears. Redesign vs refresh helps you decide.

Timing matters too. Do not launch a migration in the weeks before your busiest season, and do not launch on a Friday. The full sequence, from audit to the month after launch, is in the website redesign process.