Der Plattformwechsel von WordPress zu Astro sollte das Projekt sein. Er erwies sich als der Prolog. Inhalte exportieren, Templates neu bauen, eine statische Website zum Kompilieren und Ausliefern auf Cloudflare Pages bringen, das dauerte Wochen. Dann begann das eigentliche Jahr: Redirects, hreflang, die Parität von sechs Sprachen und ein Build, der der Plattform entwuchs, auf der er ausgeliefert wurde. Dies ist ein Bericht darüber, wohin die Zeit ging, denn die Zeit ging nicht dorthin, wohin die Planung sie geschickt hatte.
Die Polemik, falls es eine gibt, richtet sich gegen die Auffassung des Plattformwechsels als einmaliger Umzug. “Weg von WordPress hin zu einer statischen Website” klingt nach einer einmaligen Migration. Für eine mehrsprachige Content-Website kommt es eher dem Übernehmen der Verantwortung für drei Systeme gleich, die WordPress bisher verborgen hat: die Routing-Schicht, den Build und die sprachübergreifende Struktur. Keines davon ist schwer. Alle sind fortlaufend.
WordPress-zu-Astro-Migration, die wahren Kosten: TL;DR in 4 Punkten
- Der Umzug ist der billige Teil. Templates und Inhaltsexport dauerten Wochen; die Migration brauchte etwa zwölf Monate, um eine stabile, rückfallfreie Suchleistung zu erreichen.
- Die Redirect-Schicht ist die erste Überraschung. Tausende zuvor indexierter URLs brauchen jede einen 301, und das schiere Volumen kollidierte mit einer Dateigrößenbegrenzung von Cloudflare Pages, die Regeln stillschweigend verwarf.
- Die Parität von sechs Sprachen ist fortlaufende Arbeit, keine Aufgabe. Hreflang, kanonische URLs und Abschnittsstruktur müssen über jede Sprachversion hinweg abgestimmt bleiben, für immer.
- Der Build entwuchs dem hauseigenen Runner von Cloudflare. Eine Build-Grenze von 8 GB reicht nicht für Tausende vorgerenderter Seiten; die Antwort war, lokal mit einem 16-GB-Heap zu bauen und das fertige Artefakt auszuliefern.
Glossar: statischer Build, Prerender, hreflang, Edge
Der Bericht stützt sich auf einige Plattformbegriffe.
- Statischer Build - die gesamte Website wird im Voraus, während eines Build-Schritts, in einfache HTML-Dateien gerendert, statt pro Anfrage.
- Prerender - das HTML jeder Seite zur Build-Zeit erzeugen. Eine Website mit sechs Sprachen multipliziert die Seitenzahl mit der Zahl der Sprachen, daher skaliert der Build mit Inhalt mal Sprachen.
- Cloudflare Pages - der Host. Er liefert die vorgebauten Dateien vom Edge aus und kann auch den Build ausführen, innerhalb der Speichergrenzen.
- Wrangler - das Kommandozeilenwerkzeug von Cloudflare, hier verwendet, um ein lokal gebautes Artefakt direkt auszuliefern und den Build-Schritt der Plattform zu umgehen.
- Hreflang - die Verweise, die Suchmaschinen sagen, welche Seite die deutsche, polnische oder spanische Version desselben Artikels ist.
- 301-Redirect - eine permanente Weiterleitung, die das Ranking-Signal einer verschobenen URL auf ihre neue Adresse überträgt.
Wochen: der Umzug, den jeder einplant
Die sichtbare Migration ist der Teil, der geschätzt wird, und die Schätzung ist ungefähr richtig. Inhalte kommen aus WordPress heraus, Templates werden in Astro mit Tailwind neu gebaut, ein Build kompiliert, ein Deploy landet auf Cloudflare Pages. Eine Content-Website mittlerer Größe erreicht in Wochen einen funktionierenden statischen Build. Das ist die Phase, die sich gut demonstrieren lässt und jeden überzeugt, dass das Projekt fast fertig ist.
Es ist nicht fast fertig. Es ist über den Teil hinaus, der leicht vorherzusagen war, und kommt beim Teil an, den niemand eingeplant hat. Der funktionierende Build beweist, dass die Templates rendern; er beweist nichts darüber, ob die alten URLs aufgelöst werden, ob die Sprachen sich untereinander einig sind oder ob der Build noch durchläuft, wenn sich der Inhalt verdreifacht.
Monate: die Redirect-Schicht, die niemand eingeplant hat
Der erste Monat des langen Schwanzes ging in Redirects. Jede URL, die WordPress je veröffentlicht und Google je indexiert hatte, brauchte einen 301 auf ihre neue Astro-Adresse, sonst wurde sie zu einem 404 und das Ranking-Signal verflüchtigte sich. Auf einem einsprachigen Blog ist das eine lange Liste. Auf einer Website mit sechs Sprachen und beschreibenden Slugs läuft sie in die Tausende.
Dieses Volumen prallte gegen eine Wand, die ihren eigenen Feldbericht hat: Cloudflare Pages verwirft _redirects-Regeln über einer Dateigrößenbegrenzung von 100 KB stillschweigend, ohne Warnung, sodass ein Teil der Redirect-Map grün ausgeliefert wurde und nie griff. Das Symptom zeigte sich Monate später als 404er in der Search Console und nicht verfügbare Produktseiten im Merchant Center, lange nachdem die Migration fertig aussah. Die Lektion lässt sich über Cloudflare hinaus verallgemeinern: bei einem Plattformwechsel ist die Redirect-Map kein Punkt auf einer Checkliste, den man abhakt; sie ist ein System, das man betreibt, mit eigenen Fehlerarten und eigenem Monitoring.
Monate: sechs Sprachen, die sich für immer einig sein müssen
WordPress verbirgt mit den richtigen Plugins die mehrsprachige Struktur hinter einem Backend. Ein statischer Build legt sie offen. Sechs Sprachversionen jedes Artikels müssen strukturell parallel bleiben: dieselben Abschnittsüberschriften in derselben Reihenfolge, hreflang-Verweise, die tatsächlich zu jeder Geschwister-Version auflösen, kanonische URLs, die dorthin zeigen, wohin sie sollen, und Taxonomie-URLs, die über die Sprachen hinweg passen. Wenn eine Sprache abdriftet, bricht der sprachübergreifende Link-Graph auf der Indexierungsebene, während jede Seite weiterhin einwandfrei rendert.
Das hängt direkt mit einer anderen Fehlerart zusammen, wie sie in wie KI-Übersetzung mehrsprachiges SEO kaputtmacht beschrieben ist: Übersetzungswerkzeuge, die strukturelle Felder berühren, erzeugen einen Sprachdrift, der auf der Seite unsichtbar und im Index teuer ist. Nach der Migration hörte die Parität auf, ein Meilenstein zu sein, und wurde zu einer ständigen Prüfung, ausgeführt bei jeder Inhaltsänderung, denn sechs Sprachen bleiben nicht von selbst abgestimmt.
Die Werkzeuge, die Sie neu bauen und die WordPress kostenlos gab
Ein leiserer Preis des Abschieds von WordPress ist, dass Sie die Verantwortung für Prüfungen erben, die die Plattform und ihre Plugins bisher unsichtbar erledigten. WordPress validierte interne Verweise über seinen Editor, hielt eine Sitemap über ein Plugin aktuell und warnte im Backend vor kaputten Verweisen. Ein statischer Build tut nichts davon von allein; Sie bauen es nach, oder Sie liefern Rückfälle aus.
Über das Jahr bedeutete das eine kleine Bibliothek von Validatoren, die in den Deploy eingebunden waren: Validierung interner Verweise gegen die echte Routenfläche, damit ein umbenannter Slug keine hängenden Verweise hinterlässt, Prüfungen strukturierter Daten, damit das Schema im Frontmatter über die Sprachen hinweg wohlgeformt bleibt, Paritätsprüfungen, die Geschwister-Sprachen auf fehlende Abschnitte vergleichen, und ein Generator für Sitemap und hreflang zur Build-Zeit. Jede davon ersetzt etwas, das WordPress stillschweigend tat. Unterm Strich mehr Kontrolle und mehr Sicherheit (die Prüfungen sind explizit, versioniert und laufen in CI), aber es ist echtes Engineering, das das Wort Migration nicht erwähnt. Wer einen Plattformwechsel kalkuliert, sollte diese Position hinzufügen: Sie verschieben nicht nur die Inhalte, Sie implementieren die Leitplanken neu, die die alte Plattform kostenlos anlegte.
Monate: der Build, der seinem Host entwuchs
Die letzte Überraschung war mechanisch. Cloudflare Pages liefert eine große statische Website mühelos aus, doch eine zu bauen ist durch Speicher begrenzt, und der hauseigene Build-Runner der Plattform stößt bei 8 GB an die Decke. Eine mehrsprachige Astro-Website mit Tausenden vorgerenderter Seiten, wobei jede Sprache die Zahl multipliziert, braucht mehr Heap als das, und der Plattform-Build begann mit Out-of-Memory-Fehlern zu scheitern, deren Erkennung einige Zeit brauchte.
Die Lösung war, mit dem Bauen auf der Plattform aufzuhören. Die Website baut nun lokal mit einem 16-GB-Heap, und die fertige Ausgabe wird mit Wrangler auf Cloudflare Pages geschoben, das ein Artefakt ausliefert, ohne es neu zu bauen. Eine lokale Maschine der M-Serie schließt den Build zuverlässig in Minuten ab, wo der eingeschränkte Runner ihn überhaupt nicht abschließen konnte. Bilder erzwangen eine verwandte Disziplin: alles, was durch die Asset-Pipeline von Astro läuft, wird zur Build-Zeit optimiert, was hervorragend, aber speicherhungrig ist, daher werden vorab optimierte Hintergründe unverändert aus dem Public-Verzeichnis ausgeliefert und nur Bilder, die von der Verarbeitung profitieren, bleiben in der Pipeline, in vernünftiger Größe gehalten, damit der Build unter seiner Decke bleibt.
Was die Migration tatsächlich einbrachte
Klar gesagt, damit das Jahr nicht wie Reue klingt: der Wechsel hat sich gelohnt. Seiten rendern vom Edge als statische Dateien, was schneller und stetiger ist als das Rendern auf Anfrage, die Angriffsfläche schrumpfte auf ungefähr nichts Dynamisches, und der Crawler-Zugang wurde vorhersehbar, statt vom Verhalten der Plugins abzuhängen. Für eine Content-Website, auf der Geschwindigkeit, Stabilität und zuverlässige Lesbarkeit für Such- und KI-Crawler der Sinn der Sache sind, ist das der richtige Tausch.
Die ehrliche Einschränkung ist dieselbe, die jedem Plattformwechsel vorausgehen sollte: es ist der richtige Tausch für eine Content-Website und der falsche für eine Website, die von dynamischer, eingeloggter Funktionalität lebt, wo das Rendern zur Anfragezeit und das Ökosystem von WordPress das Feature sind, nicht die Last. Die Entscheidung lautet nicht “statisch ist besser”. Sie lautet “statisch ist besser für diese Art von Website, und hier ist das Jahr Schwanzarbeit, das das Wort Migration verbirgt”. Mehr Engineering-Berichte aus diesem Umbau finden Sie im wppoland-Blog.
