Ich habe meine 47. WordPress-Website letzte Woche von WordPress migriert. Die Entscheidungsregel, die mich nie im Stich gelassen hat: Wenn du mehr Zeit damit verbringst, gegen WordPress zu kämpfen, als Funktionen zu bauen, dann weg.

Das klingt vereinfacht, ich weiß. Aber nach Jahren der Entwicklung mit WordPress — und Jahren, in denen ich Projekte von WordPress herunterfahre — habe ich die Frage „sollte ich bleiben oder sollte ich gehen" auf etwas Strukturierteres reduziert. Ein Fünf-Fragen-Framework, das dir eine ehrliche, quantifizierbare Antwort gibt. Keine Vibes. Keine Stammes-Loyalität zu PHP oder React. Nur eine Checkliste, die sich auf echte Schmerzpunkte abbildet.

Lass mich dich dadurch führen, und dann sprechen wir darüber, wohin man migriert, was es kostet und welche Fehler deine Migration zerstören, wenn du nicht vorsichtig bist.

Inhaltsverzeichnis

Das 5-Fragen-Framework: Solltest du WordPress verlassen?

Ich habe dieses Framework mit Kunden, mit meinen eigenen Projekten und mit Dev-Teams verwendet, die ihren Stack bewerten. Fünf Ja-oder-Nein-Fragen. Jede zielt auf eine spezifische Kategorie von WordPress-Schmerz ab — Plugin-Überfluss, Kosten, Sicherheit, Performance und Geschwindigkeit.

1. Hast du mehr als 20 aktive Plugins?

Zwanzig ist die Zahl. Nicht weil etwas Magisches daran ist, sondern weil das die Schwelle ist, bei der WordPress aufhört, ein CMS zu sein, und zu einem Frankenstein-Monster wird, das von add_filter-Hooks und Gebet zusammengehalten wird.

Jedes Plugin ist eine Abhängigkeit, die du nicht kontrollierst. Jedes Plugin-Update ist eine potenzielle Breaking Change. Und 2026 hat das WordPress-Plugin-Ökosystem ein Sicherheitsproblem, das schwer zu ignorieren ist: Patchstack meldete über 11.300 Plugin-CVEs allein 2025, ein Anstieg von 42% gegenüber dem Vorjahr. Mehr Plugins bedeutet mehr Angriffsfläche.

Zähle deine aktiven Plugins jetzt. Ich warte.

Wenn du bei 30+ bist, führst du mit fast absoluter Sicherheit Plugins aus, die Funktionalität duplizieren, miteinander kollidieren, oder die nur existieren, weil WordPress nicht nativ etwas tut, das moderne Frameworks out-of-the-box handhaben — Dinge wie Bildoptimierung, Caching, SEO-Meta-Tags oder Formularverarbeitung.

2. Zahlst du mehr als 100$/Monat für verwaltetes Hosting?

WordPress ist „kostenlose" Software, die irgendwie ein Vermögen kostet, um gut gehostet zu werden. Wenn du auf WP Engine, Kinsta oder Flywheel bist, zahlst du wahrscheinlich $30-$115/Monat für eine einzelne Website. Skaliere das auf 5-10 Websites und du schaust auf $300-$600/Monat.

Unterdessen eine statisch generierte Website auf Vercel oder Netlify? Der kostenlose Tier reicht für die meisten Marketing-Sites. Sogar ein Headless-CMS + Next.js-Setup auf Vercel Pro kostet $20/Monat. Das ist kein Apfel-zu-Apfel-Vergleich (WordPress enthält eine Datenbank, Admin-UI, etc.), aber darum geht es — du zahlst für Infrastruktur, die du möglicherweise nicht brauchst.

Wenn deine Hosting-Rechnung dich zusammenzucken lässt, ist das ein Signal.

3. Wurdest du in den letzten 12 Monaten gehackt oder hattest du Ausfallzeiten?

Das ist eine binäre Frage und sie ist wichtiger als die meisten Entwickler zugeben. WordPress betreibt etwa 40% des Webs, was es zum einzeln größten Ziel für automatisierte Angriffe macht. Brute-Force-Login-Versuche, SQL-Injection durch veraltete Plugins, Malware, die über nulled Themes injiziert wird — ich habe alles gesehen.

Wenn du gehackt wurdest, kennst du das Verfahren: Sucuri-Scan, Datenbankbereinigung, Passwort-Rotationen, Client-Panik. Wenn du Ausfallzeiten hattest, weil ein Plugin-Update deine Website um 2 Uhr morgens blockiert hat, kennst du auch dieses Gefühl.

Moderne statische Sites und server-gerenderte Apps ohne öffentliches Admin-Panel haben einfach nicht diese Angriffsfläche. Es gibt kein /wp-admin zum Brute-Force. Es gibt kein xmlrpc.php zum Ausnutzen. Das Sicherheitsmodell ist grundlegend anders.

4. Sind deine Core Web Vitals auf mobil fehlgeschlagen?

Google's Core Web Vitals sind 2026 Standard für SEO. Und WordPress-Websites kämpfen hier konstant. Eine HTTP-Archive-Analyse von 2025 zeigte, dass ungefähr 71% der WordPress-Origins die mobile CWV-Bewertung nicht bestanden — im Vergleich zu deutlich besseren Pass-Quoten für Sites, die auf Frameworks wie Next.js und Astro gebaut sind.

Der Schuldige? Render-blocking CSS von Themes und Plugins. Unoptimierte Bilder, die ohne moderne Formate bereitgestellt werden. Übermäßige DOM-Größe aus Page-Buildern. JavaScript, das überhaupt nicht nötig war. Du kannst Caching-Plugins auf das Problem werfen, aber du behandelst Symptome, nicht Ursachen.

Führe deine Website durch PageSpeed Insights. Wenn dein mobiles LCP über 2,5 Sekunden liegt und dein CLS ausfällt, könnte WordPress selbst der Engpass sein.

5. Möchte dein Team Funktionen schneller versenden, als WP erlaubt?

Das ist die Frage, die für Engineering-Teams am meisten zählt. WordPress's Entwicklungsmodell — PHP-Templates, die Loop, Hooks und Filter, die Gutenberg-Block-API — ist eine bestimmte Art zu bauen. Es ist nicht schlecht. Aber es ist langsam im Vergleich zu komponentenbasierter Entwicklung mit React, Vue oder Svelte.

Wenn dein Team mehr Zeit verbringt:

  • Mit der React-aber-nicht-wirklich-Architektur des Block-Editors kämpft
  • Custom-PHP schreibt, um Theme-Einschränkungen zu umgehen
  • Plugin-Konflikte nach Updates debuggt
  • Auf Full-Page-Cache-Invalidierung wartet

...als tatsächlich Funktionen zu bauen, die deine Nutzer wollen, dann ist das deine Antwort.

Moderne Frameworks lassen dich schneller versenden. Das ist keine Meinung — das ist Physik. Komponentenbasierte Architekturen mit Hot-Module-Reloading, TypeScript und API-gesteuertem Inhalt schlagen die WordPress-Entwicklungsschleife bei Iterations-Geschwindigkeit jedes Mal.

Deine Antworten bewerten

Hier ist die Entscheidungsmatrix. Absichtlich einfach:

Ja-Antworten Empfehlung Begründung
0-1 Bleibe bei WordPress Deine Probleme sind machbar. Optimiere, was du hast.
2 Bleibe, aber plane Beginne, Alternativen zu prototypisieren. Du näherst dich dem Wendepunkt.
3 Beginne zu migrieren Der Schmerz ist echt und er verschwindet nicht. Beginne mit der Planung deiner Migration.
4-5 Gehe jetzt WordPress kostet dich aktiv Zeit, Geld und Sicherheit. Priorisiere Migration.

Ich habe das wahrscheinlich auf 60+ Projekte angewendet. Es hat mir nie einen falschen Positiv gegeben. Die Kunden, die 3+ Punkte erreicht und bei WordPress geblieben sind? Sie kamen 6-12 Monate später zurück, und die Migration war bis dahin schwieriger und teurer.

Wohin migrieren (nach Anwendungsfall)

Hier zerfällt die meisten „Verlasse WordPress"-Artikel. Sie sagen dir, Next.js für alles zu verwenden, oder sie listen 15 CMS-Optionen auf, ohne dir zu sagen, welche zu deiner Situation passt. Lass mich spezifisch sein.

Marketing-Websites und Blogs

Empfohlener Stack: Astro + ein Headless-CMS (Sanity, Storyblok oder Contentful)

Astro wurde im Grunde dazu entworfen, WordPress für Content-Sites zu ersetzen. Es sendet standardmäßig null JavaScript, generiert statisches HTML und unterstützt partielle Hydration für interaktive Komponenten. Deine Lighthouse-Scores gehen von „enttäuschend" zu „perfekt" über Nacht.

Wir bauen viele davon bei Social Animal — unsere Astro-Entwicklungsfähigkeiten sind stark auf genau diesen Migrationspfad ausgerichtet. Paare Astro mit Sanity Studio und deine Content-Editoren bekommen eine bessere Authoring-Erfahrung als WordPress ihnen je gegeben hat.

E-Commerce

Empfohlener Stack: Next.js + Shopify (Headless) oder Medusa.js

Wenn du WooCommerce betreibst, kennst du bereits den Schmerz. WooCommerce ist mächtig aber fragil unter Last, langsam ohne ernsthafte Caching-Infrastruktur und teuer zum Anpassen. Shopify's Storefront API mit einem Next.js-Frontend gibt dir Warenkorb-Funktionalität, Checkout und Bestandsverwaltung ohne deine eigene Datenbank zu betreiben.

Für Teams, die volle Kontrolle und Self-Hosting mögen, hat sich Medusa.js 2026 erheblich entwickelt und ist eine Bewertung wert.

Web-Anwendungen (Dashboards, Portale, SaaS)

Empfohlener Stack: Next.js (App Router) + Headless-CMS für Content-Abschnitte + deine eigene API

Wenn du WordPress mit Custom-Post-Types, ACF und REST-API-Endpoints in eine Anwendung gehackt hast... stopp. WordPress war nie dazu gedacht, ein Application-Framework zu sein. Next.js mit Server-Komponenten, Server-Aktionen und Middleware gibt dir eine echte Anwendungsarchitektur.

Content-Heavy Editorial-Websites

Empfohlener Stack: Next.js oder Astro + Sanity oder Strapi

Editorial-Teams brauchen strukturierte Content-Modellierung, Draft-Vorschau und gemeinsames Bearbeiten. Das ist, wo ein Headless-CMS glänzt. Sanity's Echtzeit-Zusammenarbeit ist Jahre voraus von WordPress's Gutenberg-Editor. Strapi gibt dir eine Self-Hosted-Option mit einem sauberen Admin-Panel.

Anwendungsfall Empfohlenes Frontend Empfohlenes CMS Hosting Geschätzter monatlicher Kosten
Marketing-Website / Blog Astro Sanity oder Contentful Vercel / Netlify $0-$20
E-Commerce Next.js Shopify Storefront API Vercel $29-$79 (Shopify) + $20 (Vercel)
Web-Anwendung Next.js Sanity (für Content) Vercel / AWS $20-$100
Editorial / Publishing Next.js oder Astro Sanity oder Strapi Vercel $0-$99

Vergleiche das mit deiner aktuellen WordPress-Hosting-Rechnung. Für die meisten Teams fallen die Infrastrukturkosten um 30-60%.

Migrations-Zeitplan und Kosten (echte Zahlen)

Ich gebe dir die Zahlen, die niemand veröffentlichen möchte, weil sie Angst haben, Kunden zu erschrecken. Diese basieren auf echten Migrationen, die wir 2025-2026 gemacht und beobachtet haben.

Kleine Website (unter 50 Seiten, einfacher Blog)

  • Zeitplan: 3-5 Wochen
  • Kosten: $5.000-$12.000 (Agentur) / 40-80 Stunden (In-House)
  • Schlüsselaufgaben: Content-Export und Umstrukturierung, Template-Neubau in Astro/Next.js, CMS-Setup, Redirect-Mapping, DNS-Umstellung
  • Schwierigster Teil: Extrahiere Content aus Page-Builder-Shortcodes. Wenn dein Content mit [vc_row] oder Elementor-JSON-Blobs gefüllt ist, veranschlage zusätzliche Zeit für Content-Bereinigung.

Mittlere Website (50-200 Seiten, mehrere Content-Typen)

  • Zeitplan: 6-10 Wochen
  • Kosten: $15.000-$35.000 (Agentur) / 120-250 Stunden (In-House)
  • Schlüsselaufgaben: Alles oben, plus Content-Modellierung im Headless-CMS, benutzerdefinierte Komponentenentwicklung, Formular-Migrationen, Umverkabelung von Drittanbieter-Integrationen (Analytics, E-Mail-Marketing, CRM)
  • Schwierigster Teil: Wiederaufbau von benutzerdefinierten ACF-Feldgruppen und -Beziehungen in einem neuen Content-Modell. Das ist, wo die meisten Zeitschätzungen in die Luft gehen.

Große Website (200+ Seiten, E-Commerce, benutzerdefinierte Funktionalität)

  • Zeitplan: 12-20 Wochen
  • Kosten: $40.000-$80.000+ (Agentur) / 400-800+ Stunden (In-House)
  • Schlüsselaufgaben: Vollständige Content-Prüfung, phasenweise Migrationsstrategie, Data-Migration-Scripts, E-Commerce-Plattform-Migration, Benutzerkonten-Migration, SEO-Erhaltung (Redirects, Sitemap, strukturierte Daten)
  • Schwierigster Teil: SEO nicht zu zerstören. Große Websites haben Jahre an Backlinks, indexierten Seiten und Such-Autorität angesammelt. Eine verpfuschte Redirect-Map kann deinen organischen Traffic für Monate zerstören.

Diese Zahlen mögen hoch erscheinen, aber vergleiche sie mit den Gesamtbetriebskosten des Bleibens bei WordPress für weitere 3 Jahre: verwaltetes Hosting ($100-$300/mo × 36 = $3.600-$10.800), Premium-Plugin-Lizenzen ($500-$2.000/Jahr × 3 = $1.500-$6.000), Sicherheits-Incident-Reaktion ($2.000-$10.000 pro Incident) und Entwicklerzeit für Wartung statt Funktionsentwicklung.

Wenn du über Spezifika für dein Projekt sprechen möchtest, legt unsere Pricing-Seite dar, wie wir das handhaben, und du kannst immer direkt Kontakt aufnehmen.

Die 3 Fehler, die WordPress-Migrationen zerstören

Ich habe gesehen, wie diese Migrationen totschlagen. Nicht „verursachen Verzögerungen" — zerstören sie. Als in, das Team gibt auf und geht zurück zu WordPress, nachdem es Monate und zehntausende Dollar verschwendet hat.

Fehler 1: Migration von Content ohne Umstrukturierung

Der größte Fehler ist, die Migration als Copy-Paste-Job zu behandeln. Du exportierst deine WordPress-Posts und Seiten, importierst sie in ein neues CMS und baust die gleichen Templates neu. Das gibt dir die gleiche chaotische Content-Architektur in einer glänzenderen Box.

Der ganze Sinn der Migration ist die Umstrukturierung. WordPress fördert ein flaches Content-Modell: Posts, Pages und Custom-Post-Types mit ACF-Feldern angebracht. Ein Headless-CMS lässt dich richtige Content-Modelle mit typisierten Feldern, Referenzen und Validierung definieren.

Verbringe die Zeit, dein Content vor dem Schreiben einer einzigen Codezeile zu prüfen. Welche Content-Typen brauchst du wirklich? Welche Felder sind wichtig? Welche Seiten können konsolidiert oder gelöscht werden? Ich habe gesehen, wie 200-Seiten-WordPress-Websites auf 60 Seiten gut strukturierten Contents während der Migration reduziert wurden — ohne Wertverlust.

Fehler 2: Das Redirect-Mapping ignorieren

WordPress-URLs folgen einem spezifischen Muster (/2024/03/post-title/, /category/uncategorized/, etc.). Deine neue Website wird unterschiedliche URL-Muster haben. Jede alte URL muss zu ihrem neuen Äquivalent umleiten, oder du verlierst den SEO-Wert, den diese Seiten aufgebaut haben.

Das ist langweilig, undankbar Arbeit. Es ist auch die einzeln wichtigste technische Aufgabe in der gesamten Migration. Verwende ein Crawling-Tool wie Screaming Frog, um jede indexierte URL zu exportieren, bilde jede zu ihrem neuen Ziel ab und implementiere 301-Redirects.

// next.config.js — Beispiel Redirect-Mapping
const nextConfig = {
  async redirects() {
    return [
      {
        source: '/2024/03/old-post-slug/',
        destination: '/blog/new-post-slug',
        permanent: true,
      },
      {
        source: '/category/:slug',
        destination: '/topics/:slug',
        permanent: true,
      },
      // ... möglicherweise Hunderte davon
    ];
  },
};

Für große Websites möchtest du diese programmatisch aus deinem Content-Export generieren, anstatt sie von Hand zu mappen.

Fehler 3: Editoren kein CMS vor dem Launch geben

Entwickler lieben Migrationen. Content-Editoren hassen sie. Du nimmst das Tool weg, das sie kennen (WordPress) und gibst ihnen etwas Unfamilliäres. Wenn du deine Editoren nicht früh einbeziehst — trainierst sie im neuen CMS, bekummerst dich um ihr Feedback zum Content-Authoring-Workflow, stellst sicher, dass sie tatsächlich ohne Entwickler-Hilfe veröffentlichen können — werden sie rebellieren.

Ich habe gesehen, wie eine Migration zwei Wochen vor dem Launch storniert wurde, weil das Marketing-Team sagte „wir können damit nicht arbeiten". Das Dev-Team hatte eine wunderschöne Astro-Website mit Sanity Studio gebaut, aber niemand hatte den Editoren bis zur Launch-Woche Sanity gezeigt.

Bringe dein Content-Team in Woche 2, nicht Woche 10. Lass sie Test-Content im neuen CMS erstellen. Hör auf ihre Beschwerden. Passe die Studio-Konfiguration an. Das ist, was Annahme macht oder bricht.

FAQ

Woher weiß ich, dass es Zeit ist, WordPress zu verlassen?

Verwende das Fünf-Fragen-Framework oben. Wenn du „Ja" auf drei oder mehr der Fragen antwortest — mehr als 20 Plugins, Hosting über $100/Monat, Sicherheits-Incidents oder dein Team kann nicht schnell genug versenden — ist es Zeit. Das Framework geht nicht um WordPress-Hass. Es geht darum, ehrlich zu bewerten, ob die Plattform dir hilft oder dich zurückhält. Zwei oder weniger? WordPress ist wahrscheinlich immer noch in Ordnung für deine Bedürfnisse, und du solltest dich auf die Optimierung konzentrieren, was du hast.

Was ist die billigste WordPress-Alternative?

Astro mit einem kostenlosen Headless-CMS (Sanity's kostenlosen Plan unterstützt 3 Nutzer, Contentful's kostenlosen Plan unterstützt 5 Nutzer) auf Netlify oder Vercel's kostenlosen Tier bereitgestellt. Gesamtkosten: $0/Monat. Seriös. Für eine Marketing-Website oder einen Blog ist dieser Stack produktionsreif und funktioniert besser als ein $100/Monat verwalteter WordPress-Setup. Der Nachteil ist, dass du einen Entwickler brauchst, der sich mit Astro und dem CMS seiner Wahl auskennt — aber wenn du diesen Artikel liest, bist du das wahrscheinlich.

Wie lange dauert eine Migration von WordPress?

Für eine typische kleine Website (unter 50 Seiten) veranschlage 3-5 Wochen. Mittlere Websites mit 50-200 Seiten und mehreren Content-Typen benötigen 6-10 Wochen. Große Websites mit E-Commerce oder komplexer benutzerdefinierter Funktionalität können 12-20 Wochen dauern. Die größte Variable ist nicht Code — es ist Content. Wenn dein Content sauberer und gut strukturiert ist, geht die Migration schnell. Wenn es in Page-Builder-Shortcodes und tief verschachtelten ACF-Feldgruppen steckt, veranschlage zusätzliche Zeit für Extraktion und Umstrukturierung.

Verliere ich SEO, wenn ich von WordPress migriere?

Du kannst, aber wirst es nicht, wenn du es richtig machst. Der kritische Schritt ist die Implementierung einer vollständigen 301-Redirect-Map von jeder alten URL zu ihrem neuen Äquivalent. Du musst auch deine Meta-Titel, -Beschreibungen und strukturierte Daten (Schema-Markup) bewahren. Durchsuche deine bestehende Website mit Screaming Frog vor der Migration, exportiere alle indexierten URLs und verifiziere jeden Redirect funktioniert nach dem Launch. Die meisten gut ausgeführten Migrationen sehen eine temporäre 2-4-Wochen-Fluktuation im Ranking, gefolgt von Verbesserung dank besserer Core Web Vitals.

Kann ich WordPress stattdessen als Headless-CMS verwenden, anstatt vollständig zu migrieren?

Ja, und das ist ein gültiger Zwischenschritt. Die REST API von WordPress (oder WPGraphQL) lässt dich WordPress als Content-Backend verwenden, während du ein modernes Frontend in Next.js oder Astro baust. Dieser Ansatz lässt deine Editoren die WordPress-Admin-Oberfläche verwenden, die sie kennen, während dein Dev-Team ein schnelleres Frontend baut. Die Nachteile: Du bist immer noch eine WordPress-Installation (mit all seiner Sicherheits- und Update-Overhead), und die REST API kann ohne Caching langsam sein. Ich würde das als Zwischenschritt empfehlen, nicht als Ziel.

Was passiert mit meinen WordPress-Plugins, wenn ich migriere?

Sie verschwinden — und das ist der Sinn. Die meisten Plugins existieren, um Lücken in WordPress zu füllen (SEO, Caching, Formulare, Bildoptimierung, Sicherheit). In einem modernen Stack werden diese vom Framework oder von Build-Tools gehandhabt. Next.js hat eingebaute Bildoptimierung. Astro sendet standardmäßig null JS. Kontaktformulare können Dienste wie Formspree oder Resend verwenden. Analytics wechseln zu Plausible oder Vercel Analytics. Du musst deine Plugin-Liste prüfen und jede zu ihrem Ersatz im neuen Stack abbilden.

Sollte ich alle auf einmal migrieren oder in Phasen?

Für Websites unter 100 Seiten, migriere alle auf einmal. Der Koordinations-Overhead des Betriebs zweier Systeme gleichzeitig ist es nicht wert. Für große Websites (200+ Seiten), erwäge einen phasenweisen Ansatz: Migriere zuerst die Marketing-Seiten und den Blog, behalte komplexe Abschnitte (E-Commerce, Nutzer-Portale) vorübergehend auf WordPress und verwende Reverse-Proxy-Regeln, um beide von der gleichen Domain zu bedienen. Das reduziert Risiko aber erhöht architektonische Komplexität.

Brauche ich eine Agentur, um von WordPress zu migrieren, oder kann ich es selbst machen?

Kommt auf die Website an. Ein Entwickler, der sich mit Next.js oder Astro auskennt, kann einen einfachen Blog in ein paar Wochenenden migrieren. Aber für Websites mit komplexem Content-Modell, E-Commerce, benutzerdefinierter Funktionalität oder hohen SEO-Einsätzen, rettet das Arbeiten mit einem Team, das das schon gemacht hat, echte Zeit und Geld. Wir haben dutzende dieser Migrationen gemacht — die Muster sind vorhersehbar und die Fallstricke sind bekannt. Schau dir unsere Fähigkeiten an oder nimm direkt Kontakt auf, wenn du über deine spezifische Situation sprechen möchtest.