WordPress verlassen: meine Seite zu Astro und SQLite migrieren

Jahrelang lief andrew.khanoff.com auf WordPress: PHP-FPM, eine MySQL-Datenbank, einen Haufen Plugins und das stetige Hintergrundrauschen von „Ihre Seite benötigt ein Update“. Es funktionierte – aber es waren 475 MB an Dateien, eine 160 MB große Datenbank mit 301 Tabellen und eine Angriffsfläche, die ich nie wollte (xmlrpc.php, wp-login.php, das Plugin der Woche). Für ein persönliches Lebenslauf, das hauptsächlich Text zeigt, ist das zu viele bewegliche Teile zum Patchen und Worüber nachzudenken.

Also habe ich es ersetzt. Hier ist das Warum und das Wie.

Warum von WordPress wegziehen

• Angriffsfläche. Ein statisches CV benötigt kein Login-Formular im öffentlichen Internet, kein Kommentar-System oder Remote Code Execution durch ein Plugin.
• Fußabdruck. PHP + MySQL + WordPress Core + Plugins, nur um eine Seite zu rendern, die sich nur ein paar Mal im Jahr ändert.
• Kontrolle. Ich wollte den Inhalt in einem Format, das mir gehört, gerendert von Code, den ich lesen kann, ohne ein Admin-Panel aus dem offenen Web erreichbar zu haben.

Der Ersatz ist absichtlich klein: eine einzige Astro App (server-rendered, Node adapter) in einem Docker Container, mit SQLite als alleiniger Wahrheitsquelle. Kein PHP. Kein MySQL. Das Admin ist passkey-only und auf das LAN beim Reverse Proxy beschränkt. Projekte werden durch einen täglichen GitHub→local-LLM Pipeline erstellt, und Analytik ist first-party mit einer lokalen GeoIP-Datenbank.

Die Regel: nichts Destruktives ohne Rückfallmöglichkeit

Die gesamte Migration erfolgte in Phasen, und die erste Phase war kein Code – es waren Backups. Bevor ich irgendetwas berührt habe:

1. tar des gesamten WordPress docroot (350 MB komprimiert).
2. mysqldump --single-transaction der WordPress-Datenbank (18 MB).
3. Prüfsummen und ein Test-Extrahieren, um zu beweisen, dass die Archive echt waren.

Erst dann habe ich die neue Seite neben WordPress gebaut, auf einem temporären Port, ohne den Live vhost zu berühren. WordPress hat während der gesamten Zeit, in der die neue App erstellt und mit Inhalt gefüllt wurde, weiterhin den Domainnamen bedient.

Umstellung ohne Ausfallzeiten

Der Wechsel selbst war eine Änderung des Reverse Proxys, keine Datenmigration. nginx wechselte vom Bedienen von /var/www/andrew.khanoff.com über PHP-FPM zum Proxying des neuen Containers auf 127.0.0.1:8090:

location / {
    proxy_pass http://127.0.0.1:8090;
}

Der alte vhost wurde zuerst gesichert, nginx -t sperrte das Neuladen, und wenn irgendetwas falsch ausgesehen hätte, war der Rollback ein einfaches cp des alten Konfigs plus ein Neuladen. Die WordPress-Dateien und die Datenbank blieben vollständig intakt – nur der Domainname zeigte nicht mehr darauf. Rollback-Zeit: Sekunden.

Ich habe die neue Seite eine Weile live laufen lassen, alles verifiziert (öffentliche Seiten, passkey Login, den Projekt-Pipeline, PDF Export, Analytik), und erst dann die WordPress-Datenbank gelöscht – nachdem ich einen weiteren frischen Dump unmittelbar vor dem DROP gemacht hatte. Die 475 MB an WordPress-Dateien wurden zuletzt entfernt, nachdem die Backups erneut verifiziert waren.

Was jetzt besser ist

• Sicherheit: kein öffentliches Login, kein PHP, keine Plugins. Das Admin befindet sich hinter WebAuthn Passkeys und einer allow 10.0.20.0/24 Regel in nginx. HSTS ist aktiv.
• Performance: mobiles Lighthouse erreicht 92 / 96 / 96 / 100 (Performance / Accessibility / Best-Practices / SEO), LCP ~1,4 s. Die Serverantwort beträgt ~30 ms, weil kein Datenbank-Roundtrip-Tanz nötig ist – nur SQLite und Astro.
• Betrieb: die gesamte Seite ist ein Container und eine einzige SQLite-Datei. Backups sind trivial. Die interessante Automatisierung (GitHub + ein lokales LLM) lebt in einem offline Batch Path – wenn es ausfällt, merkt die Seite nichts davon.
• Eigentum: der Inhalt befindet sich in SQLite und Markdown, in einem git Repo, gerendert durch ~2k Zeilen Code, den ich tatsächlich lesen kann.

WordPress ist ein gutes Werkzeug. Es war nur nicht das richtige Maß an Maschinerie für ein CV, das schnell sein, im Betrieb langweilig und sicher zu vernachlässigen ist. Dieser Beitrag und die Seite, auf der Sie ihn lesen, sind das Ergebnis.