SEO beim Website Relaunch schützen: So erneuern Sie Ihre Website ohne Traffic Verlust

Wie schützen Sie SEO beim Website Relaunch?
SEO beim Website Relaunch schützen Sie mit einem Verfahren in fünf Phasen: Zunächst frieren Sie Inventar und Messwerte ein, danach bauen Sie eine URL und Inhaltskarte, dann prüfen Sie die Technik auf der Staging Umgebung, anschließend arbeiten Sie am Tag des Livegangs ein festes Protokoll ab, und schließlich beobachten Sie die Website 90 Tage lang.
Mein Leitsatz seit 2012 lautet: Ein Website Relaunch ist keine Designaufgabe, sondern ein Umzug. Wer umzieht, nimmt sein Adressbuch mit, sonst findet ihn niemand mehr. Das Adressbuch Ihrer Website ist die Liste aller URLs, die Google kennt, verlinkt und in den Suchergebnissen zeigt.
Ich arbeite von Istanbul aus ohne Zwischenhändler und betreue auch Kunden in Deutschland, Österreich und der Schweiz. Deshalb plane ich in meinen Webdesign Projekten die Erneuerung grundsätzlich zusammen mit SEO, nicht danach. In diesem Ratgeber zeige ich Ihnen daher Schritt für Schritt, wie Sie Design, Technik und Sichtbarkeit gleichzeitig erneuern.
Warum verliert eine Website beim Relaunch organischen Traffic?
Organischer Traffic bricht nach einem Relaunch fast immer aus denselben fünf Gründen ein. Keiner davon hat allerdings etwas mit dem Design zu tun. Stattdessen geht es um Adressen, Inhalte, Verknüpfungen, Geschwindigkeit und Sichtbarkeit für den Crawler.
- URL Änderungen ohne Weiterleitung: Alte Adressen liefern dann 404, Rankings und Backlinks laufen ins Leere.
- Gelöschte Inhalte: Seiten mit wenig Design, aber viel Suchverkehr verschwinden zum Beispiel im Aufräumeifer.
- Verlorene interne Verlinkung: Ein schlankes Menü macht tiefe Seiten zu Waisen ohne Einstieg.
- Langsameres Theme: Zudem verschlechtern schwere Skripte und Bilder die Core Web Vitals.
- Staging Leck oder vergessenes noindex: Google indexiert die Testumgebung oder ignoriert die neue Website.
Laut Google kann es bei einer mittelgroßen Website mehrere Wochen oder länger dauern, bis die Suche neue URLs statt der alten zeigt. Diese Übergangszeit nach dem Website Relaunch ist also normal. Allerdings bleibt der Verlust dauerhaft, wenn eine der fünf Ursachen ungelöst ist. Deshalb behandle ich jede Ursache in diesem Ratgeber mit einer eigenen Prüfung.
Ein Hinweis zur Ehrlichkeit: Zahlen wie "90 Prozent aller Relaunches schaden dem SEO" stammen aus Agenturwerbung und lassen sich nicht belegen. Ich nenne Ihnen stattdessen Erfahrungswerte aus meiner Praxis, klar als Ausgangsbereich und nicht als Garantie markiert.
Welche Daten sichern Sie vor dem Website Relaunch?
Vor dem Website Relaunch frieren Sie Ihre Messwerte ein. Denn nach dem Livegang brauchen Sie einen Vergleichsstand, sonst streiten Sie später über Gefühle statt über Zahlen. Diese Phase dauert bei mir meist zwei bis fünf Arbeitstage, je nach Größe der Website.
- Zunächst exportieren Sie in der Search Console die Leistungsdaten der letzten 16 Monate, getrennt nach Suchanfragen und Seiten.
- Danach ziehen Sie aus Google Analytics 4 die Liste aller Landingpages mit Sitzungen und Conversions.
- Außerdem notieren Sie alle Seiten mit externen Backlinks, denn diese Adressen sind Kapital.
- Speichern Sie eine Momentaufnahme der wichtigsten Rankings mit Datum.
- Crawlen Sie die gesamte Website mit einem Werkzeug wie Screaming Frog und archivieren Sie die Ausgabe.
- Kopieren Sie die alte sitemap.xml und die alte robots.txt Datei.
- Schließlich legen Sie ein vollständiges Backup von Dateien und Datenbank an.
Der Crawl aus Punkt fünf ist Ihr Adressbuch. Denn er enthält jede URL, jeden Title, jede Meta Description, jede H1 und jedes Canonical Tag der alten Website. Außerdem zeigt er Ihnen, welche Seiten intern auf welche verweisen. Ohne diese Datei können Sie später nicht beweisen, was verloren ging.
Zudem empfehle ich, diese Exporte mit Datum in einem Ordner abzulegen, den niemand anfasst. In der Praxis wird dieser Ordner drei Monate später zum wichtigsten Werkzeug der Fehlersuche.
Welche Seiten behalten, zusammenlegen oder löschen Sie?
Für jede Seite treffen Sie eine von drei Entscheidungen: behalten, zusammenlegen oder löschen. Als Grundlage dient eine Matrix aus drei Werten, nämlich Traffic, Backlinks und Conversions. Eine Seite mit einem hohen Wert in nur einer Spalte bleibt beim Website Relaunch also bereits unantastbar.
Ein Beispiel, ausdrücklich als Beispielrechnung gekennzeichnet: Eine Website hat 400 Seiten. Laut Search Console kommen 80 Prozent der Klicks aus 60 Seiten. Diese 60 Seiten bilden dann die Liste der unantastbaren Adressen. Für die restlichen 340 Seiten prüfen Sie Backlinks und Conversions.
- Behalten: Seiten mit Traffic, Backlinks oder Conversions bleiben unter gleicher oder weitergeleiteter URL bestehen.
- Zusammenlegen: Mehrere dünne Seiten zum selben Thema verschmelzen zu einer starken Seite mit 301 Weiterleitungen.
- Löschen: Seiten ohne Traffic, ohne Links und ohne Zweck erhalten einen 410 oder 404 Status.
In der Beispielrechnung entstehen aus 120 zusammengelegten Seiten 120 Zeilen in der Weiterleitungskarte. Somit wissen Sie schon vor der Gestaltung, wie viele Weiterleitungen Sie brauchen. Vor allem verhindert diese Reihenfolge, dass ein Designer eine Seite streicht, die Ihnen monatlich Anfragen bringt.
Löschen Sie außerdem nie aus optischen Gründen. Eine unscheinbare Seite über Lieferzeiten kann mehr Umsatz bringen als die neue Startseite. Daher entscheidet die Matrix, nicht der Geschmack.
Müssen Sie die URL Struktur beim Website Relaunch ändern?
Nein, in den meisten Fällen nicht. Die sicherste Variante beim Website Relaunch behält jede bestehende URL bei. Dann brauchen Sie keine Weiterleitungen, und Google bewertet die Seiten weiter wie bisher. Ein neues Design und alte Adressen vertragen sich also ausgezeichnet.
Allerdings gibt es gute Gründe für neue URLs. Dazu zählen zum Beispiel ein Wechsel des Content Management Systems, kryptische Parameter wie ?id=482 oder eine völlig neue Sprachstruktur. Wenn Sie ändern, dann ändern Sie mit Plan und nicht beiläufig.
- Behalten Sie die URL, wenn das System es erlaubt, auch wenn sie nicht perfekt ist.
- Ändern Sie die URL nur, wenn ein technischer oder struktureller Zwang besteht.
- Vermeiden Sie kosmetische Umbenennungen wie /leistungen/ zu /services/ ohne Mehrwert.
Google rät ausdrücklich dazu, nur eine Sache auf einmal zu ändern. Wer gleichzeitig Design, System und Domain wechselt, kann später nicht erkennen, welche Änderung den Verlust ausgelöst hat. Deshalb trenne ich in meinen Projekten den Systemwechsel vom Domainwechsel zeitlich, wenn beides ansteht.
Falls neue Adressen nötig sind, benennen Sie sie konsistent: Kleinbuchstaben, keine Umlaute, Wörter durch Bindestriche getrennt. Unser Slug Generator erzeugt aus einem Seitentitel sofort eine saubere Adresse. Somit vermeiden Sie Mischformen, die später eine zweite Weiterleitungsrunde erzwingen.
Wie erstellen Sie die 301 Weiterleitungskarte?
Die Weiterleitungskarte ist eine Tabelle mit einer Zeile pro alter URL. Sie entsteht aus dem Crawl der alten Website, nicht aus dem Gedächtnis, und sie ist das Herzstück jedes Website Relaunch Projekts. Jede Zeile enthält fünf Spalten: alte URL, neue URL, Statuscode, Priorität und Testergebnis.
- Alte URL: exakt so, wie Google sie kennt, inklusive Schrägstrich am Ende.
- Neue URL: die thematisch passendste Zielseite, also nicht pauschal die Startseite.
- Statuscode: fast immer 301, bei bewusst gelöschten Seiten dagegen 410.
- Priorität: hoch für Seiten mit Traffic oder Backlinks, niedrig für den Rest.
- Testergebnis: leer bis zum Test auf der Staging Umgebung.
Zwei Regeln sind dabei unverhandelbar. Erstens: keine Ketten. Wenn A schon auf B zeigt und B nun auf C zeigt, dann ändern Sie A direkt auf C. Zweitens: keine Schleifen. Der Googlebot folgt laut Google Dokumentation standardmäßig höchstens zehn Weiterleitungen, danach bricht er ab.
Zudem verlangt Google, dass Weiterleitungen nach einem Umzug so lange wie möglich bestehen bleiben, in der Regel mindestens ein Jahr. Bei Kunden mit alten Backlinks lasse ich sie dauerhaft aktiv, denn eine Weiterleitung kostet nichts, ein verlorener Link dagegen viel.
Prüfen Sie jede Zeile anschließend mit unserem Redirect Checker. Er zeigt Ihnen den vollständigen Pfad einer Weiterleitung inklusive Zwischenstationen und Statuscodes. Daher erkennen Sie Ketten sofort, bevor Google sie sieht.
301 oder 302: Welche Weiterleitung schützt das Ranking?
Die permanente Weiterleitung mit 301 oder 308 schützt das Ranking. Laut Google ist sie ein starkes Signal dafür, dass die Zielseite die kanonische Version ist. Eine temporäre Weiterleitung mit 302, 303 oder 307 sendet dieses Signal nicht. Für einen Website Relaunch ist sie deshalb die falsche Wahl.
Daneben gibt es Methoden, die Entwickler gern aus Bequemlichkeit einsetzen. Die folgende Tabelle zeigt, wie Google jede Methode liest und wo beim Relaunch das Risiko liegt.
| Methode | Bedeutung für Google | Wann sinnvoll | Risiko beim Relaunch |
|---|---|---|---|
| 301 / 308 | Permanent, Ziel gilt als kanonisch | Jede dauerhafte URL Änderung | Gering, wenn ohne Ketten |
| 302 / 307 | Temporär, Original bleibt kanonisch | Kurzfristige Aktionen, Wartung | Hoch, Ranking bleibt auf der alten URL |
| Meta Refresh 0 Sekunden | Gilt als permanent | Nur ohne Serverzugriff | Mittel, langsamer für Nutzer |
| Meta Refresh verzögert | Gilt als temporär | Praktisch nie | Hoch |
| JavaScript Redirect | Erst nach dem Rendern erkannt | Nur wenn serverseitig unmöglich | Mittel, Verzögerung durch Renderwarteschlange |
| noindex | Seite aus dem Index nehmen | Staging, interne Seiten | Hoch, wenn beim Livegang vergessen |
| robots.txt Disallow | Crawling verboten, Index möglich | Crawlbudget steuern | Hoch, blockiert auch das noindex |
| HTTP Authentifizierung | Kein Zugriff, nichts im Index | Staging Umgebung | Gering |
Kurz gesagt: Serverseitige 301 Weiterleitungen sind der Standard, alles andere ist ein Kompromiss. Konkret prüfe ich vor jedem Livegang in der Serverkonfiguration, ob das Framework nicht heimlich 302 ausgibt. Denn manche Systeme senden temporäre Codes als Voreinstellung.
Wann brauchen Sie das Tool zur Adressänderung in der Search Console?
Das Tool zur Adressänderung brauchen Sie nur, wenn sich die Domain oder die Subdomain ändert. Für einen Wechsel von HTTP auf HTTPS oder von www auf ohne www ist es laut Google Hilfe nicht nötig. Bei einem reinen Design Relaunch unter derselben Domain lassen Sie es also unberührt.
Falls die Domain wechselt, gelten drei Voraussetzungen. Sie müssen beide Properties in der Search Console besitzen, beide mit demselben Google Konto verwalten, und die 301 Weiterleitungen müssen vor der Meldung aktiv sein. Erst dann melden Sie den Umzug im Tool.
- Nötig: neue Domain, zum Beispiel von firma.de zu firma.com.
- Nötig: Wechsel zwischen Subdomains, etwa von shop.firma.de zu firma.de/shop/.
- Unnötig dagegen: Protokollwechsel auf HTTPS.
- Ebenso unnötig: Änderung einzelner Pfade unter gleicher Domain.
Das Tool überträgt die Signale 180 Tage lang an die neue Website. Google verlangt außerdem, dass die Weiterleitungen mindestens 180 Tage bestehen bleiben, und länger, solange noch Traffic aus der Google Suche über die alten Adressen kommt. In meiner Praxis heißt das: nie abschalten.
Ein Fehler, den ich mehrfach gesehen habe: Der Umzug wird gemeldet, bevor die Weiterleitungen funktionieren. Dann findet Google auf der alten Domain 404 Seiten, und folglich stockt die Übertragung. Daher gilt die Reihenfolge Weiterleitung, Test, Meldung.
Wie verstecken Sie die Staging Umgebung vor Google?
Die Staging Umgebung schützen Sie am sichersten mit HTTP Authentifizierung, also einem Passwortschutz auf Serverebene. Der Googlebot bekommt dann keinen Inhalt zu sehen, und nichts landet im Index. Ein noindex Tag ist dann die zweite Wahl. Die robots.txt Datei allein ist dagegen eine Falle.
Warum eine Falle? Laut Google muss der Crawler eine Seite abrufen können, um das noindex zu lesen. Blockiert die robots.txt den Abruf, dann sieht Google das noindex nie. Findet Google die URL über einen Link, kann sie trotzdem in den Ergebnissen erscheinen, nur ohne Beschreibung.
Der zweite Teil des Problems entsteht beim Livegang. Denn Entwickler kopieren die Staging Konfiguration häufig eins zu eins auf den Live Server. Dann trägt die neue Website ein noindex auf jeder Seite, und Google entfernt sie nach und nach aus dem Index.
- Ist das noindex auf allen Seiten der Live Website entfernt?
- Ist außerdem die robots.txt die Live Version und nicht die Staging Version mit Disallow: /?
- Zeigen die Canonical Tags auf die Live Domain und nicht auf staging.firma.de?
- Verweist zudem die sitemap.xml auf Live URLs?
- Steht in keinem Template noch eine Testdomain in absoluten Links?
Diese fünf Fragen beantworte ich vor jedem Livegang im Quelltext, nicht im Backend. Zudem erstelle ich die Live Datei mit unserem robots.txt Generator neu, statt die alte zu bearbeiten. So bleibt kein Rest der Sperre übrig.
Wie übernehmen Sie Title, Meta Description und H1 ins neue Design?
Title, Meta Description und H1 übernehmen Sie aus dem Crawl der alten Website, Seite für Seite. Bei einem Themewechsel gehen genau diese drei Felder am häufigsten verloren, weil das neue Template sie aus anderen Datenbankfeldern zieht oder pauschal aus dem Seitennamen erzeugt.
Ein typisches Bild nach einem unbedachten Relaunch: Jede Seite trägt den Title "Startseite | Firma", die Meta Description ist leer, und die H1 ist plötzlich das Logo. Google bewertet solche Seiten daher neu, und die Rankings für die eigentlichen Suchbegriffe rutschen ab.
- Exportieren Sie Title, Meta Description und H1 pro URL aus dem alten Crawl.
- Danach importieren Sie die Werte ins neue System oder pflegen Sie sie in das SEO Plugin ein.
- Prüfen Sie im Staging Crawl, ob jede Seite genau eine H1 und einen eigenen Title hat.
- Schließlich vergleichen Sie beide Crawls per Tabellenkalkulation, Zeile für Zeile.
Für neue Seiten ohne Vorlage hilft unser Meta Tag Generator, der Title und Description in der richtigen Länge ausgibt. Mit der Google SERP Vorschau sehen Sie außerdem, wie das Ergebnis auf dem Smartphone abgeschnitten wirkt.
Verbessern Sie die Texte ruhig, aber verändern Sie das Thema nicht. Ein Title, der seit Jahren für "Steuerberater Köln" rankt, sollte diesen Begriff auch nach dem Relaunch tragen. Daher gilt: erst übernehmen, dann in Ruhe optimieren.
Was passiert mit der internen Verlinkung, wenn das Menü schrumpft?
Ein schlankes Menü sieht modern aus, aber es kappt die Wege des Crawlers. Seiten, die vorher über die Navigation in einem Klick erreichbar waren, liegen danach vier Klicks tief oder gar nicht mehr verlinkt. Google findet solche verwaisten Seiten folglich seltener und bewertet sie schwächer.
Deshalb lege ich vor dem Relaunch eine interne Linkkarte an. Sie zeigt für jede wichtige Seite, wie viele interne Links auf sie zeigen und aus welchen Bereichen. Diese Zahl darf nach dem Relaunch nicht sinken. Sinkt sie, dann brauchen Sie Ersatz.
- Footer Bereiche mit Leistungen, Standorten oder Kategorien ersetzen verlorene Menüpunkte.
- Außerdem verbinden Kontextlinks im Fließtext verwandte Seiten thematisch.
- Verwandte Beiträge und Produkte am Seitenende halten tiefe Seiten erreichbar.
- Schließlich fängt eine HTML Sitemap Seite alles auf, was sonst nirgends verlinkt ist.
Prüfen Sie nach dem Staging Crawl den Bericht über Seiten ohne eingehende Links. Jede URL darin ist somit ein Kandidat für Rankingverlust. Zudem vergleichen Sie die Klicktiefe: Seiten mit Traffic sollten weiterhin in höchstens drei Klicks von der Startseite erreichbar sein.
Ein Beispiel aus meiner Erfahrung, ohne Kundennamen: Ein Menü schrumpfte von 30 auf 7 Einträge, und 40 Unterseiten verloren jeden internen Link. Der Traffic dieser Seiten sank in den Folgewochen spürbar, obwohl keine URL geändert wurde. Somit reicht ein Menü allein aus, um Verluste zu erzeugen.
Verschlechtert das neue Theme die Core Web Vitals?
Ein neues Theme kann die Core Web Vitals verbessern oder verschlechtern, deshalb messen Sie es vor dem Livegang. Die Schwellen laut Google: LCP innerhalb von 2,5 Sekunden, INP unter 200 Millisekunden, CLS unter 0,1. Google erklärt, dass diese Werte mit dem übereinstimmen, was die Rankingsysteme belohnen wollen.
Seit März 2024 ersetzt INP die frühere Metrik FID. INP misst die Verzögerung aller Klicks, Berührungen und Tastatureingaben über die gesamte Lebensdauer der Seite. Schwere JavaScript Themes mit vielen Animationen, Slidern und Trackingskripten verschlechtern genau diesen Wert.
- Zunächst messen Sie die alte Website mit Lighthouse und notieren Sie LCP, INP und CLS.
- Dann messen Sie die Staging Version mit denselben Seiten und demselben Gerät.
- Vergleichen Sie beide Werte, bevor Sie das Design freigeben.
- Schließlich prüfen Sie nach dem Livegang die Felddaten im Bericht Core Web Vitals der Search Console.
Lighthouse liefert Labordaten, die Search Console zeigt echte Nutzerdaten aus dem Chrome User Experience Report. Beide brauchen Sie also. Denn ein Theme kann im Labor glänzen und bei echten Nutzern auf älteren Smartphones einbrechen.
In der Praxis sind die üblichen Verdächtigen immer dieselben: unkomprimierte Hero Bilder, Webfonts ohne Vorladen, Slider im sichtbaren Bereich und ein Dutzend Plugins, die jeweils ihr eigenes Skript laden. Daher streiche ich vor dem Relaunch zuerst Funktionen, die niemand nutzt.
Ist ein JavaScript Framework beim Website Relaunch ein SEO Risiko?
Ein JavaScript Framework wie React, Vue oder ein Headless Aufbau ist beim Website Relaunch nur dann ein Risiko, wenn der Inhalt erst im Browser entsteht. Google verarbeitet JavaScript laut eigener Dokumentation in drei Schritten: Crawling, Renderwarteschlange, Indexierung.
Das Warten in der Renderwarteschlange kann wenige Sekunden dauern, aber auch deutlich länger. Bis dahin sieht Google also eine leere Seite. Deshalb bezeichnet Google serverseitiges Rendering und Prerendering weiterhin als gute Idee. Der Crawler erhält dann fertiges HTML, so wie bei einer klassischen Website.
- Serverseitiges Rendering: Der Server liefert fertiges HTML, das Framework übernimmt danach im Browser.
- Statische Generierung: Seiten entstehen beim Build als HTML Dateien, zum Beispiel für Blogs und Landingpages.
- Reines clientseitiges Rendering: Nur für Bereiche hinter Login, nie für Seiten, die ranken sollen.
Ein zweites Problem betrifft Statuscodes. Single Page Applications liefern oft bei jeder Adresse einen 200 Status, auch wenn die Seite nicht existiert. Google nennt das Soft 404 und behandelt die Seite folglich als Fehler. Verlangen Sie daher echte 404 und 401 Codes vom Server.
Ich bin nicht gegen Frameworks, sondern gegen ungeprüfte Frameworks. Konkret öffne ich vor der Freigabe den gerenderten Quelltext im Test der Search Console und prüfe, ob Titel, Text und Links im HTML stehen. Fehlen sie, ist das Framework noch nicht bereit für den Livegang.
Wann ist der richtige Zeitpunkt für den Website Relaunch?
Der richtige Zeitpunkt für den Website Relaunch liegt in Ihrer schwächsten Saison, an einem Wochentag am Vormittag und außerhalb laufender Werbekampagnen. Google selbst empfiehlt, einen Umzug in eine Zeit mit niedrigem Traffic zu legen. Dann kostet jeder Fehler weniger, und Sie haben Zeit für die Korrektur. Kurz gesagt: Der Website Relaunch gehört in die ruhige Zeit.
| Szenario | SEO Risiko | Pflichtschritte | Adressänderung nötig |
|---|---|---|---|
| Nur Design, gleiche URLs | Niedrig | Meta Felder, interne Links, Core Web Vitals | Nein |
| Design plus neue URLs | Mittel | Weiterleitungskarte, Test, Sitemap | Nein |
| Wechsel des CMS | Mittel bis hoch | Alles oben plus Statuscodes und Rendering | Nein |
| Wechsel der Domain | Hoch | Alles oben plus beide Properties | Ja |
Vermeiden Sie außerdem den Freitagnachmittag und die Tage vor Feiertagen. Falls am Abend die Weiterleitungen versagen, braucht Ihr Team Zugriff auf Entwickler und Hosting. Ein Dienstag um zehn Uhr hat sich bei mir als verlässlich erwiesen.
Ein weiterer Punkt betrifft bezahlte Werbung. Laufende Kampagnen aus der Google Ads Verwaltung senden Besucher auf feste Zielseiten. Ändern sich diese URLs ohne Anpassung, zahlen Sie für Klicks auf Weiterleitungen oder Fehlerseiten. Daher stimme ich den Kampagnenkalender vor jedem Relaunch mit dem Livegang ab.
Wie sieht die Checkliste für den Tag des Livegangs aus?
Am Tag des Livegangs arbeiten Sie eine feste Liste in fester Reihenfolge ab. Denn unter Zeitdruck vergisst jeder etwas, und ein vergessenes noindex kostet Wochen. Meine Liste umfasst zehn Punkte und beginnt bereits vor der Umschaltung.
- Senken Sie die DNS TTL 24 Stunden vorher auf wenige Minuten, damit der Wechsel schnell greift.
- Dann aktivieren Sie die Weiterleitungen unmittelbar mit der Umschaltung, nicht Stunden später.
- Prüfen Sie eine Stichprobe von 20 wichtigen alten URLs mit dem Redirect Checker.
- Außerdem öffnen Sie die robots.txt im Browser und lesen Sie jede Zeile.
- Kontrollieren Sie im Quelltext der Startseite, dass kein noindex und kein Staging Canonical steht.
- Danach erstellen Sie die neue Sitemap und reichen Sie sie in der Search Console ein.
- Beobachten Sie das Serverprotokoll in der ersten Stunde auf 5xx Fehler.
- Zudem testen Sie Formulare, Warenkorb und Tracking auf der Live Website.
- Prüfen Sie die mobile Ansicht auf einem echten Smartphone.
- Schließlich halten Sie den alten Server 48 Stunden bereit für einen Rückwechsel.
Punkt sieben ist wichtiger, als er aussieht. Laut Google verlangsamen 5xx Fehler das Crawling vorübergehend, und die Geschwindigkeit steigt erst wieder schrittweise, sobald der Server wieder 2xx antwortet. Ein überlasteter Server am Tag des Livegangs kostet Sie also Crawlbudget in den entscheidenden Tagen.
Die Sitemap aus Punkt sechs erzeugen Sie mit unserem XML Sitemap Generator oder direkt aus dem CMS. Sie darf nur Live URLs mit Status 200 enthalten, keine weitergeleiteten und keine gelöschten Adressen.
Was beobachten Sie nach dem Livegang in der Search Console?
Nach dem Livegang beobachten Sie zwei Wochen lang täglich drei Berichte in der Search Console: Seitenindexierung, Crawling Statistiken und Leistung. Danach reicht ein wöchentlicher Blick bis zum 90. Tag. Diese Phase entscheidet, ob Ihr Website Relaunch als Umzug oder als Verlust endet.
- Seitenindexierung: Steigt die Zahl der Seiten mit 404 oder Soft 404, fehlt eine Weiterleitung.
- Crawling Statistiken: Ein Einbruch der Anfragen deutet auf Serverfehler oder eine Sperre hin.
- Leistung: Außerdem vergleichen Sie Klicks und Impressionen mit dem eingefrorenen Export von vor dem Relaunch.
Das URL Prüftool ist dabei Ihr Mikroskop. Laut Google Hilfe zeigt es den Indexstatus einer URL, das Datum des letzten Crawls und welchen Googlebot Google verwendet hat. Mit dem Live Test prüfen Sie außerdem, ob eine Weiterleitung aus Sicht von Google korrekt funktioniert.
Erwarten Sie keinen sofortigen Wechsel. Google nennt mehrere Wochen oder mehr, bis alte URLs aus den Ergebnissen verschwinden. In dieser Zeit sehen Sie beide Adressen nebeneinander. Das ist also kein Fehler, sondern der normale Übergang.
Wenn Sie diese Berichte nicht selbst lesen möchten, übernehme ich das im Rahmen einer SEO Beratung mit wöchentlichen Zusammenfassungen. Vor allem in den ersten 14 Tagen zählt, dass jemand jeden Morgen hinschaut.
Der Traffic fällt: Was tun Sie in den ersten 72 Stunden?
Fällt der Traffic nach dem Relaunch, arbeiten Sie eine Diagnose in fünf Schritten in fester Reihenfolge ab. Die Reihenfolge folgt der Häufigkeit der Ursachen aus meiner Praxis. Springen Sie nicht zum fünften Schritt, bevor die ersten vier sauber sind.
- 404 Bericht: Exportieren Sie alle Fehlerseiten aus der Search Console und ergänzen Sie fehlende Weiterleitungen.
- Weiterleitungstest: Danach prüfen Sie die 50 wichtigsten alten URLs auf Statuscode, Ketten und Zielseite.
- noindex und robots.txt: Suchen Sie im Quelltext nach noindex und lesen Sie die robots.txt erneut.
- Canonical: Außerdem kontrollieren Sie, ob die Canonical Tags auf die Live URLs zeigen.
- Geschwindigkeit: Schließlich vergleichen Sie die Core Web Vitals mit den Werten vor dem Relaunch.
Eine Beispielrechnung für die Priorisierung: Von 200 geprüften URLs liefern 15 einen 404 Status. Diese 15 Seiten trugen laut altem Export 22 Prozent aller Klicks. Dann reparieren Sie zuerst die Seiten mit den meisten Klicks, nicht alphabetisch. Zwei Weiterleitungen können so die Hälfte des Verlusts beheben.
Halten Sie zudem die Nerven bei kleinen Schwankungen. Ein Rückgang von zehn Prozent in der ersten Woche liegt in meiner Erfahrung im normalen Übergangsbereich, als Ausgangswert und nicht als Garantie. Ein Rückgang von 50 Prozent dagegen ist dann fast immer ein technischer Fehler aus den Schritten eins bis drei.
Wie schützen Sie Hreflang und Shop URLs beim Website Relaunch?
Mehrsprachige Websites und Onlineshops brauchen beim Website Relaunch zwei zusätzliche Prüfungen. Bei Sprachversionen geht es um die Hreflang Zuordnung, bei Shops um Produkt, Kategorie und Filter URLs. Beide Bereiche erzeugen viele Adressen, und viele Adressen bedeuten viele Möglichkeiten für Fehler.
Meine eigene Website läuft dreisprachig mit Türkisch, Englisch und Deutsch. Beim letzten Umbau habe ich gelernt: Ändert sich eine Sprachversion, ändern sich auch alle Hreflang Verweise der Schwesterseiten. Deshalb erzeuge ich die Zuordnung nach dem Relaunch neu mit unserem Hreflang Generator, statt alte Zeilen zu flicken.
- Jede Sprachversion nennt alle Geschwister und sich selbst mit der neuen URL.
- Außerdem verwenden Canonical und Hreflang exakt dieselbe Schreibweise der Adresse.
- Weitergeleitete URLs stehen in keinem Hreflang Tag mehr.
Bei Shops liegt die Gefahr in Filtern und Parametern. Alte Kategorieseiten mit ?farbe=rot ranken oft unbemerkt, und das neue System erzeugt Filter mit anderer Syntax. Zudem verschwinden ausverkaufte Produkte gern komplett, obwohl sie Backlinks und Suchverkehr tragen.
- Leiten Sie ausverkaufte Produkte auf die Kategorie oder den Nachfolger weiter.
- Vor allem behalten Sie Kategorie URLs unverändert, denn sie tragen den meisten Umsatz.
- Zudem setzen Sie Filterseiten ohne Suchvolumen auf noindex, nicht auf Disallow.
In der E-Commerce Beratung beginne ich daher mit dem Umsatz pro URL, nicht mit dem Design. Eine Kategorie, die 30 Prozent des Umsatzes bringt, bekommt beim Relaunch dieselbe Aufmerksamkeit wie die Startseite.
Wann gilt Ihr Website Relaunch als erfolgreich?
Ihr Website Relaunch gilt als erfolgreich, wenn am 90. Tag Suchanfragen, Klicks und Conversions das Niveau vor dem Umbau erreichen oder übertreffen. Die Vergleichsbasis ist der eingefrorene Export aus der ersten Phase. Ohne diese Basis gibt es also kein Urteil, nur Gefühle.
| Phase | Dauer (Ausgangsbereich) | Ergebnis | Verantwortlich |
|---|---|---|---|
| Inventar und Messung | 2 bis 5 Tage | Exporte, Crawl, Backup | SEO |
| URL und Inhaltskarte | 3 bis 10 Tage | Entscheidungsmatrix, Weiterleitungskarte | SEO und Inhaber |
| Technik auf Staging | 1 bis 3 Wochen | Getestete Weiterleitungen, Meta Felder, Vitals | Entwicklung und SEO |
| Tag des Livegangs | 1 Tag | Abgearbeitete Checkliste | Alle |
| Beobachtung | 90 Tage | Wöchentlicher Vergleich, Korrekturen | SEO |
Ob Sie das selbst machen oder abgeben, hängt von der Größe ab. Eine Website mit 30 Seiten und gleichen URLs schaffen Sie mit dieser Anleitung allein. Ein Shop mit 5.000 Adressen oder ein Domainwechsel braucht dagegen beim Website Relaunch jemanden, der das schon oft gemacht hat und die Verantwortung für die Karte trägt.
Falls Sie eine Erneuerung planen, finden Sie auf der Seite Website erstellen lassen Kosten transparente Preise für Design und SEO aus einer Hand. Oder schreiben Sie mir direkt über das Kontaktformular mit der Adresse Ihrer aktuellen Website. Dann sage ich Ihnen ehrlich, ob Sie neue URLs brauchen oder nicht.




