appfarms.com — von WordPress zu Astro

Über das Projekt

Diese Referenz ist ein Eigenprojekt: die Migration unserer eigenen Website appfarms.com von einer langjährig gewachsenen WordPress-Installation auf einen statisch ausgelieferten Astro-Stack. Wir dokumentieren das Projekt aus zwei Gründen offen — inklusive der Stolpersteine.

Erstens, weil wir uns selbst an dem messen lassen wollen, was wir Kund:innen empfehlen: ein modernes Web, das schnell, sicher, wartbar und langlebig ist. Zweitens, weil die Schmerzpunkte, die uns zur Migration bewogen haben, in vielen Unternehmen identisch sind — und eine ehrliche Erfahrungsschilderung mehr wert ist als jede Hochglanz-Liste.

Ausgangslage: was uns an WordPress nicht mehr passte

Die alte Seite lief stabil — aber sie kostete kontinuierlich Aufmerksamkeit, ohne dass dem ein redaktioneller Mehrwert gegenüberstand:

• Plugin- und Core-Updates als wiederkehrende Wartungsaufgabe, mit Risiko von Inkompatibilitäten und Breaking Changes.
• Sicherheitsoberfläche: PHP-Runtime, Datenbank, Plugin-Code Dritter und ein öffentliches Login — jedes Element ist potenziell ein Angriffsvektor und braucht Patch-Disziplin.
• Performance trotz Caching: gute Werte erforderten zusätzliche Plugins, deren Konfiguration regelmäßig neu justiert werden musste.
• Editor- und Page-Builder-Fragmentierung: Inhalte waren teils im Block-Editor, teils im Builder, teils in Plugin-Custom-Fields gepflegt. Strukturierte Inhalte (Case Studies, FAQs) ließen sich schwer konsistent halten.
• Reproduzierbarkeit: Stagings und lokale Umgebungen waren aufwändig, Datenbank- und Medien-Sync ein wiederkehrender Reibungspunkt.

Keiner dieser Punkte ist ein Argument gegen WordPress generell. Für unser Profil — eine primär redaktionelle Marketing- und Referenzseite mit überschaubarem Änderungstakt — war das Verhältnis aus Komplexität und Nutzen aber zunehmend schlecht.

Was ein externes Audit der Alt-Seite gezeigt hat

Vor der Migration haben wir die laufende WordPress-Installation passiv von außen geprüft — ohne Login, ohne aktive Exploits, nur mit öffentlich erreichbaren Endpunkten. Die Befunde waren typisch für eine gewachsene WP-Site und keineswegs ungewöhnlich, aber eindeutig:

• Benutzer-Enumeration über /wp-json/wp/v2/users lieferte ohne Authentifizierung den Login-Slug des Admins — ideale Vorlage für gezieltes Brute-Force.
• Author-Slug-Leak über ?author=1, der per Redirect denselben Login offenlegte.
• Fehlende Security-Header auf den öffentlichen Seiten: kein HSTS, keine CSP, kein X-Content-Type-Options, kein X-Frame-Options, keine Referrer-Policy, keine Permissions-Policy.
• Versions-Fingerprinting durch x-powered-by: PHP/8.2.28, frei zugängliche readme.html/license.txt und Plugin-Versionen im Markup.
• Application Passwords aktiv ohne durchgesetzte 2FA — dauerhafte API-Tokens als realistischer Folgevektor.
• wp-cron.php öffentlich triggerbar, ein typischer DoS-Verstärker.

Keiner dieser Punkte ist ein Skandal — jeder einzelne ist mit WP-Bordmitteln, Plugins oder Webserver-Regeln zu schließen. Aber jeder einzelne ist auch Pflegeaufwand, der wiederkehrt, sobald Plugins aktualisiert werden, ein neues Theme dazukommt oder ein Hosting-Wechsel ansteht. Genau diese Daueraufgabe wollten wir loswerden — nicht WordPress an sich.

Entscheidung: warum Astro

Wir haben drei Optionen ernsthaft geprüft: WordPress modernisieren (bereinigen, Plugins reduzieren, Headless-Frontend), eine Hugo/Eleventy-Lösung, und Astro. Die Entscheidung fiel auf Astro, weil es für unser Profil die beste Kombination liefert:

• Statische Auslieferung als Default — kein PHP, keine DB, kein Login. Die Angriffsfläche reduziert sich auf die ausgelieferten Dateien.
• Komponentenmodell mit TypeScript, ohne SSR-Zwang und ohne Framework-Lock-in. Wir können punktuell React/Svelte-Inseln einsetzen, wenn nötig — müssen es aber nicht.
• Content Collections mit Zod-Schema: Inhalte werden bei Build-Zeit validiert. Ein fehlendes Pflichtfeld bricht den Build, statt unbemerkt live zu gehen.
• Mehrsprachigkeit sauber als Dateistruktur (de/, en/), nicht als Plugin.
• SEO-Grundlagen (Sitemap, JSON-LD, hreflang, Canonical) sind im Code, versioniert und reviewbar — nicht in einem Plugin-Backend.

Migrationsweg

1. Content-Audit: jede WordPress-Seite bewertet (behalten, neu schreiben, streichen, zusammenführen). Ergebnis: deutlich weniger, aber stärkere Seiten.
2. Inhaltsmodell vor Inhalt: Schema für Seiten, Case Studies und FAQs in content.config.ts definiert, bevor Inhalte migriert wurden. Das hat einige Inkonsistenzen aus der Altseite sichtbar gemacht.
3. Markdown-Migration: Inhalte als Markdown übernommen, Bilder optimiert, Alt-Texte ergänzt.
4. Redirect-Map: 1:1-Mapping alter URLs auf neue Slugs, damit Rankings und Backlinks erhalten bleiben.
5. SEO-Bausteine: JSON-LD für Organisation, Breadcrumbs, FAQs und Case Studies; saubere <title>-/Meta-Beschreibungen pro Seite.
6. CI/CD: Build und Deploy laufen automatisiert; jeder Push auf main ist ein Deploy, jeder PR bekommt eine Preview.

Ergebnis

Was sich in der Praxis spürbar geändert hat:

• Wartung: keine Plugin-Updates, keine PHP-Patches, kein Login-Hardening. Updates beschränken sich auf Dependencies, die im PR-Review sichtbar sind.
• Performance: statisches HTML mit minimalem JS. Core Web Vitals sind ohne Caching-Plugin im grünen Bereich. (Konkrete Vorher/Nachher-Werte: Lighthouse, TTFB, LCP — werden nach finalem Launch ergänzt.)
• Redaktionsworkflow: neue Referenz oder Leistung = neue Markdown-Datei mit Schema. Konsistenz wird vom System erzwungen, nicht von Disziplin.
• Sicherheit: keine öffentliche Datenbank, kein Login-Endpoint, keine Plugins Dritter im Auslieferungspfad. Die im Audit gefundenen Vektoren (User-Enumeration, Author-Slug-Leak, fehlende Header, Application-Password-Endpoint, öffentlicher wp-cron) existieren auf einer statisch ausgelieferten Site schlicht nicht mehr; Security-Header werden zentral am Edge gesetzt und sind im Repository versioniert.
• Kosten: einfacheres Hosting, weniger Wartungsstunden. (Genaue Zahlen werden im Betrieb ermittelt.)

Lessons Learned — ehrlich

• Das Content-Schema ist die wichtigste Entscheidung, nicht das Framework. Wer die Datenstruktur sauber definiert, gewinnt unabhängig vom Stack.
• Die Migration ist zu 70 % Inhaltsarbeit, zu 20 % SEO/Redirects, zu 10 % Technik. Wer das umdreht, unterschätzt den Aufwand.
• Astro ist nicht für jede Seite die richtige Wahl. Bei stark dynamischen, eingeloggten oder hochfrequent redaktionellen Szenarien können andere Stacks besser passen.
• “Kein CMS” heißt nicht “keine Redaktion”. Wer ein nicht-technisches Team hat, sollte ein leichtgewichtiges Editor-Frontend einplanen — Astro lässt das offen.

Was bedeutet das für Ihr Projekt?

Wenn Sie eine Website betreiben, die primär Marketing-, Referenz- oder Produktinhalte transportiert, in der Sicherheit und Performance hohe Priorität haben und der Wartungsaufwand spürbar geworden ist, lohnt sich ein ehrlicher Blick auf einen Astro-basierten Stack. Wir begleiten solche Migrationen — vom Content-Audit über das Schema bis zum SEO-erhaltenden Go-live. Sprechen Sie uns gern an.