Die meisten Website-Relaunches scheitern nicht am Design. Sie scheitern an Entscheidungen, die zu spät oder gar nicht getroffen wurden. Ein Relaunch ist keine Designübung. Er ist ein strukturiertes Projekt, in dem technische, inhaltliche und strategische Weichenstellungen getroffen werden, die sich über Jahre auswirken. Wer das unterschätzt, bekommt eine neue Website, die dieselben Probleme hat wie die alte, nur mit frischerer Optik. Dieser Artikel beschreibt die sechs Entscheidungen, die vor dem Launch feststehen müssen, damit ein Relaunch wirkt. Er richtet sich an alle, die gerade einen Relaunch planen, evaluieren oder begleiten.

Warum Relaunch-Projekte so oft scheitern

Das Scheitern passiert selten in einer großen Katastrophe. Es passiert in einer Reihe kleiner Versäumnisse, die sich über die Projektlaufzeit aufschichten.

Das CMS wird gewählt, ohne dass der Redaktionsprozess besprochen wurde. Die Zielgruppe wird nicht neu definiert, obwohl sie sich in den letzten drei Jahren verschoben hat. Das Tracking wird als letztes eingerichtet, weil alle nach dem Live-Gang erschöpft sind und „das noch schnell erledigen" wollen. Und die alten URLs werden auf neue weitergeleitet, aber das Konzept dafür wurde nie gebaut, weil es niemand im Briefing hatte.

Was danach folgt, ist bekannt: Rankings brechen ein, weil Redirects fehlen oder falsch gesetzt wurden. Die Redaktion kann die neuen Seiten nicht selbst pflegen, weil das CMS nicht zu ihren Prozessen passt. Die Geschäftsführung fragt drei Monate nach Launch, warum die Anfragen nicht gestiegen sind. Und das Team hat keine Antwort, weil kein Tracking eingerichtet wurde.

Hinter diesen Problemen steckt in den meisten Fällen keine schlechte Ausführung. Es steckt dahinter, dass wichtige Entscheidungen nicht im richtigen Moment getroffen wurden. Ein Relaunch ist ein Projekt mit Abhängigkeiten. Wer Entscheidung B trifft, bevor Entscheidung A klar ist, baut auf einem instabilen Fundament.

Die sechs Entscheidungen vor dem Launch

Erstens: Ziele und Erfolgsmessung

Eine neue Website ist kein Selbstzweck. Sie soll etwas bewirken: Leads generieren, Vertrauen aufbauen, Bewerbungen anziehen, Produkte verkaufen oder die Marke in einem neuen Markt positionieren.

Wer diese Ziele nicht vor dem Projekt definiert, kann hinterher nicht messen, ob der Relaunch gewirkt hat. Und wer nicht messen kann, ob etwas gewirkt hat, kann auch nicht begründen, ob ein Nachfolge-Investment sinnvoll ist.

Zum Ziel gehört die Erfolgsmessung. Welche KPIs werden getrackt, über welches Tool, und wer wertet sie aus? Das klingt banal. In der Praxis fehlt es in einem erschreckend hohen Anteil der Projekte.

Zweitens: CMS-Auswahl

Das CMS ist nicht nur eine technische Entscheidung. Es bestimmt, wie das Team die Website langfristig pflegen kann. Ein System, das Entwickler braucht, um Inhalte zu ändern, ist für die meisten Marketingteams ein langfristiges Problem. Ein System, das zu flexibel ist, wird ohne klare Redaktionsprozesse zur Baustelle.

Die Wahl zwischen einem klassischen CMS wie WordPress, einem Headless-System wie Storyblok oder einem Visual-Editor-Tool wie Webflow hängt von drei Faktoren ab: Wie sieht die Teamstruktur aus, welche technischen Anforderungen hat die Website und wie skaliert die Lösung, wenn das Unternehmen wächst? Wer diese Fragen nicht vor der CMS-Entscheidung beantwortet, kauft eine Lösung, die in zwei Jahren das neue Problem ist.

Drittens: URL-Struktur und Redirect-Konzept

Wenn sich URLs ändern, muss jede alte URL auf eine neue weitergeleitet werden. Das ist kein Luxus, sondern eine SEO-Grundvoraussetzung. Wer das erst nach dem Launch aufräumt, verliert Rankingpotenzial, das über Jahre aufgebaut wurde, und bricht externe Links, die Backlink-Wert tragen.

Das Redirect-Konzept gehört ins Briefing, nicht in die Nacharbeiten. Es ist keine technische Aufgabe am Ende, sondern eine inhaltliche Entscheidung am Anfang: Welche alten URLs gibt es, was passiert mit ihnen, und wohin leiten sie weiter?

Viertens: Content-Strategie

Welche Seiten werden neu erstellt? Welche werden zusammengelegt oder gelöscht? Welche Inhalte kommen von der alten Site und welche werden neu geschrieben? Wann werden die Texte erstellt, von wem, und wer gibt sie frei?

Diese Entscheidungen bestimmen, wie lange das Projekt dauert und wie viel Kapazität das Team einplanen muss. Sie bestimmen auch, ob die neue Website inhaltlich stärker ist als die alte oder nur anders aussieht. Content-Produktion ist der häufigste Verzögerungsgrund in Relaunch-Projekten. Wer sie als selbstverständlich betrachtet und nicht plant, blockiert am Ende alle anderen.

Fünftens: Tracking-Architektur

Google Analytics, Tag Manager, Conversion-Tracking für Formulare, Ads-Pixel, CRM-Integrationen. Diese Infrastruktur muss vor dem Launch eingerichtet und getestet sein. Nicht danach.

Jeder Tag ohne funktionierendes Tracking nach dem Launch ist ein Tag, an dem Daten unwiederbringlich verloren gehen. Das ist kein theoretisches Problem. Es ist eines der häufigsten Dinge, die in Relaunch-Projekten passieren, weil Tracking in der Projektplanung oft als „technisches Detail am Ende" behandelt wird.

Sechstens: Launchstrategie

Wann geht die neue Site live? Gibt es eine Übergangsphase mit Staging-Umgebung? Wer nimmt die Site ab und nach welchen Kriterien? Was passiert, wenn am ersten Tag etwas nicht funktioniert?

Ein klarer Launchplan mit definierten Verantwortlichkeiten und einem Rollback-Szenario verhindert Chaos. Der Launch ist nicht das Ende des Projekts. Er ist der Beginn der Phase, in der die Website tatsächlich arbeitet. Wer den Launch nicht strukturiert, übergibt eine unfertige Baustelle an den Alltag.

Technische Bereiche, die beim Relaunch unterschätzt werden

Neben den sechs strategischen Entscheidungen gibt es technische Felder, die in Relaunch-Projekten regelmäßig zu spät betrachtet werden.

Performance ist kein Nice-to-have. Core Web Vitals sind ein Rankingfaktor und wirken direkt auf Absprungraten. Bilder, die nicht komprimiert sind, ein CMS, das schwere Skripte lädt, oder ein Hosting-Paket, das nicht zur erwarteten Last passt, kosten Rankings und Conversions. Wer Performance erst nach dem Launch optimiert, optimiert immer gegen das, was bereits passiert.

SEO-On-Page muss Teil des Konzepts sein, nicht der Nacharbeiten. H1-Struktur, Meta-Titles, Alt-Texte für Bilder, interne Verlinkungsarchitektur. Diese Elemente werden in vielen Projekten erst im letzten Moment angegangen, obwohl sie von Beginn an im Seitenkonzept stehen sollten. Eine SEO-Briefing-Checkliste pro Seitentemplate ist hier das einfachste Mittel.

Barrierefreiheit ist seit dem European Accessibility Act 2025 für viele Unternehmen rechtlich relevant. Kontrastverhältnisse, Tastaturnavigation, ARIA-Labels, korrekte Dokumentstruktur. Wer einen Relaunch plant, sollte Barrierefreiheit von Beginn an ins Konzept einbauen. Das ist kein Mehraufwand, wenn es im Design und Development mitgedacht wird. Es ist ein erheblicher Mehraufwand, wenn es danach nachgerüstet werden muss.

Was pechschwarz® beim Relaunch anders macht

Wir behandeln den Relaunch nicht als Designprojekt. Wir beginnen mit Zielen und enden nicht beim Launch, sondern beim Betrieb. Das bedeutet, dass CMS-Entscheidungen vor dem Design getroffen werden, nicht nach dem Prototyping. Redirect-Konzepte entstehen in der Konzeptionsphase, nicht in der Entwicklungsphase. Und Tracking wird vor dem Launch getestet, nicht danach eingerichtet.

120+ Brands haben mit uns an Websites und Plattformen gearbeitet. Vom Corporate-Relaunch für mittelständische Industrieunternehmen bis zur E-Commerce-Plattform für wachsende Consumer-Brands. Was sich jedes Mal zeigt: Die sechs Entscheidungen aus diesem Artikel sind immer die Stellen, an denen Projekte gewinnen oder verlieren.

Wenn du einen Website-Relaunch planst oder den nächsten Schritt machen möchtest, zeigt dir unser Webdesign-Team, wie ein strukturierter Prozess aussieht: pechschwarz.com/de/webdesign-agentur

Checkliste vor dem Relaunch

Ziele und KPIs definiert und in einem Tracking-Konzept festgehalten. CMS auf Basis von Teamstruktur, Skalierungszielen und technischen Anforderungen ausgewählt. URL-Mapping erstellt und Redirect-Konzept fertiggestellt. Content-Inventur durchgeführt, Entscheidungen über Behalten, Zusammenführen und Löschen dokumentiert. Tracking-Infrastruktur eingerichtet und vor dem Launch getestet. Launchplan mit Verantwortlichkeiten, Abnahmekriterien und Rollback-Szenario dokumentiert.