Website-Relaunch oder Neubau: Was lohnt sich?

Zurück zum Journal / Web & Design

Von KORBI · 27. Oktober 2026 · 2 Min. Lesezeit

Ein visuelles Redesign, ein technisches Refactoring und ein Neubau lösen unterschiedliche Probleme. Prüfen Sie zuerst den bestehenden Auftritt.

«Redesign» und «Neubau» werden oft gleich verwendet. Ein Redesign verändert Gestaltung und Nutzerführung. Ein Refactoring verändert die Softwarestruktur, ohne das Verhalten grundsätzlich ersetzen zu müssen. Ein Neubau ersetzt grosse Teile des bestehenden Systems. Ein Projekt kann mehrere dieser Arbeiten brauchen, doch ohne Diagnose sollten sie nicht in denselben Umfang gepackt werden.

Zuerst den bestehenden Auftritt prüfen

Halten Sie fest, welche Seiten nützliche Anfragen unterstützen, welche Kundenwege funktionieren und wo Mitarbeitende auf manuelle Umwege angewiesen sind. Prüfen Sie Inhaltspflege, Seitentypen, Performance, Zugänglichkeit, Mobile-Verhalten, Sicherheitsupdates und – sofern verlässliche Daten vorhanden sind – Suchzugriffe. Ziel ist keine lange Dokumentation, sondern eine begründete Liste: behalten, verbessern, entfernen oder ersetzen.

Wann ein Redesign genügt

Wenn das System stabil ist, Inhalte gut gepflegt werden können und vor allem Verständlichkeit oder Nutzerführung fehlen, kann ein Redesign reichen. Behalten Sie nützliche URL-Pfade und Inhalte, wo es sinnvoll ist. Verbessern Sie Informationsarchitektur, Typografie, Handlungsaufforderungen und Mobile-Layouts und testen Sie die wichtigen Kundenwege. Ein neuer Look sollte keine weiterhin hilfreichen Seiten verschwinden lassen.

Wann Refactoring oder Neubau sinnvoll wird

Ein Refactoring kann passen, wenn die Architektur kleine Änderungen unnötig langsam oder riskant macht, die zentralen Daten und Geschäftsregeln aber noch stimmen. Ein Neubau kann sinnvoll sein, wenn die bestehende Plattform zentrale Abläufe nicht sicher oder wirtschaftlich unterstützt oder nicht mehr verantwortbar betrieben werden kann. Entscheiden Sie anhand dokumentierter Anforderungen und Risiken, nicht allein anhand eines neuen Frameworks.

  • Refactoring, wenn Wartbarkeit das Haupthindernis ist und die Grundfunktionen noch passen.
  • Neubau, wenn wichtige Anforderungen auf der heutigen Grundlage nicht verantwortbar erfüllt werden können.
  • Weiterbetrieb, wenn Nutzen und Risiko eines Ersatzes nicht überzeugen.

URL-Migration gehört zum Projekt

Bei einem Wechsel können sich URLs, Inhalte, interne Links, Metadaten und Sprachbeziehungen ändern. Ordnen Sie jede alte URL einem möglichst passenden Ziel zu, behalten Sie gültige Pfade und leiten Sie nur wirklich verschobene Seiten dauerhaft weiter. Aktualisieren Sie interne Links, Canonicals, Sitemap und Sprachalternativen. Google empfiehlt, Weiterleitungen zu planen und die neuen URLs nach dem Wechsel zu prüfen; ein neues Design garantiert keine automatische Übernahme der Auffindbarkeit.[1][2]

Bestehende Abhängigkeiten schützen

Dokumentieren Sie Formulare, Kundendaten, Produktangaben, Zahlungswege, CRM-Verbindungen, Rollen und Drittanbieter. Legen Sie fest, wer migriert, wie realistische Tests aussehen und was im Fehlerfall passiert. Schalten Sie ein funktionierendes System erst ab, wenn das Ersatzsystem die vereinbarten Prüfungen bestanden hat.

Eine praktische Entscheidungsfolge

  • Problem und vorhandene Belege benennen.
  • Visuelle, redaktionelle, technische und operative Ursachen trennen.
  • Die kleinste Intervention wählen, die das blockierende Problem löst.
  • Migration, Inhalte und Betreuung neben der Entwicklung schätzen.
  • Abnahmetests und Rückfallplan vor dem Start vereinbaren.

Quellen und weiterführende Informationen

  1. Site Moves and Migrations — Google Search Central
  2. How to Specify a Canonical URL — Google Search Central

Weiterlesen