Ein Relaunch ist eines der kritischsten Routineereignisse im Leben einer Website. Nicht, weil etwas kaputtgeht, das man sieht - sondern weil etwas kaputtgeht, das man nicht sieht. Die neue Seite ist schneller, schöner, moderner. Und drei Wochen später sind die Anfragen weg, die Rankings abgerutscht, der Traffic halbiert. Niemand versteht warum, denn alles sieht ja besser aus.
Das ist kein Pech und kein Einzelfall. Es ist ein Muster mit einer klaren Ursache: Rankings leben nicht im Design. Sie leben in URLs, in der Struktur, in Inhalten und in technischen Signalen - und genau die verändert ein Relaunch, oft ohne dass es jemand merkt.
Dieser Artikel zeigt, warum das passiert, welche fünf stillen Risiken dahinterstecken und in welcher Reihenfolge ein Relaunch ablaufen muss, damit die Sichtbarkeit den Umzug übersteht. Am Ende steht ein realer Fall, in dem wir genau diese Aufräumarbeit übernehmen mussten - und ein Selbstcheck, bevor Sie den Launch-Button drücken.
Warum ein schöneres Design allein nichts rettet
Google bewertet kein Design nach Geschmack. Aber Google bewertet die Signale, die ein Relaunch oft verändert: URLs, Inhalte, interne Links, Ladezeit, Indexierbarkeit und technische Struktur. Eine Seite, die seit zwei Jahren auf Platz 3 für „Elektriker München” steht, hat sich dieses Ranking über Signale erarbeitet, die an dieser einen URL hängen.
Ein Relaunch fasst fast alle diese Signale gleichzeitig an: Die URL ändert sich. Die Seitenstruktur ändert sich. Texte werden neu geschrieben, Überschriften umgestellt, interne Links neu verlegt. Jede dieser Änderungen ist für sich genommen ein Eingriff in einen Rankingfaktor. Alle zusammen, an einem Tag, sind ein abrupter Eingriff in viele Signale auf einmal.
Google selbst sagt klar: Bei einem Umzug mit URL-Änderungen sind vorübergehende Ranking-Schwankungen normal, und ein mittelgroßer Umzug braucht einige Wochen, bis die meisten Seiten neu indexiert sind. Die entscheidende Frage ist deshalb nicht, ob es schwankt - sondern ob Sie vorübergehend verlieren oder dauerhaft. Der Unterschied zwischen beidem ist Vorbereitung.
Der Fehler, der die meisten Seiten auf einmal trifft: Redirects
Wenn ein Relaunch Rankings kostet, sind fehlende oder falsche Weiterleitungen die Ursache, die auf einen Schlag die meisten Seiten trifft.
Die Mechanik ist einfach - und sie verzeiht keine Lücken. Die alte URL rankt und hat Backlinks. Beim Relaunch bekommt die Seite eine neue Adresse, die alte wird gelöscht. Wer jetzt keine Weiterleitung von alt nach neu einrichtet, kappt die Verbindung: Die alte URL liefert einen 404-Fehler, das Ranking verfällt, und jeder externe Link, der je auf die alte Adresse zeigte, läuft ins Leere. Die Autorität, die Sie über Jahre aufgebaut haben, geht verloren.
Eine saubere Redirect-Strategie folgt vier Regeln:
- 1:1-Mapping. Jede alte URL wird auf ihr inhaltlich passendstes neues Gegenstück geleitet - nicht pauschal alles auf die Startseite. Google behandelt eine Massenweiterleitung auf die Homepage faktisch wie einen Soft-404; der Wert der alten Seiten geht verloren.
- 301, nicht 302. Eine 301 ist eine dauerhafte Weiterleitung und überträgt die Signale der alten Seite. Eine 302 signalisiert „nur vorübergehend” - ein häufiger, teurer Konfigurationsfehler.
- Keine Ketten. Alt → neu in einem Schritt. Google folgt zwar mehreren Weiterleitungen hintereinander, aber jede Stufe kostet Crawl-Zeit und ist eine Stelle mehr, die beim nächsten Umbau bricht. Bestehende Ketten beim Relaunch auf das Endziel verkürzen.
- Lange genug halten. Google empfiehlt, Weiterleitungen so lange wie möglich zu behalten - bei einem Site-Move in der Regel mindestens ein Jahr, und länger, solange noch relevante Zugriffe oder Backlinks darüber laufen.
Was zu tun ist: Die Redirect-Map entsteht vor dem Launch, nicht danach. Jede bestehende URL wird inventarisiert und einem Ziel zugeordnet, bevor die alte Seite verschwindet.
Vorlage: die Redirect-Map als Tabelle
Eine Tabelle mit diesen Spalten reicht, als CSV oder Tabellenblatt. Jede Zeile ist eine alte Adresse:
| Spalte | Inhalt | Woher |
|---|---|---|
alte_url | Vollständige alte Adresse | Crawl der alten Seite, alte Sitemap, Search Console (Leistung, Seiten) |
klicks_16m | Klicks der letzten 16 Monate | Search Console, Leistung, nach Seite |
externe_links | Ja oder nein | Search Console, Links, häufigste verlinkte Seiten |
neue_url | Inhaltlich passendstes neues Ziel, nie pauschal die Startseite | Neue Seitenstruktur |
typ | 301, oder 410 für Seiten, die bewusst ersatzlos wegfallen | Entscheidung |
geprueft | Datum der Prüfung nach dem Launch | Abnahme, siehe unten |
Sortieren Sie nach Klicks. Die Zeilen oben tragen die meisten Besuche und verdienen eine Prüfung von Hand, ob das neue Ziel die alte Suchfrage wirklich beantwortet. Die Search Console zeigt Leistungsdaten der letzten 16 Monate, deshalb die Spalte klicks_16m.
Eine Redirect-Map, die erst nach dem Launch gebaut wird, ist keine Vorsorge mehr. Sie ist Schadensbegrenzung - und manches lässt sich dann nicht mehr begrenzen.
Die fünf stillen Risiken
Redirects sind die häufigste Ursache, aber nicht die einzige. Diese fünf Fehler richten den Schaden an, den niemand beim Launch bemerkt - weil die Seite funktioniert und gut aussieht.
- Versehentliches
noindexoder eine übernommene Sperre. Während der Entwicklung wird die Staging-Seite von Google ferngehalten: per Passwort (niemand kommt hinein), pernoindex(Google darf abrufen, aber nicht indexieren) oder perrobots.txt(Google darf nicht abrufen, kann die Adresse aber trotzdem ohne Inhalt in den Index aufnehmen). Geht eine dieser Sperren mit auf die Live-Seite, darf Google die neuen Seiten nicht indexieren (noindex) oder nicht einmal abrufen (robots.txt). Der klassische Relaunch-Fehler, weil er von außen unsichtbar ist. - Entfernter oder gekürzter Content. Seiten oder Texte, die gut rankten, werden im Zuge des Relaunches gekürzt, zusammengelegt oder „aufgeräumt”. Damit verschwindet genau der Inhalt, für den Google die Seite als relevant einstufte. Schöner heißt nicht automatisch sichtbarer.
- Kollabierte interne Verlinkung. Eine neue Navigation vergräbt vorher gut erreichbare Seiten drei Klicks tief. Interne Links steuern, wie Autorität durch die Seite fließt - bricht diese Struktur, sinken auch Seiten, an denen technisch nichts geändert wurde.
- Eingebrochene Performance. Das neue Design bringt schwerere Bilder, ein größeres Framework, mehr Skripte. Die Ladezeit steigt, die Core Web Vitals verschlechtern sich - und damit ein Signal, das zur gesamten Page Experience beiträgt.
- Verlorene Mess-Signale. Analytics-Tag vergessen, Search Console nicht migriert, strukturierte Daten beim Redesign weggefallen. Das Tückische daran: Sie verlieren nicht nur Signale - Sie verlieren die Fähigkeit, den Schaden überhaupt zu sehen.
Was zu tun ist: Jeder dieser Punkte gehört auf eine Launch-Checkliste, die vor dem Go-Live abgehakt wird - nicht in die Fehlersuche danach.
Der Ablauf, der Rankings schützt
Ein Relaunch ohne Rankingverlust ist keine Glückssache, sondern eine Reihenfolge. Diese hier hat sich bewährt:
1. Vorher messen: Inventar und Baseline
Sie können nicht schützen, was Sie nicht gemessen haben. Bevor irgendetwas umgebaut wird, entsteht ein vollständiges Inventar: alle bestehenden URLs, ihre aktuellen Rankings, die Top-Seiten nach Traffic, die wichtigsten Backlinks. Das ist der Bauplan für alles Weitere - und die einzige Referenz, an der sich später ehrlich messen lässt, ob der Umzug gelungen ist.
2. Redirect-Map erstellen - vor dem Launch
Jede alte URL bekommt ihr 1:1-Ziel zugewiesen, als 301. Diese Map ist das Rückgrat des gesamten Umzugs und entsteht, während die alte Seite noch existiert.
3. Struktur und rankenden Content bewahren
Was rankt, bleibt - in Substanz, nicht zwingend im Layout. Gut performende Inhalte werden übernommen und gestärkt, nicht im Namen der Frische gekürzt. Überschriften, die Relevanz tragen, bleiben erhalten.
4. Launch geordnet ausführen
Bei kleinen und mittleren Websites ist ein Umzug in einem Zug meist sinnvoll - das hilft den Algorithmen, den Umzug schneller zu erkennen. Große Websites können abschnittsweise migriert werden, wenn Monitoring und Fehlerbehebung dadurch besser kontrollierbar bleiben. In beiden Fällen gilt beim Go-Live: die Staging-Sperre entfernen und die neue Sitemap in der Search Console einreichen. Bei einem Domain- oder Subdomain-Umzug zusätzlich das Change-of-Address-Tool der Search Console nutzen; bei reinen URL-Änderungen innerhalb derselben Domain genügen saubere Redirects und eine aktualisierte Sitemap.
5. Abnahme am Launch-Tag
Diese Prüfungen laufen in der ersten Stunde nach dem Umschalten. Jede hat ein klares Bestanden-Kriterium:
| Prüfung | Bestanden, wenn |
|---|---|
| Alle alten Adressen aus der Redirect-Map abrufen, zum Beispiel mit Screaming Frog im Listenmodus | Jede antwortet mit dem geplanten Status: 301 in einem Schritt auf ein Ziel mit 200, 410 wo so vorgesehen, 200 wo die Adresse gleich bleibt |
Robots-Meta, X-Robots-Tag und robots.txt der Live-Seite | Kein noindex auf Seiten, die ranken sollen; die robots.txt sperrt keine Inhaltsverzeichnisse |
| Canonical-Tags | Zeigen auf die Live-Domain, nicht auf die Staging-Adresse |
| Neue Sitemap | Enthält nur Adressen mit Status 200 und ist in der Search Console eingereicht |
| Live-Test der URL-Prüfung in der Search Console für die fünf wichtigsten Seiten | Seite ist abrufbar und indexierbar |
| Formular und Telefonlink auf dem Handy | Testanfrage kommt an |
6. Nachher überwachen
In den Wochen nach dem Launch: Seitenindexierung in der Search Console beobachten, in der URL-Prüfung das von Google gewählte Canonical der wichtigsten Seiten kontrollieren, auf 404-Fehler und kaputte Weiterleitungen prüfen, Klicks und Impressionen je Seite gegen die Baseline halten. Vergleichen Sie gleich lange Zeiträume und rechnen Sie mit zwei bis drei Tagen Verzögerung in den Daten. Schwankungen sind normal, aber Einbrüche, die nach einigen Wochen nicht zurückkommen, sind ein Signal zum Eingreifen.
Projektplan für den Relaunch: acht bis zwölf Wochen in fünf Phasen
So planen wir einen Relaunch. Die Phasen und Wochen sind dieselben wie bei jedem Website-Projekt, die SEO-Aufgaben laufen in jeder Phase mit, nicht erst am Ende. Die Tabelle eignet sich als Vorlage für Ihren eigenen Projektplan, auch wenn eine andere Agentur baut.
| Phase | Wochen | SEO-Aufgabe in dieser Phase | Ergebnis |
|---|---|---|---|
| Struktur und Suchintention | 1 bis 2 | Vollcrawl der alten Seite, Search-Console-Baseline, URL-Inventar | Neue Sitemap und erster Entwurf der Redirect-Map |
| Design | 3 bis 5 | Prüfen, dass jeder rankende Seitentyp im neuen Design einen Platz hat | Seitentypen ohne verlorene Inhalte |
| Texte | 5 bis 7 | Rankende Inhalte übernehmen und ausbauen, Metadaten und strukturierte Daten | Alle Texte mit dokumentierten Kürzungen |
| Entwicklung | 7 bis 10 | Staging hinter Passwort und noindex, Weiterleitungen umsetzen und testen | Fertige Seite auf Staging, Redirect-Map geprüft |
| Launch und Übergabe | 10 bis 12 | Abnahme am Launch-Tag (siehe oben), Sitemap einreichen | Live-Seite und Redirect-Protokoll |
| Monitoring | 30 Tage nach Launch | Seitenindexierung, 404-Fehler, Klicks je Seite gegen die Baseline | Bericht mit Abweichungen und Maßnahmen |
Planen Sie die Redirect-Map nicht erst für die Launch-Woche. Dann fehlt die Zeit, sie gegen den Crawl zu prüfen. Der erste Entwurf gehört in Woche 1 bis 2.
Was der Fall Rucker Elektro über das Aufräumen lehrt
Manchmal kommen wir nicht für den Relaunch, sondern für die Aufräumarbeit danach. So war es bei Rucker Elektro, einem Münchner Elektrobetrieb, dessen Website wir von einer Vorgängeragentur übernommen und am 25.07.2026 neu gelauncht haben. Bei der Übernahme zeigten sich zwei Problemfelder: technische Datenschutzrisiken und ein Setup, das wichtige SEO-Signale nicht sauber erhalten hatte.
Das deutlichste Beispiel: eine Seite zur Zählerschrank-Modernisierung, die zuvor auf einer Spitzenposition für München-Suchanfragen stand. Durch das fehlerhafte Setup und fehlende Weiterleitungen rutschte sie immer weiter ab - bis sie schließlich ganz aus dem Index fiel. Wir haben die Redirect-Map nachgezogen und gerettet, was rettbar war. Aber genau hier liegt die unbequeme Lehre: Nicht alles war rettbar. Eine Seite, die erst aus dem Index gefallen ist, kehrt nicht auf Knopfdruck und nicht garantiert vollständig zurück.
Was sich reparieren ließ, haben wir repariert. Google Search Console, 28 Tage vor dem Go-Live (27.06. bis 24.07.2026) gegen den 04.08. bis 31.08.2026:
- Klicks: +119 %.
- Impressionen: +26 %.
- Suchanfragen in den Top 10: +63 % (von der API gelieferte Zeilen, eine Untergrenze).
Die durchschnittliche Position blieb dabei nahezu gleich (9,55 zu 9,84); eine mögliche Erklärung sind die vielen neu hinzugekommenen Suchanfragen, die den Durchschnitt mitbestimmen. Die Entwicklung im Detail steht auf der Referenzen-Seite. Welche Seitentypen die Klicks tragen, und dass die Leistungsseiten bisher kaum mitgewachsen sind, zeigt die Aufschlüsselung auf der Seite SEO für Handwerker.
Diese Zahlen sind kein Argument dafür, wie gut Recovery funktioniert. Sie sind ein Argument dafür, dass Recovery teurer, langsamer und unvollständiger ist als Prävention. Ein sauber vorbereiteter Relaunch hätte die Zählerschrank-Seite nie verloren. Das Aufräumen konnte sie nicht zurückholen.
Ist der Relaunch schon passiert und die Rankings sind weg, hilft der Artikel Rankings nach Relaunch verloren mit fünf Prüfschritten weiter.
Selbstcheck vor dem Launch
Bevor die neue Seite live geht - können Sie diese fünf Fragen mit Ja beantworten?
- Gibt es eine vollständige Liste aller alten URLs mit ihren aktuellen Rankings?
- Existiert eine 1:1-Redirect-Map (301), bevor die alte Seite verschwindet?
- Ist sichergestellt, dass die
noindex-Sperre der Staging-Umgebung beim Go-Live entfernt wird? - Bleiben die Inhalte erhalten, die heute ranken - in Substanz, nicht nur im Look?
- Sind Analytics und Search Console für den ersten Tag nach dem Launch eingerichtet?
Wenn auch nur eine Antwort Nein lautet, ist das die Baustelle - nicht das Design.
Was Sie jetzt tun sollten
Ein Relaunch ist kein Grund, Rankings zu opfern - aber er bestraft jeden, der ihn als reines Designprojekt behandelt. Wenn Ihr Relaunch bevorsteht, prüfen wir vor dem Go-Live die kritischen SEO-Risiken: URLs, Redirects, Indexierung, interne Links, rankende Inhalte, Sitemap, Tracking und Search Console. Ziel ist kein schönerer Launch. Ziel ist ein Relaunch, der Sichtbarkeit schützt.
Das ist der Kern unserer Website-Relaunch-Leistung; wie sich der Umzug in eine laufende SEO-Strategie einfügt, klären wir im selben Schritt.
Häufige Fragen
Wie lange dauert es, bis die Rankings nach einem Relaunch zurückkommen?
Bei einem mittelgroßen Umzug braucht Google laut eigener Dokumentation einige Wochen, bis die meisten Seiten neu indexiert sind; größere Seiten länger. Mit sauberen 301-Weiterleitungen bleiben die Signale der alten Seiten erhalten, und die Schwankung ist vorübergehend. Ohne Weiterleitungen kann der Verlust dauerhaft sein.
Reicht es, alle alten Seiten auf die Startseite umzuleiten?
Nein. Google behandelt eine pauschale Weiterleitung vieler URLs auf die Startseite faktisch wie einen Fehler (Soft-404), und der Ranking-Wert der alten Seiten geht verloren. Jede alte URL braucht ihr inhaltlich passendes 1:1-Ziel.
301 oder 302 - spielt das wirklich eine Rolle?
Ja, und der Unterschied ist teuer. Eine 301 ist eine dauerhafte Weiterleitung und setzt für Google das klare Signal, dass die neue URL die kanonische Zielseite sein soll. Eine 302 signalisiert einen temporären Zustand und ist für dauerhafte Relaunch-Weiterleitungen die falsche Wahl.
Wir haben schon relauncht und Traffic verloren - ist es zu spät?
Oft nicht. Wenn die Redirects schnell nachgezogen werden, kehrt ein Großteil der Sichtbarkeit zurück. Seiten, die bereits ganz aus dem Index gefallen sind, kommen nicht garantiert vollständig zurück. Je früher die Aufräumarbeit beginnt, desto mehr lässt sich retten.
Schlussgedanke
Ein Relaunch ist ein Versprechen an die nächsten Jahre - und ein Risiko für alles, was Sie sich bisher erarbeitet haben. Behandeln Sie die unsichtbaren Signale mit derselben Ernsthaftigkeit wie das sichtbare Design, und der Umzug wird zum Wachstumsschritt statt zum Rückschlag. Behandeln Sie sie nicht, zahlen Sie den Preis dort, wo ihn niemand kommen sieht: in den Anfragen, die ausbleiben.
Quellen:
- Google Search Central - Site moves with URL changes: permanente Weiterleitungen, Umzug bei kleinen/mittleren Seiten in einem Zug, Sitemap einreichen, Weiterleitungen so lange wie möglich (i.d.R. mind. ein Jahr) halten, vorübergehende Schwankungen normal
- Google Search Central - Redirects and Google Search: permanente Weiterleitungen als Kanonisierungs-Signal; 302 für dauerhafte Umzüge ungeeignet
- Google Search Console - Change of Address Tool: Adresswechsel bei Domain- oder Subdomain-Umzug korrekt anmelden
- Praxisdaten Rucker Elektro: Google Search Console, 27.06. bis 24.07.2026 gegen 04.08. bis 31.08.2026 (Stand 31.08.2026)