Website-Relaunch planen: Bestandsaufnahme, Weiterleitungen und Zeitplan

Warum ein Relaunch mehr als ein neues Design ist

Ein Website-Relaunch verändert häufig mehrere technische Ebenen gleichzeitig: Gestaltung, Inhalte, URL-Struktur, Content-Management-System, Serverumgebung, Tracking, Formulare und Berechtigungen. Wird nur die sichtbare Oberfläche betrachtet, bleiben wichtige Abhängigkeiten unentdeckt. Nach dem Start können dann nicht mehr erreichbare Seiten, fehlerhafte Formulare, verlorene Suchzugriffe oder Sicherheitslücken auftreten.

Eine belastbare Planung behandelt den Relaunch deshalb als kontrollierte Migration. Das bestehende Angebot wird zunächst dokumentiert, anschließend werden Ziele und Anforderungen festgelegt. Danach folgen Konzeption, technische Umsetzung, Tests, die Übernahme der Inhalte und ein überwacht durchgeführter Start. Besonders kritisch sind Änderungen an den URLs. Eine neue Adresse ist für Menschen zwar oft verständlich, für Suchmaschinen, Lesezeichen und externe Verweise handelt es sich jedoch um eine neue Ressource.

Dieser Leitfaden beschreibt ein Vorgehen, das für kleine Websites ebenso geeignet ist wie für umfangreichere Unternehmens- oder Projektauftritte. Die einzelnen Arbeitsschritte lassen sich an die Größe und Komplexität des jeweiligen Projekts anpassen.

Ziele, Umfang und Verantwortlichkeiten festlegen

Am Anfang steht eine schriftliche Abgrenzung. Ohne klare Zieldefinition wächst ein Relaunch schnell zu einem offenen Sammelprojekt. Das führt zu zusätzlichen Änderungswünschen, unklaren Freigaben und einem schwer kalkulierbaren Termin.

Zu den zentralen Fragen gehören:

• Welche Probleme soll die neue Website lösen?
• Welche Inhalte und Funktionen müssen erhalten bleiben?
• Welche Bereiche werden überarbeitet, entfernt oder neu aufgebaut?
• Ändert sich das Content-Management-System oder nur die Gestaltung?
• Wer entscheidet über Inhalte, Technik, Datenschutz, Barrierearmut und Veröffentlichung?
• Welche Abhängigkeiten bestehen zu Formularen, Newsletter-Systemen, Schnittstellen oder internen Anwendungen?

Das Projektziel sollte überprüfbar formuliert werden. „Modernere Website“ beschreibt eine Absicht, aber kein prüfbares Ergebnis. Präziser sind Ziele wie eine verständlichere Navigation, eine überarbeitete mobile Darstellung, kürzere redaktionelle Abläufe oder die technische Ablösung eines nicht mehr unterstützten Systems. Ein Ziel gehört nur dann in den Relaunch, wenn es mit den verfügbaren Ressourcen, Zuständigkeiten und Tests abgesichert werden kann.

Für jede Aufgabe sollte es eine verantwortliche Person oder Rolle geben. Dabei geht es nicht darum, Namen öffentlich zu dokumentieren, sondern intern festzulegen, wer Anforderungen bestätigt, Inhalte freigibt, technische Änderungen prüft und im Notfall eine Rückkehr zur vorherigen Version veranlassen kann.

Die Bestandsaufnahme als technische Grundlage

Die Bestandsaufnahme, auch Audit oder Inventur genannt, verhindert, dass wichtige Bestandteile der alten Website beim Wechsel übersehen werden. Sie sollte nicht nur die sichtbaren Seiten umfassen. Auch Dateien, Weiterleitungen, Formulare, Metadaten, Zugriffsregeln und externe Einbindungen gehören in die Dokumentation.

URLs und Inhalte erfassen

Erstelle zunächst eine vollständige Liste der öffentlich erreichbaren Adressen. Dazu zählen HTML-Seiten, PDF-Dateien, Bilder, Downloads und gegebenenfalls Sprachversionen. Die Liste kann aus mehreren Quellen zusammengeführt werden: aus der internen Inhaltsverwaltung, aus Serverprotokollen, aus vorhandenen XML-Sitemaps und aus einem kontrollierten Abruf der Website. Jede Quelle hat Lücken, daher ist der Abgleich wichtig.

Für jede Adresse sollten mindestens folgende Informationen erfasst werden:

• aktuelle URL und Seitentitel
• Seitentyp, etwa Artikel, Produktseite, Kontaktseite oder Download
• Verantwortlichkeit und fachlicher Status
• Weiterverwendung, Überarbeitung, Zusammenführung oder Löschung
• neue Zieladresse, falls sich die URL ändert
• interne Verlinkungen und wichtige externe Verweise
• technischer Statuscode und mögliche Fehler

Eine solche Tabelle ist das zentrale Arbeitsdokument des Relaunches. Sie trennt vorhandene Inhalte von geplanten Inhalten und macht sichtbar, wo noch Entscheidungen fehlen.

Funktionen und Schnittstellen prüfen

Viele Risiken liegen nicht im Layout, sondern in Funktionen, die im Alltag selten auffallen. Prüfe Kontaktformulare, Suchfunktionen, Login-Bereiche, Downloads, Kommentarfunktionen, Karten, eingebettete Medien, Zahlvorgänge und Schnittstellen zu anderen Systemen. Dokumentiere außerdem, welche E-Mail-Adressen Formulare verwenden und ob automatische Antworten oder Benachrichtigungen ausgelöst werden.

Bei jeder externen Einbindung sollte geklärt werden, ob sie weiterhin benötigt wird, welche Daten übertragen werden und ob sie mit der neuen technischen Umgebung funktioniert. Nicht mehr verwendete Erweiterungen und unklare Skripte gehören nicht ungeprüft in die neue Installation.

Technik, Sicherheit und Datenschutz dokumentieren

Zur technischen Inventur zählen das eingesetzte System, die Versionen von Erweiterungen, die Serverumgebung, Datenbanken, Cron-Aufgaben, Speicherorte von Medien und vorhandene Zugriffsrollen. Ebenso wichtig sind Zertifikate, DNS-Einträge, E-Mail-Konfigurationen, Schutzmechanismen gegen automatisierte Anfragen sowie Sicherungs- und Wiederherstellungsverfahren.

Vor dem Relaunch sollten aktuelle Sicherungen angefertigt und testweise wiederhergestellt werden. Eine Datei, die zwar vorhanden ist, aber nicht zurückgespielt werden kann, ist keine verlässliche Notfallmaßnahme. Sicherungen der Datenbank, der Mediendateien und der Konfiguration müssen getrennt betrachtet werden. Außerdem sollte geklärt sein, wie Zugangsdaten sicher übertragen und nach Abschluss des Projekts geändert werden.

Inhalte bewerten und die neue Struktur entwerfen

Ein Relaunch ist ein geeigneter Zeitpunkt, Inhalte systematisch zu prüfen. Jede Seite braucht eine Entscheidung: bleibt sie unverändert, wird sie redaktionell überarbeitet, mit einer anderen Seite zusammengeführt, ersetzt oder entfernt? Die Entscheidung sollte anhand ihrer Funktion getroffen werden, nicht nur anhand der Zugriffszahlen.

Auch eine wenig besuchte Seite kann für einen bestimmten Suchbegriff, einen rechtlichen Hinweis, einen Download oder eine wiederkehrende Nutzerfrage wichtig sein. Umgekehrt können stark besuchte Seiten veraltete Informationen enthalten. Beurteile deshalb Inhalt, Aktualität, fachliche Qualität, interne Verlinkung, Zielgruppe und technische Erreichbarkeit gemeinsam.

Die neue Informationsarchitektur sollte aus Sicht der Nutzer nachvollziehbar sein. Hauptbereiche müssen eindeutig benannt und in einer konsistenten Hierarchie angeordnet werden. Vermeide mehrere Menüpunkte mit nahezu gleicher Bedeutung. Eine flache Struktur ist nicht automatisch besser; entscheidend ist, dass Nutzer vom Einstieg aus zu den relevanten Informationen gelangen und ihren Standort erkennen.

Lege für jede wichtige Seite ein Ziel fest. Eine Informationsseite kann etwa eine Frage beantworten, ein Verfahren erklären oder zu einer Kontaktaufnahme führen. Dieses Ziel beeinflusst Überschrift, Aufbau, interne Verlinkung und die Auswahl von Handlungsaufforderungen.

URL-Konzept und Weiterleitungen richtig planen

Weiterleitungen verbinden die alte und die neue Website. Sie sorgen dafür, dass alte Lesezeichen, externe Verweise und Suchergebnisse nicht ins Leere führen. Die fachlich passende Regel für eine dauerhaft verschobene Seite ist eine permanente Weiterleitung. Beim HTTP-Statuscode 301 wird die Ressource dauerhaft an eine neue Adresse verlagert. Der Statuscode 308 erfüllt ebenfalls eine dauerhafte Weiterleitungsfunktion und bewahrt zusätzlich die HTTP-Methode. Welche Variante technisch verwendet wird, hängt von Server, Anwendung und Anwendungsfall ab.

Für einen Relaunch sollte jede alte URL einer der folgenden Kategorien zugeordnet werden:

Vermeide Weiterleitungsketten. Eine alte Adresse sollte möglichst direkt zur endgültigen Zieladresse führen. Ketten wie alte URL, Zwischenadresse, zweite Zwischenadresse und Ziel erhöhen die Fehleranfälligkeit und erschweren die Analyse. Ebenso problematisch sind Weiterleitungsschleifen, bei denen zwei Regeln gegenseitig aufeinander verweisen.

Weiterleitungen sollten auf Protokoll, Hostnamen, Pfade und gegebenenfalls Sprachvarianten geprüft werden. HTTP und HTTPS müssen konsistent behandelt werden. Dasselbe gilt für Varianten mit und ohne Subdomain. Die gewünschte Hauptvariante sollte feststehen, bevor Regeln erstellt werden.

Regeln dokumentieren und testen

Die Weiterleitungstabelle sollte alte URL, Ziel-URL, Regeltyp, Begründung, Prüfdatum und verantwortliche Rolle enthalten. Teste nicht nur einige bekannte Seiten, sondern alle Einträge. Zusätzlich sind Varianten mit abschließendem Schrägstrich, Groß- und Kleinschreibung, URL-kodierten Zeichen und nicht mehr vorhandenen Dateien zu prüfen.

Eine Weiterleitung ersetzt keine interne Linkpflege. Navigation, Breadcrumbs, XML-Sitemap, hreflang-Angaben bei mehrsprachigen Angeboten und strukturierte Daten müssen auf die neuen Adressen zeigen. Alte interne Links können zwar funktionieren, erzeugen aber unnötige Umwege und erschweren die Wartung.

Technische Umsetzung in einer getrennten Testumgebung

Die neue Website sollte zunächst in einer geschützten Testumgebung aufgebaut werden. Diese Umgebung darf nicht versehentlich für Suchmaschinen oder die Öffentlichkeit erreichbar sein. Zugangsschutz, eine passende Serverkonfiguration und eine klare Kennzeichnung verhindern, dass Testinhalte mit der produktiven Website verwechselt werden.

Übertrage Inhalte, Medien und Konfigurationen kontrolliert. Nach einem Import müssen Zeichencodierung, Dateinamen, Bildgrößen, interne Verweise und Berechtigungen geprüft werden. Ein Datenbankexport allein garantiert keine vollständige Migration, wenn Medien in separaten Verzeichnissen liegen oder Erweiterungen eigene Tabellen verwenden.

Für die Sicherheitsprüfung gehören unter anderem diese Punkte auf die Checkliste:

• aktuelle und unterstützte Versionen der zentralen Software
• individuelle Konten statt gemeinsam genutzter Zugangsdaten
• begrenzte Administrationsrechte nach dem Prinzip der geringsten Berechtigung
• geschützte Administrationsbereiche und sichere Anmeldung
• verschlüsselte Übertragung für alle relevanten Bereiche
• deaktivierte Testkonten, Beispielinhalte und nicht benötigte Erweiterungen
• geprüfte Sicherungen und ein dokumentierter Wiederherstellungsweg

Datenschutzanforderungen sollten bereits in der Konzeption berücksichtigt werden. Prüfe, welche personenbezogenen Daten Formulare, Protokolle, Analysewerkzeuge oder eingebundene Dienste verarbeiten. Datenschutzhinweise, Einwilligungsmechanismen und Löschfristen müssen zum tatsächlichen technischen Verhalten passen. Eine nachträgliche Anpassung entdeckt häufig nicht alle Datenflüsse.

Testplan: Inhalt, Technik, Zugänglichkeit und Betrieb

Ein Relaunch ist erst startbereit, wenn die wichtigsten Nutzungsszenarien geprüft wurden. Der Testplan sollte konkrete Fälle enthalten und nicht nur die Aussage „Website getestet“. Für jede Prüfung werden erwartetes Ergebnis, tatsächliches Ergebnis, Status und gegebenenfalls ein Fehlernachweis dokumentiert.

Funktionale und redaktionelle Tests

• Navigation, Suchfunktion und Breadcrumbs auf zentralen Seitentypen
• Formulare mit gültigen und ungültigen Eingaben
• Versand, Empfang und Darstellung von Benachrichtigungen
• Downloads, Medien, Tabellen und eingebettete Inhalte
• Login, Passwortänderung und rollenabhängige Bereiche
• Darstellung von Überschriften, Listen, Links und Fehlermeldungen

Technische Prüfungen

• Statuscodes und Weiterleitungen für alte und neue URLs
• keine unbeabsichtigten Weiterleitungsketten oder Schleifen
• keine internen Links auf nicht vorhandene Ziele
• korrekte XML-Sitemap und robots.txt-Konfiguration
• funktionierendes HTTPS sowie konsistente Host- und Protokollvarianten
• angemessene Darstellung auf kleinen und großen Bildschirmen
• vertretbare Ladezeiten unter realistischen Bedingungen

Die Anforderungen an Barrierearmut sollten nicht auf einen automatischen Prüfbericht reduziert werden. Tastaturbedienung, sichtbarer Fokus, ausreichende Kontraste, verständliche Fehlermeldungen, sinnvolle Alternativtexte und eine nachvollziehbare Überschriftenstruktur benötigen zusätzlich eine manuelle Prüfung. Automatische Werkzeuge können Hinweise liefern, ersetzen aber keine Nutzung mit unterschiedlichen Eingabemethoden.

Einen realistischen Zeitplan für den Relaunch erstellen

Der Zeitplan sollte Abhängigkeiten sichtbar machen. Inhalte können erst endgültig getestet werden, wenn die Seitentypen feststehen. Weiterleitungen benötigen die bestätigte URL-Struktur. Ein Starttermin ohne Puffer für Fehlerbehebung erhöht das Risiko, dass offene Aufgaben in den Produktivbetrieb gelangen.

Plane einen verbindlichen Abnahmepunkt für Inhalte und einen weiteren für Technik ein. So wird vermieden, dass redaktionelle Änderungen kurz vor dem Start unkontrolliert in bereits geprüfte Seiten einfließen. Änderungen nach der technischen Abnahme müssen erneut bewertet werden, wenn sie URLs, Formulare, Skripte oder Seitentemplates betreffen.

Ein Notfallplan gehört ebenfalls in den Zeitplan. Er sollte festlegen, wer die Schaltung stoppen darf, wie eine vorherige Version wiederhergestellt wird und welche Informationen bei einem Fehler gesammelt werden. Die Rückkehr zur alten Version ist nicht in jedem System ohne Datenverlust möglich. Deshalb muss geklärt werden, ob während des Startfensters neue Formulareingaben, Bestellungen oder redaktionelle Änderungen eingehen.

Der Go-live als kontrollierter Betriebswechsel

Der Start sollte in einem vorher festgelegten Zeitfenster erfolgen, in dem die zuständigen Rollen erreichbar sind. Vor der Umschaltung werden die letzte Sicherung, die Konfiguration und die Weiterleitungstabelle kontrolliert. Nach der Veröffentlichung beginnt keine Wartephase, sondern eine aktive Überwachung.

Unmittelbar nach dem Start sind besonders wichtige Seiten und Funktionen manuell aufzurufen. Dazu gehören Startseite, Hauptnavigation, Kontaktwege, Login-Bereiche, Downloads und häufig genutzte Inhalte. Parallel sollten Serverprotokolle und Überwachungsdaten auf ungewöhnliche Fehler, viele Anfragen an nicht vorhandene Adressen oder Probleme bei Formularen geprüft werden.

Beachte, dass Zwischenspeicher die Anzeige alter Inhalte verlängern können. Prüfe deshalb die Website aus unterschiedlichen Sitzungen und auf mehreren Geräten. Cache-Leerungen sollten gezielt erfolgen, damit sie nicht als Ersatz für eine saubere Konfiguration dienen.

Nach dem Start werden die wichtigsten alten URLs erneut getestet. Zusätzlich sollte die neue Adresse in den relevanten technischen Werkzeugen zur Überwachung eingetragen werden. Änderungen an Crawling-Regeln, Sitemaps oder Zugriffsrechten brauchen eine besondere Kontrolle, weil eine unbeabsichtigte Sperre die Auffindbarkeit ganzer Bereiche beeinflussen kann.

Die Nachkontrolle nach dem Relaunch

In den ersten Tagen und Wochen nach dem Start sollten Fehler systematisch gesammelt und nach Schweregrad sortiert werden. Ein nicht funktionierendes Kontaktformular ist dringlicher als eine kleinere Abweichung im Abstand eines Gestaltungselements. Die Priorisierung sollte sich an Nutzung, Datenverlust, Sicherheit und fachlicher Bedeutung orientieren.

Wichtige Beobachtungspunkte sind:

• nicht erreichbare Seiten und unerwartete Statuscodes
• Weiterleitungen ohne passendes Ziel
• Formularfehler und ausbleibende Benachrichtigungen
• fehlende oder falsch dargestellte Medien
• ungewöhnliche Serverfehler und erhöhte Last
• Probleme bei mobilen Ansichten oder Tastaturbedienung
• falsch gesetzte Indexierungs- oder Zugriffssperren
• veraltete interne Links und fehlerhafte Downloads

Dokumentiere nach dem Abschluss, welche Entscheidungen getroffen wurden, wie Weiterleitungen funktionieren, wo Sicherungen liegen und wer Änderungen durchführen darf. Diese Unterlagen erleichtern spätere Wartung, Migrationen und die Einarbeitung neuer Beteiligter. Ein Relaunch ist kein Endpunkt, sondern der Beginn eines geregelten Betriebs mit regelmäßigen Inhalts-, Sicherheits- und Funktionstests.

FAQ zum geplanten Website-Relaunch

Wie früh sollte die URL-Liste erstellt werden?

Die URL-Liste gehört in die Bestandsaufnahme und sollte vor der finalen Konzeption beginnen. Je früher alte Adressen, Downloads und Sprachvarianten bekannt sind, desto verlässlicher lässt sich die neue Struktur planen. Die Liste wird während des Projekts fortgeführt, weil neue oder zusammengeführte Inhalte zusätzliche Regeln erzeugen können.

Wann ist eine Weiterleitung besser als eine Fehlerseite?

Eine Weiterleitung ist sinnvoll, wenn eine alte Adresse einen inhaltlich passenden neuen Zielort besitzt. Gibt es keinen Ersatz, sollte keine thematisch fremde Seite als Ziel verwendet werden. In diesem Fall ist eine bewusst gestaltete Fehlerbehandlung meist nachvollziehbarer. Die konkrete technische Antwort hängt vom Inhalt, vom System und vom gewünschten Verhalten ab.

Kann eine Website ohne Änderung der URLs neu gestaltet werden?

Ja, ein Relaunch kann auf die Gestaltung, Templates oder technische Plattform beschränkt werden. Auch dann bleiben Tests für interne Links, Formulare, Medien, Statuscodes, Zugriffsschutz und Sicherungen erforderlich. Das Risiko einer URL-Migration entfällt, die übrigen Betriebsrisiken bleiben bestehen.

Welche Sicherung wird vor dem Start benötigt?

Benötigt wird eine überprüfte Sicherung aller für den Betrieb notwendigen Bestandteile. Dazu gehören je nach System Datenbank, Mediendateien, Konfigurationen und besondere Serverregeln. Entscheidend ist nicht nur die Erstellung, sondern auch ein nachvollziehbarer Wiederherstellungsweg. Zugangsdaten und Sicherungen müssen geschützt aufbewahrt werden.

Wann gilt der Relaunch als abgeschlossen?

Der Relaunch ist abgeschlossen, wenn die vereinbarten Ziele geprüft, kritische Fehler behoben, Weiterleitungen kontrolliert, Sicherungen dokumentiert und Zuständigkeiten für den laufenden Betrieb festgelegt sind. Ein einzelner störungsfreier Aufruf reicht nicht als Nachweis. Die Nachkontrolle muss auch reale Nutzungsszenarien und technische Überwachung einbeziehen.