Zwölf Monate Migration von WordPress zu Astro auf Cloudflare Pages

Der Plattformwechsel von WordPress zu Astro sollte das gesamte Projekt darstellen. Er erwies sich jedoch als reiner Prolog. Inhalte exportieren, Templates in Astro neu bauen, eine statische Website zum Kompilieren und Ausliefern auf Cloudflare Pages bringen, das dauerte nur wenige Wochen. Dann begann das eigentliche Jahr: Redirects, hreflang-Graphen, die strikte Parität von sechs Sprachen und ein Build, der der Plattform entwuchs, auf der er ausgeliefert wurde. Dies ist ein technischer Bericht darüber, wohin die Zeit tatsächlich ging, denn die Zeit ging nicht dorthin, wohin die ursprüngliche Planung sie geschickt hatte.

Die Polemik, falls es eine gibt, richtet sich gegen die oberflächliche 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 dauerhaften Übernehmen der Verantwortung für drei fundamentale Systeme gleich, die WordPress bisher verborgen hat: die Routing-Schicht, den Build-Prozess und die sprachübergreifende Inhaltsstruktur. Keines davon ist unlösbar. Alle sind jedoch fortlaufend zu pflegen.

[!NOTE] Der Fall auf einen Blick

• Projekt: wppoland.com von WordPress zu Astro auf Cloudflare Pages umgestellt, ein hauseigener Neuaufbau unserer eigenen Website
• Umfang: sechs Sprachen, über 14.000 vorgerenderte Seiten mit beschreibenden Slugs und vollständiger Hreflang-Verknüpfung
• Zeitrahmen: Wochen bis zu einem funktionierenden statischen Build, etwa zwölf Monate bis zu einer stabilen, rückfallfreien Suchleistung in internationalen Suchmaschinen
• Build: überschritt die 8-GB-Runner-Grenze von Cloudflare Pages, gelöst durch lokales Bauen mit einem 16-GB-Heap und Ausliefern des Artefakts mit Wrangler
• Redirects: Tausende 301-Regeln, die an Cloudflares 100-KB-_redirects-Grenze stießen und in eine Cloudflare-Functions-Schicht verschoben wurden
• Stack: Astro mit Tailwind CSS, AVIF-Bildpipeline, statisches HTML vom globalen Edge ausgeliefert
• Ergebnis: globaler TTFB unter 40 ms, null dynamische Angriffsfläche, vorhersehbarer KI-Crawler-Zugriff, Parität über sechs Sprachen gehalten

#WordPress-zu-Astro-Migration, die wahren Kosten: TL;DR in 4 Punkten

1. 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.
2. Die Redirect-Schicht ist die erste Überraschung. Tausende zuvor indexierter URLs brauchen jede einen 301-Code, und das schiere Volumen kollidierte mit einer Dateigrößenbegrenzung von Cloudflare Pages, die Regeln stillschweigend verwarf.
3. Die Parität von sechs Sprachen ist fortlaufende Arbeit, keine einmalige Aufgabe. Hreflang, kanonische URLs und Abschnittsstruktur müssen über jede Sprachversion hinweg synchron bleiben.
4. Der Build entwuchs dem hauseigenen Runner der Plattform. Eine Speichergrenze von 8 GB reicht nicht für 14.000 vorgerenderte Seiten; die Antwort war, lokal mit einem 16-GB-Heap zu kompilieren und das fertige Artefakt via CLI 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 dynamisch erzeugt zu werden.
• Prerender - das vollständige DOM jeder Unterseite wird zur Build-Zeit in physische HTML-Dateien geschrieben. Eine Website mit sechs Sprachen multipliziert den Seitenumfang mit der Sprachanzahl.
• Cloudflare Pages - die Hosting-Plattform, die vorgebaute Dateien weltweit über das CDN-Edge-Netzwerk ausliefert und Edge-Logik über Pages Functions ausführt.
• Wrangler - das CLI-Werkzeug von Cloudflare, hier verwendet, um das lokal kompilierte dist/-Verzeichnis direkt hochzuladen und Runner-Grenzen zu umgehen.
• Hreflang - HTML-Header-Attribute, die Suchmaschinen mitteilen, welche URL das lokale Äquivalent in einer anderen Sprache darstellt.
• 301-Redirect - eine permanente HTTP-Weiterleitung, die das Ranking-Signal und die Indexhistorie einer verschobenen URL auf ihre neue Zieladresse überträgt.

#Wochen: der Umzug, den jeder einplant

Die sichtbare Migration ist der Teil, der geschätzt wird, und die Schätzung ist anfangs meist zutreffend. Inhalte werden aus WordPress-MySQL-Tabellen in Markdown-Dateien mit YAML-Frontmatter exportiert. PHP-Templates und Child-Themes werden als Astro-Komponenten mit Tailwind CSS neu geschrieben. Der Build kompiliert sauber und das Deployment landet auf Cloudflare Pages. Eine Content-Website mittlerer Größe erreicht in wenigen Wochen einen funktionierenden statischen Build. Das ist die Phase, die sich in internen Reviews hervorragend präsentiert und das Management überzeugt, dass das Projekt fast fertig sei.

In Wahrheit steht das Projekt erst am Anfang seiner eigentlichen ingenieurtechnischen Herausforderungen. Ein lauffähiger Build beweist lediglich, dass Astro-Komponenten fehlerfreies HTML zusammensetzen können. Er beweist nichts darüber, ob Tausende historischer URLs den Suchverkehr korrekt weiterleiten, ob hreflang-Graphen im Google-Index intakt bleiben oder ob der Node.js-Buildprozess weiteres Inhaltswachstum verkraftet.

#Monate: die Redirect-Schicht, die niemand eingeplant hat

Das erste Quartal nach dem Launch floss in die Redirect-Infrastruktur. Jede URL, die WordPress seit 2006 je erzeugt hatte (einschließlich Datumsarchive, Kategorien, Autoren-Taxonomien und Plugin-Pfade), benötigte eine präzise 301-Weiterleitung auf die neue Astro-Struktur. Ohne eine lückenlose Mapping-Schicht stiegen die 404-Fehler in der Google Search Console sprunghaft an und gewachsenes SEO-Kapital ging verloren.

Auf einer einsprachigen Website ist das eine überschaubare Listenaufgabe. Auf einer Website mit sechs Sprachen und lokalisierten Slugs (deutsche, polnische, norwegische, spanische und portugiesische Pfade) wuchs die Liste auf über 18.000 individuelle Regeln an.

Hier stießen wir auf ein undokumentiertes Limit von Cloudflare Pages: die Datei _redirects besitzt eine harte Grenze von 100 KB. Ab dieser Größe ignoriert der Parser der Plattform überschüssige Zeilen ohne jegliche Fehlermeldung beim Deployment. In der Folge griffen frühe Regeln fehlerfrei, während spätere Regeln in 404-Fehlern endeten. Die Lösung bestand darin, die gesamte Weiterleitungslogik in eine TypeScript-basierte Edge-Middleware (functions/redirect-map.ts) auszulagern, die Weiterleitungen im Arbeitsspeicher mit O(1)-Komplexität auf Edge-Ebene auflöst.

#Monate: sechs Sprachen, die sich für immer einig sein müssen

In herkömmlichen WordPress-Installationen verbergen mehrsprachige Plugins wie WPML oder Polylang die relationalen Verknüpfungen hinter Datenbanktabellen. Ein statischer SSG-Build legt diese Beziehungen in Markup und Dateien vollständig offen.

Sechs Sprachversionen jedes Artikels müssen dauerhaft strukturell synchron bleiben:

• Identische H2- und H3-Gliederung in identischer logischer Reihenfolge.
• Vollständige, wechselseitige hreflang-Verweise im HTML-Head zu allen fünf Geschwister-Sprachen.
• Exakte kanonische URLs, die die regionale Routing-Struktur widerspiegeln.
• Einheitliche Kategorisierung und Taxonomie-Zuordnungen über alle Märkte.

Wenn eine Sprachversion abweicht (etwa durch eine hinzugefügte Unterüberschrift oder einen geänderten Slug), beginnen Suchmaschinen, asymmetrische hreflang-Signale zu ignorieren. Dies führt zu Keyword-Kannibalisierung zwischen Ländermärkten. Aus diesem Grund führten wir automatisierte Paritäts-Prüfskripte ein, die vor jedem Commit die Konsistenz aller Sprachversionen verifizieren.

#Node.js-Speichertopologie bei 14.000 vorgerenderten Seiten

Astro kompiliert statische Seiten in einem einzigen Hauptprozess. Als das Repository auf über 14.000 Unterseiten anwuchs (durch die Kombination aus technischen Leitfäden, Leistungsseiten, Portfolio-Fallstudien und Städteseiten in 6 Sprachen), war das standardmäßige 4-GB-Heap-Limit der V8-Engine rasch erschöpft.

Der Standard-Build-Runner von Cloudflare Pages stellt 8 GB RAM bereit. Während der intensiven TypeScript-Typüberprüfung, der MDX-AST-Transformation und des CSS-Tree-Shakings stürzte der Prozess regelmäßig mit JavaScript heap out of memory ab.

Wir lösten diesen Engpass durch eine Umstrukturierung des Deployment-Prozesses:

1. Lokal gesteuerter Build auf Apple Silicon: Der Build läuft lokal auf M-Series-Prozessoren mit expliziter Heap-Zuweisung über NODE_OPTIONS='--max-old-space-size=12288'. Die Maschine baut 14.477 HTML-Seiten in unter 3,5 Minuten.
2. Prerender-Artefakt-Bereinigung: Astro erzeugt beim Kompilieren das Verzeichnis dist/.prerender für Server-Module. Einzelne Chunk-Dateien erreichten 43,9 MiB, was gegen das 25-MiB-Dateilimit von Cloudflare Pages verstieß. Ein Bereinigungsskript entfernt diese internen Prerender-Chunks vor dem Upload.
3. Direkter Upload via Wrangler: Das verifizierte dist/-Verzeichnis wird direkt ins Cloudflare-Edge-Netzwerk übertragen, wodurch Build-Limits in der Cloud vollständig umgangen werden.

#Modulare Sitemap-Generierung und kanonische Graphen

Eine weitere Herausforderung lag in der Sitemap-Architektur. Die Standardintegration @astrojs/sitemap erzeugte für 14.000 URLs eine einzige gigantische XML-Datei, was Crawling-Budgets belastete und spezifische Noindex-Regeln missachtete.

Wir entwickelten einen modularen Sitemap-Generator, der eine hierarchische Struktur aus 32 verknüpften XML-Dateien erzeugt:

• Ein zentraler sitemap-index.xml-Einstiegspunkt, der auf 6 regionale Sprachindizes verweist (sitemap-de.xml, sitemap-en.xml etc.).
• Jeder Sprachindex unterteilt sich in thematische Blattdateien: Blogbeiträge, Leistungsseiten, Fallstudien und Standortprofile.
• Ein strikter Filter schließt alle Seiten mit noindex-Attribut aus (überwacht durch das Skript check:noindex-sitemaps).

Dank dieser Aufteilung können Suchmaschinen und KI-Crawler die Sitemap-Struktur schrittweise ohne Timeouts abarbeiten.

#Die Werkzeuge, die Sie neu bauen und die WordPress kostenlos gab

Ein oft übersehener Aufwand beim Abschied von einem CMS ist der Neubau jener Qualitätssicherungen, die WordPress und sein Plugin-Ökosystem unsichtbar im Hintergrund ausführten. WordPress verhinderte doppelte Slugs, überwachte Datenbankrelationen und prüfte Links bei der Eingabe. In einem statischen System landet jeder Tippfehler im Frontmatter ungefiltert in der Produktion, sofern er nicht durch automatische Tests abgefangen wird.

Im Laufe von zwölf Monaten etablierten wir eine Testsuite aus 34 automatisierten Qualitäts-Gates (run-gates.mjs), die vor jedem Release ausgeführt werden:

• Interne Link-Integrität (check:links und check:service-navigation-parity): Prüft alle internen Verweise auf 404-Ziele und stellt sicher, dass jede Kernleistung mindestens zwei eingehende Links besitzt.
• Zeichensatz- und Diakritika-Prüfung (check:diacritic-wordlist): Erkennt Zeichensatzfehler und falsche Sonderzeichen in allen sechs Sprachen.
• Preisschutz-Wächter (check:no-own-prices): Verhindert, dass ungeprüfte Stundensätze oder Festpreise in redaktionellen Texten außerhalb freigegebener Preisseiten auftauchen.
• Content Security Policy Validierung (check:csp-inline): Berechnet SHA-256-Hashes für alle Inline-Skripte im generierten HTML und setzt strikte CSP-Header ohne unsafe-inline durch.
• KI-Rhetorik-Audit (check:slop-rhetoric): Filtert nichtssagende Marketing-Floskeln und wahrt eine nüchterne, ingenieurmäßige Tonalität.

Diese automatisierte Testbatterie bietet eine Zuverlässigkeit, die kein WordPress-Backend erreichen kann, erforderte jedoch hunderte Stunden dedizierter Entwicklungsarbeit.

#Typensichere Content-Collections mit Zod-Validierung

Im Unterschied zu WordPress, wo benutzerdefinierte Felder (Advanced Custom Fields / ACF) als unstrukturierte Meta-Einträge in der Tabelle wp_postmeta landen, erzwingt Astro strikte Typsicherheit über Content-Collections mit Zod-Schemata:

• Strikte Typisierung von Metadaten: Jedes Markdown-Dokument wird zur Build-Zeit gegen ein Zod-Schema validiert. Fehlende Pflichtfelder wie title, description, canonicalUrl oder fehlerhaft formatierte ISO-Datumsangaben stoppen den Build sofort mit präzisen Zeilenangaben.
• Schema.org-JSON-LD-Automatisierung: Strukturierte Daten für Suchmaschinen (darunter FAQPage, HowTo und Article) werden typsicher aus dem Frontmatter generiert, wodurch fehlerhafte strukturierte Daten im Google-Suchindex ausgeschlossen sind.
• Automatisierte Beziehungsauflösung: Querverweise zwischen Autoren, Kategorien und mehrsprachigen Äquivalenten werden direkt zur Kompilierzeit aufgelöst, ohne zur Laufzeit relationale Datenbank-Joins ausführen zu müssen.

#Medien-Pipelines und lokale DSGVO-konforme Typografie

In dynamischen WordPress-Setups erfolgt die Bildverarbeitung beim Medien-Upload über GD oder ImageMagick. In Astro wird die Bildoptimierung zu einem integralen Schritt des Build-Prozesses.

Die unbedachte Verarbeitung tausender hochauflösender Rastergrafiken führte anfangs zu Speicherüberlastungen der Sharp-Bibliothek. Wir etablierten eine klare Trennung:

1. Vorab optimierte statische Assets: Dekorative Hintergründe werden vorab in AVIF und WebP umgewandelt und im Verzeichnis public/ abgelegt, sodass sie ohne Compiler-Last direkt vom CDN ausgeliefert werden.
2. Feste Bilddimensionen: Alle Inhaltsbilder erhalten explizite width- und height-Attribute, was Layout-Verschiebungen vollständig unterbindet (Cumulative Layout Shift, CLS = 0.00).
3. Selbst gehostete Schriftarten: Wir entfernten sämtliche Aufrufe zu Google Fonts. Alle Schriftfamilien liegen lokal im WOFF2-Format mit lateinischem Subsetting vor, was Render-Blockaden verhindert und 100%ige DSGVO-Konformität gewährleistet.

#Enterprise-Sicherheit und automatisierte Content-Security-Policy (CSP)

Ein wesentlicher Schwachpunkt gewachsener WordPress-Installationen ist das Risiko von Cross-Site-Scripting (XSS) durch Drittanbieter-Plugins, die unkontrolliert Skripte in den Dokumentenkörper injizieren. In einer statischen Astro-Architektur wird die Sicherheit bereits auf Build-Ebene deterministisch verankert:

1. Vollständige Eliminierung von unsafe-inline: Statt permissive Sicherheitsrichtlinien zuzulassen, analysiert ein automatisierter Build-Schritt (check:csp-inline) jedes generierte HTML-Dokument und berechnet kryptografische SHA-256-Hashes für alle erforderlichen Inline-Skripte.
2. Strikte Header-Verteilung am CDN-Edge: Die resultierende CSP-Richtlinie wird direkt in den HTTP-Headern von Cloudflare Pages forciert, inklusive Strict-Transport-Security: max-age=63072000; includeSubDomains; preload, X-Content-Type-Options: nosniff und Referrer-Policy: strict-origin-when-cross-origin.
3. Isolierte Third-Party-Integrationen: Analyse- und Nachverfolgungsdienste werden streng über definierte Berechtigungsrichtlinien (Permissions-Policy) isoliert, ohne Zugriff auf sensible Browser-APIs wie Geolocation, Mikrofon oder Kamera.

#Astro Islands für interaktive Komponenten ohne JavaScript-Ballast

Der größte architektonische Vorteil von Astro liegt im Prinzip “Zero-JS by default”. Leser redaktioneller Inhalte laden reines HTML und CSS ohne jeglichen JavaScript-Overhead herunter.

Wo Interaktivität technisch zwingend erforderlich ist (etwa bei Kontaktformularen, Filtern oder Kalkulatoren), nutzen wir Astro Islands:

• Das Kontaktformular wird als isolierte Insel mit der Direktive client:visible geladen, wodurch Skripte erst beim Herunterscrollen nachgeladen werden.
• Filterleisten und Kategoriemenüs nutzen client:idle, um Skripte erst in ungenutzten Browser-Zyklen auszuführen, wodurch der Haupt-Thread beim initialen Rendern vollständig frei bleibt.
• Responsive Menü-Elemente nutzen client:media="(max-width: 768px)", sodass Desktop-Nutzer keinerlei Navigations-JavaScript herunterladen oder ausführen müssen.
• Spamschutz erfolgt über eine unsichtbare Cloudflare-Turnstile-Integration ohne störende Bilderrätsel oder Datenschutzkonflikte.
• Formulardaten werden zustandslos über einen Edge-API-Endpunkt an Transaktions-Webhooks (Resend) übermittelt, wodurch kein dauerhafter Server-Backend nötig ist.

#Clientseitige WASM-Suche ohne Datenbanklast

Klassisches WordPress stützt sich bei Suchanfragen auf relationale SQL-Abfragen der Tabelle wp_posts. In einer rein statischen Architektur muss die Volltextsuche ohne Datenbankserver auskommen.

Wir implementierten eine WebAssembly-basierte Volltextsuchmaschine im Browser:

• Während des Builds wird ein kompakter, segmentierter lexikalischer Index aus den Artikelkörpern erzeugt, bereinigt um Navigation, Code-Blöcke und Boilerplate.
• Der Browser lädt bei der Eingabe nur kleine, relevante Index-Chunks (15-30 KB), die Suchergebnisse mit unscharfer Begriffssuche (Fuzzy Matching) und Begriffshervorhebung in unter 15 ms darstellen.
• Mehrsprachige Stoppwort-Wörterbücher und Wortstammbildung (Stemming) gewährleisten hohe Treffgenauigkeit bei minimalem Datenvolumen für alle sechs Sprachen.
• Die Serverlast bleibt selbst bei tausenden parallelen Suchanfragen bei absolut null.

#Kontinuierliche Core-Web-Vitals-Automatisierung in CI/CD

In WordPress-Umgebungen verschlechtern sich Web-Vitals-Werte häufig unbemerkt nach Plugin-Updates. In Astro werden Performance-Budgets als automatisierte CI/CD-Schranken durchgesetzt:

• Lighthouse CI: Jeder Build durchläuft automatisierte Audits für Largest Contentful Paint (LCP < 1,0s), Interaction to Next Paint (INP < 50ms) und Cumulative Layout Shift (CLS = 0,00).
• Visuelle Regressionstests: Automatisierte Playwright-Suiten überprüfen kritische Viewports auf Desktop und Mobilgeräten vor dem Merge.
• Sofortige Edge-Cache-Invalidierung: Nach dem Deployment ruft das Release-Skript die Cloudflare Zone API auf (purge_cache: {"purge_everything": true}), sodass weltweite Edge-Knoten ohne Wartezeit auf s-maxage-Abläufe aktualisierte Inhalte ausliefern.
• Deterministisches Caching für Hashed Assets: Statische CSS-, JS- und AVIF-Dateien tragen den Header Cache-Control: public, max-age=31536000, immutable, während HTML-Dokumente über max-age=0, must-revalidate mit Edge-Tags gesteuert werden. Dies ermöglicht sofortige Rollbacks ohne veraltete Zwischenspeicherartefakte.

#Technische Migrations-Checkliste: 10 Schritte vor dem Abschalten von WordPress

Aus zwölf Monaten Produktivbetrieb leitet sich folgende praxiserprobte Checkliste vor der DNS-Umschaltung ab:

1. Vollständiges Routen-Inventar: Export aller historischen URLs aus WordPress-MySQL-Tabellen (Beiträge, Seiten, Archive, Kategorien, RSS-Feeds, Medienanhänge).
2. Design der Weiterleitungsarchitektur: Erstellung einer lückenlosen 301-Mapping-Tabelle unter Berücksichtigung aller Sprachpfade.
3. Bereitstellung von Edge Functions: Implementierung der Weiterleitungs-Engine in einer Edge Function (Cloudflare Functions / Worker), um statische Dateigrenzen zu umgehen.
4. Hreflang-Netzwerk-Validierung: Sicherstellung vollständiger wechselseitiger Verknüpfungen über alle Sprachversionen des gesamten Korpus.
5. JSON-LD-Schema-Audit: Validierung von Article-, FAQPage-, HowTo- und Organization-Schemas nach schema.org-Standards.
6. Modulare Sitemap-Bereitstellung: Segmentierung der XML-Sitemaps mit striktem Ausschluss aller noindex-Seiten.
7. Heap- und Build-Profiling: Testen der Kompilierung unter Speicherbeschränkungen und Feinjustierung der V8-Heap-Parameter.
8. Sicherheits-Header konfigurieren: Erzwingung von CSP, HSTS, X-Frame-Options und Permissions-Policy auf CDN-Ebene.
9. Indexierungs-Audit: Verifizierung, dass Staging-Umgebungen und Duplikate zuverlässig von der Indexierung ausgeschlossen sind.
10. Post-Cutover Smoke Testing: Automatisierte HTTP-Statuscode-Prüfungen und Monitoring der Search Console direkt nach der DNS-Propagierung.

#Was die Migration tatsächlich einbrachte: 12-Monats-Ergebnisse

Nach zwölf Monaten kontinuierlicher Telemetriedaten ist die Bilanz der Migration zu Astro auf Cloudflare Pages für unsere Content- und Service-Plattform eindeutig positiv:

1. Server-Antwortzeit (TTFB): Rückgang von durchschnittlich 650-1200 ms (unter PHP/MySQL-Last) auf konstante 25-45 ms über alle weltweiten Cloudflare-Edge-Standorte.
2. Beseitigung von Sicherheitsrisiken: Die Abschaffung der PHP-Laufzeitumgebung, der SQL-Datenbank und des wp-admin-Bereichs eliminierte 100% der klassischen CMS-Angriffsvektoren (SQL-Injections, Plugin-Sicherheitslücken, Brute-Force-Angriffe).
3. KI- und Suchmaschinen-Verfügbarkeit: Schlankes, semantisches HTML ohne blockierendes JavaScript ermöglicht es Suchmaschinen und LLM-Crawlern (OpenAI, Anthropic, Perplexity), technische Inhalte unmittelbar zu erfassen (GEO/AEO).
4. Minimale Betriebskosten: Die Bereitstellung statischer Dateien über CDNs verursacht im Vergleich zu hochverfügbaren Datenbank-Clustern vernachlässigbare Infrastrukturkosten.

Das ehrliche Fazit: Die Migration von WordPress zu Astro ist kein oberflächlicher Relaunch. Es ist ein tiefgreifendes Softwareprojekt, bei dem das Erstellen der Templates der leichteste Schritt ist und die Hauptarbeit in Routing-Architektur, automatisierten Qualitäts-Gates und mehrsprachiger Disziplin liegt. Für Plattformen, die globale Spitzenleistung ohne Wartungsaufwand fordern, zahlt sich dieser Schritt in jeder Dimension aus. Wenn Sie diese Architektur für Ihr Unternehmen evaluieren möchten, erfahren Sie mehr über die Arbeitsweise unseres Astro-Entwicklers, oder informieren Sie sich über unseren Leitfaden zur WordPress-zu-Astro-Migration. Weitere ingenieurtechnische Analysen finden Sie im WPPoland-Blog.