Der Relaunch ändert die Optik, das Problem bleibt oft stehen
Ein Website-Relaunch beginnt fast immer mit demselben Anlass: Die Seite sieht veraltet aus, die Konversion stimmt nicht mehr, ein neuer Markenauftritt soll sich auch online zeigen. Alles Gründe, die am Design ansetzen, und deshalb wird der Relaunch meistens auch nur als Design-Projekt beauftragt. Neues Layout, neue Struktur, vielleicht ein neues Theme im bestehenden System.
Das Problem dabei: Wenn die eigentliche Ursache für die tägliche Frustration nicht die Optik war, sondern das System darunter, überlebt genau dieses Problem den Relaunch unverändert. Ein neues Design auf demselben brüchigen Fundament sieht für ein paar Monate frischer aus und fühlt sich danach genauso mühsam an wie vorher, nur mit neuen Farben. Der Relaunch ist damit vertan, denn er ist der einzige Moment, in dem sich diese Frage überhaupt günstig stellen lässt. Danach ist wieder alles im Betrieb, und ein zweiter Wechsel kurz nach dem ersten lässt sich intern kaum begründen.
Design-Problem oder Struktur-Problem, zwei unterschiedliche Diagnosen
Die beiden Probleme fühlen sich im Alltag oft ähnlich an, “die Website nervt”, zeigen sich aber an ganz unterschiedlichen Stellen.
Ein Design-Problem sieht so aus: Die Seite lädt zuverlässig, die Redaktion kommt mit dem Backend zurecht, neue Unterseiten lassen sich anlegen, ohne dass etwas kaputtgeht. Was fehlt, ist die Außenwirkung, veraltete Typografie, ein Layout, das auf dem Handy schlecht funktioniert, eine Struktur, die Besucher nicht zur richtigen Seite führt. Das lässt sich mit einem neuen Frontend lösen, ohne dass irgendetwas am System darunter angefasst werden muss.
Ein Struktur-Problem zeigt sich anders, und meistens an mehreren dieser Symptome gleichzeitig: Für jede noch so kleine Textänderung braucht die Redaktion einen Entwickler, weil der Inhalt fest in ein Template gegossen ist statt in eigenen Feldern zu stecken. Ein Dutzend Plugins wurde über die Jahre installiert, niemand im Team weiß mehr genau, welches wofür zuständig ist, und jedes Update ist ein kleines Risiko. Neben der eigentlichen Website ist eine eigene Anwendung entstanden, ein Konfigurator, ein Kundenbereich, ein Formular mit eigener Verarbeitungslogik, die im CMS eigentlich keinen Platz hat und deshalb als Fremdkörper danebenhängt. Oder die Inhalte sollen nicht mehr nur auf der Website landen, sondern auch in einer App oder bei einem Partner, und das bestehende System kennt nur den einen Ausgabekanal, für den es ursprünglich gebaut wurde.
Der Unterschied zwischen beiden Fällen ist entscheidend, weil ein Redesign das erste Problem löst und das zweite überhaupt nicht berührt.
Wann WordPress einfach bleiben sollte
Das ehrliche Ergebnis dieser Diagnose ist häufiger, als Systemvergleiche im Netz vermuten lassen: WordPress bleibt die richtige Wahl. Für eine Unternehmenswebsite mit einer überschaubaren Anzahl an Seiten, einer kleinen Redaktion, die mit dem Backend zurechtkommt, und einem gepflegten, schlanken Plugin-Bestand ist ein CMS-Wechsel reiner Mehraufwand ohne echten Gegenwert. Das Geld und die Zeit, die ein Systemwechsel kostet, sind dort besser in das Design und den Content selbst investiert. Ein Relaunch ist kein Selbstzweck, und “wir bauen mal was Neues” ist kein Grund, ein funktionierendes System zu ersetzen.
Wann das CMS tatsächlich das Problem ist
Anders sieht es aus, wenn die im vorigen Abschnitt genannten Struktur-Symptome zutreffen: Plugin-Wildwuchs, den niemand mehr überblickt, jede Inhaltsänderung als Entwickler-Ticket, eine eigene Anwendung, die neben der Website wächst, statt in ihr Platz zu haben, oder Inhalte, die auf mehr als einen Kanal sollen. In diesen Fällen ist das CMS nicht nebensächlich für den Relaunch, sondern dessen eigentlicher Gegenstand. Ein neues Design auf einem System mit diesen Symptomen bringt zwar sofort eine hübschere Optik, ändert an der täglichen Reibung aber nichts, weil die Reibung nie am Aussehen der Seite lag.
Was ein Enterprise CMS in diesem Zusammenhang meint
Für den Fall, dass die Website groß und inhaltsstark genug ist und mehrere Redakteure parallel arbeiten, fällt in Deutschland oft der Begriff Enterprise CMS. Der Begriff ist im Deutschen doppelt belegt und das sorgt regelmäßig für Verwechslungen: Enterprise Content Management, kurz ECM, bezeichnet Dokumentenmanagement und Aktenverwaltung in Unternehmen, eine völlig andere Softwarekategorie. Ein Enterprise CMS im hier gemeinten Sinn ist dagegen schlicht eine Content-Plattform, die für den Umfang einer großen Website ausgelegt ist: viele Seiten, ein durchdachtes Content-Modell statt starrer Templates, Rollen für mehrere Redakteure, und die Fähigkeit, dieselben Inhalte an mehr als einen Ausgabekanal zu liefern. Wenn du nach einem Enterprise CMS suchst, klär also zuerst, welche der beiden Bedeutungen gemeint ist, bevor du nach Anbietern suchst.
Wo ein selbst gehostetes, TypeScript-basiertes CMS wirklich besser ist
Wenn die Diagnose auf ein Struktur-Problem fällt, ist die nächste Frage, welches System an die Stelle des alten tritt. Neben etablierten klassischen CMS ist ein selbst gehostetes, TypeScript-basiertes System wie Payload CMS eine ehrliche zusätzliche Option, kein Ersatz für alle Fälle. Der Vorteil zeigt sich dort, wo Website und eigene Anwendungslogik zusammen wachsen sollen: ein Kundenportal, individuelle Formularverarbeitung mit eigener Logik, oder Inhalte, die auch außerhalb der eigenen Website ausgespielt werden. Diese Fälle lassen sich in einem solchen System direkt im selben Code und im selben Deploy umsetzen, statt eine Erweiterung dafür zu bauen.
Der Nachteil ist genauso real: Ein reines TypeScript-Team ist nötig, das Plugin-Ökosystem für reine Redaktionsfunktionen ist schmaler als bei etablierten CMS, und für eine Website ohne eigene Anwendungslogik ist der Vorteil gar nicht vorhanden, weil es dort schlicht keine eigene Logik gibt, die im selben System leben müsste. Für diesen Fall bleibt WordPress, oder ein anderes etabliertes CMS, die pragmatischere Wahl.
Was vor dem Relaunch entschieden werden muss
Die CMS-Frage gehört an den Anfang eines Relaunchs, nicht in dessen Mitte. Wenn sie erst auftaucht, während Design und Struktur schon feststehen, ändert sich mitten im Projekt der Umfang, und ein Teil der bereits getroffenen Entscheidungen muss neu gedacht werden. Sinnvoll ist deshalb, vor dem eigentlichen Relaunch drei Dinge ehrlich zu klären: Ob die Reibung im Alltag tatsächlich am Design liegt oder an der Struktur darunter, ob eine eigene Anwendungslogik neben der Website existiert oder geplant ist, die im aktuellen System keinen Platz hat, und ob die Inhalte langfristig nur auf der eigenen Website bleiben sollen oder auch anderswo ausgespielt werden müssen. Erst danach lässt sich seriös entscheiden, ob der Relaunch ein Design-Projekt bleibt oder auch das System selbst betrifft.
Wenn die Entscheidung auf einen Systemwechsel fällt, ist die eigentliche Migrationsarbeit, Inhalte, URLs und Redaktion sauber in das neue System zu überführen, ein eigenes Thema mit eigenen Risiken. Wie sich das ohne einen Redaktions-Blackout durchführen lässt, beschreiben wir separat, unabhängig davon, welches System am Ende auf der neuen Seite steht.