Aufräumen statt neu bauen. WordPress bleibt bestehen, wird aber schlanker, schneller und wartbarer. Der mittlere Weg zwischen Weiterwurschteln und komplettem Ausstieg.
Der Begriff kommt aus der Softwareentwicklung und beschreibt etwas, das jeder aus dem eigenen Haushalt kennt: Man löst ein Problem schnell statt richtig und zahlt später Zinsen darauf.
Bei einer Website sieht das so aus. Ein Layout klappt auf dem Handy nicht, also kommt eine kleine Ausnahme in die Stildatei. Ein Kunde braucht ein Feld im Formular, also wird eine zweite Erweiterung installiert. Ein Update macht Ärger, also wird eine Datei angepasst statt das Child-Theme zu nutzen.
Jede dieser Entscheidungen war im Moment vernünftig. Nach fünf Jahren liegt aber so viel davon auf einander, dass jede neue Änderung teurer wird als die vorherige. Genau das sind technische Schulden und Refactoring ist ihr Abbau.
Schulden abbauen heißt dabei nicht, alles auf einmal zu tilgen. Es reicht meist, die teuersten Posten anzugehen: die Stellen, an denen jede kleine Änderung überproportional viel Zeit kostet. Welche das sind, zeigt sich schon nach wenigen Stunden in einer Installation.
Wichtig: Refactoring ändert nicht, was die Website tut. Es ändert nur, wie sie es tut. Für Ihre Besucher sieht danach alles aus wie vorher, bis auf die Ladezeit. Das ist der Unterschied zu einem Relaunch, bei dem sich Struktur und Gestaltung mit ändern.
Wann sich das lohnt
Wenn die Redaktion mit WordPress gut zurecht kommt, die Struktur passt und nur die Technik unordentlich ist. Dann ist Aufräumen deutlich günstiger als der Wechsel.
Wann eher nicht
Wenn im Haus ohnehin niemand mehr Inhalte pflegt. Dann zahlen Sie für ein System das Sie nicht nutzen und lohnt der Blick auf die Ablösung des Unterbaus mehr.
Technische Schulden sind unsichtbar, bis sie Geld kosten. Diese Signale kennen die meisten Kunden aus dem Alltag, ordnen sie aber selten technisch ein.
Wenn Sie hier mehrfach nicken, ist der Zeitpunkt gut. Je länger gewartet wird, desto mehr baut sich auf, und irgendwann kippt die Rechnung zugunsten eines kompletten Nachbaus.
Nicht jede ist bei jedem Projekt dabei. Die Reihenfolge entspricht in etwa dem Nutzen den sie meist bringen.
Doppelte Funktionen zusammenführen, verwaiste Pakete entfernen, überdimensionierte Werkzeuge durch wenige Zeilen eigenen Code ersetzen. Meist bleibt am Ende etwa die Hälfte übrig. Mehr dazu unter Erweiterungen sinnvoll reduzieren.
Seiten, die im Baukasten gebaut wurden, werden auf saubere Vorlagen umgestellt. Das Aussehen bleibt, der ausgelieferte Code schrumpft oft auf ein Drittel. Das ist der größte Einzelposten und der aufwendigste.
Anpassungen wandern aus dem Theme in ein Child-Theme oder in ein eigenes kleines Modul. Damit überlebt jede Änderung das nächste Update, ohne dass jemand sie an Hand alter Notizen rekonstruieren muss.
Alte Beitragsversionen, Reste entfernter Erweiterungen, verwaiste Einstellungen und aufgeblähte Protokolltabellen. Der Effekt auf die Ladezeit ist kleiner als viele hoffen, der auf die Wartbarkeit größer.
Bilder in modernen Formaten, Schriften lokal statt von fremden Servern, Skripte nur dort laden wo sie gebraucht werden. Was dahintersteht, erklären wir unter Ladezeit messbar verbessern.
Aktuelle PHP-Version, geprüfte Backups, Testumgebung für Updates, aufgeräumte Benutzerkonten. Das ist unspektakulär und verhindert die meisten späteren Notfälle.
Wir sehen uns Installation, Theme, Erweiterungen, Datenbank und Ladeverhalten an. Sie bekommen eine Liste der Baustellen, jeweils mit Aufwand und erwartetem Nutzen.
Gemeinsam entscheiden wir, was zuerst passiert. Meist beginnen wir mit dem was schnell wirkt, damit der Nutzen früh sichtbar wird.
Eine vollständige Kopie, in der gearbeitet wird. Die Live-Seite bleibt während der gesamten Zeit unangetastet und erreichbar.
Nach jedem Schritt wird geprüft: Startseite, Menüs, Formulare, Suche, die wichtigsten Unterseiten. So bleibt jederzeit nachvollziehbar was eine Änderung bewirkt hat.
Die geprüfte Fassung geht live. Danach vergleichen wir Ladezeiten und Fehlerprotokolle mit dem Zustand davor.
Sie bekommen schriftlich, was geändert wurde und warum. Damit kann jeder andere Dienstleister nahtlos weiterarbeiten.
Refactoring ist unsichtbare Arbeit. Deshalb legen wir Wert darauf, den Effekt messbar zu machen statt ihn zu behaupten.
Ehrliche Grenze
Wenn das Theme selbst das Problem ist und nicht mehr gepflegt wird, ist Refactoring Flickwerk. Dann ist der Nachbau das beste Vorgehen, auch wenn er zuerst teurer aussieht.
Die drei Wege werden oft verwechselt. Sie lösen unterschiedliche Probleme und kosten unterschiedlich viel.
| Kriterium | Reparatur | Refactoring | Rückbau |
|---|---|---|---|
| Anlass | etwas ist kaputt | alles läuft, aber zäh | Pflege lohnt nicht mehr |
| Ziel | wieder funktionsfähig | wartbar und schnell | ohne laufende Pflege |
| System danach | WordPress | WordPress | schlanke Auslieferung |
| Dauer | Stunden bis Tage | ein bis vier Wochen | zwei bis acht Wochen |
| Wirkt gegen | akute Ausfälle | steigende Kosten | dauerhaften Aufwand |
In der Praxis folgen die Wege oft aufeinander. Erst wird repariert, weil es dringend ist, dann wird aufgeräumt, weil dieselbe Baustelle sonst wiederkommt. Und irgendwann stellt sich die Frage, ob das System überhaupt noch gebraucht wird. Diese Reihenfolge ist völlig in Ordnung, solange sie bewusst passiert und nicht aus Zufall. Was wir vermeiden wollen, ist der vierte Fall: jahrelang reparieren, ohne je die Frage zu stellen warum dieselben Dinge immer wieder kaputtgehen.
Am Aussehen nichts, an der Geschwindigkeit meistens schon. Genau das ist das Ziel: gleiche Seite, weniger Ballast. Wenn wir gestalterisch etwas ändern müssen, weil eine alte Lösung technisch nicht sinnvoll erhaltbar ist, zeigen wir das vorher und entscheiden es mit Ihnen.
Meist deutlich weniger, weil Konzept, Gestaltung und Inhalte bereits vorhanden sind. Wir arbeiten in abgegrenzten Paketen, sodass Sie nach dem ersten Schritt entscheiden können ob es weitergeht. Eine Zahl nennen wir nach der Analyse, nicht davor.
Ja, mit einer Einschränkung. Größere inhaltliche Änderungen sollten wir kurz absprechen, damit sie beim Zurückspielen nicht verloren gehen. Normale Beiträge und kleine Korrekturen sind kein Problem.
Beim Refactoring ändern sich weder Adressen noch Inhalte, deshalb ist das Risiko gering. Bessere Ladezeiten wirken sich eher positiv aus. Anders sieht es aus, wenn im gleichen Zug die Struktur geändert wird. Dann gelten die Regeln aus der abgesicherten Migration.
Das hängt davon ab, ob danach Regeln gelten. Ohne Absprachen sammelt sich in zwei bis drei Jahren wieder Ballast an. Mit einem festen Update-Rhythmus, einer jährlichen Durchsicht und einer kurzen Prüfung vor jeder neuen Erweiterung hält der Zustand deutlich länger.
Ja, das ist ein guter Teil unserer Arbeit. Viele Agenturen haben Bestandskunden mit schwierigen Installationen und keine Kapazität für die technische Tiefe. Wir arbeiten dann im Hintergrund und treten gegenüber dem Endkunden nicht auf, wenn Sie das so möchten.
Sie bekommen eine Liste der Baustellen mit Aufwand und erwartetem Nutzen. Danach entscheiden Sie, was davon umgesetzt wird und in welcher Reihenfolge.