Website-Relaunch ohne Rankingverlust: Weiterleitungen richtig machen

Im September 2026 habe ich azarco.de neu gebaut: weg von WordPress, hin zu einer eigenen React-Seite. Dabei sind 29 alte Adressen umgezogen. Zwei Dinge habe ich falsch gemacht, und Google hat beide innerhalb von Tagen in der Search Console gemeldet. Hier steht, wie ein Umzug ohne Rankingverlust geht, mit den Fehlern, die ich selbst gemacht habe, damit du sie nicht machen musst.

Warum Relaunches Rankings kosten

Google kennt deine Website als Liste von Adressen. Jede davon hat über Jahre Vertrauen gesammelt: Links von anderen Seiten, Klicks, Verweildauer. Beim Relaunch ändern sich Adressen, weil die neue Seite anders aufgebaut ist. Aus /leistungen/webdesign wird /leistungen, aus /ueber-uns wird /ueber-mich. Wenn die alte Adresse danach ins Leere läuft, ist das gesammelte Vertrauen weg. Google sieht einen Fehler 404 und streicht die Seite nach einer Weile aus dem Index. Der Link von der Handwerkskammer, der seit 2019 auf deine alte Leistungsseite zeigt, bringt dann nichts mehr.

Die Lösung heißt Weiterleitung: Die alte Adresse antwortet nicht mit „gibt es nicht“, sondern mit „ist umgezogen nach …“. Google folgt und überträgt das Vertrauen. Klingt einfach. Die Details entscheiden.

Schritt 1: Alle alten Adressen finden

Du brauchst eine vollständige Liste. Nicht die Seiten, die du kennst, sondern die, die Google kennt. Drei Quellen:

• Search Console, Bericht „Leistung“, Reiter „Seiten“: alle Adressen, die in den letzten 16 Monaten Impressionen hatten.
• Search Console, Bericht „Seitenindexierung“: alle Adressen, die Google kennt, auch die nicht indexierten.
• Die Sitemap der alten Seite und, wenn du Zugriff hast, die Server-Logs.

Bei mir kamen dabei Adressen heraus, an die ich nicht gedacht hätte. /home/, die alte WordPress-Startseite. /vcard, /visitenkarte und /card, drei Schreibweisen für dieselbe digitale Visitenkarte. Und /?wpr_templates=user-header-aimatrix-v1-header, ein Baustein des alten Seitenbaukastens, den Google als eigene Seite geführt hat.

Schritt 2: Jeder alten Adresse ein Ziel geben

Für jede alte Adresse legst du fest, wohin sie führt. Die Regel: auf die Seite, die inhaltlich am nächsten dran ist. Nicht auf die Startseite. Wenn alle alten Adressen auf die Startseite zeigen, wertet Google das als „Soft 404“, also als verkappten Fehler, und überträgt nichts.

Bei mir sah die Liste so aus, ein Ausschnitt:

Alt	Neu
/ueber-uns	/ueber-mich
/leistungen/webdesign	/leistungen
/leistungen/flyer-design	/projekte
/vcard, /visitenkarte, /card	/v-card
/home	/

Die Liste lebt bei mir an genau einer Stelle im Code. Daraus entstehen die Weiterleitungen auf dem Server und die Tests, die prüfen, ob alle 29 noch funktionieren. Zwei Listen, eine im Kopf und eine im Server, laufen auseinander.

Schritt 3: Echter 301, nichts anderes

Es gibt vier Wege, einen Besucher umzuleiten. Nur einer ist für Google der richtige.

• 301 (dauerhaft verschoben): Der Server antwortet, bevor irgendeine Seite geladen wird. Google überträgt Rankings. Das ist der Weg.
• 302 (vorübergehend): Google behält die alte Adresse im Index, weil „vorübergehend“ heißt, sie kommt wieder. Falsch für einen Relaunch.
• Meta-Refresh im HTML: Die alte Seite lädt mit Status 200 und springt dann weiter. Google muss die Seite rendern, um die Weiterleitung zu sehen. Unzuverlässig.
• JavaScript (location.replace): Dasselbe Problem, nur schlimmer. Crawler ohne JavaScript sehen gar nichts.

Mein erster Fehler: Ich hatte für die alten Adressen kleine HTML-Dateien hinterlegt, die per Meta-Refresh und JavaScript weiterleiten, mit noindex als Sicherheitsnetz. Der Server lieferte sie mit Status 200 aus. Google hat sie gelesen, das noindex gesehen und die Adressen unter „Durch noindex-Tag ausgeschlossen“ einsortiert. Das Vertrauen wurde nicht übertragen, es wurde verworfen. Erst echte 301-Antworten vom Server haben das behoben.

Schritt 4: Ein Sprung, nicht vier

Weiterleitungen stapeln sich gern. Typische Kette: http://www.deine-seite.de/ueber-uns/ geht zuerst auf https, dann von www auf ohne www, dann vom Schrägstrich am Ende auf ohne, dann von /ueber-uns auf /ueber-mich. Vier Sprünge. Jeder einzelne kostet Google eine Anfrage, ab zehn bricht der Crawler ab, und schon ab drei merkt es der Besucher an der Ladezeit.

Genau das hatte ich: vier Regeln hintereinander, jede mit eigener Weiterleitung. Die Lösung ist, die endgültige Adresse einmal auszurechnen und mit einem einzigen 301 dorthin zu springen. In Express sieht der Kern so aus:

function kanonisch(req) {
  let pfad = req.path
    .replace(/\/{2,}/g, '/')          // doppelte Schrägstriche
    .replace(/\/index\.html$/i, '/')  // /index.html ist die Datei, nicht die Seite
  if (pfad.length > 1) pfad = pfad.replace(/\/+$/, '') // kein Schrägstrich am Ende
  pfad = ALTE_URLS[pfad.toLowerCase()] ?? pfad      // alte Adresse → neues Ziel
  const hostFalsch = req.protocol !== 'https' || req.hostname.startsWith('www.')
  if (pfad === req.path && !hostFalsch) return null
  return 'https://azarco.de' + pfad
}

Egal, wie die Anfrage ankommt: Es gibt genau eine Antwort, und die zeigt auf die endgültige Adresse.

Schritt 5: Die Schrägstrich-Falle

Mein zweiter Fehler, und der hat mehr gekostet. Die neue Seite liegt als vorab gerendertes HTML auf dem Server, jede Unterseite in einem eigenen Ordner: /webdesign-herford/index.html. Apache hängt bei Ordnern automatisch einen Schrägstrich an die Adresse. Aus /webdesign-herford wurde /webdesign-herford/, per Weiterleitung. Meine eigene Regel „kein Schrägstrich am Ende“ hat dann wieder zurückgeleitet.

Das Ergebnis in der Search Console: Unterseiten aus meiner eigenen Sitemap standen unter „Seite mit Weiterleitung“. Google hat sie aufgerufen, eine Weiterleitung bekommen und sie als nicht indexierbar eingestuft. Wochenlang. Die Zeile DirectorySlash Off in der .htaccess hat es behoben. Wer einen eigenen Server betreibt, prüft nach dem Relaunch jede Adresse aus der Sitemap mit curl -I und erwartet überall Status 200.

Schritt 6: Canonical, Sitemap, robots.txt

Drei Dinge, die Google nach dem Umzug braucht, damit es die neue Struktur schnell versteht:

• Canonical-Tag auf jeder Seite, das auf die eigene, endgültige Adresse zeigt. Mit oder ohne Schrägstrich, aber überall gleich. Ich hatte die Startseite einmal mit und einmal ohne, je nachdem, ob das HTML vom Server oder vom Browser kam.
• Sitemap nur mit den neuen Adressen, keine einzige alte. Das Datum lastmod soll stimmen. Wer bei jedem Deploy alle Seiten auf „heute“ setzt, sagt Google damit nichts, und Google ignoriert die Angabe irgendwann. Bei mir rückt das Datum nur vor, wenn sich der Inhalt der Seite wirklich geändert hat.
• robots.txt ohne versehentliche Sperren. Nach einem Relaunch lohnt ein Blick, ob dort noch Disallow: / aus der Entwicklungsphase steht. Das passiert öfter, als man denkt.

Schritt 7: Die Search Console lesen, ohne in Panik zu geraten

Nach dem Relaunch wird der Bericht „Seitenindexierung“ erst einmal schlechter aussehen. Das ist normal. Was die Einträge bedeuten:

• „Seite mit Weiterleitung“: Alte Adressen, die korrekt weiterleiten. Das ist kein Fehler, sondern das gewünschte Ergebnis. Die Schaltfläche „Fehlerbehebung überprüfen“ wird hier immer „fehlgeschlagen“ melden, weil die Seiten ja weiterleiten sollen. Nicht klicken.
• „Gefunden, zurzeit nicht indexiert“: Google kennt die neuen Adressen, hat sie aber noch nicht gecrawlt. Warteschlange. Bei kleinen Seiten kann das Wochen dauern.
• „Gecrawlt, zurzeit nicht indexiert“: Google war da und hat sich gegen die Seite entschieden. Meist dünner oder sehr ähnlicher Inhalt. Hier lohnt ein Blick auf den Text.
• „Durch noindex-Tag ausgeschlossen“: Sollte nach einem Relaunch bei null stehen. Wenn nicht, liefert dein Server irgendwo Seiten mit noindex aus, die eigentlich weiterleiten oder indexiert werden sollen.

Für die wichtigsten zehn Seiten kannst du über „URL-Prüfung“ die Indexierung beantragen. Das beschleunigt den ersten Crawl. Alles Weitere ist Geduld.

Die Checkliste

1. Alle alten Adressen aus Search Console, alter Sitemap und Logs sammeln.
2. Jeder alten Adresse ein inhaltlich passendes Ziel geben, nie pauschal die Startseite.
3. Weiterleitungen als 301 vom Server, nicht per Meta-Refresh oder JavaScript.
4. Jede Weiterleitung in einem Sprung ans endgültige Ziel, absolute Adresse im Location-Header.
5. http, www, Schrägstrich am Ende, /index.html: alles auf eine Schreibweise.
6. Jede Adresse aus der neuen Sitemap mit curl -I prüfen: Status 200, keine Weiterleitung.
7. Canonical auf jeder Seite, überall dieselbe Schreibweise.
8. Sitemap nur mit neuen Adressen, lastmod nur bei echten Änderungen.
9. robots.txt prüfen, noindex prüfen.
10. Search Console: alte Sitemap entfernen, neue einreichen, Schlüsselseiten zur Indexierung beantragen, dann vier bis acht Wochen beobachten.

Was es gebracht hat

Zwei Wochen nach der Korrektur stand „Durch noindex-Tag ausgeschlossen“ auf null und die Validierung auf „bestanden“. Die Seiten, die unter „Seite mit Weiterleitung“ festhingen, werden nach und nach wieder als normale Seiten gecrawlt. Die neuen Unterseiten tauchen seitdem eine nach der anderen in der Suche auf, zuerst mit Impressionen, die Klicks kommen später. Ohne saubere Weiterleitungen wäre die Kurve zuerst nach unten gegangen.

Wenn du einen Relaunch planst oder gerade einen hinter dir hast, bei dem die Zahlen eingebrochen sind: Schreib mir. Ich schaue mir Search Console und Server an und sage dir, wo es hakt.