Website relaunch without losing rankings: the checklist

The new website has been online for three weeks. It looks better, loads faster and the team is proud. Then the figures arrive: organic visits are down 62 per cent. Search Console reports 1,400 pages returning 404 errors. What happened? Old addresses ended in /leistungen/webdesign.html, while new ones end in /leistungen/webdesign. One dot, four letters and half the visibility is gone.

In brief: A relaunch is a move. Changing addresses without arranging forwarding loses both visitors and rankings. This is avoidable through an inventory before rebuilding, a complete 301 mapping, a disciplined launch sequence and four weeks of follow-up checks. This article provides the checklist and redirect configuration.

Send an enquiry

Why the figures fall, and why it is no coincidence

Search engines have a picture of the old website: which addresses exist, what content they contain and how strongly they are linked. A relaunch often changes that picture radically. Typical causes of losses include:

• Changed URLs without redirects: the classic problem. Old addresses return 404 errors and accumulated authority dissipates.
• Lost content: pages nobody thought they would miss, but which ranked well and brought visitors.
• Missing or generic metadata after moving into the new system.
• Blocked indexing: the development environment was blocked through robots.txt or noindex, and the restriction accidentally goes live.
• Slower loading caused by new scripts, larger images or an overloaded theme.

Almost all of these are avoidable. The cause is rarely technical impossibility; it is missing planning.

Half a day of inventory saves weeks of investigation

An inventory comes before the first line of code. It is the foundation for everything that follows:

• A complete list of old URLs, obtained with a crawler rather than from memory.
• Traffic figures per page from analytics and Search Console: which pages actually bring visitors?
• Rankings for key search terms as a baseline for later comparison.
• External links: which third-party sites link to which pages? Those addresses must not disappear.
• Metadata, including titles and descriptions, backed up so they can be transferred rather than reinvented.

Collecting these data takes half a day's work and can save weeks of troubleshooting later.

301 redirects, one to one and without chains

Every old URL needs a destination. The rules are simple but strict:

• 301 rather than 302: a permanent redirect signals a definitive move and transfers signals from the old address.
• One to one wherever possible: the old page points to the matching new page, not indiscriminately to the homepage. Search engines treat blanket homepage redirects like errors.
• No chains: redirects leading to further redirects cost time and signal strength. Always point directly to the final destination.
• Removed content should lead to the closest relevant replacement. Only where there genuinely is no replacement is a clean 410 response the honest answer.
• Include images and PDFs: they generate traffic and links too.

What matters is that the redirect list is complete and tested before launch.

Redirects can be maintained in the server configuration. The exact implementation depends on the hosting environment:

# Apache: .htaccess – Einzelregeln und Muster
RewriteEngine On

# 1:1-Umzug einzelner Seiten
Redirect 301 /leistungen/webdesign.html /leistungen/webdesign

# Ganze Verzeichnisse mit gleicher Struktur
RewriteRule ^produkte/(.*)\.html$ /produkte/$1 [R=301,L]

# Alte Dateiendung generell entfernen
RewriteCond %{REQUEST_URI} \.html$
RewriteRule ^(.*)\.html$ /$1 [R=301,L]

# nginx: gleiche Logik
location ~ ^/produkte/(.*)\.html$ {
    return 301 /produkte/$1;
}

# Einzelne Umzüge sauber als Map pflegen
map $request_uri $redirect_ziel {
    /leistungen/webdesign.html   /leistungen/webdesign;
    /ueber-uns/team.html         /agentur/team;
}

Two practical rules matter. First, test the list before launch. A simple script requesting every old URL and recording status codes finds gaps within minutes:

# Alle alten URLs prüfen: erwartet wird 301, nicht 404
while read url; do
  code=$(curl -o /dev/null -s -w "%{http_code}" -I "$url")
  echo "$code  $url"
done < alte-urls.txt | grep -v "^301"

Second, avoid redirect chains. If A points to B and B to C, A should point directly to C. Every intermediate stop costs loading time and part of the transferred signals.

Launch day: sequence beats haste

The switchover is decisive. A short, fixed sequence has proved effective. First launch the new website and immediately check that search-engine restrictions have been removed. A forgotten noindex directive from testing is the most expensive mistake of all. Then activate redirects and spot-check the most important old addresses.

Next generate the new sitemap and submit it in Search Console, check robots.txt, verify the analytics tool is still measuring and work through the website's main functions: forms, search and contact details. A quick loading-speed test completes the day. Working through this systematically makes for a calmer weekend.

In practice: 1,200 lost pages and what they were worth

A typical scenario showing how such a case unfolds; the figures are illustrative.

A machinery manufacturer launches a new website. Two weeks later, the sales team reports no more enquiries through the site. Search Console shows 1,200 pages returning 404 errors. The old product documentation, linked by specialist forums over many years, has vanished entirely.

Diagnosis takes an hour. The provider had “tidied up” the structure: /produkte/typ-4711.html became /loesungen/maschinen/typ-4711. Redirects existed, but only for the twenty most important pages. The other 1,180 led nowhere, including every PDF data sheet.

Recovery follows the pattern described here: reconstruct the old URL list by crawling the archive, map it to the new destinations, configure 301 redirects, test and resubmit the sitemap. After around four weeks, traffic returns to its previous level; after eight weeks, it rises above it because the new site really is faster.

The real lesson: complete redirects always take less effort than recovering lost visibility. The data sheets nobody had listed turned out to be the website's most valuable pages.

Four weeks of follow-up checks

The first four weeks are crucial. Check coverage daily in Google Search Console. A sudden increase in 404 errors indicates missing redirects. Traffic figures show whether a drop stays within the normal range. A slight decline during the first two to three weeks is common while search engines process the new structure.

If the decline persists or worsens, investigate systematically. Are all old URLs redirected? Was previously ranking content shortened? Has loading time deteriorated? Experience shows that one of these three questions explains most cases. Avoid frantic changes: rankings need several weeks to settle again.

The opportunity in rebuilding

A relaunch is more than damage limitation. It is the best opportunity to remove structural baggage: create a clearer page structure with useful categories, descriptive URLs, consistent internal linking and organised content instead of dozens of barely visited pages.

Technical improvements also pay off immediately: modern image formats, good loading performance, structured data, accessibility and a maintainable CMS. Including these during the rebuild can leave a website measurably better after a few weeks, rather than merely back where it started.

Conclusion: forwarding is half the job

A relaunch without visibility loss is the result of preparation: capture all old URLs, redirect each address permanently to the correct destination, permit indexing, transfer metadata, watch loading speed and monitor consistently during the first weeks. Completing these steps turns risk into an improvement: a website that is faster, clearer and easier to find than its predecessor.

Frequently asked questions

Short answers to common questions about relaunches, redirects and visibility afterwards.