Website-Relaunch ohne Rankingverlust

Ein Relaunch kann moderner aussehen, schneller laden und redaktionell leichter zu pflegen sein – und trotzdem organische Sichtbarkeit verlieren. Der Grund liegt selten in der Farbe eines Buttons. Für Google ist eine Website kein einzelnes Design, sondern ein Geflecht aus erreichbaren URLs, Inhalten, internen Links, technischen Signalen und externen Verweisen. Wenn der Relaunch dieses Geflecht verändert, muss Google die neue Struktur erst wieder entdecken, verstehen und den bisherigen Seiten zuordnen.

Ein Relaunch verändert oft mehrere Systeme gleichzeitig

In einem typischen Projekt wechseln Layout, Content-Management-System, Navigation und URL-Struktur gemeinsam. Texte werden gekürzt, weil das neue Raster weniger Platz vorsieht. Kategorien erhalten neue Namen. Alte Landingpages gehen in übergeordneten Seiten auf. Canonicals, strukturierte Daten oder Sprachverweise werden aus dem neuen Template anders ausgegeben. Jede einzelne Änderung kann sinnvoll sein; zusammen verändern sie jedoch genau die Signale, auf denen die bisherige Sichtbarkeit beruhte.

Deshalb beginnt SEO-Sicherheit nicht mit einer Weiterleitungsliste kurz vor dem Start. Sie beginnt mit der Entscheidung, welche bestehende Leistung erhalten werden soll. Eine Seite kann für Besucher wichtig sein, ohne viel organischen Traffic zu haben. Eine andere bringt kaum direkte Anfragen, sammelt aber externe Links oder verbindet einen Themenbereich intern. Erst die gemeinsame Betrachtung verhindert, dass das Projekt eine scheinbar nebensächliche URL entfernt, die für die Gesamtstruktur wichtig war.

„Ohne Rankingverlust“ bedeutet kontrollieren, nicht garantieren

Google weist bei bedeutenden Website-Änderungen ausdrücklich auf vorübergehende Schwankungen hin, während alte und neue URLs erneut gecrawlt und verarbeitet werden. Ein seriös geplanter Relaunch kann diese Bewegung begrenzen und Fehler schnell sichtbar machen, aber kein bestimmtes Ranking festschreiben. Das belastbare Ziel lautet daher: Relevante Signale werden systematisch erfasst, jede bekannte alte URL erhält eine bewusste Behandlung, und Abweichungen lassen sich nach dem Start auf konkrete Ursachen zurückführen.

Diese Erwartung verändert auch den Projektablauf. Der Go-live ist nicht der Moment, an dem SEO „fertig“ ist. Er ist der Übergang zwischen zwei messbaren Zuständen. Vorher wird eine Ausgangslage gesichert, danach wird geprüft, ob Google und Nutzer im neuen System dieselben wichtigen Ziele erreichen.

Ein Relaunch ist etwas anderes als ein reiner Serverwechsel

Bleiben Inhalte, Domain, URLs und System gleich und ändert sich nur der Hoster, liegt ein anderer Vorgang vor. Dann stehen DNS, Server, E-Mail und die unterbrechungsfreie Umschaltung im Mittelpunkt. Dafür gilt unser Leitfaden zum Umzug derselben Website auf einen neuen Server. Der vorliegende Artikel behandelt dagegen den vollständigen Relaunch, bei dem sich Informationsarchitektur, Templates oder Inhalte und damit suchrelevante Beziehungen verändern.

Bevor die neue Navigation feststeht, braucht das Projekt ein Bild der alten Website. Eine exportierte XML-Sitemap reicht dafür nicht aus. Sie zeigt nur die URLs, die das bisherige System bewusst ausgibt. Alte Kampagnenziele, verwaiste Seiten mit externen Links, PDFs, Bilder oder noch aufgerufene Adressen können außerhalb dieser Liste liegen. Ein brauchbares Inventar führt deshalb mehrere Quellen zusammen.

Vier Quellen zeigen vier verschiedene Ausschnitte

• CMS und Sitemap: Welche Inhalte und Mediadateien das System aktuell verwaltet und veröffentlicht.
• Search Console: Welche Seiten Impressionen, Klicks, interne oder externe Links und Indexierungsstatus besitzen.
• Analytics: Welche Einstiegsseiten Besucher tatsächlich erreichen und welche Ziele daraus entstehen.
• Serverprotokolle: Welche URLs von Nutzern und Crawlern aufgerufen werden, auch wenn sie in keiner Navigation mehr stehen.

Google nennt für eine URL-Bestandsaufnahme genau diese Logik: Sitemaps, Analytics, Serverprotokolle und die Linkdaten der Search Console ergänzen einander. Zusätzlich gehören Bilder, Videos, JavaScript- und CSS-Adressen in die Planung, wenn sie beim Relaunch ihren Ort wechseln. Das Inventar ist deshalb keine bloße Seitenliste. Es ist die Verbindung zwischen einer Adresse und ihrer heutigen Funktion.

Dabei wird nicht jede technisch erzeugte Parameterkombination ungeprüft zu einer eigenen Inhaltsseite erklärt. Filter, Trackingparameter, Druckansichten und Groß-/Kleinschreibungsvarianten können dieselbe Seite mehrfach erscheinen lassen. Das Inventar trennt echte Inhalte von URL-Varianten und hält fest, welche kanonische Adresse bisher maßgeblich war. Varianten, die noch externe Links oder regelmäßige Abrufe erhalten, bleiben trotzdem im Blick: Sie benötigen beim Wechsel einen direkten Weg zum richtigen neuen Ziel, auch wenn sie nie als eigenständige Seite gedacht waren.

Die Kennzahlen erklären, was an einer URL erhaltenswert ist

Zu jeder wichtigen URL gehören mindestens Seitentyp, Thema, Statuscode, Canonical, organische Einstiege, relevante Suchanfragen, interne Verlinkung und bekannte externe Links. Diese Angaben müssen nicht zu einem künstlichen Punktesystem verrechnet werden. Sie beantworten unterschiedliche Fragen. Traffic zeigt Nachfrage, externe Links zeigen gewachsene Empfehlungen, und interne Links zeigen die Rolle einer Seite in der Architektur. Eine Seite mit wenig Traffic kann trotzdem das richtige Ziel für zahlreiche Fachartikel sein.

Auch Inhalte ohne aktuellen SEO-Erfolg brauchen eine Entscheidung. Manche erfüllen eine rechtliche oder operative Aufgabe. Andere sind tatsächlich überholt und dürfen entfallen. Wichtig ist, dass „kein Traffic“ nicht automatisch „keine Bedeutung“ heißt und dass eine Löschung nicht zufällig aus dem neuen Menü oder einem unvollständigen Export entsteht.

Die Ausgangsmessung wird später zum Vergleich

Vor dem Umbau werden die Suchleistung nach Seiten und Suchanfragen, die indexierten URL-Muster und wichtige technische Befunde gesichert. Dabei zählt die Struktur mehr als ein einzelner Gesamtwert. Wenn nach dem Relaunch nur ein Verzeichnis verliert, ist das eine andere Ursache als ein Einbruch aller Seitentypen. Der vorherige Export macht diesen Unterschied sichtbar, auch wenn sich Berichte und Daten während des Projekts weiterbewegen.

Das Inventar braucht außerdem eine verantwortliche Person. Wenn Redaktion, Entwicklung und SEO jeweils eigene Listen führen, entstehen widersprüchliche Zieladressen und unbemerkte Lücken. Eine gemeinsame Quelle hält fest, wer über Zusammenlegung, Löschung, Inhaltserhalt und neue URL entscheidet.

Die neue Informationsarchitektur sollte nicht aus einer leeren Navigation entstehen. Sie übersetzt vorhandene Themen und Nutzerwege in ein verständlicheres System. Das bedeutet nicht, jede alte Seite zu konservieren. Es bedeutet, ihren Zweck zu kennen, bevor eine neue Adresse oder ein gemeinsames Ziel festgelegt wird.

Seitenzweck kommt vor Seitenname

Zwei alte Seiten dürfen zusammengeführt werden, wenn sie dieselbe Such- und Nutzeraufgabe erfüllen und die neue Seite beide Inhalte sinnvoll aufnimmt. Ähnliche Seitentitel allein reichen nicht. Eine Leistungsübersicht und ein ausführlicher Ratgeber können dasselbe Wort verwenden, aber unterschiedliche Erwartungen bedienen. Werden sie nur wegen einer schlankeren Navigation zusammengelegt, verliert mindestens eine Absicht ihr passendes Ziel.

Umgekehrt kann eine überladene Seite mehrere klare Ziele brauchen. Dann entstehen neue URLs, deren interne Einordnung und Inhalt bereits vor dem Design feststehen. So bestimmt die Architektur das Template – nicht umgekehrt. Ein Kartenraster darf nicht entscheiden, dass aus sieben fachlich notwendigen Abschnitten vier werden.

Stabile URLs reduzieren unnötige Bewegung

Wenn eine bestehende Adresse weiterhin zum selben Inhalt passt, gibt es keinen SEO-Grund, sie nur wegen eines neuen Systems zu ändern. Eine lesbarere Schreibweise kann attraktiv wirken, erzeugt aber zusätzlichen Migrationsaufwand und ein neues Ziel, das Google verarbeiten muss. URL-Änderungen gehören deshalb an einen fachlichen Anlass: neue Hierarchie, zusammengeführte Inhalte, Domainwechsel oder eine technisch nicht weiterführbare Altstruktur.

Google empfiehlt bei komplexen Migrationen, nicht mehrere große Veränderungen ohne Not gleichzeitig vorzunehmen. Für einen Relaunch heißt das: Ein Domainwechsel, ein neues CMS und eine vollständige Inhaltsneuausrichtung erhöhen gemeinsam die Zahl möglicher Ursachen. Wo sich Schritte trennen lassen, wird die spätere Bewertung klarer. Wo sie aus Projektgründen zusammenfallen, muss die Dokumentation umso genauer sein.

Entfallene Inhalte brauchen eine ehrliche Behandlung

Nicht jede alte URL hat einen sinnvollen Nachfolger. Wurde ein Angebot vollständig eingestellt und gibt es keine gleichwertige Information, ist eine Fehlerantwort mit 404 oder 410 verständlicher als eine pauschale Weiterleitung zur Startseite. Google warnt davor, viele unähnliche alte Seiten auf ein irrelevantes gemeinsames Ziel zu leiten; solche Ziele können als Soft 404 behandelt werden. Eine Zusammenführung ist dagegen sinnvoll, wenn die neue Seite den alten Inhalt tatsächlich aufnimmt.

Die Architektur verbindet Navigation und interne Links

Eine Seite bleibt nicht wichtig, nur weil sie in der alten Website wichtig war. Die neue Struktur muss diese Rolle wieder ausdrücken: durch erreichbare Navigation, kontextuelle Links, Breadcrumbs und passende Übersichtsseiten. Das Mapping der URLs und das Modell der internen Verlinkung entstehen deshalb gemeinsam. Sonst führt die Weiterleitung zwar auf eine vorhandene Seite, die im neuen System jedoch verwaist.

Das URL-Mapping verbindet den alten und den neuen Zustand auf Seitenebene. Für jede erreichbare alte Adresse steht darin genau eine Entscheidung: Die URL bleibt bestehen, sie leitet dauerhaft auf ein gleichwertiges neues Ziel, oder sie endet bewusst mit einem passenden Fehlerstatus. Solange diese Entscheidung fehlt, ist der Relaunch fachlich nicht fertig geplant.

Eine Zuordnung erklärt mehr als zwei Spalten

Neben alter und neuer URL gehören der geplante Status, der Grund der Änderung, die inhaltlich verantwortliche Person und besondere Signale in die Zuordnung. Bei mehrsprachigen Seiten kommen Sprachbeziehungen hinzu. Bei PDF- oder Bildadressen wird festgehalten, ob sie weiter erreichbar bleiben oder ebenfalls umziehen. Dadurch wird aus der Liste ein Arbeitsmittel für Redaktion, Entwicklung und Abnahme.

Google empfiehlt, die alten URLs aus mehreren Quellen zu bestimmen und anschließend für jede Adresse ein Ziel festzulegen. Bei einem Relaunch ist dieser Schritt besonders wichtig, weil das neue CMS oft nur die künftig geplanten Seiten kennt. Was im Zielsystem nicht angelegt wurde, verschwindet sonst aus dem Blick, obwohl die alte Adresse weiterhin in Suchergebnissen, Lesezeichen oder externen Links vorkommt.

Gleichwertigkeit entsteht durch Aufgabe und Inhalt

Eine alte Unterseite über eine konkrete Leistung gehört nicht automatisch auf die neue Leistungsübersicht. Das Ziel ist nur dann gleichwertig, wenn es die wesentliche Frage der alten Seite weiter beantwortet. Wurde der Inhalt auf eine neue, umfassendere Seite übernommen, kann diese das richtige Ziel sein. Fehlt die Antwort dort, erzeugt die Weiterleitung zwar keinen technischen Fehler, aber einen Bruch für Besucher und Suchmaschine.

Diese Prüfung verhindert auch die verbreitete Sammelweiterleitung zur Startseite. Sie ist bequem zu konfigurieren, verliert aber die Bedeutung der einzelnen alten URLs. Besser ist eine direkte Zuordnung zum engsten passenden Ziel. Gibt es keines, bleibt eine klare 404- oder 410-Antwort ehrlicher.

Dauerhafte Weiterleitungen senden das passende Signal

Für dauerhaft geänderte Adressen empfiehlt Google serverseitige permanente Weiterleitungen, insbesondere HTTP 301 oder 308. Sie teilen Nutzern und Suchmaschine mit, dass der Inhalt einen neuen Ort hat, und dienen als Canonical-Signal. Temporäre 302- oder 307-Weiterleitungen passen dagegen zu einer vorübergehenden Ausweichadresse, nicht zum endgültigen Relaunch.

Direkte Ziele vermeiden Ketten und alte Umwege

Wenn eine URL bereits früher weitergeleitet wurde, sollte der Relaunch nicht einfach eine weitere Stufe ergänzen. Die alte Adresse zeigt direkt auf das endgültige neue Ziel. Das verkürzt den Weg für Besucher und Crawler und verhindert, dass spätere Änderungen eine immer längere Kette bilden. Das Mapping muss deshalb auch bestehende Weiterleitungen enthalten, nicht nur aktuell sichtbare Seiten.

Ein Relaunch ist oft auch ein redaktioneller Neustart. Alte Texte wirken zu lang, uneinheitlich oder nicht mehr markengerecht. Das ist ein legitimer Anlass zur Überarbeitung. Riskant wird es, wenn die neue Fassung zwar eleganter klingt, aber genau die Antworten, Begriffe, Belege und fachlichen Besonderheiten entfernt, für die die Seite bisher gefunden wurde. Das betrifft klassische Suchergebnisse ebenso wie generative Suchfunktionen.

Die Suchabsicht steckt im vollständigen Seitenzusammenhang

Title und H1 sind sichtbar, erklären aber nicht allein, warum eine Seite rankt. Entscheidend ist, welche Fragen der Hauptinhalt beantwortet, wie eindeutig das Thema abgegrenzt ist und welche weiterführenden Seiten verlinkt werden. Vor einer Kürzung wird deshalb verglichen, welche Suchanfragen und Einstiege die alte URL erreicht und welche Abschnitte diese Erwartung bedienen.

Ein konkretes Beispiel: Eine alte Leistungsseite erklärt neben dem Angebot auch Ablauf, Voraussetzungen und typische Übergaben. Im neuen Design bleibt nur eine kurze Nutzenbotschaft übrig. Die Marke klingt prägnanter, aber ein Besucher mit einer konkreten Prozessfrage findet keine Antwort mehr. Der Inhalt wurde nicht nur gekürzt, sondern in seiner Aufgabe verändert. Wenn diese Veränderung gewollt ist, braucht die verlorene Teilfrage ein anderes sinnvolles Ziel.

GEO beginnt beim Relaunch mit denselben belastbaren Grundlagen

Für Sichtbarkeit in generativen Suchfunktionen braucht es laut Google keine eigene technische Parallelwelt. Eine Seite muss weiterhin crawlbar, indexierbar und für die Anzeige eines Snippets geeignet sein. Wichtige Aussagen sollten als sichtbarer Text vorliegen, über interne Links erreichbar sein und durch passende Bilder oder Videos ergänzt werden. Strukturierte Daten helfen nur, wenn sie den sichtbaren Inhalt korrekt beschreiben. Gehen diese Grundlagen beim Relaunch verloren, fehlt nicht nur klassischen Treffern, sondern auch generativen Suchsystemen eine verlässliche Quelle.

Deshalb gehört GEO in die Inhaltsabnahme, aber nicht als Sammlung vermeintlicher Tricks. Eine zusätzliche KI-Datei, ein besonderes GEO-Markup oder künstlich zerstückelte Texte ersetzen keine klare Informationsarchitektur. Erhalten werden sollten vor allem eigene Erfahrungen, nachvollziehbare Beispiele, eindeutige Leistungsangaben, fachlich verantwortete Aussagen und Belege, die über austauschbares Allgemeinwissen hinausgehen. Genau diese Substanz wird bei einer rein werblichen Kürzung oft zuerst entfernt.

Ein Relaunch darf Inhalte verbessern, aber nicht blind ersetzen

Erhalten bedeutet nicht, jeden alten Satz zu kopieren. Veraltete Aussagen werden korrigiert, doppelte Abschnitte zusammengeführt und schwer verständliche Passagen neu geschrieben. Die fachliche Substanz, relevante Beispiele und nachgewiesene Besonderheiten bleiben jedoch sichtbar. So entsteht eine bessere Seite mit demselben oder einem bewusst weiterentwickelten Zweck.

Auch Seitentitel, Beschreibungen, Autor- oder Unternehmensangaben und Aktualisierungsinformationen werden nicht mechanisch aus dem alten System übernommen. Sie müssen zur neuen Seite passen. Werden sie geändert, geschieht das als redaktionelle Entscheidung, nicht als Nebenwirkung eines Templates, das überall dieselbe Formulierung einsetzt oder Verantwortlichkeit unsichtbar macht.

Interne Links übertragen Themenbeziehungen

Links im Hauptinhalt zeigen, welche Seiten ein Thema vertiefen und welche Begriffe miteinander verbunden sind. Nach dem Relaunch sollten sie direkt auf die neuen Ziele weisen, nicht dauerhaft über Weiterleitungen laufen. Eine reine Prüfung der Hauptnavigation übersieht diese Beziehungen. Deshalb werden Content-Links, Breadcrumbs, Footer-Module und automatisch erzeugte Empfehlungen gemeinsam gegen die neue Architektur geprüft.

Technische Auszeichnungen müssen zur sichtbaren Seite passen

Canonicals, hreflang-Verweise und strukturierte Daten gehören zum Inhaltssystem. Jede neue URL braucht ein selbstreferenzierendes Canonical, sofern keine begründete andere Zuordnung besteht. Sprachverweise müssen auf die neuen Sprachvarianten zeigen. Strukturierte Daten dürfen nur Eigenschaften beschreiben, die auf der Seite tatsächlich sichtbar und fachlich korrekt sind. Ein Relaunch ist keine Gelegenheit, alte Markups ungeprüft in neue Templates zu kopieren.

Eine Staging-Umgebung muss zwei gegensätzliche Aufgaben erfüllen: Das Projektteam braucht realistische, vollständig erreichbare Seiten für die Abnahme, während die Öffentlichkeit und Suchmaschinen den unfertigen Stand nicht sehen sollen. Diese Trennung wird früh geplant, weil ein hastig gesetztes noindex kurz vor dem Start ebenso gefährlich ist wie eine frei zugängliche Testdomain.

Zugriffsschutz und Indexierungsregeln sind nicht dasselbe

Für vertrauliche oder unfertige Inhalte ist ein Passwortschutz die klarste Grenze. Ein noindex-Meta-Tag verhindert eine Aufnahme in Suchergebnisse erst, wenn ein Crawler die Seite abrufen und die Regel lesen kann. Wird dieselbe URL zugleich per robots.txt vom Crawling ausgeschlossen, kann Google das noindex nicht erkennen. Das ist auf Staging nicht nur theoretisch wichtig: Wer mehrere Schutzmechanismen vermischt, weiß beim Go-live oft nicht mehr, welche Regel wo entfernt werden muss.

Google weist für Website-Migrationen ausdrücklich darauf hin, schon während der Vorbereitung festzuhalten, welche robots.txt- und noindex-Regeln zum Start geändert werden. Der Relaunch braucht daher keine lose Erinnerung, sondern eine definierte Produktionskonfiguration. Testdomain, Vorschaumodus und Live-System erhalten jeweils nachvollziehbare Regeln.

Die Abnahme prüft Seitentypen und nicht nur Lieblingsseiten

Startseite und zwei zentrale Leistungen können korrekt aussehen, während ein seltenes Template falsche Canonicals oder leere Überschriften ausgibt. Die Stichprobe folgt deshalb den Seitentypen: Leistungsseite, Ratgeber, Kategorie, Detailseite, Suche, Formular, PDF, Sprachversion und Fehlerseite. Für jeden Typ werden HTML-Ausgabe, Statuscode, Titel, H1, Canonical, Indexierungsregel, interne Links und strukturierte Daten geprüft.

Zusätzlich läuft das vollständige URL-Mapping gegen die Staging-Ziele. Jede neue Zieladresse muss erreichbar sein und den erwarteten Inhalt zeigen. Eine Weiterleitung kann technisch auf 200 enden und fachlich trotzdem falsch sein. Deshalb gehören Statusprüfung und Inhaltsprüfung zusammen.

Die neue Navigation muss ohne alte Website verständlich sein

Im Projekt kennen alle Beteiligten die alte Struktur. Besucher und Crawler sehen nach dem Start nur die neue. Die Abnahme betrachtet deshalb, ob wichtige Seiten von passenden Übersichten erreichbar sind, ob Breadcrumbs ihre Position erklären und ob kein neues Ziel allein durch eine Weiterleitung existiert. Eine Seite, die nur über ihre alte Adresse auffindbar bleibt, ist in der neuen Architektur nicht wirklich angekommen.

Ein festgeschriebener Freigabestand schützt den Go-live

Kurz vor der Umschaltung werden keine ungeprüften Design- oder Inhaltsideen mehr aufgenommen. Der freigegebene Build, das Mapping und die Redirect-Konfiguration bilden einen gemeinsamen Stand. Ändert sich danach noch eine URL, muss auch ihre Zuordnung neu geprüft werden. So verhindert das Projekt, dass Redaktion und Entwicklung in den letzten Stunden zwei verschiedene Zielsysteme vorbereiten.

Am Go-live treffen alle vorbereiteten Entscheidungen aufeinander. Die neue Website, Weiterleitungen, Indexierungsregeln und Messung müssen denselben Zustand beschreiben. Eine Reihenfolge verhindert, dass die Seite zwar erreichbar ist, Google aber noch alte oder widersprüchliche Signale erhält.

Die Produktion erhält zuerst den freigegebenen Stand

Die neue Anwendung und ihre Inhalte werden so bereitgestellt, dass alle Ziel-URLs funktionieren. Erst dann werden alte Adressen auf diese Ziele umgeschaltet. Das vermeidet Weiterleitungen auf noch nicht vorhandene Seiten. Gleichzeitig bleiben Analytics, Search-Console-Verifikation und andere Messpunkte erhalten, damit der Übergang vom ersten Aufruf an beobachtbar ist.

Weiterleitungen und interne Signale wechseln gemeinsam

Die permanenten serverseitigen Weiterleitungen aus dem Mapping werden aktiviert. Parallel zeigen interne Links, Canonicals, hreflang-Verweise und die XML-Sitemap direkt auf die neuen URLs. Wenn diese Signale auseinanderlaufen, muss Google zwischen alter Weiterleitung, altem Canonical und neuer Sitemap vermitteln. Eine konsistente Aussage ist leichter zu verarbeiten: Die alte URL führt dauerhaft zur neuen, und die neue bezeichnet sich selbst als maßgeblich.

Temporäre Sperren müssen im Live-System verschwinden

Passwortschutz, noindex und Staging-Regeln gehören nicht auf die veröffentlichte Website. Google nennt vergessene noindex- oder robots.txt-Sperren ausdrücklich als häufigen Fehler bei Migrationen. Die Kontrolle erfolgt deshalb in der tatsächlich ausgelieferten Produktion, nicht nur in einer Konfigurationsdatei. Ein Live-Test zeigt, welchen HTML-Code und welchen Status ein externer Abruf wirklich erhält.

Sitemap und Domainwechsel senden zusätzliche Hinweise

Nach dem Start enthält die neue Sitemap die kanonischen, erreichbaren Ziel-URLs. Sie wird in Search Console eingereicht, damit Google die neue Struktur schneller entdecken kann. Eine Sitemap garantiert keine Indexierung und ersetzt keine internen Links; sie ist ein zusätzlicher Weg, der denselben Sollzustand bestätigt. Ändert der Relaunch zusätzlich die Domain oder Subdomain, kommt das Change-of-Address-Werkzeug in Search Console hinzu. Google stellt klar, dass es für echte Domain- oder Subdomainwechsel gedacht ist, nicht für veränderte Pfade innerhalb derselben Domain oder den Wechsel zwischen HTTP und HTTPS. Die Weiterleitungen bleiben trotzdem notwendig; das Werkzeug ersetzt das URL-Mapping nicht.

Abbruchkriterien gehören vor den Starttermin

Ein Go-live braucht eine eindeutige Entscheidung darüber, welche Fehler die Veröffentlichung verhindern. Nicht jede abweichende Schriftgröße ist ein Abbruchgrund. Fehlende Zielseiten, falsche Canonicals, eine globale noindex-Regel, nicht funktionierende Weiterleitungen oder ausgefallene Formulare betreffen dagegen den erreichbaren und messbaren Zustand der Website. Diese Kriterien werden vor dem Termin festgelegt, damit Zeitdruck ihre Bedeutung nicht relativiert.

Auch ein Rückweg muss den Datenzustand berücksichtigen. Bei einer reinen Inhaltswebsite lässt sich ein vorheriger Stand oft einfacher wiederherstellen als bei einem Shop oder Portal, in dem nach dem Start neue Bestellungen, Konten oder Formulareingaben entstehen. Deshalb beschreibt der Umschaltplan nicht nur, wie der neue Stand veröffentlicht wird, sondern auch, bis zu welchem Moment ein kontrollierter Rückbau möglich ist und ab wann Fehler direkt im neuen System behoben werden müssen.

Eine Redirect-Datei kann vollständig aussehen und trotzdem falsche Ziele enthalten. Deshalb wird sie nicht nur auf Syntax, sondern auf Wirkung geprüft. Jede wichtige alte URL muss den erwarteten dauerhaften Status liefern, ohne Umweg beim vorgesehenen neuen Inhalt ankommen und dort einen erfolgreichen Seitenstatus erhalten.

Status und Ziel beantworten unterschiedliche Fragen

Ein 301-Status bestätigt nur, dass eine dauerhafte Weiterleitung eingerichtet wurde. Er sagt nicht, ob das Ziel fachlich passt oder erreichbar ist. Der Test erfasst deshalb den ersten Status, alle Zwischenstationen, die endgültige URL und deren Status. Zusätzlich wird stichprobenartig geprüft, ob der Inhalt die alte Aufgabe tatsächlich übernimmt.

Bei großen Listen geschieht die Statusprüfung automatisiert, während die fachliche Prüfung nach Seitentypen und Bedeutung priorisiert wird. Besonders wichtig sind URLs mit organischen Einstiegen, externen Links, Kampagnenverweisen oder hoher interner Bedeutung. Seltene alte Adressen werden dadurch nicht ignoriert; ihre technische Behandlung bleibt Teil des vollständigen Mappings.

Ketten zeigen meist eine unvollständige Historie

Eine alte URL leitet auf eine zwischenzeitliche Adresse und diese auf das neue Ziel. Solche Ketten entstehen, wenn nur der aktuelle Webauftritt exportiert wurde. Google empfiehlt, direkt zum endgültigen Ziel weiterzuleiten und Weiterleitungsketten möglichst zu vermeiden. Dafür muss die Konfiguration auch frühere URL-Varianten kennen.

Dasselbe gilt für Protokoll-, Host- und Slash-Varianten. Die Regeln sollten sich nicht gegenseitig in mehreren Schritten korrigieren. Eine klare Normalisierung führt auf direktem Weg zur kanonischen Zieladresse.

Fehlende Ziele werden nicht durch die Startseite geheilt

Wenn eine Weiterleitung auf eine nicht vorhandene neue URL zeigt, entsteht ein vermeidbarer Fehler. Wird stattdessen pauschal die Startseite eingesetzt, bleibt der fachliche Bruch bestehen. Google nennt irrelevante Sammelziele als möglichen Soft-404-Fall. Der Test unterscheidet daher zwischen falsch konfiguriertem Ziel, bewusst entfallenem Inhalt und einer echten Zusammenführung.

Weiterleitungen bleiben Teil der Website

Google empfiehlt bei Site Moves, Weiterleitungen möglichst lange und im Allgemeinen mindestens ein Jahr zu erhalten, damit Signale übertragen und alte Verweise erneut verarbeitet werden können. Für Nutzer können sie auch darüber hinaus sinnvoll bleiben. Gleichzeitig werden interne Links und wichtige externe Profile möglichst auf die neuen Ziele aktualisiert, damit nicht jeder Aufruf dauerhaft den Umweg braucht.

Nach dem Go-live beginnt kein tägliches Ranking-Orakel, sondern ein strukturierter Vergleich mit der Ausgangslage. Google verarbeitet Migrationen pro URL. Deshalb können neue und alte Adressen eine Zeit lang nebeneinander in Berichten erscheinen, während die Zuordnung fortschreitet. Einzelne Schwankungen sind in dieser Phase weniger aussagekräftig als wiederkehrende Muster nach Seitentyp oder Verzeichnis.

Search Console zeigt Verarbeitung und Suchleistung getrennt

Der Indexierungsbericht zeigt, ob neue Seiten aufgenommen werden und ob Fehler, Sperren oder unerwartete Ausschlüsse zunehmen. Der Leistungsbericht zeigt Impressionen, Klicks, Suchanfragen und Zielseiten. Beide Perspektiven gehören zusammen. Eine neue URL kann technisch indexiert sein und dennoch weniger Nachfrage erreichen, weil ihr Inhalt oder ihre interne Rolle verändert wurde.

Bei einem Domainwechsel werden alte und neue Property getrennt betrachtet. Google beschreibt den erwartbaren Übergang so: Zugriffe und Indexierung nehmen auf den alten URLs ab und auf den neuen zu. Innerhalb derselben Domain lässt sich dieselbe Logik über URL-Muster und Seitengruppen nachvollziehen.

Serverprotokolle zeigen, was Crawler wirklich abrufen

Logs ergänzen die Search Console um den tatsächlichen Abruf. Sie zeigen, ob Googlebot alte URLs besucht, den Redirect erhält und die neuen Ziele erreicht. Gleichzeitig werden unerwartete 404-, 5xx- oder Redirect-Fehler sichtbar. Google weist darauf hin, dass die neue Website nach einer Migration stärker gecrawlt werden kann, weil Abrufe alter Adressen zusätzlich auf neue Ziele führen. Ausreichende Serverkapazität gehört deshalb zur Relaunch-Planung.

Die Beobachtung folgt Seitengruppen statt Gesamtwerten

Startseite, Leistungen, Ratgeber, Standorte und andere Seitentypen werden getrennt verglichen. Wenn nur eine Gruppe verliert, führt die Suche zu ihrem Template, Mapping oder Inhalt. Fallen alle Gruppen gleichzeitig, liegen globale Ursachen wie Sperren, Canonicals, Erreichbarkeit oder Messfehler näher. Diese Segmentierung verhindert, dass eine kleine Problemgruppe durch den Gesamttraffic verborgen bleibt.

Eine fehlende URL braucht einen konkreten Befund

Ist eine neue Seite gar nicht auffindbar, wird zuerst ihr technischer Zustand geklärt: erreichbar, crawlbar, indexierbar, kanonisch und intern verlinkt. Eine allgemeine Diagnose für Seiten, die Google nicht findet, gehört in den eigenen Leitfaden zur Indexierung und Auffindbarkeit. Im Relaunch-Monitoring ist entscheidend, ob das Problem aus Mapping, Template oder Freigaberegel des neuen Systems stammt.

Wenn organische Zugriffe nach dem Start sinken, ist der Relaunch ein naheliegender Auslöser, aber noch keine Diagnose. Die zeitliche Nähe zeigt, wo die Untersuchung beginnt. Sie beweist nicht, dass jede verlorene Position aus derselben Ursache stammt. Eine ruhige Reihenfolge trennt technische Blocker, falsche Zuordnungen und inhaltliche Veränderungen.

Globale technische Fehler kommen zuerst

Ist die gesamte Website betroffen, werden Erreichbarkeit, robots.txt, noindex, Canonicals, Serverfehler und Messung geprüft. Ein vergessenes noindex kann alle weiteren Inhaltsdiskussionen überflüssig machen. Die Kontrolle erfolgt an mehreren Seitentypen und im gerenderten Live-Zustand. Erst wenn diese Grundlagen stimmen, lohnt sich die Analyse einzelner Themen.

Verluste einzelner Gruppen führen zurück zum Mapping

Fällt nur ein Verzeichnis oder Seitentyp, werden alte und neue URLs paarweise betrachtet. Stimmt das Ziel? Ist die Weiterleitung direkt? Hat die neue Seite den bisherigen Zweck übernommen? Erhält sie vergleichbare interne Links? Ein Mapping kann technisch vollständig sein und fachlich dennoch zu grob. Dann hilft keine pauschale Änderung an der gesamten Website, sondern eine Korrektur der betroffenen Beziehung.

Inhaltsänderungen brauchen den Vergleich mit der alten Aufgabe

Wurde eine Seite stark gekürzt, neu positioniert oder mit anderen Inhalten zusammengeführt, wird die Suchanfrage hinter dem Verlust betrachtet. Fehlt eine vormals hilfreiche Antwort, kann sie sinnvoll in die neue Seite zurückkehren oder ein eigenes Ziel erhalten. Es geht nicht darum, alte Texte reflexhaft wiederherzustellen. Die neue Website soll die berechtigte Frage weiterhin vollständig beantworten.

Nicht jeder zeitgleiche Verlust ist ein Relaunch-Fehler

Ändert sich die Sichtbarkeit auch bei unveränderten Seitengruppen oder fällt der Zeitpunkt mit einer breiteren Neubewertung zusammen, wird die Diagnose erweitert. Der Artikel zum Rankingverlust rund um ein Google Core Update behandelt diesen Fall getrennt. Diese Abgrenzung verhindert, dass ein Relaunch-Team funktionierende Redirects umbaut, obwohl die Ursache außerhalb der Migration liegt.

Die Übergabe entscheidet über die ersten Reaktionen

Nach dem Start brauchen Redaktion, Entwicklung und SEO dieselbe Dokumentation: Ausgangswerte, Mapping, Freigabestand, bekannte Ausnahmen und Verantwortliche. So kann eine Auffälligkeit einem Seitentyp und einer Änderung zugeordnet werden. Ohne diese Übergabe beginnt jede Analyse wieder bei Vermutungen.

Wenn interne Rollen für Inventur, technische Abnahme und Monitoring fehlen, zeigen wir dir, wie wir Relaunches von der Bestandsaufnahme bis zur Beobachtung nach dem Start begleiten. Die Begleitung ersetzt keine Garantie auf unveränderte Positionen; sie sorgt dafür, dass Suchsignale bewusst übertragen und Abweichungen nachvollziehbar bearbeitet werden.