Kurz beantwortet
Rankings bleiben bei einem Relaunch erhalten, wenn alle bisherigen Seiten erfasst, jede alte Adresse per 301-Weiterleitung auf die passende neue Seite umgeleitet, wichtige Inhalte übernommen und die neue Website nach dem Launch in der Google Search Console kontrolliert wird. Leichte Schwankungen in den ersten Wochen sind laut Google normal.
Das Wichtigste in Kürze
- Erfassen Sie vor dem Relaunch alle Seiten, Besucherzahlen, Rankings und Links.
- Leiten Sie jede alte URL per 301 oder 308 auf die inhaltlich passende neue Seite um, nie pauschal auf die Startseite.
- Google empfiehlt, Weiterleitungen so lange wie möglich zu behalten, in der Regel mindestens ein Jahr.
- Schützen Sie die Testumgebung mit Passwort oder noindex. Die robots.txt allein reicht nicht.
- Bei kleinen und mittleren Websites dauert der Umzug laut Google einige Wochen.
Warum Rankings bei einem Relaunch verloren gehen
Google hat Ihre bisherigen Seiten über Jahre bewertet. Bei einem Relaunch ändern sich oft Adressen, Inhalte, Struktur und Technik gleichzeitig. Die häufigsten Ursachen für Ranking-Verluste sind:
- Fehlende Weiterleitungen: Alte Adressen führen ins Leere, Besucher und Google landen auf Fehlerseiten.
- Gelöschte Inhalte: Seiten, die Besucher brachten, fallen weg, ohne dass es jemand bemerkt.
- Gesperrte Website: Die Sperre der Testumgebung bleibt nach dem Launch aktiv.
- Technische Fehler: falsche Canonical-Angaben, Weiterleitungsketten oder deutlich langsamere Seiten.
Google rät, bei grossen Umzügen möglichst nicht alles gleichzeitig zu ändern. Wenn Design, System und Adressen neu sind, ist sorgfältige Planung umso wichtiger.
Phase 1: Bestandsaufnahme
Bevor etwas verändert wird, halten Sie fest, was heute funktioniert:
- Alle URLs der aktuellen Website erfassen, zum Beispiel mit einem Crawler und aus der Sitemap.
- In der Google Search Console die Seiten mit den meisten Klicks und Impressionen exportieren.
- Besucherzahlen pro Seite aus Google Analytics sichern.
- Wichtige externe Links auf Ihre Website festhalten.
- Seitentitel, Meta-Beschreibungen und strukturierte Daten der wichtigsten Seiten dokumentieren.
- Ladezeiten und Core Web Vitals der alten Website messen, als Vergleichswert.
Praxistipp
Exportieren Sie die Daten aus der Search Console vor dem Relaunch. So können Sie später genau vergleichen, welche Seiten wie viele Klicks hatten.
Phase 2: URL-Plan und 301-Weiterleitungen
Das Herzstück jedes Relaunchs ist der URL-Plan: eine Liste, in der jede alte Adresse ihrer neuen Adresse zugeordnet ist. Google empfiehlt dafür serverseitige, permanente Weiterleitungen.
| Art | Typ | Wie Google sie behandelt |
|---|---|---|
| 301 und 308 | permanent, serverseitig | Empfohlen. Die neue URL wird als Hauptversion übernommen. |
| 302 und 307 | temporär | Die alte URL bleibt eher in den Suchergebnissen. |
| Meta-Refresh mit 0 Sekunden | permanent | Möglich, aber weniger zuverlässig als serverseitig. |
| JavaScript-Weiterleitung | permanent | Nur wenn nichts anderes geht. Schlägt das Rendering fehl, sieht Google sie nicht. |
Regeln für saubere Weiterleitungen
- Jede alte URL zeigt auf die inhaltlich passendste neue Seite.
- Keine Massenweiterleitung auf die Startseite. Google kann solche Weiterleitungen als «Soft 404» werten.
- Keine Ketten: Weiterleitungen führen direkt zum endgültigen Ziel.
- Seiten, die es ohne Ersatz nicht mehr gibt, dürfen einen echten 404-Status liefern.
- Weiterleitungen so lange wie möglich behalten, laut Google in der Regel mindestens ein Jahr.
Phase 3: Die Testumgebung richtig schützen
Die neue Website wird meist auf einer Testumgebung aufgebaut. Diese soll nicht bei Google erscheinen, sonst konkurriert sie mit der echten Website.
- Passwortschutz: der sicherste Weg, private Inhalte von Google fernzuhalten.
- noindex: über ein Meta-Tag oder den HTTP-Header X-Robots-Tag.
- Nicht nur robots.txt: Laut Google ist die robots.txt kein Mittel, um Seiten aus dem Index fernzuhalten. Gesperrte Seiten können trotzdem indexiert werden, wenn andere auf sie verlinken.
Achtung
Führen Sie eine Liste aller Seiten mit noindex. Am Launch-Tag muss diese Sperre auf der echten Website zuverlässig entfernt werden.
Phase 4: Der Launch-Tag
- Sperren der Testumgebung entfernen: noindex, Passwortschutz, robots.txt.
- Weiterleitungen aktivieren und Stichproben mit dem URL-Prüftool der Search Console testen.
- Interne Links auf die neuen URLs umstellen, statt sich auf Weiterleitungen zu verlassen.
- Canonical- und hreflang-Angaben auf die neuen URLs aktualisieren.
- Eine Sitemap mit den neuen URLs einreichen. Laut Google kann die alte Sitemap während des Umzugs zusätzlich bestehen bleiben.
- Bei einem Domainwechsel das Tool «Adressänderung» in der Search Console nutzen. Es ist nur für Domain- oder Subdomain-Wechsel gedacht.
- Ladezeiten prüfen und mit den Werten der alten Website vergleichen.
| Core Web Vital | Misst | Gut |
|---|---|---|
| LCP | Ladezeit des grössten Inhalts | bis 2,5 Sekunden |
| INP | Reaktion auf Eingaben | bis 200 Millisekunden |
| CLS | Verschieben des Layouts | bis 0,1 |
Phase 5: Nach dem Launch kontrollieren
Laut Google crawlt der Googlebot eine umgezogene Website für eine Weile stärker als üblich. Bei kleinen und mittleren Websites dauert es einige Wochen, bis die meisten Seiten umgezogen sind. Schwankungen in der Sichtbarkeit sind in dieser Zeit normal.
| Bericht in der Search Console | Was Sie prüfen |
|---|---|
| Seitenindexierung | Werden die neuen Seiten indexiert? Gibt es Weiterleitungsfehler oder Soft 404? |
| Sitemaps | Wurde die neue Sitemap erfolgreich gelesen? |
| URL-Prüfung | Welche URL hat Google als Hauptversion gewählt? |
| Leistung mit Vergleich | Entwickeln sich Klicks und Impressionen im Vergleich zur Zeit vor dem Relaunch? |
Prüfen Sie in den ersten Wochen wöchentlich, danach monatlich. Fehler, die Sie früh finden, sind schnell behoben.
Die häufigsten Fehler
- Alle alten URLs auf die Startseite umleiten.
- Die noindex-Sperre der Testumgebung mit live schalten.
- Seiten mit vielen Besuchern ohne Ersatz löschen.
- Weiterleitungen nach wenigen Wochen wieder entfernen.
- Interne Links nicht anpassen und so Weiterleitungsketten erzeugen.
- Die neue Website langsamer machen als die alte.
Inhalte übernehmen und verbessern
Ein neues Design ist schnell gemacht. Über die Rankings entscheiden aber vor allem die Inhalte. Gehen Sie beim Übernehmen so vor:
- Seiten mit vielen Klicks oder externen Links behalten und inhaltlich verbessern, statt sie zu kürzen.
- Seitentitel und Meta-Beschreibungen übernehmen oder gezielt verbessern.
- Überschriften-Struktur und wichtige Begriffe der erfolgreichen Seiten beibehalten.
- Bilder mit Alternativtexten übernehmen.
- Strukturierte Daten auf der neuen Website wieder einbauen.
- Schwache oder doppelte Seiten zusammenlegen und per 301 auf die neue Seite weiterleiten.
Zeitplan für einen Relaunch
| Zeitpunkt | Aufgaben |
|---|---|
| Vor der Umsetzung | Bestandsaufnahme, Daten exportieren, URL-Plan erstellen |
| Während der Umsetzung | Testumgebung schützen, Inhalte übernehmen, Weiterleitungen vorbereiten |
| Kurz vor dem Launch | Weiterleitungen testen, Launch-Checkliste durchgehen |
| Launch-Tag | Sperren entfernen, Weiterleitungen aktivieren, Sitemap einreichen |
| Erste Wochen | Search Console wöchentlich prüfen, Fehler sofort beheben |
| Erstes Jahr | monatlich kontrollieren, Weiterleitungen bestehen lassen |
Kleinere Websites sind bei uns meist nach 2 bis 4 Wochen online, umfangreiche Projekte dauern bis zu 3 Monate.
Fazit
Ein Relaunch ist eine Chance, Design, Struktur und Technik zu verbessern. Ranking-Verluste lassen sich mit einer sauberen Bestandsaufnahme, vollständigen 301-Weiterleitungen, einer geschützten Testumgebung und konsequenter Kontrolle nach dem Launch vermeiden. Planen Sie diese Schritte von Anfang an ein, nicht erst kurz vor dem Go-live.
Quellen
- Google: Website-Umzug mit URL-Änderungen
- Google: Website-Umzug ohne URL-Änderungen
- Google: Weiterleitungen und Google Suche
- Google: Tool zur Adressänderung
- Google: Einführung in robots.txt
- Google: Indexierung mit noindex blockieren
- Google: Bericht zur Seitenindexierung
- Google: Core Web Vitals in der Search Console
