URL-Architektur · 8 Min. Lesezeit

Website-Relaunch ohne Sichtbarkeitsverlust

Der neue Look ist fertig, die Rankings sind weg. Das ist der teuerste Fehler, den ein Relaunch produziert, und zugleich der am leichtesten vermeidbare. Sichtbarkeit übersteht einen Umbau nur, wenn Sie sie von Anfang an einplanen, statt sie hinterher zu reparieren.

Viele halten eine Migrationsdelle für ein Naturgesetz, aber die Daten zeigen etwas Härteres: Von 892 ausgewerteten Migrationen erholten sich 17 % auch nach 1.000 Tagen nicht mehr (Search Engine Journal, 2024). Schuld ist fast nie der Go-Live-Tag selbst. Es sind die Wochen davor, eine Vorbereitung, die jemand übersprungen hat, weil sie niemand auf dem Schirm hatte. Der Launch macht die Versäumnisse nur sichtbar.

Was muss vor dem Relaunch gesichert sein?

Vor dem Relaunch müssen alle rankenden Adressen, das vollständige URL-Inventar und die aktuellen Positionen gesichert sein, denn diese Daten holen Sie später nicht zurück. Sie sind die Soll-Liste, gegen die Sie nach dem Launch jeden Verlust prüfen. Ohne sie launchen Sie blind und merken einen Einbruch erst, wenn die Anfragen ausbleiben.

Den ersten Posten unterschätzen fast alle: die Google Search Console speichert Performance-Daten nur 16 Monate lang, als rollendes Fenster. Was hinten herausfällt, ist endgültig gelöscht, ohne Archiv, ohne Wiederherstellung. Wer nach dem Relaunch einen Vorher-nachher-Vergleich ziehen will, braucht den Export vorher. Semrush rät dazu zwei bis vier Wochen vor dem Umzug, samt Klicks, Impressionen, indexierter Seitenzahl und Conversion-Raten.

Verlassen Sie sich auf eine einzige Quelle, fehlen am Ende genau die Seiten, die extern verlinkt sind und still Traffic tragen. Screaming Frog empfiehlt, vor jeder Änderung einen vollständigen Crawl der Live-Website als Referenz wegzuspeichern. Besonders heikel sind die Adressen mit externen Backlinks. Für sie ist eine fehlende Weiterleitung am teuersten, weil mit dem Link auch die aufgebaute Autorität ins Leere läuft. Aleyda Solis zählt die Prüfung, ob auf eine nicht weitergeleitete Seite Backlinks zeigen, deshalb zur Kern-Validierung vor dem Launch.

• Search-Console-Daten exportiert (16-Monate-Fenster, danach gelöscht)
• Vollständiger Crawl der Live-Website als Baseline gespeichert
• URL-Inventar aus allen fünf Quellen zusammengeführt
• Seiten mit externen Backlinks als Redirect-Priorität markiert
• Aktuelle Positionen der wichtigsten Keywords festgehalten

Die Positionen halten Sie zwei bis vier Wochen vor dem Go-Live fest, nicht erst am Tag davor. Rankings schwanken täglich, ein längeres Fenster gibt einen ehrlicheren Ankerpunkt. Mit dieser Soll-Liste in der Hand geht es an die Baustelle selbst, und dort wartet die nächste Falle.

Wie sichern Sie die Baustelle gegen Google ab?

Die Baustelle sichern Sie mit Passwortschutz ab, denn ein noindex-Tag allein hält Google nicht zuverlässig fern. Ohne Zugangsdaten kommt Google nicht durch eine HTTP-Authentifizierung, egal ob irgendwo ein Link auf die Testadresse zeigt. Der Klassiker, die Staging-Umgebung nur mit noindex und einem robots-Eintrag abzuschirmen, geht regelmäßig schief, und zwar in beide Richtungen.

Warum noindex hier versagt, hat eine technische Ursache: Google respektiert das noindex-Tag nur, wenn es die Seite crawlen darf. Sperrt ein robots-Eintrag das Crawling, liest Google das Tag gar nicht und kann die Seite über externe Links trotzdem in den Index nehmen. Im dokumentierten Härtefall im Google-Search-Central-Forum wählte Google die Staging-Adresse sogar als kanonische Version und verdrängte damit die echte Produktionsseite aus dem Index.

Die andere Richtung ist genauso teuer. Ein noindex, das während der Bauphase site-weit gesetzt war, wandert beim Deploy versehentlich auf die Produktionsseite und kippt innerhalb weniger Tage die ganze Website aus den Suchergebnissen. Botify dokumentiert einen Fall, in dem der Traffic „zwei Tage nach dem Launch von der Klippe sprang". Deshalb empfiehlt auch Google selbst den Passwortschutz als primäre Methode, mit noindex und robots-Eintrag als ergänzende Schichten darüber.

Was passiert in den ersten 72 Stunden?

In den ersten 72 Stunden testen Sie zuerst die Weiterleitungen live, reichen dann die neue Sitemap ein und beobachten die Search Console auf 404-Spitzen. Die Reihenfolge hat eine klare Logik: Eine frisch eingereichte Sitemap beschleunigt die Indexierung, also sollen die Weiterleitungen vorher stimmen, damit Google nicht zügig die falschen Zieladressen aufnimmt. Diese Stunden entscheiden, ob ein temporärer Dip ein temporärer Dip bleibt.

Die Zwei-Sitemaps-Strategie ist dabei der unauffällige Hebel. Semrush bringt es auf den Punkt: Beide Sitemaps einzureichen hilft Google, die Weiterleitungen von den alten auf die neuen Adressen überhaupt zu entdecken. Die Mechanik der Weiterleitungen selbst, von 301 gegen 302 bis zur Soft-404-Falle, steht im Leitfaden zu den 301-Weiterleitungen; das laufende Ranking-Monitoring danach im Leitfaden zum Relaunch-Monitoring.

Welcher Fall vorliegt, verraten Ihnen die Daten, nicht das Bauchgefühl. Rheinspace nennt für DACH-KMU einen brauchbaren Richtwert: Bis zu 15 % Schwankung in den ersten zwei Wochen sind normal, kritisch wird es ab anhaltend über 20 % ohne Erholung nach vier Wochen. In schweren Fällen kann sich der Schaden laut Search Engine Journal über 12 bis 18 Monate ziehen. Genau deshalb wird das Monitoring-Fenster über acht bis zwölf Wochen offengehalten und nicht nach drei Tagen geschlossen.

Warum nur eine Sache auf einmal ändern?

Nur eine Sache auf einmal zu ändern hält die Fehlersuche möglich, denn bei mehreren gleichzeitigen Änderungen lässt sich ein Einbruch nicht mehr einer Ursache zuordnen. Wenn CMS, Design, URL-Struktur und Inhalte am selben Tag wechseln und die Rankings fallen, wissen Sie nicht, an welcher der vier Schrauben es hängt. Damit wird die gezielte Korrektur unmöglich, und übrig bleibt Raten.

Google Search Central rät explizit, immer nur eine Sache auf einmal zu ändern. Jede dieser Dimensionen ist für sich genommen eine vollwertige Migration: der Wechsel von HTTP auf HTTPS, der Domainwechsel, die geänderten URL-Pfade, der Systemwechsel. Müssen CMS und URL-Struktur beide neu, ziehen Sie zuerst das System um und lassen die Adressen 1:1 stehen, und bauen erst nach vier bis acht Wochen Stabilisierung die Struktur um. Die DACH-Agentur Seokratie zieht in ihrer Relaunch-Checkliste eine klare Obergrenze: höchstens zwei der vier Dimensionen gleichzeitig anfassen.

Der Maßstab ist hier wichtiger als die Zahl: Wenn fast 30.000 Adressen kontrolliert umziehen, dann ist die typische KMU-Website mit 50 bis 500 Seiten erst recht beherrschbar. Es scheitert selten an der Größe, fast immer an der fehlenden Vorbereitung. Bevor Sie also irgendetwas umbauen, lohnt der nüchterne Blick auf das Fundament Ihrer aktuellen Struktur.

Prüfen Sie Ihre Struktur, bevor Sie sie umbauen

Welche Seiten liegen zu tief vergraben, wo zeigt intern nichts mehr hin, welche Adressen tragen still Traffic, den ein unsauberer Umzug kostet? Der kostenlose URL-Architektur-Check zeigt Ihnen das in wenigen Minuten und liefert Ihnen die Soll-Liste, gegen die Sie nach dem Launch vergleichen.

Eigene Struktur prüfen

Vor dem Launch eine Soll-Liste aus zwei Quellen bauen

Bauen Sie sich vor dem Launch eine feste Soll-Liste aller rankenden Adressen, gegen die Sie danach jeden Verlust abgleichen können. Sie entsteht aus der Kombination zweier Quellen, weil keine für sich allein vollständig ist.

Diese Liste ist dasselbe Dokument, das Sie nach dem Go-Live Zeile für Zeile abhaken: Jede alte Adresse braucht ihr neues Gegenstück. Was die Liste übersieht, fängt im Idealfall das selbstheilende Netz auf, aber die Liste zuerst spart genau diese Reparatur.

Nach dem Go-Live gezielt nach noindex-Resten crawlen

Crawlen Sie direkt nach dem Go-Live die echte Live-Website und suchen Sie gezielt nach Seiten mit einem noindex-Tag aus der Bauphase. Dieser vergessene Rest ist eine der häufigsten Relaunch-Katastrophen und zugleich in fünf Minuten zu finden.

Den Crawl wiederholen Sie am besten in den ersten Tagen mehrmals, weil sich gerade frisch deployte Seiten noch ändern. Dasselbe Crawl-Werkzeug, das vorher die Soll-Liste gefüllt hat, wird hier zum Frühwarnsystem. In welcher Reihenfolge Google die freigegebenen Seiten danach aufnimmt, klärt der Leitfaden zum Indexierungsmanagement.

Den Struktur-Score vor und nach dem Launch vergleichen

Messen Sie Ihre URL-Architektur einmal vor dem Umbau und einmal danach, und vergleichen Sie die beiden Aufnahmen. So sehen Sie schwarz auf weiß, ob der Relaunch die Struktur verbessert oder ob er wichtige Seiten tiefer vergraben hat, als sie vorher lagen.

Der Wert steckt im Vergleich, nicht in der Einzelzahl. Liegt eine Leistungsseite nach dem Launch plötzlich fünf Klicks tief statt zwei, wissen Sie das, bevor die Rankings es Ihnen Wochen später verraten. Den kostenlosen URL-Architektur-Check setzen Sie dafür zweimal ein, einmal pro Aufnahme. Was eine gute Struktur überhaupt ausmacht, steht im Leitfaden zur guten URL-Struktur.

Sichtbarkeit übersteht keinen Umbau, den man ihr verschweigt. Wer sie einplant, behält sie.

Relaunch in einem Satz

Welche Relaunch-Mythen kosten Geld?

Drei verbreitete Annahmen kosten beim Relaunch regelmäßig Sichtbarkeit, obwohl die Daten und Google ihnen widersprechen. Alle drei klingen beruhigend, und genau das macht sie gefährlich, weil sie Untätigkeit rechtfertigen. Ein kurzer Faktencheck spart hier Monate.

Die ehrliche Lesart hinter allen drei Mythen: Der Schaden entsteht schon in der übersprungenen Vorbereitung, lange vor dem Go-Live-Tag. Eine kurze Schwankung und ein struktureller Einbruch sehen am ersten Tag gleich aus, unterscheiden lassen sie sich nur in den Search-Console-Daten, die Sie vorher gesichert haben. Die Mechanik dahinter, warum Google Traffic überhaupt versiegen lässt, steht im Leitfaden zur URL-Architektur.

Quellen

• Semrush – The Complete Website Migration Checklist (Inventar, Baseline, Zwei-Sitemaps)
• Screaming Frog – Pre-Migration-Crawl als Baseline
• Aleyda Solis – SEO for Web Migrations (Backlink-Mapping)
• DadSEO – GSC Data Retention, das 16-Monate-Limit
• Search Engine Land – Site Redesign SEO Checklist (Go-Live)
• Search Engine Journal – Studie über 892 Migrationen (17 % erholen sich nie)
• Search Engine Journal – Migration Hangover (12 bis 18 Monate in schweren Fällen)
• Search Engine Journal – John Mueller zu 301-Redirects und Timing
• Seokratie – Relaunch-Checkliste, Max-2-Variablen-Regel (DACH)
• Rheinspace – SEO Website Relaunch, 15-%-Richtwert (DACH)
• Webrepublic – SEO Relaunch, 6-Stufen-Framework (DACH Schweiz)
• Google Search Central – Site Moves, „change only one thing at a time"
• Google Search Console – Change-of-Address-Tool
• Searchviu – robots.txt und noindex für Staging-Umgebungen
• Conductor Academy – Staging-Umgebungen mit Passwortschutz absichern
• Google Search Central Community – Staging verdrängt Produktionsseite
• Botify – SEO Horror Stories (noindex live, Traffic von der Klippe)

Entwurf · Cluster G, Node G1 (/url-architektur/relaunch-ohne-sichtbarkeitsverlust/). Interne Links (Hub, G2, G3, I4, H1, /seo-fuer-kmu/) sind Vorwärts-Slugs, bis alle Ziel-Artikel und die Money-Page stehen. Die SEJ-Studie hat einen Selbstauswahl-Bias (Erhebung über Slack/X), ist aber die bislang größte verfügbare Datenbasis.