Von WordPress zu Astro — die Migrationsgründe

Diese Seite lief seit etwa sechs Jahren auf WordPress. Drei Versionen lang ein Elementor-Theme, zwischendrin ein paar Anläufe für eigene Templates, und am Ende ehrlich gesagt ein Stillstand: noindex, nofollow im Meta, Platzhalter-Texte, und die Erkenntnis, dass ich die Seite mehr aus Pflichtgefühl pflege als aus Lust am Schreiben. Vor zwei Wochen habe ich auf Astro umgezogen. Hier ist warum — inklusive der Punkte, an denen WordPress klar besser war.

Der Auslöser: Balada-Injector

Im Herbst 2025 ist ein Plugin auf einer meiner anderen Seiten kompromittiert worden. Klassisches Balada-Injector-Szenario: ein gepatchtes Plugin, was eigentlich gar nicht mehr aktiv war, hatte eine alte CVE noch offen. Der Injector hat Redirects in HTML-Inhalte gewoben, die einem normalen Besuch nicht auffielen (User-Agent-Sniffing — Crawler sehen die Weiterleitung, Browser-Besucher nicht), aber Google die Site abwerten ließ.

Der Aufräumvorgang war machbar — Dateisystem-Diff gegen ein sauberes Backup, Datenbank-Suche nach injected JavaScript, alle Plugin-Versionen pinnen, MFA ans Admin-Login. Vollständige Sauber-Macher-Tour. Aber das war der Moment, in dem ich gedacht habe: warum betreibe ich eigentlich eine PHP-Anwendung mit Datenbank für eine Seite, die im Wesentlichen nur Text und ein paar Bilder ausliefert?

Die Kalkulation, nüchtern

Ich habe drei Dinge gegeneinander aufgewogen:

Der einzige Bereich, in dem WordPress hier objektiv punktet: wenn jemand ohne Git-Kenntnisse schreiben soll. Das war für mich nicht der Fall — ich bin der einzige Autor.

Warum Astro, nicht Hugo / Eleventy / Next?

Ich habe Hugo zwei Stunden probiert und gemerkt, dass die Template-Logik zu sehr in eigene Goisms abdriftet, sobald man Komponenten wiederverwenden will. Eleventy war angenehm, aber bei MDX (Markdown mit React-Komponenten drinnen) wirkt es bastlerisch. Next.js wäre Overkill — ich brauche kein Server-Side-Rendering, kein React, keine API-Routes.

Astro trifft den Punkt: MDX als First-Class-Citizen, Content Collections mit Zod-Schema-Validation (was bei Tippfehlern im Frontmatter beim Build sofort auffällt, nicht erst beim Lesen), und ein Component-Modell, das wie JSX aussieht ohne JSX zur Runtime mitzuschleppen.

Was die Migration konkret bedeutet

• Hosting bleibt gleich. Derselbe V-Server, der vorher Apache mit PHP+WP bedient hat, bekommt jetzt nur noch statisches HTML aus einem dist/-Ordner. Apache läuft, das vhost-Setup ist 4 Zeilen, das LetsEncrypt-Cert bleibt.
• Deploy per CI, sobald ich die Gitea-Actions-Pipeline fertig habe. Vorerst ein simples rsync aus der lokalen Build-Ausgabe.
• Inhalts-Quelle ist Markdown in meinem zentralen Obsidian-Vault. Was hier steht, hat dort ein Pendant — Schreiben passiert im Vault, der Site-Build zieht via Sparse-Checkout nur die publish: true-Einträge.

Was ich vermisse

• WordPress’ Media-Library war komfortabel. Astro hat astro:assets mit Image-Optimierung, aber das Verwaltungs-UI fehlt. Praktisch: ein assets/-Ordner im Vault, Bilder per Markdown-Link. Funktioniert, ist nüchterner.
• Plugins für Spezialfunktionen. Wenn ich morgen einen Kommentar-Bereich wollte, müsste ich Giscus oder so selbst integrieren. Aktuell will ich keinen — kein Verlust.

Was die Site jetzt anders macht

• noindex, nofollow ist weg, die Seite ist freigegeben für Crawler.
• Werkstatt-Stücke haben eigene Detail-Pages mit Material, Maßen, Settings — vorher waren das drei Bilder ohne Story.
• Tutorials haben Schwierigkeitsgrad und Zeitabschätzung im Frontmatter (kein Theme-Trick, sondern Schema-validiert).
• Keine Cookies, kein Tracking, lokale Schriften.

Wenn deine Site ähnlich tickt — ein paar Autoren, viel Text, wenig dynamische Funktion — ist der Wechsel kein Aufwand mehr, der sich am Risiko bemisst, sondern an der Frage: wie viel Spaß macht es dir, am Setup zu basteln? Mir macht es Spaß. Das ist die ehrliche Antwort.