Website Migration: How to Protect Your Google Rankings

What counts as a website migration?

A migration is any change that alters the URLs of existing pages. Google lists the common cases: moving from HTTP to HTTPS, changing domain name (for example example.com to example.net) or merging domains, and changing URL paths, such as moving from page.php?id=1 to /widget. A redesign on a new platform, say WordPress to Next.js, usually changes paths too, so it counts.

If you are only changing hosting or a CDN and every URL stays the same, it is a lighter job. Google treats that as a move without URL changes, and most of the redirect work below doesn't apply.

Google's advice is to change one thing at a time. If you want a new domain, a new CMS and a new layout, do them one after another rather than all at once, so that if traffic drops you know which change caused it. If you're still choosing the platform, our Next.js vs WordPress comparison covers that decision.

Step 1: Build a full inventory of your current URLs

You can't redirect what you haven't listed. Start with the pages that matter most and work outwards:

• Your current XML sitemap, which usually holds the pages you care about.
• Analytics and server logs, for the URLs that get the most visits.
• The Links report in Search Console, for pages other sites link to.
• Your CMS, which can normally export every URL that holds content.
• Images, PDFs and other files you host. Google points out these may already get search traffic and links, so they need new homes too.

Put everything in one spreadsheet. For each URL we note the page title, meta description, main heading and whether it earns traffic or links. That last column decides how much care each row gets.

Step 2: Create a 301 redirect map

Next to every old URL, write the new URL it should go to. This mapping is the heart of the migration. Google recommends server-side permanent redirects, such as 301 or 308, and says plainly that 301 and other permanent redirects don't cause a loss in PageRank.

Three rules keep the map clean:

1. Redirect to the closest equivalent page. Don't send hundreds of old URLs to the new home page. Google warns this can confuse users and may be treated as a soft 404.
2. Avoid chains. Googlebot can follow up to 10 hops, but Google advises redirecting straight to the final destination, and keeping any unavoidable chain to 3 hops or fewer.
3. Let dead pages die properly. If you are deliberately not moving some content, make those URLs return a 404 or 410 rather than redirecting them somewhere unrelated.

Where the old and new URL patterns follow a rule (for example a whole /blog/ folder moving to /articles/), a pattern-based rule on the server is fine. Everything else gets its own row.

Step 3: Keep the content, titles and meta tags

Rankings belong to pages, and pages are judged largely on what they contain. When we rebuild a site, we carry over the body copy, page titles, meta descriptions, headings and image alt text for every page that earns traffic, then improve them later, after the move has settled.

Google's Search Console help notes that keeping the same site architecture helps pass signals to the new site, and that combining a move with a redesign of the content and URL structure will probably cause some traffic loss while Google relearns the pages. That is why we prefer to launch with the content as close to the old site as possible.

Step 4: Set canonical tags, sitemap and robots.txt on the new site

Before launch, check the technical signals on the new site:

• Canonical tags. Each new URL should carry a self-referencing rel="canonical" tag that points to the new address, never the old one.
• hreflang. If you run language or country versions, update those annotations to the new URLs.
• XML sitemap. Generate a sitemap that lists only the new URLs. Keep a copy of the old sitemap too, for monitoring.
• robots.txt and noindex. Many teams block crawling on the staging site. Google lists forgetting to remove those blocks as a common mistake, and it can stop the new site being indexed at all. Remove them at launch.
• Internal links. Update menus, footers and links inside your content to point directly at the new URLs, rather than relying on redirects.

Step 5: Launch, test the redirects and tell Google

Google suggests timing the move for a quieter traffic period if your traffic is seasonal, and making sure your server can cope, because Google crawls the new site more heavily than usual straight after a move.

On launch day:

1. Switch on the redirects.
2. Test them. Use the URL Inspection tool for individual pages, and a crawler or script for the full list. Google says one of the most frequent problems it sees is redirects pointing to URLs that don't exist.
3. Submit the new sitemap in Search Console.
4. If the domain or subdomain changed, use the Change of Address tool (see the table below).
5. Update profile links on social media, ad campaigns and, where you can, links from other sites.

Keep the redirects for as long as possible. Google recommends at least one year so that it can transfer signals to the new URLs.

Do you need the Change of Address tool?

The Change of Address tool is only for moving from one domain or subdomain to another. You must own both properties in Search Console with the same Google account, and the move notice shows for 180 days.

If you do use the tool, Google asks you to keep redirects for at least 180 days, longer if Google still sends traffic to them, and recommends keeping the old domain registered for at least a year so no one else can buy it and misuse it.

Step 6: Monitor for 404s and traffic after launch

The work isn't done at launch. For the first few weeks, check:

• Search Console's indexing reports for spikes in "Not found" and other errors.
• Both sitemaps. Indexed pages in the old-URL sitemap should fall over time while the new one rises. Search Console may warn that old URLs redirect, which is expected.
• Performance reports, to see the new URLs start picking up impressions and clicks.
• Server logs for URLs returning unexpected error codes.
• Page speed, because a slower new site is a common, avoidable regression. Our guide to website speed test tools explains which tool to use for which check.

Fix any broken redirect the same day you find it. After the first month, a monthly check is usually enough; this kind of upkeep is part of our website maintenance services.

Frequently asked questions

Will my rankings drop after a website migration?

They may dip for a while, and no one can honestly guarantee they won't. Google says to expect temporary ranking fluctuation while it recrawls and reindexes the site, and that rankings settle over time. A careful redirect map and unchanged content keep the risk as low as possible.

How long does it take Google to process a site move?

Google says a small to medium-sized site can take a few weeks for most pages to move, and larger sites take longer. The speed depends mainly on how many URLs there are and how fast your server responds. Submitting the new sitemap helps Google find the new URLs sooner.

Should I use a 301 or a 302 redirect?

Use a permanent redirect, a 301 or 308, for a migration. Google recommends server-side permanent redirects for site moves and confirms they don't cause a loss in PageRank. A 302 signals a temporary move, which isn't what you want when the old URL is gone for good.

Do I need to redirect every old URL?

Redirect every URL that has an equivalent page on the new site, especially pages with traffic or links. Content you are deliberately removing should return a 404 or 410 instead. Never redirect large numbers of unrelated URLs to the home page.