During a website relaunch, rankings are usually lost because addresses change, content is removed or redirects are missing. If you create an inventory of all pages beforehand, redirect every old address to the matching new one with a 301, and carry over the content of the most important pages, you'll generally lose very little. After launch, you need four weeks of monitoring in Search Console.
Most visibility losses after a relaunch have nothing to do with the new design. They happen because addresses change and nobody redirects the old ones to the new ones, because pages with visitors are removed, or because the developer pushes the «noindex» from the test environment live. All three mistakes can be avoided if you plan the relaunch like a house move: first the inventory, then the address change, then the check.
Phase 1: The inventory before the relaunch
Before anyone starts work on the new website, you need a complete list of existing pages. Without this list, you won't know what's missing after launch.
- Collect all addresses. The XML sitemap of the old website is the starting point. Add the «Pages» report from Search Console, since Google often knows addresses that don't appear in any sitemap.
- Record performance per page. Export the clicks and impressions of the last twelve months per page in Search Console. This shows you which twenty pages bring in most of the visitors. These pages must not suffer during the relaunch.
- Note down external links. Pages that other websites link to absolutely need a redirect, otherwise those visitors end up on an error page.
- Save titles and meta descriptions. Exporting page titles, descriptions and headings takes an hour and prevents well-performing lines from being replaced by placeholders in the new system.
A joinery business with 60 pages needs an afternoon for this. For an online shop with 2,000 product pages, it's worth using a crawler tool that creates the list automatically.
Phase 2: The URL mapping
The mapping is a table with one row per old address. Each row gets a decision. If the address stays the same, the row is quickly done. If it changes, enter the new one.
| Old address | New address | Action |
|---|---|---|
| /leistungen/kuechen.html | /kuechen/ | 301 to new address |
| /news/2019-messe | (none) | 410, page removed |
| /ueber-uns.html | /ueber-uns/ | 301 to new address |
| /kontakt.html | /kontakt/ | 301 to new address |
| /angebot-sommer-2022 | /kuechen/ | 301 to the closest matching page on the topic |
Two rules save you trouble: every old address points to exactly one new one that matches the content. And no address points to the homepage by default just because it's convenient. Google generally treats such redirects like a missing page.
Phase 3: Setting up redirects
The mapping is implemented as 301 redirects, that is, permanent redirects. How this works in WordPress, Wix or on the server is explained in the guide to 301 redirects. Three points matter for the relaunch:
- No chains. If /old redirects to /middle and /middle redirects to /new, rebuild the first redirect so it points directly to /new.
- Consistent protocol and www. All variants (http, https, with and without www) must redirect to a single version.
- Test before launch. Run the redirects on the test environment and check a sample of twenty addresses from the mapping before the website goes live.
Phase 4: Carrying over content
A new design is no reason to shorten proven text. For the pages that had the most clicks in the inventory, carry the content over as unchanged as possible: same headings, same text, same images with the same alt text, same page title. If you want to shorten or rewrite content, do it a few weeks after launch, so you can see which change has which effect.
Also check the internal linking. Many relaunches lose visibility because the blog is no longer linked in the new menu, or because service pages can only be reached via a dropdown menu that Google doesn't recognise as a link. Every important page should be linked from at least one other page, either in the body text or in the navigation.
Launch day
On the day of the switchover, work through a short list, ideally with two people:
- The «noindex» from the test environment has been removed, and robots.txt allows crawling.
- The new XML sitemap has been submitted in Search Console, as described under XML sitemap.
- Twenty addresses from the mapping manually tested in the browser: do they land on the correct new page?
- Canonical tags point to the new address, no longer to the test domain.
- Analytics and Search Console are running on the new website.
- Contact form and phone link work.
The point about «noindex» comes first on purpose. It's the most common mistake and the most costly one, because Google removes the website from the index after a few days.
Four weeks of follow-up checks
After launch, Search Console shows whether the move was successful. A routine that has proven effective:
| Timing | What to check | Where |
|---|---|---|
| Day 1 to 3 | Error pages (404) in the "Pages" report, crawling errors | Search Console |
| Week 1 | Are the new addresses being indexed? Are impressions dropping sharply? | Search Console, "Performance" report |
| Week 2 | Comparison of the twenty most important pages with the inventory | Search Console, export from phase 1 |
| Week 4 | Total clicks compared with the four weeks before launch | Search Console |
If an old address with many impressions shows up as a 404 in week 1, its redirect is missing. Fix this straight away. More on the reports is under Setting up and reading Search Console.
How big the drop typically is
There's no solid, public figure for this. Google states in its documentation on website moves that fluctuations in the period after a move are normal and that the transition can take several weeks for medium-sized websites. Whether you lose ten percent or half your visitors after the relaunch depends almost entirely on how smoothly phases 1 to 4 went. A relaunch with unchanged addresses and unchanged content usually changes little. A relaunch where addresses change, pages disappear and nobody has a mapping can cost months.
If the blog is part of the website, the same applies to it as to service pages: posts that bring visitors keep their address or get a redirect. With a system like BlogPilot, which connects posts via the WordPress REST API or through a proxy, check before launch that the connection to the new CMS is in place, so publishing doesn't fail after the move.
Frequently asked questions
Do I have to keep the old addresses during a relaunch?
No, but it's the safest approach. If the addresses stay the same, the whole mapping becomes unnecessary and Google doesn't need to reassign anything. If the addresses change, that's not a problem, as long as every old address points to the correct new page via a 301.
How long does it take for Google to fully take over the new website?
Google states in its documentation on website moves that it can take several weeks for most pages to be taken over on a medium-sized website. Longer for larger websites. Google doesn't give a fixed figure, so it's worth monitoring for at least four weeks.
Can I combine the relaunch with a domain change?
Technically yes, but you double the risk because two things change at once. It's better to relaunch on the old domain first, wait a few weeks, then make the domain change using the move tool in Search Console. That way, if problems arise, you can see which step caused them.
What do I do with pages that no longer exist on the new website?
If a thematically matching successor page exists, redirect to it. If there isn't one, the page can return a 404 or 410 status code. Redirecting everything to the homepage across the board is treated by Google like a missing page and brings no benefit.