Website-Relaunch ohne Rankingverlust: was wirklich zählt

Eine neue Website geht online, sie ist schneller und schöner als die alte – und drei Wochen später kommen weniger Anfragen über Google. Das ist der häufigste Ablauf eines missglückten Relaunchs. Fast nie liegt es am Design. Fast immer liegt es an Adressen.

Ich habe diese Website selbst umgezogen: von einer Laravel-Anwendung auf eine statische Seite. Was dabei wichtig war, steht unten – mit dem, was ich daraus für Kundenprojekte übernehme.

Warum Rankings nach einem Relaunch fallen

Google speichert nicht „Ihre Website“, sondern einzelne Adressen. Jede Adresse hat ihre eigene Geschichte: welche Suchbegriffe sie bedient, welche anderen Seiten auf sie verlinken, wie Nutzer auf sie reagieren. Ändert sich eine Adresse ohne Weiterleitung, beginnt diese Geschichte von vorn. Die alte Adresse liefert einen Fehler, die neue ist ein unbeschriebenes Blatt.

Die typischen Ursachen:

• Neue Adressstruktur ohne Weiterleitungen. Aus /leistungen/webdesign wird /services/web, und die alte Adresse zeigt ins Leere.
• Zusätzliche Varianten. Plötzlich ist jede Seite mit und ohne Schrägstrich am Ende erreichbar, oder mit und ohne www. Für Google sind das zwei Seiten mit identischem Inhalt.
• Verlorene Inhalte. Ein Absatz, der für eine bestimmte Suche gerankt hat, fällt beim Neuschreiben weg.
• Technische Rückschritte. Titel und Beschreibungen fehlen, strukturierte Daten sind weg, die Sitemap enthält alte Adressen.

Schritt 1: Bestand sichern, bevor etwas geändert wird

Bevor die erste Zeile Code entsteht, gehört eine Liste aller Adressen auf den Tisch, unter denen die Seite heute erreichbar ist. Quellen dafür:

• die aktuelle XML-Sitemap
• die Google Search Console, Bereich „Seiten“ und „Leistung“: Welche Adressen bekommen Klicks?
• ein Crawl der bestehenden Seite, der auch Adressen findet, die in keiner Sitemap stehen
• Adressen, auf die andere Websites verlinken

Bei dieser Website waren es zwölf Adressen, die seit Monaten in den Suchergebnissen standen. Die Entscheidung war einfach: Jede einzelne bleibt exakt so erhalten, wie sie war. Kein „wir räumen bei der Gelegenheit die URLs auf“. Eine schönere Adresse ist es nicht wert, die Geschichte der alten zu verlieren.

Schritt 2: Jede alte Adresse bekommt ein Ziel

Für jede Adresse aus der Liste gibt es genau drei Möglichkeiten:

1. Sie bleibt. Die beste Lösung, wo immer es geht.
2. Sie wird dauerhaft weitergeleitet (Statuscode 301) auf die neue Seite mit demselben Inhalt. Nicht auf die Startseite – eine Weiterleitung auf eine thematisch fremde Seite behandelt Google wie einen Fehler.
3. Sie entfällt bewusst, weil es den Inhalt nicht mehr gibt. Dann liefert sie ehrlich einen 404 oder 410.

Diese Zuordnung gehört schriftlich in eine Tabelle, nicht in den Kopf des Entwicklers.

Schritt 3: Eine Adresse pro Inhalt

Der unauffälligste Fehler: Ein Inhalt ist plötzlich unter mehreren Adressen erreichbar. Prüfen Sie nach dem Relaunch mindestens diese Varianten:

• http:// und https://
• mit und ohne www
• mit und ohne Schrägstrich am Ende
• mit .html und ohne
• Groß- und Kleinschreibung

Jede Variante außer einer wird per 301 auf die kanonische Adresse weitergeleitet oder liefert einen 404 – sie darf nur nicht denselben Inhalt ein zweites Mal ausliefern. Zusätzlich nennt jede Seite ihre kanonische Adresse im Kopf (<link rel="canonical">). Das Canonical ist ein Hinweis an Google, die Weiterleitung ist eine Tatsache. Verlassen Sie sich nicht allein auf den Hinweis.

Auch Vorschau-Umgebungen gehören dazu. Viele Hosting-Anbieter stellen jede Version unter einer eigenen Test-Adresse bereit. Ohne Canonical auf die Produktivseite konkurriert diese Testseite mit Ihrer echten um dieselben Suchbegriffe.

Schritt 4: Prüfen, automatisch

Eine Liste, die man einmal von Hand abhakt, hilft beim ersten Start. Beim fünften Update danach hilft sie nicht mehr. Deshalb läuft bei dieser Website nach jedem Bauen ein kleines Prüfskript. Es bricht den Build ab, sobald

• eine der zwölf Adressen im Ergebnis fehlt,
• eine Seite ohne Titel, Beschreibung oder Canonical ausgeliefert würde,
• ein Canonical auf eine andere Adresse oder einen anderen Host zeigt,
• eine Adresse in der Sitemap fehlt.

Ein zweites Skript folgt jedem internen Link und meldet, was ins Leere zeigt. Beides kostet einmal eine Stunde und verhindert, dass ein Tippfehler in einem Link wochenlang unbemerkt online steht.

Für Kundenprojekte übernehme ich genau das: Die Liste der Adressen aus Schritt 1 wird Teil des Projekts und wird bei jeder Änderung geprüft – nicht nur am Tag des Starts.

Schritt 5: Nach dem Start beobachten

In den ersten Wochen nach dem Relaunch lohnt ein regelmäßiger Blick in die Search Console:

• Seitenindexierung: Tauchen neue Fehler auf, etwa „Nicht gefunden (404)“ für Adressen, die vergessen wurden?
• Leistung: Verlieren einzelne Seiten deutlich Klicks? Dann gezielt diese Seite mit der alten Fassung vergleichen.
• Sitemap: neu einreichen, damit Google die neuen Seiten schnell findet.

Ein leichtes Schwanken in den ersten Tagen ist normal. Ein dauerhafter Einbruch einzelner Seiten ist es nicht – und hat fast immer eine konkrete Ursache aus der Liste oben.

Die Kurzfassung

• Erst Adressen sichern, dann bauen.
• Jede alte Adresse bleibt, wird gezielt weitergeleitet oder entfällt bewusst.
• Eine Adresse pro Inhalt, alle Varianten per 301 zusammengeführt.
• Prüfen nicht einmal, sondern bei jedem Build.
• Nach dem Start die Search Console beobachten.

Ein Relaunch muss keine Rankings kosten. Er kostet sie nur, wenn die Adressen als Detail behandelt werden, das man am Ende noch schnell erledigt.