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: vorgebautes HTML und lokal bereitgestellte Schriften reduzieren die Arbeit beim Seitenaufruf. Lighthouse dient zur technischen Prüfung; reale Ladezeiten hängen auch von Gerät und Verbindung ab.
• 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 aufwendig, 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.

Wartungsbedarf der bisherigen Website

Eine WordPress-Installation benötigt regelmäßige Pflege von Core, Plugins, Zugängen und Serverkonfiguration. Für unsere überwiegend redaktionelle Website wollten wir diese laufenden Aufgaben reduzieren. Statische Auslieferung entfernt die WordPress-Laufzeit aus dem öffentlichen Betrieb; Webserver, Abhängigkeiten und Sicherheitskonfiguration bleiben weiterhin zu pflegen.

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 – der Webserver liefert vorgebaute Dateien aus. Eine PHP-Laufzeit, WordPress-Datenbank und ein öffentliches CMS-Login werden dafür nicht benötigt.
• 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. Weiterleitungen: entfernte Seiten erhalten passende Ziele. Beispielsweise führt die frühere Ausbildungsseite zur Über-uns-Seite.
5. SEO-Bausteine: JSON-LD für Organisation, Breadcrumbs, FAQs und Case Studies; saubere <title>-/Meta-Beschreibungen pro Seite.
6. Build und Hosting: Astro erzeugt die statischen Dateien. Nginx liefert sie aus; Serverkonfiguration und Container-Setup liegen im Projekt.

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: vorgebautes HTML und lokal bereitgestellte Schriften reduzieren die Arbeit beim Seitenaufruf. Lighthouse dient zur technischen Prüfung; reale Ladezeiten hängen auch von Gerät und Verbindung ab.
• Redaktionsworkflow: neue Referenz oder Leistung = neue Markdown-Datei mit Schema. Konsistenz wird vom System erzwungen, nicht von Disziplin.
• Sicherheit: WordPress-spezifische Laufzeit-Endpunkte entfallen. HTTP-Sicherheitsheader werden separat in der Nginx-Konfiguration gesetzt; sie entstehen nicht automatisch durch statische Auslieferung.
• Betrieb: keine separate WordPress-Datenbank und keine PHP-Laufzeit für die Website. Das vereinfacht die eingesetzte Infrastruktur.

Lessons Learned – ehrlich

• Das Content-Schema ist die wichtigste Entscheidung, nicht das Framework. Wer die Datenstruktur sauber definiert, gewinnt unabhängig vom Stack.
• Inhalte und URLs verdienen eigene Planung. Das technische Grundgerüst ist nur ein Teil der Migration.
• 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.