Wissen / Website

Website erneuern: Relaunch oder gezielt verbessern?

Kurz gesagt: Ein Website-Relaunch lohnt sich, wenn Struktur, Technik oder Inhalte grundlegende Ziele behindern und einzelne Korrekturen nicht ausreichen. Funktioniert die Basis, kann gezielte Weiterentwicklung weniger Aufwand und Risiko bedeuten. Prüfen Sie deshalb zuerst, was Besucher brauchen, was heute nicht funktioniert und welche Seiten, URLs und Funktionen erhalten bleiben sollen.

Veröffentlicht am / Aktualisiert am / Redaktion: Ruhrstack / 11 Minuten Lesezeit

01 / ENTSCHEIDUNG

Was soll Ihre Website besser leisten?

Klarere Leistungen, einfachere Anfragen oder weniger Pflegeaufwand: Das gewünschte Ergebnis bestimmt den Umfang.

Die Aussage „Unsere Website ist alt“ klingt eindeutig, enthält aber mehrere mögliche Befunde. Vielleicht wirkt die Gestaltung nicht mehr passend. Vielleicht finden Interessierte wichtige Leistungen nicht. Vielleicht ist das Redaktionssystem schwer zu pflegen, die mobile Bedienung fehlerhaft oder die technische Grundlage nicht mehr unterstützt. Jeder dieser Befunde verlangt eine andere Reaktion. Ein neues Erscheinungsbild kann ein Orientierungsproblem nicht allein lösen. Ein kompletter technischer Neubau ist umgekehrt unnötig, wenn nur wenige Inhalte und Nutzerwege überarbeitet werden müssen.

Deshalb beginnt die Entscheidung nicht mit einer Startseitenidee, sondern mit dem gewünschten Ergebnis. Soll das Angebot verständlicher werden, sollen Anfragen besser vorbereitet sein, muss ein neues Leistungsfeld aufgenommen werden oder verursacht der Betrieb zu viel Aufwand? Erst wenn Ziel und Hindernis benannt sind, lässt sich prüfen, ob die bestehende Seite das Ziel mit vertretbarem Aufwand erreichen kann.

Weiterentwicklung arbeitet mit einem tragfähigen Bestand. Ein Relaunch ersetzt größere Teile des Systems und muss deshalb Inhalt, Technik, Auffindbarkeit und Betrieb neu zusammenführen. Keine der beiden Varianten ist grundsätzlich hochwertiger. Maßgeblich sind Wirkung, Folgekosten, Risiko und die Frage, wie gut die Lösung nach der Veröffentlichung gepflegt werden kann.

02 / BESTAND

Den Bestand prüfen und gute Lösungen erhalten.

Angebot, Nutzung, Technik und Betrieb zeigen gemeinsam, wo Änderungen nötig sind.

Unternehmen und Angebot
Welche Leistungen, Zielgruppen und Abläufe stimmen noch? Welche Aussagen sind überholt oder fehlen? Was soll eine Anfrage enthalten, damit das erste Gespräch sinnvoll beginnen kann?
Nutzung und Inhalt
Welche Seiten werden tatsächlich gebraucht, wo brechen Wege ab und welche Rückfragen entstehen immer wieder? Bestehende Texte, Downloads, Formulare und Medien werden nach Nutzen statt nach Gewohnheit bewertet.
Technik und Gestaltung
CMS, Code, Komponenten, responsive Zustände, Barrierefreiheit, Ladeverhalten und Integrationen werden getrennt betrachtet. Ein lokaler Fehler ist etwas anderes als eine Architektur, die jede Änderung erschwert.
Auffindbarkeit und Betrieb
Indexierte URLs, interne Links, Weiterleitungen, Suchanfragen, Zugänge, Hosting, Backups und Zuständigkeiten gehören zum Bestand. Sie wirken weiter, auch wenn die neue Oberfläche völlig anders aussieht.

Messwerte helfen, ersetzen aber keine Einordnung. Ein Performancebericht zeigt technische Symptome. Suchdaten zeigen, über welche Anfragen und Seiten Besuche entstehen. Gespräche mit Mitarbeitenden zeigen, wo Pflege oder Übergaben scheitern. Erst die Verbindung dieser Hinweise macht sichtbar, ob ein Problem punktuell oder systemisch ist.

Die Bestandsaufnahme schützt auch das Gute. Wiedererkennbare Gestaltungselemente, klare Texte, etablierte URLs oder ein funktionierender Kontaktweg müssen nicht verschwinden, nur weil an anderer Stelle neu gebaut wird. Ein Relaunch ohne Erhaltungsliste bewertet häufig nur Mängel und zerstört dabei unbemerkt funktionierende Teile.

03 / WEITERENTWICKLUNG

Wann gezielte Verbesserungen ausreichen.

Eine unklare Leistungsseite oder ein umständlicher Kontaktweg lassen sich oft im bestehenden System verbessern.

Für eine Weiterentwicklung spricht, wenn die Informationsarchitektur im Kern stimmt, wichtige URLs erhalten werden können und das System Änderungen ohne dauernde Umwege zulässt. Dann lassen sich beispielsweise eine Leistungsseite neu ordnen, Navigation und Kontaktweg vereinfachen, die mobile Typografie überarbeiten oder technische Engpässe gezielt beheben. Die Wirkung kann früher geprüft werden, weil nicht alle Ebenen gleichzeitig wechseln.

Auch gestalterische Veränderungen müssen nicht automatisch ein vollständiger Relaunch sein. Ein vorhandenes Raster kann um bessere Typografieregeln, klarere Komponenten und zugängliche Zustände ergänzt werden. Entscheidend ist, ob die alten Regeln sauber erweitert werden können. Werden dagegen auf jeder Seite Ausnahmen benötigt, ist die scheinbar kleine Optimierung langfristig möglicherweise teurer als ein geordnetes neues System.

Ein überschaubarer Auftrag benennt das Problem und das erwartete Ergebnis. Welche Besucher sollen besser zurechtkommen? Welche Seiten ändern sich? Woran erkennen Sie den Fortschritt? „Die drei zentralen Leistungen sollen auf dem Smartphone verständlich vergleichbar und direkt erreichbar sein“ ist eine konkrete Aufgabe. Daran lassen sich Konzept, Umsetzung und Abnahme ausrichten.

Schrittweise Verbesserungen lassen sich einzeln beurteilen. Nach einer Änderung können Sie Nutzung, Rückfragen und technische Werte beobachten und den nächsten Schritt daran ausrichten. Das beseitigt nicht jedes Risiko. Es macht aber leichter erkennbar, welche Maßnahme hilft und wo weitere Arbeit nötig ist.

04 / RELAUNCH

Wann ein Website-Relaunch sinnvoll ist.

Wenn Seitenstruktur, Inhalte und Technik gemeinsam geändert werden müssen, kann ein geplanter Neuaufbau sinnvoller sein.

Ein Relaunch wird plausibel, wenn Angebot und Seitenstruktur nicht mehr zusammenpassen, zentrale Nutzerwege über viele Ausnahmen führen oder das technische System notwendige Änderungen dauerhaft blockiert. Weitere Gründe können eine nicht mehr unterstützte Laufzeit, unkontrollierbare Erweiterungen, fehlende responsive Grundlagen oder eine Gestaltung sein, die nur mit immer neuen Sonderregeln fortgeführt werden kann.

Mehrere Probleme müssen nicht automatisch einen Komplettneubau auslösen. Sie zeigen zunächst, dass Abhängigkeiten gemeinsam geplant werden sollten. Wenn eine neue Navigation andere Inhalte verlangt, diese Inhalte neue Seitentypen benötigen und das bestehende CMS solche Typen nicht wartbar abbilden kann, wäre eine reine Oberflächenkorrektur zu kurz. Dann verbindet der Relaunch Strategie, Inhalt, Gestaltung und Entwicklung in einem neuen belastbaren System.

Der Relaunch ist trotzdem kein Freibrief für Veränderung. Bewährte Aussagen, URLs, Markenmerkmale und Funktionen werden bewusst übernommen. Neue Technik wird nach tatsächlichem Bearbeitungsbedarf und Funktionsumfang gewählt. WordPress kann passen, ist aber ebenso wenig Automatismus wie eine statische oder individuelle Umsetzung. Der Artikel zu den Grenzen von Website-Baukästen hilft, technische Bequemlichkeit und spätere Kontrolle voneinander zu trennen.

Ein realistischer Umfang berücksichtigt zudem Inhalte. Fehlende Fotos, unklare Leistungsbeschreibungen oder ungeklärte Freigaben verschwinden nicht durch Entwicklung. Ein Relaunchplan benennt deshalb früh, wer Texte, Medien, rechtliche Prüfung und fachliche Abnahme liefert.

05 / MIGRATION

Bestehende URLs und Suchzugriffe beim Relaunch schützen.

Erhaltene Seiten, passende Weiterleitungen und korrekte Links verhindern vermeidbare Fehler beim Wechsel.

Google unterscheidet zwischen Infrastrukturwechseln ohne sichtbare URL-Änderung und Umzügen, bei denen sich Domain oder Pfade ändern. Für einen Relaunch ist diese Trennung praktisch: Bleiben URLs gleich, konzentriert sich die technische Umschaltung auf Erreichbarkeit und korrekte Auslieferung. Ändern sich URLs, braucht es eine Zuordnung von jeder relevanten alten Adresse zu einem fachlich passenden neuen Ziel.

Permanente Weiterleitungen teilen Browsern und Suchsystemen mit, dass ein Inhalt dauerhaft umgezogen ist. Eine Sammelweiterleitung aller alten Seiten auf die Startseite ist kein Ersatz für diese Zuordnung. Entfällt ein Inhalt ohne sinnvollen Nachfolger, ist ein echter Fehlerstatus ehrlicher als ein unpassendes Ziel. Canonicals, interne Links, Sitemaps und Navigationspfade müssen anschließend auf die neuen kanonischen Adressen zeigen.

Suchsichtbarkeit lässt sich bei einem Relaunch nicht garantieren. Google weist selbst auf mögliche vorübergehende Schwankungen während erneuter Verarbeitung hin. Sorgfältige URL-Zuordnung, erreichbare Inhalte, serverseitige Weiterleitungen und Überwachung reduzieren vermeidbare Fehler, machen aber aus einem Systemwechsel keine risikofreie Sofortmaßnahme.

  1. URL-Bestand exportieren. Navigation, Sitemap, Suchdaten, Backlinks, Downloads und Serverprotokolle können unterschiedliche Adressen sichtbar machen.
  2. Jede Adresse klassifizieren. Erhalten, inhaltlich zusammenführen, passend weiterleiten oder bewusst mit echtem Fehlerstatus entfernen.
  3. Neue Signale abstimmen. Canonical, interne Links, strukturierte Daten, Sitemap und Social-Metadaten verwenden dieselbe Zieladresse.
  4. Nach Veröffentlichung beobachten. Weiterleitungen, Fehler, Indexierung, Formulare und zentrale Einstiegsseiten werden wiederholt geprüft.

06 / PRÜFUNG

Was vor und nach der Veröffentlichung geprüft wird.

Kontaktwege, mobile Bedienung, Weiterleitungen und ein möglicher Rückweg gehören zur Vorbereitung.

Vor der Umschaltung werden reale Seiten, Funktionen und Randfälle geprüft. Dazu gehören Navigation, Formulare, Downloads, interne und externe Links, Fehlerseiten, Tastaturbedienung, Fokus, Kontraste, Zoom und verschiedene Bildschirmgrößen. WCAG 2.2 bietet dafür überprüfbare Erfolgskriterien, ersetzt aber keine vollständige Prüfung des konkreten Angebots.

Performance wird mit Labor- und Felddaten betrachtet. Die Core Web Vitals beschreiben Ladeerlebnis, Reaktionsfähigkeit und visuelle Stabilität aus Nutzersicht, sind aber nicht der einzige Qualitätsmaßstab. Serverantworten, Bildgrößen, Schriftladen und JavaScript-Ausführung werden dort optimiert, wo sie den tatsächlichen Seitenaufbau bremsen. Eine gute Punktzahl allein beweist weder verständliche Inhalte noch einen verlässlichen Kontaktweg.

Zur Freigabe gehören außerdem Betrieb und Rückweg. Wer kann DNS oder Hosting ändern, wo liegt die letzte funktionsfähige Sicherung, wie werden Fehler gemeldet und wer entscheidet über eine Rückschaltung? Ein Zeitfenster ohne erreichbare Verantwortliche ist kein sinnvoller Launchplan. Nach der Umschaltung folgt eine definierte Nachkontrolle, weil Zertifikate, Caches, Formulare oder Weiterleitungen erst unter der echten Adresse vollständig sichtbar werden.

Der ausführliche Unterschied zwischen Gestaltung und funktionierender Veröffentlichung steht im Beitrag Warum ein Entwurf noch keine fertige Website ist. Er ergänzt die Relaunchentscheidung um technische und organisatorische Abnahmepunkte.

07 / RUHRSTACK

So prüft Ruhrstack, welcher Umfang zu Ihnen passt.

Wir betrachten Ihre Ziele und die vorhandene Website, bevor wir Optimierung, Teilumbau oder Relaunch empfehlen.

Auf der Leistungsseite Website erstellen und weiterentwickeln beschreibt Ruhrstack einen Ablauf, der Ziele, Inhalte, Nutzerwege, Technik und vorhandene Systeme zuerst ordnet. Ein Relaunch wird dort ausdrücklich nicht als automatische Standardlösung dargestellt. Wenn sich die vorhandene Basis mit überschaubarem Aufwand sinnvoll verbessern lässt, bleibt Optimierung eine echte Alternative.

Ist ein Relaunch begründet, werden Struktur, Gestaltung und Entwicklung als ein gemeinsames System betrachtet. Die technische Wahl folgt Bearbeitungsbedarf, Funktionen und Wartbarkeit. Vor der Veröffentlichung gehören Browser-, Geräte-, Accessibility-, Performance- und Linkprüfungen zum beschriebenen Qualitätsumfang. Hosting, Updates, Backups und Zuständigkeiten werden nicht erst nach dem Launch bedacht.

Für die erste Einordnung brauchen Sie kein fertiges Lastenheft. Schicken Sie uns Ihre URL und beschreiben Sie kurz, was heute stört oder künftig möglich sein soll. Daraus klären wir die nächsten Prüfschritte. Ob eine Weiterentwicklung, ein Teilumbau oder ein Relaunch passt, entscheiden wir anhand der vorhandenen Website.

08 / CHECKLISTE

Neun Fragen für Ihre Relaunch-Entscheidung.

Mit diesen Antworten lassen sich Prioritäten, Zuständigkeiten und ein passender Projektumfang klären.

  1. Welches geschäftliche oder kommunikative Ziel erreicht die Website heute nicht?
  2. Liegt die Ursache bei Inhalt, Struktur, Gestaltung, Technik, Betrieb oder mehreren verbundenen Ebenen?
  3. Welche Seiten, Aussagen, Funktionen und URLs funktionieren nachweislich gut und sollen erhalten bleiben?
  4. Kann das aktuelle System die notwendigen Änderungen wartbar abbilden, ohne für jede Seite neue Ausnahmen zu erzeugen?
  5. Welche Personen bearbeiten Inhalte, und welche Bedienmöglichkeiten brauchen sie wirklich?
  6. Welche Integrationen, Formulare, Domains, Postfächer oder externen Dienste hängen an der Website?
  7. Welche Suchzugriffe und bestehenden Verlinkungen dürfen bei geänderten URLs nicht verloren gehen?
  8. Wer liefert und prüft Texte, Medien, rechtliche Angaben und fachliche Freigaben?
  9. Wer übernimmt nach dem Launch Updates, Backups, Monitoring, Inhalte und spätere Änderungen?

Fehlen mehrere Antworten, ist das kein Grund, das Projekt zu verschieben. Es ist ein Hinweis, die Einordnung als eigenen ersten Schritt zu behandeln. Dadurch wird aus einer unbestimmten Relaunchidee ein überprüfbarer Auftrag.

09 / KURZANTWORTEN

Häufige Fragen zu Relaunch, URLs und CMS.

Klare Grenzen für Umfang, Suchsichtbarkeit und technische Entscheidung.

Wann reicht eine Optimierung statt eines Relaunches?

Wenn Struktur und Technik im Kern tragfähig sind, Probleme klar begrenzt werden können und Änderungen ohne dauernde Sonderlösungen möglich bleiben. Eine Bestandsaufnahme sollte das belegen. Das sichtbare Alter oder ein einzelner schlechter Messwert reichen als Entscheidung nicht aus.

Müssen bei einem Relaunch alle URLs geändert werden?

Nein. Verständliche, etablierte und weiterhin passende URLs können erhalten bleiben. Wenn Adressen fachlich geändert werden müssen, braucht jede relevante alte URL ein passendes Ziel oder einen bewussten echten Fehlerstatus. Interne Links, Canonicals und Sitemaps werden dazu synchronisiert.

Kann ein Relaunch bestehende Rankings garantieren?

Nein. Suchsysteme bewerten die neue Auslieferung und Inhalte erneut, weshalb Schwankungen möglich sind. Saubere URL-Zuordnung, permanente Weiterleitungen, erreichbare Inhalte und Überwachung reduzieren vermeidbare Verluste, versprechen aber keine feste Position.

Muss für einen Relaunch immer das CMS wechseln?

Nein. Ein Wechsel ist nur sinnvoll, wenn das vorhandene System Anforderungen an Bearbeitung, Funktionen, Wartbarkeit oder Betrieb nicht mehr angemessen erfüllt. Gestaltung und Struktur können sich grundlegend ändern, während ein geeignetes CMS bestehen bleibt.

10 / QUELLEN

Quellen und redaktioneller Stand.

Offizielle Dokumentation zu Website-Umzügen, Weiterleitungen, Canonicals, Sitemaps, Nutzererlebnis und Barrierefreiheit. Der Artikel wurde am 10. August 2026 veröffentlicht.

  1. Google Search Central: Site Moves and Migrations mit URL-Änderungen, abgerufen am 2. September 2026.
  2. Google Search Central: Changing Your Web Hosting and SEO, Stand 10. Dezember 2025.
  3. Google Search Central: Redirects and Google Search, Stand 14. April 2026.
  4. Google Search Central: Canonicalization, abgerufen am 2. September 2026.
  5. Google Search Central: Build and Submit a Sitemap, abgerufen am 2. September 2026.
  6. web.dev: Web Vitals, abgerufen am 2. September 2026.
  7. World Wide Web Consortium: Web Content Accessibility Guidelines 2.2, Recommendation vom 12. Dezember 2024.

Redaktioneller Hinweis: Dieser Beitrag dient der allgemeinen Information und ersetzt keine Einzelfallprüfung. Trotz sorgfältiger Recherche wird keine Gewähr für Vollständigkeit und fortdauernde Aktualität übernommen. Eine Haftung nach zwingenden gesetzlichen Vorschriften bleibt unberührt. Redaktionelle Einordnung.

Braucht Ihre Website einen Relaunch?

Senden Sie uns Ihre URL und zwei oder drei Sätze zu Ihrem Vorhaben. Wir klären gemeinsam, was verbessert werden soll und ob dafür ein Neuaufbau nötig ist.

Relaunch oder Optimierung besprechen