Ich habe kürzlich ein WordPress-Projekt zu Strapi migriert und möchte hier meine erprobte Vorgehensweise teilen — inklusive der Schritte, mit denen ich Downtime vermeide und den SEO-Wert der Seite vollständig erhalte. Die Migration ist oft weniger ein technisches Monster als eine Checkliste aus Datenübertragung, URL-Management und sorgfältigen Tests. Ich schreibe das hier aus praktischer Erfahrung, mit vielen kleinen Fehlern, die ich vorher gemacht habe, und den Lösungen, die am Ende zuverlässig arbeiteten.

Warum Strapi statt WordPress — kurz

Ich mag WordPress, aber für manche Projekte ist ein Headless-CMS wie Strapi flexibler: strukturiertere Inhalte, bessere APIs, moderne Deployment-Optionen und volle Kontrolle über das Frontend. Wichtig für die Migration ist: Strapi verändert nicht automatisch URLs oder Meta-Daten — das musst du planen, wenn du SEO nicht verlieren willst.

Vorbereitung: Audit und Strategie

Bevor ich irgendetwas verschiebe, mache ich ein vollständiges Audit:

  • Liste aller URLs (inkl. Query-Varianten) — Sitemap und Crawling mit Screaming Frog oder Sitebulb.
  • Analyse der wichtigsten SEO-Seiten (Traffic, Backlinks, Rankings) — Google Search Console & Analytics.
  • Inventar der Content-Typen, Felder, Medienelemente und benutzerdefinierten Felder (ACF).
  • Prüfung von strukturierten Daten (Schema.org), Meta-Tags, hreflang, Canonicals.

Ergebnis: ein Migrationsplan mit Prioritäten (z. B. Top-100 Seiten zuerst). Das reduziert Risiko und fokussiert meine Zeit auf das, was SEO-technisch zählt.

Datenexport aus WordPress

Für Inhalte nutze ich zwei Wege parallel — WP-CLI bzw. Export-Tools und die WP REST API:

  • WP-Export (XML) für einfache Fälle, aber das ist oft zu limitiert.
  • WP REST API für strukturierte Exporte: Beiträge, Seiten, Taxonomien, benutzerdefinierte Felder. Vorteil: klare JSON-Struktur, einfacher Import in Strapi.
  • Media: Ich synchronisiere /wp-content/uploads per rsync oder über ein S3-Backup, damit alle Medien vorhanden sind.

Ich exportiere zusätzlich eine Tabelle mit old_url → slug/permalink / meta, damit später Redirects und Slugs in Strapi exakt gesetzt werden können.

Strapi-Struktur aufbauen

Bevor Inhalte reinwandern, baue ich in Strapi die Content-Types modular nach:

  • Posts/Articles mit Feldern: title, slug, content (Rich-Text/Blocks), excerpt, featured_image, meta_title, meta_description, canonical, published_at.
  • Taxonomien: categories, tags — als relations abbilden.
  • Custom Fields: ACF-Felder aus WordPress eins zu eins, wenn sie relevant sind.

Wichtig: Slug-Felder sind deterministisch und müssen exakt die alten Permalinks abbilden oder es müssen Redirects geplant sein. Ich lege Felder für "old_url" oder "legacy_id" an, damit Mapping später möglich ist.

Import-Prozess

Für den Import nutze ich ein halbautomatisches Script (Node.js / Python). Ablauf:

  • WP-REST-API → hole JSON für jeden Post/Seite.
  • Transformiere Felder auf Strapi-Schema (z. B. content: wp_content → Strapi Rich Text oder Komponenten).
  • Upload der Mediadateien an Strapi (oder auf S3), und Setzen der Media-Relationen.
  • Erzeuge in Strapi Einträge via Strapi REST API / GraphQL.

Ich beginne mit einem kleinen Batch (10–20 Seiten), prüfe alles im Staging und erhöhe dann schrittweise. So bleibt die Fehlerortung einfach.

URL- und SEO-Handling (wichtig)

SEO erhalten heißt: gleiche oder permanent passende URLs, gleiche Meta-Daten, strukturierte Daten intakt, und Redirects für alles, was sich ändert.

  • Beibehaltung der Permalinks: Wenn möglich, mache die Slugs in Strapi exakt gleich. So bleiben die URLs identisch und es sind keine Redirects nötig.
  • Meta-Felder übertragen: meta_title, meta_description, canonical, robots — genau übernehmen.
  • Strukturierte Daten: JSON-LD-Snippets aus WordPress ins neue Template kopieren oder dynamisch generieren.
  • Redirect-Plan: Für abweichende URLs lege ich eine Redirect-Tabelle an (CSV: old_url,new_url,status). Diese importiere ich später in den Webserver (nginx) oder in Cloudflare Pages/Netlify Redirects.

Beispiel für eine Redirect-Tabelle, die ich im Deploy verwende:

old_urlnew_urlstatus
/blog/alter-beitrag/blog/neuer-beitrag301
/category/xyz/tags/xyz301

Zero Downtime Deployment — mein Setup

Null Downtime ist möglich, wenn du Frontend, API und DNS sauber planst. Meine Checkliste:

  • Staging-Umgebung: Vollständige Strapi-Instanz + Frontend (Next.js / Nuxt) auf Staging-URL. Teste Rendering, Metas, Structured Data.
  • Paralleles Betreiben: Plugin im Frontend, das bei Bedarf noch auf die alte WordPress-API zurückfällt (Feature-Flag) – selten nötig, aber beruhigend.
  • DNS- und Proxy-Strategie: Ich nutze einen Reverse-Proxy (nginx) oder Cloudflare. Wenn Strapi + Frontend fertig sind, weise ich per Load-Balancing oder per DNS-CNAME auf die neue Infrastruktur. TTL der DNS-Einträge vorher auf niedrig setzen (z. B. 60s).
  • Redirects auf Proxy-Level: Lade die Redirect-Liste ins nginx-Server-Block oder als _redirects in Netlify / rules in Cloudflare, damit alle Anfragen korrekt gedeutet werden, während die Umschaltung passiert.
  • Health-Checks: Setze Health-Checks und Monitoring (UptimeRobot, status pages). Ich teste mit curl die wichtigsten URLs direkt gegen die neue IP vor der DNS-Änderung.

Tests nach dem Cutover

Nach der Umschaltung folge ich einer strikten Testliste:

  • Crawl der gesamten Seite (Screaming Frog) — prüfe 200/301/404-Status und canonical Tags.
  • Vergleich der Seiteninhalte auf Top-Pages (Text, H1, Meta).
  • Google Search Console: neue Sitemap einreichen und Coverage prüfen.
  • Monitoring der Rankings und organischen Visits — speziell die Top-100 Keywords beobachten.

In my experience, leichte Ranking-Fluktuationen sind normal für 1–2 Wochen. Wenn technische Dinge stimmen (noindex versehentlich gesetzt? canonical falsch?), stabilisiert sich alles wieder.

Typische Stolpersteine und wie ich sie löse

  • Fehlende Bilder/kaputte Pfade: Ursache meist falscher Media-URL-Mapping. Lösung: absolute URLs in Strapi setzen oder ein CDN nutzen, und checken, dass alle Medien-IDs korrekt zugewiesen sind.
  • Verlorene Meta-Daten: Manchmal werden SEO-Felder nicht gemappt. Lösung: Extra-Importscript schreiben, das meta_title/meta_description per API nachträgt.
  • Canonical verweist auf alte Domain: Prüfen, ob environment-Variablen korrekt gesetzt sind (PRODUCTION_URL) und in Templates genutzt werden.
  • Performance-Probleme: Strapi-Server horizontal skalieren (PM2, Docker + Kubernetes) und Caching (Edge/SSR cache) aktivieren.

SEO Monitoring nach der Migration

Ich verfolge die Migration aktiv mit:

  • Google Search Console (Index Coverage, URL Inspection).
  • Rank-Tracking für die wichtigsten Keywords (z. B. Ahrefs, SEMrush).
  • Logfile-Analyse, um Crawl-Budget und Bot-Verhalten zu prüfen.
  • Berichte aus Google Analytics — Traffic vergleichen Woche zu Woche.

Wenn ein unerwarteter Traffic-Einbruch auftritt, priorisiere ich technische Checks (noindex, robots.txt, canonical, Redirects) — die meisten Probleme sind dort zu finden.

Praktische Tools und Snippets, die mir geholfen haben

  • WP-CLI & WP REST API — schneller Export.
  • Node-Scripts (axios + Strapi-API) für automatisierten Import.
  • rsync / s3 sync für Medien.
  • Screaming Frog, Google Search Console, Ahrefs für SEO-Audit und Monitoring.
  • Cloudflare / nginx für Redirect-Management und Zero-Downtime Umschaltung.

Wenn du möchtest, kann ich dir die Node-Import-Snippets, ein Beispiel für ein Redirect-CSV-Parser-Script oder ein minimal funktionierendes nginx-Redirect-Block zur Verfügung stellen. Bei großen Projekten begleite ich solche Migrationen gern Schritt für Schritt — oft reichen zwei bis drei Testläufe, um die kritischen Punkte auszumerzen. Frag mich einfach nach dem Bereich, zu dem du konkrete Beispiele brauchst.