Website relaunch without losing rankings: the checklist

Why a relaunch can put rankings at risk

The new website is online, everyone is happy, and four weeks later a good share of organic inquiries is missing. This pattern repeats itself with website relaunches surprisingly reliably. It is almost never the design and almost always the fact that addresses, content and technical signals Google built up over years got lost in the move.

A website relaunch without losing rankings is therefore not a stroke of luck but the result of a manageable number of steps that all have to happen before going live. This checklist goes through them in order: why rankings get lost in the first place, what has to be settled before the rebuild, what to do on launch day and how you can tell in the weeks after whether everything went smoothly.

Your old website is not just a design. It is a grown network of URLs, links and rankings. If you keep this network in mind during the rebuild, you keep your visibility.

The new website is online, everyone is happy, and four weeks later a good share of organic inquiries is missing. This pattern repeats itself with website relaunches surprisingly reliably. It is almost never the design and almost always the fact that addresses, content and technical signals Google built up over years got lost in the move.

A website relaunch without losing rankings is therefore not a stroke of luck but the result of a manageable number of steps that all have to happen before going live. This checklist goes through them in order: why rankings get lost in the first place, what has to be settled before the rebuild, what to do on launch day and how you can tell in the weeks after whether everything went smoothly.

Why rankings get lost in a relaunch in the first place

Before we get to measures, it is worth looking at the causes. A ranking loss after a relaunch rarely has one single big reason. Usually it is several small oversights that add up.

Addresses change without a redirect

This is by far the most common mistake. The new page structure is better, so the pages now have different names. Every old address that nobody redirects to its new equivalent becomes an error page. Everything Google and other websites have built up for that address is gone. On a website that has grown over time, this quickly affects several hundred addresses, most of which nobody has on their radar anymore.

Content gets shortened or deleted

A relaunch is a good opportunity to clean up, and that is exactly where damage happens. An old, visually unattractive block of text may be the one the page has been ranking with for years. If you delete content without first checking which of it brings in visitors, you throw away visibility to make room.

Internal linking gets rethought

Which pages can be reached from the homepage and the navigation tells Google something about what matters on this website. If a service page that used to be prominently linked can only be reached via the footer on the new site, it loses weight. This happens silently and is only noticed weeks later.

Technical signals are missing in the new system

Page titles, descriptions, heading structure, image alt texts and structured data don't move over on their own when you switch systems. In many projects they are added afterwards, and until then the site is live without this information.

The staging environment goes live with it

Almost every project is built on a preview address that is blocked for search engines. If this block is accidentally carried over in the move, the entire website disappears from the index. This is the most expensive mistake on this list and at the same time the easiest to avoid.

What has to be settled before building

Most of the work for a clean relaunch happens before the first new page is built. These four things should be settled while the old website is still running.

A complete list of all addresses

Pull a list of every reachable address on the old website. Not just the pages from the navigation, but also blog posts, landing pages from old campaigns, PDF files and pages that can only be reached via direct links. This list is the basis for everything else. If you don't have it, you can't redirect either.

A snapshot of rankings and traffic

Record which pages are currently found for which search terms and how many visitors they bring in. Without this baseline, you can't judge after launch whether a change is normal or a problem. A screenshot of the key figures from the last three months is completely enough.

Evaluate content instead of carrying it over wholesale

Go through the address list with the traffic numbers next to it and decide for each page: stays, gets merged or goes. Pages with traffic stay or get merged, never deleted without replacement. Pages without any traffic and without external links can go. This decision belongs before the design, not after.

Know who links to you

Links from other websites often don't point to the homepage but to a specific subpage. These exact addresses must never lead nowhere. A list of the most important links therefore belongs next to the address list, so it is clear which redirects need to be checked especially carefully.

The go-live checklist

Once the groundwork is done, the go-live itself can be planned. These five steps in this order cover most of the risk.

Step 1: Set up the redirect matrix

Every old address gets a new destination address, entered in a table with two columns. Redirects are permanent, so with status code 301, and always to the page with matching content, not to the homepage across the board. Google treats a blanket redirect to the homepage as an error page with a detour and handles it accordingly. Redirect chains with several hops are resolved, so every old address points directly to its destination.

Step 2: Carry over page titles and headings

Enter the title, description and heading structure for every page before it goes live. If a page has been performing well, there is no reason to reinvent its title as part of the relaunch. Design may change, the content signals should only change on purpose.

Step 3: Check the technology before anyone sees the site

Before switching over, three things need to be checked: the search engine block from the staging environment has been removed, the sitemap contains the new addresses and no old ones, and the security certificate works on all variants of the domain. This check takes ten minutes and prevents the greatest possible damage.

Step 4: Prepare measurement

Analytics and Search Console should work on launch day, not a week later. Set up the goals again, check whether the tracking code is on all page types and submit the new sitemap. That is the only way to see immediately if something is wrong.

Step 5: Time the launch deliberately

Not on a Friday afternoon and not before a vacation. The first two working days after switching over are when errors show up and need to be fixed quickly. Plan this time in instead of hoping it won't be needed.

The weeks after the launch

The first 72 hours

Open the most important old addresses manually and check whether they land in the right place. Look for new error pages in Search Console and have the new sitemap read in. If something stands out here, it can still be corrected in this phase without lasting damage.

The first eight weeks

Some movement in the rankings is normal after a relaunch. Google first has to fully capture the new structure. A dip in the first two to three weeks is no reason to panic, as long as the curve rises again afterwards. Anything that is still clearly below the baseline after eight weeks, on the other hand, is a real problem and needs to be looked at.

Conclusion

A relaunch doesn't lose rankings because the design changes. It loses them because connections that existed for years break during the move. The list of measures is manageable: know which addresses exist, know which content carries weight, redirect every old address cleanly, carry over the technical signals and keep an eye on things after launch.

The difference between a relaunch that costs visibility and one that keeps it doesn't happen on launch day. It happens in the weeks before, in a table with two columns that nobody sees and that still decides the outcome.