Website-Relaunch: Redirect-Mapping und Launch-Test gegen Rankingverlust

Ein Relaunch ändert meist Plattform, Design und URL-Struktur zugleich. Für Suchmaschinen ist jede alte URL jedoch ein Datensatz mit Geschichte: Backlinks, interne Verlinkung, Nutzersignale, Crawl-Budget. Fällt die URL ohne saubere Weiterleitung weg, startet die neue Adresse ohne diesen Kontext. Das führt zu schleichenden Verlusten, die oft erst nach Wochen auffallen.

Dieser Beitrag beschreibt einen technischen Ablauf, der sich in Relaunch-Projekten bewährt hat: ein vollständiges URL-Inventar, ein Redirect-Mapping als Tabelle, 301-Regeln im Webserver, eine Launch-Checkliste und ein automatisierter Test direkt nach dem Go-live. Es gibt keine Rankinggarantie. Das Ziel: vermeidbare Fehler ausschließen. Eine ausführlichere Einordnung inklusive Kosten und rechtlicher Punkte steht in der Anleitung zur SEO-Migration beim Website-Relaunch.

URL-Inventar und Mapping

Vor der ersten Zeile Code kommt die Bestandsaufnahme. Ein Crawler wie Screaming Frog erfasst alle indexierbaren URLs, Bilder und PDF-Dokumente. Ergänzend liefert der Export aus der Search Console jene Adressen, die Traffic erhalten, intern aber kaum verlinkt sind und im Crawl deshalb fehlen.

Aus dem Inventar entsteht das Mapping: jede alte URL erhält genau ein Ziel und einen erwarteten Statuscode.

Alte URL	Neue URL	Status
/leistungen.html	/leistungen/	301
/blog/2019/seo-tipps	/blog/seo-tipps/	301
/kontakt.php	/kontakt/	301
/impressum.html	/impressum/	301
/alte-aktion	ohne Ersatz	410
/downloads/preisliste.pdf	unverändert	200

Drei Regeln gelten für die Tabelle:

• Jede alte URL wird auf die inhaltlich passende neue Seite umgeleitet. Eine pauschale Weiterleitung aller Altadressen auf die Startseite kann von Google als Soft-404 behandelt werden, und die Backlinks wirken dann nicht auf der passenden Seite.
• Das Ziel ist immer die endgültige URL. Ketten wie 301, 301, 200 kosten pro zusätzlicher Weiterleitung Ladezeit und sollten vermieden werden.
• Seiten ohne Ersatz bekommen bewusst 410 oder 404, keine Weiterleitung ins Leere.

Ein Mapping lässt sich später nur mühsam rekonstruieren und hinterlässt blinde Flecken. Es muss deshalb vor dem Design erfolgen.

301-Regeln im nginx

Bei einigen hundert URLs hat sich eine Map-Datei bewährt, die aus der Tabelle generiert wird. Das hält die Server-Konfiguration übersichtlich und die Regeln versionierbar.

# /etc/nginx/conf.d/redirects.conf (http-Kontext)
map $uri $redirect_target {
    default                  "";
    /leistungen.html         /leistungen/;
    /blog/2019/seo-tipps     /blog/seo-tipps/;
    /kontakt.php             /kontakt/;
    /impressum.html          /impressum/;
    ~^/produkt/(\d+)-(.+)$   /artikel/$2/;
}

server {
    listen 443 ssl;
    server_name example.com;

    if ($redirect_target) {
        return 301 $redirect_target;
    }

    location = /alte-aktion {
        return 410;
    }
}

Die Map arbeitet mit $uri und damit ohne Query-String. Parameter wie Tracking-Angaben bleiben bei return 301 $redirect_target nicht erhalten. Sollen sie mitgeführt werden, ist $redirect_target$is_args$args zu verwenden. Das HTTP-zu-HTTPS-Umleiten und die Wahl zwischen www und Apex-Domain gehören in einen eigenen Server-Block, damit pro Aufruf nur ein Hop entsteht.

Launch-Checkliste

Technische Fehler aus der Staging-Umgebung sind eine häufige Ursache für Indexverluste. Vor dem Umschalten sollte Folgendes feststehen:

• Staging war per Passwortschutz und Disallow: / abgeschirmt. Auf der Live-Domain ist die robots.txt anschließend wieder bereinigt.
• Kein noindex mehr im <head> oder im HTTP-Header (X-Robots-Tag).
• Canonical-Tags zeigen auf die neuen, absoluten Ziel-URLs mit HTTPS.
• Die neue XML-Sitemap enthält nur URLs mit Status 200 und ist in der Search Console eingereicht.
• Impressum, Datenschutzerklärung und strukturierte Daten sind migriert und unter den neuen URLs erreichbar.
• Interne Links verweisen direkt auf Ziel-URLs und nicht auf Altadressen, die erst weiterleiten.
• Mixed Content ist behoben, die Core Web Vitals liegen auf Staging im grünen Bereich.
• Search Console, Bing Webmaster Tools und ein Uptime-Monitoring laufen bereits vor dem Relaunch.

Als Zeitpunkt für das Go-live eignet sich ein Vormittag unter der Woche, etwa Dienstag oder Mittwoch. Bei Serverproblemen bleibt dann Zeit zum Reagieren, bevor das besucherstarke Wochenende beginnt.

Automatisierter Test nach dem Go-live

Manuelles Stichprobenklicken reicht bei einem Mapping mit mehreren hundert Zeilen nicht aus. Ein kleines Skript prüft jede Zeile: Antwortet die alte URL mit dem erwarteten Code, zeigt der Location-Header auf das richtige Ziel, und liefert das Ziel direkt 200 statt einer weiteren Weiterleitung?

Die Eingabedatei mapping.tsv enthält pro Zeile alte URL, erwarteten Status und Ziel, durch Tabulator getrennt:

/leistungen.html    301 /leistungen/
/kontakt.php    301 /kontakt/
/alte-aktion    410 
/downloads/preisliste.pdf   200 

#!/usr/bin/env bash
# Aufruf: ./check-redirects.sh https://example.com mapping.tsv
set -u
BASE="${1:?Basis-URL fehlt}"
MAP="${2:?Mapping-Datei fehlt}"
errors=0

while IFS=$'\t' read -r old expected target; do
  [[ -z "${old:-}" || "$old" == \#* ]] && continue

  read -r code location < <(curl -s -o /dev/null --max-time 10 \
    -w '%{http_code} %{redirect_url}\n' "${BASE}${old}")

  if [[ "$code" != "$expected" ]]; then
    echo "FEHLER  ${old}: erwartet ${expected}, erhalten ${code}"
    errors=$((errors + 1))
    continue
  fi

  if [[ "$expected" == "301" ]]; then
    if [[ "${location:-}" != "${BASE}${target}" ]]; then
      echo "FEHLER  ${old}: falsches Ziel (${location:-leer})"
      errors=$((errors + 1))
      continue
    fi
    final=$(curl -s -o /dev/null --max-time 10 -w '%{http_code}' "${BASE}${target}")
    if [[ "$final" != "200" ]]; then
      echo "FEHLER  ${old}: Ziel liefert ${final}, Kette oder Lücke"
      errors=$((errors + 1))
      continue
    fi
  fi
  echo "OK      ${old} (${code})"
done < "$MAP"

echo "Fehler gesamt: ${errors}"
exit $(( errors > 0 ))

Weil curl Weiterleitungen ohne -L nicht verfolgt, sieht das Skript den ersten Hop und kann Ketten sauber erkennen. Der Exit-Code ermöglicht den Einsatz in einer Pipeline oder einem Cronjob.

Ein Beispiel aus der Praxis zeigt, wie weit sich das treiben lässt: Ein Deploy-Skript führte sechs geprüfte Schritte aus. Zuerst wurde das Archiv gepackt und auf Vollständigkeit kontrolliert, danach hochgeladen und die Dateigröße verglichen, anschließend ein Backup angelegt, entpackt, gebaut und zuletzt verifiziert. Die Verifikation rief neun Seiten und drei Bilder ab und erwartete jeweils Status 200. Schlug ein Schritt fehl, stellte das Skript den vorherigen Stand automatisch wieder her. Dasselbe Prinzip gilt für Relaunches: Die Prüfung ist Teil des Ablaufs und kein nachgelagerter Handgriff.

Rollback-Plan

Ein Rollback muss vor dem Go-live geübt sein, sonst existiert er nur auf dem Papier. Bewährt hat sich:

1. Der alte Stand bleibt unverändert lauffähig, auf separatem Verzeichnis oder Server, inklusive Datenbank-Snapshot.
2. Vorab ist festgelegt, was als Abbruchkriterium gilt, etwa fehlerhafte Checkouts, ein großer Anteil an 404 im Mapping-Test oder eine blockierte robots.txt.
3. Der Wechsel erfolgt über einen einzigen Schalter, etwa Symlink, Upstream im nginx oder DNS mit niedriger TTL. Eine TTL von wenigen Minuten (Richtwert) sollte rechtzeitig vor dem Termin gesetzt werden.
4. Nach einem Rollback bleibt das Mapping unverändert. Es wird korrigiert und der Test erneut ausgeführt, bevor ein zweiter Versuch startet.

Monitoring in der Search Console

Die ersten Tage nach dem Go-live (als Richtwert 72 Stunden) sind die kritische Phase. Täglich zu prüfen sind:

• Bericht "Seiten": Warum werden Seiten nicht indexiert? Neue Gruppen wie "Seite mit Weiterleitung", "Durch robots.txt blockiert" oder "Ausgeschlossen durch noindex-Tag" sind Warnsignale.
• Crawling-Statistiken: Steigende Serverantwortzeiten (grober Praxisrichtwert, keine Vorgabe von Google: dauerhaft über 800 ms) bremsen das Crawling, besonders bei großen Katalogen.
• Core Web Vitals: LCP bis 2,5 Sekunden, INP bis 200 ms, CLS bis 0,1, jeweils im 75. Perzentil der Nutzerdaten, laut Empfehlung von Google.
• Server-Logs: Googlebot-Zugriffe mit 404, 5xx und Redirect-Ketten zeigen vergessene Zeilen im Mapping.
• Rankings der wichtigsten Suchbegriffe: Ein plötzlicher Absturz wichtiger Suchbegriffe innerhalb von 48 Stunden kann auf ein technisches Problem hindeuten.

Wie lange eine Erholung dauert, lässt sich nicht verlässlich vorhersagen; sie hängt von Umfang und Qualität der Migration ab. Je früher Fehler behoben werden, desto geringer fällt der Schaden aus.

Fazit

Ein Relaunch mit möglichst geringem Rankingrisiko ist weniger eine Frage des Designs als der Disziplin: Inventar vor Entwicklung, Mapping als Tabelle, Regeln im Webserver, ein automatisierter Test nach dem Umschalten und ein geübter Rückweg. Wer das Monitoring bereits Wochen vor dem Termin aufsetzt und die Staging-Umgebung regelmäßig crawlt, erkennt Canonical-Konflikte und langsame Seiten, bevor sie live gehen. Das Ergebnis lässt sich nicht garantieren, aber die häufigsten vermeidbaren Fehler lassen sich so deutlich verringern.

Hinweis: Dieser Beitrag ist Eigenwerbung (Werbung) des Anbieters von Webentwickler.Pro. Die vollständige Anleitung steht im Blog von Webentwickler.Pro.