Entwicklung

Zwei WordPress-Seiten an einem Nachmittag abgelöst

~4 Min. Lesezeit von Ralf Siepker
Zwei WordPress-Seiten an einem Nachmittag abgelöst

Zwei meiner alten Domains liefen seit Jahren auf WordPress, ohne dass dort noch etwas passierte. mageconsult.de war ab 2010 mein erster Auftritt als Magento-Freelancer, magelounge.de der dazugehörige Blog mit Fachbeiträgen aus derselben Zeit. Beide waren inhaltlich eingefroren und trotzdem laufender Aufwand: Updates, Plugins, Sicherheitsmeldungen.

Beide Seiten sind weiterhin erreichbar, die Links oben führen direkt auf das Ergebnis des Umbaus.

Den gröbsten Lärm hatte ich denen schon länger abgewöhnt, mit einem Probe-Block in der .htaccess. Nur ändert der nichts daran, dass unter der Oberfläche weiter ein Content-Management-System läuft, das gepflegt werden will.

Am 9. August habe ich beide an einem Nachmittag ersetzt. Nicht abgeschaltet, sondern als statische Seiten neu gebaut, damit die Inhalte erhalten bleiben. Gearbeitet habe ich mit Claude Code. Dieser Beitrag beschreibt, wie das abgelaufen ist und was mich daran überrascht hat.

Die Zeitleiste

Die Git-Historie beider Projekte ist ziemlich genau protokolliert, deshalb kann ich das nachvollziehbar aufschreiben statt aus dem Gefühl:

Uhrzeit
15:15 Projekt-Setup für beide Seiten
16:56 magelounge: statischer Neubau steht
16:59 Generator-Bereinigung, Zeilenenden und Upload-Reste
17:10 Härtung nach Security-Audit
17:28 mageconsult: One-Pager steht
17:36 magelounge ist live
17:41 mageconsult parallel abgelöst, Server aufgeräumt

Zwei Stunden und gut zwanzig Minuten für beide Seiten, inklusive Rechtstexten, Meta-Angaben, strukturierten Daten, Deployment und einem Sicherheitscheck.

Zwei sehr unterschiedliche Aufgaben

Die beiden Seiten sahen nach ähnlicher Arbeit aus, waren es aber nicht.

magelounge ist ein Blog-Archiv: 31 Beiträge von Juli 2010 bis September 2013, dazu Kontakt- und Rechtsseiten, insgesamt 35 Seiten. Titel wie „Wie stelle ich fest, ob mein Server Magento-tauglich ist" oder die „37-Punkte-Checkliste für den Magento-Golive". Der schönste Fund war ein Beitrag von 2013 mit der Zeile, dass Magento 2 noch ausstehe.

Für diese Seite entstand ein Generator: ein Skript, das die Inhalte aus dem alten WordPress zieht, in eine strukturierte Datei schreibt und daraus statisches HTML rendert. Rund 1.550 Zeilen Code. Viel, aber sobald das Skript lief, war es egal, ob es 31 oder 300 Beiträge sind.

mageconsult ist dagegen ein einziger One-Pager. Drei Seiten insgesamt, wenn man Impressum und Datenschutz mitzählt. Deutlich weniger Code, und er war trotzdem nicht schneller fertig, sondern brauchte nach dem Blog-Archiv noch einmal eine gute halbe Stunde.

Der Engpass waren die Entscheidungen, nicht der Code

Das ist die Beobachtung, die ich mitgenommen habe. Beim Blog-Archiv war die Aufgabe klar: Inhalte erhalten, Struktur beibehalten, URLs stabil halten. Das ist viel Arbeit, aber es sind kaum Entscheidungen zu treffen. So etwas läuft mit KI-Unterstützung außerordentlich zügig.

Beim One-Pager war fast nichts an der Umsetzung schwierig und fast alles an der Frage, was da eigentlich stehen soll. Die Marke ist über die Jahre von mageconsult über CommerceWerft zu com:werft gewandert, und dorthin führt der One-Pager heute auch. Wie erzählt man diesen Weg, ohne dass es wie ein Nachruf klingt? Welche Projekte darf ich überhaupt benennen, wenn ein Teil davon in Festanstellung entstanden ist? Welcher Ton passt zu einer Seite, deren einziger Zweck es ist, Besucher weiterzuleiten?

An dieser Stelle musste ich mehrfach korrigieren. Der erste Entwurf nannte Kundennamen, die dort nichts zu suchen haben. Das war kein Fehler des Werkzeugs, sondern eine Information, die es nicht haben konnte. Sie steht seitdem in der Projektanleitung, damit sie bei der nächsten Änderung nicht wieder verloren geht.

Die Faustregel, die daraus folgt: KI-Unterstützung beschleunigt den Teil, der sich beschreiben lässt. Der Teil, der von Kontext und Urteil abhängt, bleibt genauso langsam wie vorher. Bei einer Datenmigration ist das Verhältnis günstig, bei einer Positionierungsseite deutlich weniger.

Was statisch bedeutet

Beide Seiten liefern heute nur noch vorbereitete Dateien aus. Kein CMS, keine Datenbank, keine Plugins, keine Update-Zyklen. Änderungen laufen über Git und ein Deployment-Skript.

Das ist kein Fortschritt an sich, sondern passt zu diesen beiden Seiten: Sie sind fertig. Eine Seite, auf der wöchentlich Beiträge erscheinen und an der mehrere Leute arbeiten, wäre mit dieser Lösung schlecht bedient. Für ein Archiv und eine Marken-Chronik ist sie richtig.

Wohin die Reise gegangen ist, steht auf beiden Seiten am Ende der Chronik: Aus mageconsult wurde CommerceWerft und daraus com:werft, wo ich heute als Freelancer für Shopware 6, Laravel und PHP arbeite. Die alten Domains bleiben erhalten, sie erzählen nur noch, wie es dazu kam.

Was der Wechsel an Angriffsfläche gespart hat, lässt sich an den Server-Logs sogar beziffern. Das ist ein eigener Beitrag geworden: Was ein stillgelegtes WordPress an Angriffen anzieht.

wordpress statisch claude-code ki relaunch

Auch interessant

WordPress absichern: Scanner-Anfragen mit Status 410 abfangen

Vulnerability-Scanner klopfen pausenlos WordPress-Pfade ab, und jede Antwort ist eine große Fehlerseite. Ein kurzer Block in der .htaccess liefert stattdessen HTTP-Status-Code 410 (Gone) mit 282 Byte und füttert nebenbei fail2ban. So läuft das hier seit Monaten auf sechs Seiten.

14. Mai 2026 7 Min.