Bei einem Relaunch ist die bestehende Website eine wichtige Informationsquelle. Ein neues Frontend kann Probleme lösen, aber auch funktionierende Abläufe ersetzen, die anschließend neu gebaut werden müssen. Vor der Architekturentscheidung sollte daher klar sein, was am aktuellen System tatsächlich nicht passt.
Bestand und Probleme erfassen
Die Bestandsaufnahme umfasst:
- Inhalte und Adressen: Welche Seiten werden genutzt, verlinkt und redaktionell gepflegt?
- Funktionen: Welche Formulare, Suchen, Benutzerbereiche und Schnittstellen existieren?
- Redaktion: Wie werden Seiten gestaltet, geprüft und veröffentlicht?
- Technik: Wo liegen nachweisbare Fehler, Ladeprobleme oder Wartungshürden?
- Betrieb: Wer betreut Hosting, Updates und Sicherungen?
Verbesserung im bestehenden System prüfen
Ein unübersichtliches Theme, zu große Bilder oder eine ungünstige Erweiterung sind noch kein Beleg dafür, dass WordPress als Architektur ungeeignet ist. Prüfen Sie zuerst die konkrete Ursache. Klassisches WordPress kann Seiten aus einem Cache ausliefern; die reale Leistung hängt von Konfiguration und Funktionen ab.
Bleiben Inhaltspflege und Seitenausgabe in einem System, kann das redaktionelle Abläufe vereinfachen. Ein überarbeitetes Theme oder klar definierte Inhaltsmodule können deshalb ein passender Relaunch sein, wenn die Anforderungen damit erfüllt werden.
Die Folgen einer Trennung vollständig erfassen
Bei WordPress als Headless-CMS werden Inhalte über eine Schnittstelle an ein separates Frontend geliefert. Die REST API ist Bestandteil von WordPress; GraphQL benötigt eine Ergänzung. Funktionen eines bisherigen Themes oder Plugins stehen im neuen Frontend nicht automatisch in gleicher Form zur Verfügung.
Für eine getrennte Oberfläche zusätzlich planen:
- Vorschau und Veröffentlichung: Wie sieht die Redaktion einen Entwurf im tatsächlichen Frontend?
- Aktualisierung: Wann wird ein geänderter Inhalt öffentlich sichtbar und wie werden Caches erneuert?
- Funktionen: Wie werden Formulare, Suche und weitere bisherige Erweiterungen angebunden?
- Fehlerfälle: Was zeigt das Frontend, wenn Inhalte fehlen oder das CMS nicht erreichbar ist?
Migration und Suchadressen vorbereiten
Erstellen Sie eine Zuordnung alter und neuer URLs. Inhaltlich gleichwertige Nachfolger können gezielt weitergeleitet werden; nicht jede entfernte Seite gehört auf die Startseite. Interne Links, Canonicals und Sitemap werden am neuen Stand geprüft. Vor der Umstellung braucht es außerdem eine Sicherung und einen nachvollziehbaren Rückweg für technische Probleme.
An einer repräsentativen Seite entscheiden
Setzen Sie zuerst einen typischen Inhalt samt Vorschau und einer wichtigen Funktion um. Lassen Sie Redaktion und Technik diesen Ablauf prüfen. Dadurch lässt sich beurteilen, ob eine getrennte Architektur den konkreten Bedarf besser abdeckt oder vor allem zusätzliche Integrationsarbeit erzeugt.
Ein Relaunch sollte vorhandene Probleme lösen und funktionierende Aufgaben weiterhin ermöglichen. Der Architekturwechsel ist nur dann sinnvoll, wenn sein Nutzen und die zusätzliche Betriebsverantwortung nachvollziehbar sind.
Quellen und weiterführende Dokumentation
Themen
- WordPress
- Headless CMS
- Next.js
- Nuxt
- SvelteKit
- JAMstack
- Architektur