WordPress zu Astro migrieren – oder WordPress headless weiterbetreiben.

Nicht, wenn der Umzug geplant wird. Wir ziehen vorher alle indexierten URLs, bauen daraus eine vollständige 301-Liste und testen jede Weiterleitung vor dem Go-live. Titel-, Überschriften- und Inhaltsstruktur der tragenden Seiten bleiben stabil; strukturierte Daten und Sitemap werden nachgebaut. Nach dem Launch beobachten wir Indexierung und Rankings mehrere Wochen und korrigieren nach. Kurzfristige Schwankungen sind normal, dauerhafte Verluste sind ein Planungsfehler.

Über den WordPress-Export, die REST-API oder einen direkten Datenbankauszug – je nachdem, wie sauber die Inhalte gepflegt sind. Beiträge, Seiten, Kategorien, Autoren, Medien und Custom Post Types werden auf ein Content-Modell abgebildet und als Content Collections mit Zod-Schema abgelegt. Der Export selbst ist der einfache Teil. Die Arbeit steckt im Aufräumen: Shortcodes, Page-Builder-Markup und über Jahre gewachsene Sonderfälle müssen einzeln entschieden werden.

Ja – die Frage ist nur, womit. Bei der vollständigen Migration pflegen sie Inhalte entweder direkt im Repository, über ein angebundenes Headless CMS oder per Chat. Beim Headless-Weg ändert sich für die Redaktion praktisch nichts: Block-Editor, Medienbibliothek, Rollen und Freigaben bleiben, nur die Auslieferung übernimmt Astro. Wenn Ihr Team täglich publiziert und am Editor hängt, ist genau das der bessere Weg.

Plugin-Funktionen werden nicht migriert, sondern ersetzt oder gestrichen. Caching- und Bild-Plugins entfallen, weil Astro statisches HTML ausliefert und Bildoptimierung eingebaut ist. Formulare, Newsletter, Suche und Consent bekommen jeweils einen Nachfolger. Membership-, Buchungs- und Shop-Plugins sind Anwendungen: Sie bleiben entweder in WordPress oder werden neu gebaut. Wir gehen Ihre Plugin-Liste vor dem Angebot Zeile für Zeile durch – das verhindert die teuren Überraschungen nach dem Launch.

Meistens raten wir davon ab. WooCommerce ist kein Plugin, sondern ein Geflecht aus Katalog, Warenkorb, Checkout, Steuer- und Versandregeln, Zahlungsanbietern und Erweiterungen. Astro kann als Storefront vor einer Commerce-API stehen, aber dann ist es ein Shop-Projekt mit entsprechendem Risiko. Zwei sinnvolle Varianten gibt es: Sie bleiben bei WooCommerce, oder Sie wechseln bewusst auf eine dedizierte Commerce-Plattform. Ein Zwischenweg ist, nur den Marketing-Teil umzuziehen und den Shop unberührt zu lassen.

Headless heißt: WordPress bleibt das Redaktions-Backend, liefert die Inhalte aber nur noch als Daten über die REST-API oder WPGraphQL aus. Das Frontend baut Astro. Astro dokumentiert diesen Betrieb ausdrücklich, es ist also kein Bastelweg. Die bessere Wahl ist es immer dann, wenn Ihre Redaktion den gewohnten Editor behalten soll, Sie aber ein schlankes, schnelles Frontend brauchen. Ausführlich beschreiben wir das unter WordPress als Headless CMS.

Den Rahmen bestimmen drei Größen: die Anzahl unterschiedlicher Seitentypen – nicht der Seiten –, die Menge an Plugin-Funktionen, die ersetzt werden muss, und der Zustand der Inhalte. Ein sauber gepflegter Auftritt mit fünf Seitentypen und drei Plugins liegt deutlich unter einem gewachsenen Portal mit Page-Builder, Mehrsprachigkeit und zwanzig Erweiterungen. Nach der Bestandsaufnahme bekommen Sie eine nachvollziehbare Schätzung mit offengelegten Annahmen.

Wir versprechen keine Prozentzahl, weil wir Ihre Ausgangslage vorher nicht kennen. Was wir zusagen: Wir nehmen Ihre Core Web Vitals vor dem Umzug aus den Felddaten auf und messen nach dem Launch erneut mit denselben Werten. Strukturell spricht viel dafür – vorgerendertes HTML statt Datenbankabfrage pro Aufruf, kein Client-JavaScript, solange keins angefordert wird, und ein Ende des Page-Builder-Markups. Belegt ist es aber erst, wenn Ihre eigenen Zahlen es zeigen.

Unsere Erfahrungswerte für Weg A: ein aufgeräumter Auftritt bis rund 30 Seiten mit vier bis sechs Seitentypen liegt bei drei bis fünf Wochen. Ein typischer Unternehmensauftritt mit Blog und mehreren zu ersetzenden Plugin-Funktionen bei sechs bis zehn Wochen. Gewachsene Portale mit Page-Builder, mehreren Sprachen und eigener Funktionslogik ab zwölf Wochen. Weg B liegt meist bei vier bis acht Wochen. Gerechnet ab Kickoff. Der größte Einzelfaktor sind nicht die Seiten, sondern Ihre Freigabezyklen.

Für Ihre Besucher entsteht keine Lücke: Die WordPress-Seite bleibt bis zur Umschaltung unverändert online, die neue Seite entsteht parallel auf einer Staging-Domain. Umgeschaltet wird erst, wenn der Redirect-Test gegen die vollständige URL-Liste sauber durchläuft. Weil ein DNS-Wechsel nicht bei allen Providern in derselben Minute greift, halten wir beide Auslieferungen kurz parallel. Für den Inhaltsabgleich vereinbaren wir ein Redaktions-Fenster von ein bis zwei Tagen. 4.000 Beiträge sind dabei kein Mengenproblem – der Export ist automatisiert, aufwendig sind die Sonderfälle darin.

Ja, und meistens sauberer als vorher. Jeder Custom Post Type wird zu einer eigenen Content Collection, jedes ACF-Feld zu einem Feld im Zod-Schema – mit dem Unterschied, dass das Schema beim Build prüft, ob ein Eintrag gültig ist. Relationen zwischen Post Types werden zu Referenzen, Repeater und Flexible Content zu verschachtelten Strukturen oder Block-Listen. Der Aufwand steckt im Mapping: Felder, die seit Jahren leer sind, doppelt existieren oder nur ein einziges Mal befüllt wurden, entscheiden wir vorher einzeln.

Ja, aber das Netzwerk-Konzept selbst kommt nicht mit. Statt einer Installation mit zwölf Unterseiten bekommen Sie im Regelfall ein Projekt mit einer gemeinsamen Komponentenbibliothek und einer Collection je Standort – alternativ mehrere Deployments, die sich dieselben Komponenten teilen. Gemeinsame Benutzerverwaltung und netzwerkweite Plugins entfallen. Die entscheidende Frage stellen wir vor der Schätzung: Teilen sich die zwölf Seiten wirklich dieselben Vorlagen, oder sind über die Jahre zwölf Sonderfälle daraus geworden? Das ist der Unterschied zwischen einem Bauteil und zwölf.

Der zieht nicht einfach um – ein Mitgliederbereich ist eine Anwendung, kein Inhalt. Drei Wege sind üblich. Erstens: Der geschützte Bereich bleibt in WordPress, nur der öffentliche Teil zieht um. Das ist häufig die wirtschaftlichste Variante. Zweitens: Ein spezialisierter Dienst übernimmt Authentifizierung und Zahlungen, die geschützten Routen rendern in Astro on demand über einen Adapter. Drittens: Der Bereich wird als eigene Anwendung neu gebaut. Welcher Weg passt, entscheiden Mitgliederzahl, Umsatzanteil und wie tief die Logik im Plugin steckt.

Drei Optionen, und wir zählen vorher aus, welche sich lohnt. Erstens: Bestandskommentare kommen aus dem WordPress-Export mit und werden als Teil des Beitrags statisch ausgeliefert – lesbar und indexierbar, aber ohne neue Beiträge. Zweitens: Ein externer Kommentardienst übernimmt neue Kommentare, eingebunden als Insel, die erst beim Scrollen lädt. Drittens: Kommentare werden bewusst abgeschaltet und die Diskussion wandert dorthin, wo sie ohnehin stattfindet. In der Praxis liegen die letzten echten Kommentare oft Jahre zurück.

Impressum und Datenschutzerklärung sind normale Inhaltsseiten und ziehen unter derselben URL um – wichtig, weil auf beide von außen verlinkt wird und Behörden wie Plattformen sie erwarten. Das Consent-Plugin entfällt; an seine Stelle tritt ein Consent-Werkzeug als Insel, das nur dort JavaScript lädt, wo es gebraucht wird. Häufig schrumpft dabei die Liste der einwilligungspflichtigen Dienste, weil vorher Plugins auf jeder Seite fremde Skripte nachgeladen haben. Die juristische Prüfung der Texte bleibt bei Ihnen beziehungsweise Ihrer Rechtsberatung: Wir bauen um, wir beraten nicht juristisch.

Ehrlich: Der Personalmarkt ist kleiner als bei WordPress – das ist der Punkt, an dem WordPress unschlagbar bleibt. Praktisch wiegt es weniger schwer, als es klingt, weil eine Astro-Komponente im Kern HTML, CSS und JavaScript ist und interaktive Teile in React, Vue, Svelte, Preact, SolidJS oder Alpine.js geschrieben sein können. Wer moderne Frontend-Arbeit kennt, findet sich in wenigen Tagen zurecht. Und nichts davon ist proprietär: Astro steht unter MIT-Lizenz, der Code liegt in Ihrem Repository, nicht in einer Plattform.

Sie behalten alles, was Sie zum Weiterarbeiten brauchen. Repository, Hosting-Account und Domain laufen auf Ihren Namen, nicht auf unseren. Astro steht unter MIT-Lizenz, es gibt keine Plattformgebühr und keinen Baustein, der nur bei uns läuft. Ein Build ist ein Standard-Kommando, ein Deploy ein Standard-Vorgang, den jede Frontend-Agentur ausführen kann. Zur Übergabe gehören eine Dokumentation im Repository und eine Einführungssitzung – auch dann, wenn niemand vorhat, sie je zu brauchen.

Fehler, die aus unserer Umsetzung stammen, beheben wir im Rahmen der vertraglichen Gewährleistung ohne gesonderte Rechnung. Damit das nicht Auslegungssache wird, definieren wir die Abnahme vorher: Redirect-Test gegen die vollständige URL-Liste, Metadaten-Prüfung, Lighthouse-Messung auf Staging, ein Durchgang zur Barrierefreiheit. Was danach an neuen Wünschen kommt, ist Weiterentwicklung und wird getrennt beauftragt. Für den laufenden Betrieb gibt es eine Wartungsvereinbarung – verpflichtend ist sie nicht.

Ja, das ist der Normalfall, und wir bauen darauf hin. Das Projekt ist ein gewöhnliches Repository mit npm-Skripten und Git-Historie; wer schon einmal ein Frontend ausgeliefert hat, kommt hinein. Zur Übergabe gehören eine README mit Setup, Build und Deploy, die dokumentierte Struktur der Content Collections und die Stellen, an denen typischerweise etwas geändert wird. Danach können wir uns auf Wartung beschränken, punktuell unterstützen – oder gar nichts mehr tun. Ein Lock-in wäre für uns ohnehin das schlechtere Geschäft.

Das Framework ja: Astro ist quelloffen und steht unter MIT-Lizenz. Es gibt keine Lizenz- und keine Plattformgebühr, unabhängig davon, wie groß die Seite wird. Kosten entstehen für Entwicklung, Hosting und – falls Sie eines einsetzen – ein Headless CMS.

Im Standardfall nicht. Astro rendert vor und liefert statisches HTML aus, das jedes einfache Hosting oder ein CDN ausliefern kann. Erst Routen, die on demand rendern müssen – Formularverarbeitung, Vorschau, personalisierte Bereiche –, brauchen einen Adapter und eine passende Laufzeit.

Ja, das ist der Kernfall. Beiträge liegen als Markdown oder MDX in einer Content Collection, ein Zod-Schema legt die Pflichtfelder fest, und Übersichten, Kategorien, Autorenseiten und Feeds werden daraus erzeugt. Content Collections bringen dafür Caching für tausende Einträge mit.

Die Voraussetzungen stimmen: Der Inhalt steht als HTML im Quelltext, weil serverseitig gerendert wird, und Titel, Description, Canonicals, Sitemap und strukturierte Daten liegen in den Layouts statt in einem Plugin. Rankings entstehen dadurch nicht automatisch – die Inhaltsarbeit bleibt Ihre.

Astro ist ein quelloffenes Projekt, das öffentlich im withastro-Repository auf GitHub entwickelt wird. Der Lizenztext steht unter MIT und nennt Fred K. Schott als Copyright-Inhaber, mit Jahresangabe 2021. Die aktuelle Major-Linie ist Astro 7; Astro folgt Semantic Versioning.