IMMER WEBSERVICES
Start a project

Website Relaunch SEO: A Migration Checklist to Keep Your Rankings

Website relaunch SEO made practical: URL inventory, 301 redirect map, password-protected staging, sitemaps, Search Console and what to monitor after launch.

Wimmer Webservices team 9 min read

Redirect map for a relaunch: three old URLs redirect with 301 to new pages, one page removed without replacement returns 410

A website relaunch doesn’t have to cost you rankings. If every old URL 301-redirects to the right new page and Google can crawl the new site without obstacles, your visibility carries over. Most drops come from forgotten URLs, content lost in the rewrite, or a staging block that survives launch day. This checklist covers what to do before, during and after the move.

Why sites lose rankings after a relaunch

Google doesn’t rank a website as a whole. It ranks individual URLs, and each one has built up signals over the years: links from other sites, clicks, an understanding of which searches it answers. When a URL changes, Google has to transfer those signals to the new address. That only works if the old URL points cleanly to the new one.

The usual culprits:

  • old URLs lead nowhere because nobody set up a redirect
  • pages that ranked well were shortened or dropped during the rewrite
  • page titles and meta descriptions didn’t make it across
  • the new site still carries a noindex or robots.txt block from staging
  • internal links still point to old URLs and run through redirect chains

Even a clean migration causes some movement. Google itself says to expect temporary ranking fluctuation while the new URLs are processed (Google Search Central: Site moves with URL changes). That’s nothing to worry about, as long as things settle within a few weeks.

Before launch: URL inventory and redirect map

The work that decides whether your migration goes smoothly happens before the new site goes live.

List every old URL

Start with a complete list of the URLs your site has today. Good sources:

  • your current XML sitemap
  • the Performance report in Search Console, which shows which pages get clicks and impressions
  • a crawl of the existing site with an SEO crawler
  • your analytics, if you have it, for pages with real traffic
  • pages that other websites link to

Don’t forget PDFs, images with their own URLs, and leftovers from earlier relaunches. Flag the pages that bring in search traffic. Those are the ones where a mistake costs the most.

Decide where each URL goes

Your inventory becomes the redirect map: a spreadsheet with the old URL in one column and the new URL in the next. Every row needs a deliberate decision.

What happens to each old URL

  • The page still exists, just at a new address301 straight to the new URL
  • Several old pages are merged into one301 from each of them to the merged page
  • The topic is gone, but a related page covers it301 to that related page
  • The content is gone with no replacement404 or 410, not a redirect to the homepage
  • URL and content stay the sameNothing to do, just check it still loads
Based on Google Search Central, “Site moves with URL changes” and “Redirects and Google Search”.

The fourth case is where most migrations go wrong. It’s tempting to send everything that’s disappearing to the homepage. Google advises against exactly that: it confuses users and may be treated as a soft 404. As far as Google is concerned, 404 and 410 work the same way. Both say the content no longer exists.

The cheapest URL is the one that doesn’t change. If your current URL structure makes sense, keep it.

Carry over content and metadata

A redesign often tempts people to cut copy. For pages that rank well today, that’s risky. Check that what Google found on those pages is still there on the new version: headings, answers to common questions, tables, the specific terms people search for.

Also carry over, or improve:

  • page titles and meta descriptions
  • image alt text
  • structured data, for your business or FAQs, for example
  • canonical tags, now pointing to the new URLs

Staging: visible to you, invisible to Google

The new site is usually built on a test address, often a subdomain. It mustn’t end up in search results, or it will compete with your live site.

Password protection is the safest option. Google can’t read or index what sits behind a login. A noindex tag in the page head also works (Google Search Central: Block search indexing with noindex). A robots.txt block on its own isn’t enough. It stops crawling, but it doesn’t reliably keep a URL out of the index if someone links to it.

The classic mistake happens at launch. The site goes live and the noindex or robots.txt block from staging comes along with it. Google sees a site asking not to be indexed and does as it’s told. Put “remove staging blocks” at the very top of your launch-day list.

If you can, launch during a quiet period rather than the week before your busiest season. And keep a few days free afterwards so someone can fix problems straight away.

Set up 301 redirects properly

Google recommends permanent server-side redirects, meaning a 301 or 308 status code (Google Search Central: Redirects and Google Search). The redirect types behave quite differently:

Redirect How Google reads it For a relaunch
301 or 308 (server) permanent, the new URL is shown in results first choice
302, 303 or 307 (server) temporary, the old URL tends to stay in results not suitable
Meta refresh with no delay treated like a permanent redirect only if the server can’t do a 301
JavaScript only seen if rendering succeeds last resort

Watch out for chains. If a URL from a previous relaunch redirects to an address that’s now moving again, you end up with several hops. Update those old rules so every URL goes straight to its final destination.

Test the redirects against your map: single URLs with the URL Inspection tool in Search Console, large batches with a crawler or a short script.

Update internal links to the new URLs. A redirect catches old links, but every internal link that goes through one is a needless detour for visitors and for Google. That includes the navigation, the footer, links in body copy and image URLs.

If your site is multilingual, hreflang annotations need the same treatment. They connect the language versions of a page and must point to the new URLs in every language after the move. Google calls this out specifically in its migration guide.

XML sitemaps and Search Console

Create an XML sitemap with the new URLs and submit it in Search Console. Google suggests keeping the old sitemap submitted for a while too. That helps Google find the redirects, and the Sitemaps report shows you the old URLs dropping out of the index as the new ones come in.

Changing domains: the Change of Address tool

If you’re moving to a new domain or subdomain, say from example.at to example.com, also tell Google through the Change of Address tool in Search Console. You’ll need to be a verified owner of both properties. For a relaunch on the same domain, a move to HTTPS or a switch between www and non-www, you don’t need it.

After launch: monitor and fix

For the first few weeks, check Search Console regularly:

  • Page indexing: a sudden rise in “Not found (404)” or “Soft 404” usually means missing redirects.
  • Sitemaps: is the number of indexed new URLs going up?
  • Performance: are the new URLs picking up impressions and clicks for the searches the old pages ranked for?

Look at your server logs or analytics for 404 errors as well. Any old URL that still gets visits deserves its own redirect. For a medium-sized site, Google says it can take a few weeks or more for most pages to move.

How long to keep redirects

Google recommends keeping redirects for as long as possible, generally at least a year. If you’ve changed domains, that also means keeping the old domain registered and the server behind it serving redirects. Let the old domain lapse after a few months and you lose every link still pointing at it. Because old URLs live on in bookmarks, emails and other people’s websites, the simplest approach is usually to leave the rules in place for good.

Fix speed and accessibility while you’re at it

A relaunch is the cheapest moment to get the technical basics right. Measure how fast the old site loads and set a target for the new one. Our article on Core Web Vitals explains what the metrics mean and where to check them.

The same goes for accessibility. A site built from the start to work with a keyboard and a screen reader costs far less than retrofitting one later. Whether your site is legally required to be accessible in the EU is covered in our post on the European Accessibility Act. And if you’re budgeting for the relaunch itself, see what drives the cost of a website.

Your checklist

Before launch

  1. list every old URL and flag the important ones
  2. redirect map: a matching target for each old URL, or a deliberate 404/410
  3. carry over content, titles, descriptions and structured data
  4. staging behind a password or noindex

On launch day

  1. remove staging blocks
  2. switch on 301 redirects, test them, collapse chains
  3. point internal links, canonicals and hreflang to the new URLs
  4. submit the new sitemap and keep the old one for now
  5. if the domain changes: use the Change of Address tool

After launch

  1. check Search Console and 404 errors weekly
  2. add any missing redirects
  3. keep redirects for at least a year, ideally for good

When we relaunch a site, the redirect map is part of the plan from day one, so your site doesn’t lose visibility on Google. You can see how we work on our web design page. If you’d like one fixed contact for the technical side and search after launch, have a look at SEO and ongoing care. Or tell us about your project through the contact form.

Frequently asked questions

Will I lose rankings when I relaunch my website?

Not necessarily. Some fluctuation in the first few weeks is normal, because Google processes the move one URL at a time. Lasting drops usually have specific causes: missing redirects, content that didn't make it across, or a site still set to noindex after launch.

How long should I keep 301 redirects after a site migration?

Google recommends keeping redirects for as long as possible, generally at least a year. That gives Google time to pass signals from the old URLs to the new ones. Since old links live on in emails, bookmarks and other websites, there's a good case for never removing them.

Do I need the Change of Address tool in Search Console?

Only if you're moving to a new domain or subdomain, for example from example.at to example.com. You don't need it for a relaunch on the same domain, a move from HTTP to HTTPS, or switching between www and non-www.

Can I redirect old pages to the homepage?

It's better not to. Google specifically advises against redirecting lots of old URLs to one irrelevant page such as the homepage, as it confuses users and may be treated as a soft 404. Redirect to the closest matching new page, or let the old URL return a 404 or 410.

How long does it take Google to process a website migration?

Google says a medium-sized site can take a few weeks or more for most pages to move, and larger sites longer. Speed also depends on how often Google crawls your site anyway. Track progress in Search Console rather than checking positions every day.

More articles

All articles →