WordPress Renovierung – eine Fallstudie

Das Musiktheater Animato veranstaltet Opernworkshops an Schulen. Dazu fahren die Darsteller mit dem Tourbus (=Lieferwagen) durch Österreich und Deutschland und bauen in den Turnsälen ihr Setting auf. Oper für die Zielgruppe vor Ort. Gebucht werden die Auftritte von den Schulen. Die Website unterstützt das mit Kontaktform und ein paar Informationen zu den angebotenen Stücken.

Technisch: 2015 habe ich die Site gelauncht. Als Theme war Total im Einsatz, das kam mit WPBakery als Page Builder. Für den Kern – das Kontaktformular – habe ich ContactForm7 verwendet. Dazu noch ein Sitemap-Plugin (das war damals nicht im WordPress Core), Slider, etc. Die Site lief ohne Probleme – regelmäßge Updates waren immer ein Teil des Paketes. Und wenn wir nicht umgebaut hätten, würde die Site immer noch laufen. 

Inhaltlich: die Site besteht nur aus Seiten (Pages), neben dem Üblichen besteht der Kern aus 6 Seiten, die jeweils ein Stück beschreiben. Manche davon haben ein paar Feedbacks, die beim Stück angezeigt werden. Das Musiktheater Animato gibt es seit Jahrzehnten, die Zielgruppe weiss das. Die Marke und das Angebot sind bekannt. Vermutlich würde es auch ohne Website klappen. Es geht nicht ums Verkaufen, es geht darum, im Bedarfsfall mit der Website die Kunden zu unterstützen. 

Warum also das gute Stück überhaupt angreifen? Im Sommer 2026 konnte man schon ein paar kritische Signale sehen: die Website wurde gefühlt langsamer. Zumindest Mobil hat es schon ein wenig gedauert. Ein kleines Sicherheitsaudit zeigte schon recht betagte Komponenten, die zwar nicht umgehend, aber doch jetzt irgendwann mal zu ersetzen wären. Theme und Builder sind deutlich in die Jahre gekommen. Nein, Spass macht das keinen, aber wenn es funktioniert, warum angreifen?

Die klassische Reaktion wäre vermutlich gewesen: Relaunch! Alle Argumente sind da. Aber – wozu? Welchen Vorteil hätte der Enduser wirklich von einem Relaunch? Was – ausser Kosten – hätte der Betreiber davon? Gemeinsam mit dem Kunden haben wir uns also folgende Fragen gestellt – und beantwortet:

Funktionalität: wir brauchen keine funktionale Änderung. Sie soll weiter machen was sie bisher gemacht hat. 

Performance: die Website soll – besonders auf Mobilgeräten – schneller werden.

Sicherheit: auch in den nächsten Jahren wollen wir gepflegte Komponenten, und davon möglichst wenige.

Hosting: es gibt keinen Änderungsbedarf. Kosten passen, die Performace ist für das Projekt völlig ausreichend.

Bedienungskomfort: bei so wenig Änderungen eher ein „nice 2 have” und kein need. Aber wenn schon, dann kann es doch gerne ein wenig gemütlicher im Backend werden. 

Unser Vorher zeigt die Painpoints: rot bei Mobile Performance (50), Largest Contentful Paint (LCP) und Total Blocking Time (TBT). Ausserdem ein D- bei Sicherheitsscore (Mozilla HTTP Observatory) und ein Browser-Fehler: ein Totes Tracking-Pixel aus 2023 (längst abgeschaltet, aber noch im Code).

In der Analyse versuchen wir die roten Punkte denn den Komponenten zuzuordnen: WPBakery war einer (nicht der einzige), das Theme und die Plugins bzw. deren Zustand und Notwendigkeit die weiteren Ansatzstellen um aufzuräumen.

Was die Sicherheit ausserhalb der Komponenten betrifft haben wir den Einbau von mehr Header-Sicherheit beschlossen. Mit einem Plugin mehr haben wir zwar wieder eine Komponente mehr, allerdings eine beschützende und keine bremsende.

Als Profi wissen wir ja schon oft wärend die Fragen ausgesprochen werden die Antworten – aber lassen wir uns nicht von uns selber täuschen, wir können ja messen. Und das haben wir auch vorher/nachher getan.

Es wurde wieder mal: Bricks. Weil: aktive Entwicklung, sehr gute Performace-Defaults, Webfont Handling, regelmässige Updates. Bereinigt benötigen wir jetzt genau 1 Plugin neben Bricks für die Funktion der Website: ein SMTP-Plugin. Ersetzt wurden: Pagebuilder, Formular, Slider, Captcha (Bricks unterstützt hCaptcha native), Sitemap (weil jetzt in WP selber), Cookie-Notice (weil keine externe Statistik: wir zählen mit Matomo am selben Server, Google ist komplett raus).

Es bleiben die systemunabhängigen Plugins für Backup und Wartung, die ich überall verwende.

Schon alleine die Anzahl der reduzierten Angriffs- und Fehlerflächen sowie Updatehäufigkeit würde für den Techniker in mir ausreichen als Argument für einen Wechsel – aber Techniker treffen diese Entscheidungen nicht alleine. 

Warum kein Blocktheme? Bricks bündelt Funktionalität, die mit Gutenberg mehrere Plugins bräuchte. Das reduziert Komplexität für den Betreiber, bindet die Site aber auch enger an das Bricks-Ökosystem. Wobei die Abwägung zwischen einem Blocktheme mit Erweiterung und Bricks knapp war. Auf der anderen Seite wiederum ist es egal, ob ich an eine Erweiterung oder einen Builder gebunden bin. Die Performance wäre vmtl. ziemlich gleich. 

Nach den Fakten entscheidet dann eben immer noch die persönliche Vorliebe … 

Erster Scan nach dem Launch: schon die erste Zeile zeigt: der Systemwechsel führte zu einer Performace-Steigerung Mobil von 45 Punkten (50 > 95). Alle roten Bereiche konnten so gelöst werden: Einfach dadurch, dass die Basis der Website jetzt dem aktuellen Stand der Technik entspricht. Beim CLS haben wir eine Verschlechterung: hier war eine Schriftendefinition nicht ganz genau und hat einen Layout Shift verursacht, der durch preloading beseitigt werden kann.

Kein Thema war und ist SEO. Zuerst mal, weil der Tausch Inhalt gegen Traffic von Google einseitig gekündigt wurde. Noch nie in den vielen Jahren des Projektes wurde über die Website ein neuer Kundenkontakt abgeschlossen – es geht um die Pflege und unterstützung bestehender Kundenbeziehungen. Und ja, natürlich ist der Pagespeed auch eine SEO-Massnahme – aber hier geht es um Benutzerfreundlichkeit, und nicht um Maschinenfreundlichkeit.

Was auch nicht angedacht war: Webdesign Änderung. Das Design mag nicht mehr das eleganteste sein, aber durch den Themewechsel wurde die mobile Nutzbarkeit „von selbst” verbessert. Farben, Design und Proportionen wurden einfach belassen. Die einzige Änderung war bei der Schrift: statt der Systemschrift „Helvetica” wurde auf den Webfont „Roboto” umgestellt. 

Und wie lange hat das jetzt gedauert, oder noch konkreter: wieviel hat diese Website-Renovierung gekostet? Die Zeiterfassung verrät es: 8 Netto-Arbeitsstunden. Wenn man das mit der zu erwartenden weiteren Lebensdauer der Website vergleicht, recht wenig. Die Arbeitsdauer hängt natürlich sehr stark von der Erfahrung des Technikers ab: wer seine Tools kennt ist immer schneller. Die Schritte sind fast immer gleich:

1. Lokale Kopie der Website erstellen
2. Novamira installieren und KI verbinden
3. Design.md erstellen und anpassen
4. Neues Theme installieren, Styles und Templates erstellen
5. Seiten umbauen
6. Clean up (Themes, Templates, Revisionen etc.)
7. Zurückspielen der Site auf den Webhost. (Downtime etwa 1 Minute).

In desem Fall gab es noch 2 Besonderheiten: die Formularabsendungen von früher wurden mit Flamingo (einer Erweiterung für CF7 gespeichert). Diese Funktion wurde ersatzlos gestrichen. Ausserdem gab es einen eigenen Posttyp für das Feedback für einzelne Stücke. Anstatt hier einen CPT zu verwenden haben wir diese Inhalte in einfache Beiträge überführt und mit Schlagworten den Stücken zugeordnet. Damit blieben Metainformationen wie Erstellungsdaten erhalten, den Posttyp Beitrag verwendet die Site sonst ohnehin nicht. 

Es gibt bei beinahe jeder älteren WordPress-Installation die eine oder andere Falle. Der Vorteil für den Betrieber der Site ist klar an den Parametern zu erkennen, aber noch klarer daran, dass er sich um nichts kümmern musste – und sich auch in den nächsten Jahren vmtl. nicht mehr als bisher kümmern muss.

Neue Webtechnik ist einfach schneller als alte Webtechnik. Um das zu nutzen muss man nicht immer alles neu bauen. Bei manchen Renovierungen ist die Substanz gut und die Fassade kommt neu, hier war es eher umgekehrt. 

Solche Projekte haben nie Dringlichkeit – sind aber wichtig. Wenn die Dinge dringend werden ist es meisst schon zu spät. Ob die gewählte Lösung die richtige Entscheidung war wird man erst in einigen Jahren wissen – keine Entscheidung zu treffen wäre auf jeden Fall die falsche gewesen.