2017 rief mich ein Kunde in Panik an. Sie hatte die Website ihres Blumengeschäfts mit GoDaddys Website-Builder gebaut, das dauerte ein Wochenende, sah auf dem Handy ordentlich aus, und sie war stolz darauf. Dann wollte sie einen einfachen Eventkalender hinzufügen. Nur einen Kalender. GoDaddy konnte das nicht. Nicht ohne einen Workaround, der so hässlich war, dass sich ein Junior-Entwickler geschämt hätte. Am Ende zahlte sie mich dafür, das Ganze zu WordPress zu migrieren, und ich erinnere mich, dass ich dachte: Warum fangen die Leute überhaupt hier an?
Wichtigste Erkenntnis: GoDaddys Builder handelt Flexibilität gegen Einfachheit stärker ein als seine Konkurrenten; WordPress, Webflow und Squarespace bieten alle bei vergleichbaren Kosten mehr Spielraum.
Ich verstehe das, ehrlich gesagt. GoDaddys Pitch ist verführerisch. Registrieren Sie sich, wählen Sie ein Template, geben Sie Ihren Geschäftsnamen ein, gehen Sie noch vor dem Mittagessen live. Für jemanden, der sich noch nie mit einem CMS befasst hat, fühlt sich diese Geschwindigkeit wie eine Superkraft an. Aber es ist nur geliehene Zeit. Und nachdem ich bei Seahawk weit über 12.000 Websites gebaut habe, habe ich mittlerweile den Überblick verloren, wie viele GoDaddy-Migrationen ich für Clients durchgeführt habe, die schneller daraus herausgewachsen sind, als sie erwartet hätten.
Also lass mich dir sagen, worauf ich Kunden (und mich selbst) tatsächlich migriert habe und warum.
---
Das GoDaddy-Builder-Problem ist nicht die Geschwindigkeit, es sind die Grenzen
GoDaddys Website-Builder ist wirklich schnell zu handhaben. Ich will mir da nichts vormachen. GoDaddy Airo, ihre KI-Schicht, kann eine markengebundene Website mit Logo und E-Mail-Kampagnen-Templates gerüstet haben, bevor Sie Ihren Kaffee zu Ende getrunken haben. Der Editor ist sauber, intuitiv und nicht abschreckend für Menschen, die nicht wissen, was ein div ist und das auch gar nicht lernen wollen.
Aber.
Du kannst Abschnitte nicht frei verschieben. Du kannst HTML oder CSS nicht bearbeiten. Du kannst Layouts nicht über die vorgebackenen Optionen hinaus ändern. Und du kannst mit Sicherheit kein Plugin installieren, das nicht in ihrem geschlossenen Ökosystem existiert. Wie eine gründliche Bewertung des Builders es deutlich ausdrückt: Der Komfort des Setups ist real, aber sobald du etwas über die Grundlagen des Designs hinaus möchtest, stößt du auf eine Mauer.
Diese Mauer ist das Problem. Nicht der Builder selbst.
Ich hatte einen Kunden, eine Physiotherapie-Klinik in Bristol, die seit drei Jahren bei GoDaddy war. Eine schön aussehende Website. Dann wollten sie Online-Buchungen mit Aufnahmformularen, Integration mit ihrer Praxisverwaltungssoftware und einen Mitgliederbereich für eine Videobibliothek mit Übungen. Wir verbrachten zwei Stunden damit, zu überprüfen, was GoDaddy nativ unterstützen konnte. Die Antwort war im Grunde nichts auf dieser Liste. Drei Jahre Inhalte, und sie mussten architektonisch von vorne anfangen.
Das ist keine Warnung speziell vor GoDaddy. Das ist eine Warnung davor, Plattformen danach auszuwählen, wie schnell Sie starten können, statt danach, wie weit Sie gehen können.
---
WordPress: Immer noch die sinnvolle Standardwahl für die meisten
Menschen erklären WordPress seit etwa einem Jahrzehnt für tot. Es betreibt immer noch etwa 40% des gesamten Webs. Das ist nicht Trägheit, das ist Netzwerkeffekt in einer Größenordnung, die nichts verdrängt hat.
Warum ich es immer noch empfehle
Das Plugin-Ökosystem allein ist den Preis wert (der, um fair zu sein, kostenlos ist). 60.000+ Plugins bedeuten, dass praktisch jede Funktion, die du dir vorstellen kannst, bereits von jemandem gebaut, von Tausenden von Websites in der Produktion getestet und auf YouTube dokumentiert wurde. WooCommerce für eCommerce. ACF für benutzerdefinierte Felder. Yoast oder Rank Math für SEO. Der Stack ist langweilig und das ist wirklich ein Kompliment.
Für Agenturen ist auch der Talentpool wichtig. Ich kann einen WordPress-Entwickler in London, Lagos oder Ljubljana einstellen und bin mir ziemlich sicher, dass er weiß, was ein Custom Post Type ist. Versuche das mit einem proprietären Builder.
Die WordPress-Vorbehalte, bei denen ich ehrlich bin
Es ist nicht perfekt. Plugin-Konflikte sind real. 40 Plugins aktuell zu halten, ohne etwas zu beschädigen, ist, wie ein Hacker News-Kommentator es ausdrückte, „MySQL-Babysitting". Sicherheit ist ein echtes Problem, wenn du eine alte Version eines schlecht gepflegten Plugins ausführst. Und der Block-Editor (Gutenberg) teilt die Meinungen auf eine Weise, die fast theologisch wirkt.
Aber für einen Client, der echte Flexibilität, Inhaltseigentum und eine Website braucht, die mit ihm wachsen kann? WordPress bleibt meine erste Empfehlung, es sei denn, das Briefing weist eindeutig woanders hin.
---
Headless WordPress und Jamstack: Wenn das Briefing woanders hinweist
Vor etwa drei Jahren häuften sich bei Seahawk Anfragen, in denen Performance keine optionale Ausstattung mehr war, sondern eine harte Anforderung. Schnelle Ladezeiten. Hohe Core Web Vitals-Scores. Der Inhalt musste überall laufen: auf der Website, in der App, möglicherweise auf einem Display im Einzelhandel. Standard-WordPress-Hosting reichte da nicht mehr aus.
Das ist, als wir uns stärker auf Headless-Architektur konzentrierten.
Was Headless wirklich bedeutet (ohne Jargon)
Headless WordPress bedeutet, du behältst WordPress als Backend, als Content-Repository, als Admin-Interface, in das sich dein Kunde einloggt, aber du entkoppelst das Frontend komplett. Der „Head" (das, was Nutzer sehen) wird in einem JavaScript-Framework wie Next.js oder Astro gebaut. WordPress stellt Inhalte über seine REST API oder GraphQL bereit. Das Frontend holt sich diese Daten und rendert sie, wie es will.
Das Ergebnis: blitzschnelle Seitenladezeiten, kein PHP-Rendering-Engpass und totale Freiheit über deine Frontend-Architektur. Die Sicherheit verbessert sich auch, weil die WordPress-Admin-Oberfläche nicht auf die gleiche Weise öffentlich zugänglich ist.
Die Jamstack-CMS-Landschaft
Wenn Sie vollständig auf Jamstack setzen, müssen Sie WordPress nicht einmal als Backend verwenden. Es gibt ein solides und wachsendes Feld von Headless-CMS-Optionen, die speziell für diese Architektur gebaut sind. Ein paar, die ich in Produktion verwendet habe:
- Contentful, ausgereift, gut dokumentiert, leicht teuer bei Skalierung, aber sehr zuverlässig
- Sanity, extrem flexibles Content-Modelling, großartige DX, echtzeitliche Zusammenarbeit für Editorial-Teams
- Storyblok, der visuelle Editor ist wirklich beeindruckend für nicht-technische Clients, die Änderungen in Echtzeit sehen möchten
- Strapi, open-source, selbst gehostet, Node.js-basiert, gut wenn du die Infrastrukturkosten niedrig halten willst
- Directus, unterschätzt, besonders bei datenintensiven Projekten, die eine ordentliche Datenbankabstraktionsschicht brauchen
Keine dieser Optionen ist perfekt für jedes Projekt. Storybloks visueller Editor ist eine Freude für Editoren, aber er bringt auch Komplexität auf der Entwicklerseite mit sich. Sanitys GROQ-Abfragesprache hat eine Lernkurve. Wähle basierend auf dem aktuellen Projekt, nicht auf dem Hype.
---
EmDash: Der Newcomer, den man beobachten sollte (mit Vorbehalten)
Im April 2026 ist etwas Interessantes gelauncht worden. EmDash ist ein neues CMS, das von Cloudflare unterstützt wird, positioniert sich als spiritueller Nachfolger von WordPress, gebaut auf modernen Web-Technologien, mit Plugin-Isolation über Cloudflare Workers, und Inhalte werden als strukturierte Daten gespeichert, die nativ von KI-Tools lesbar sind.
Das Pitch ist wirklich interessant. WordPress läuft auf PHP, was funktioniert, aber nicht unbedingt das ist, was man 2026 von Grund auf neu entwerfen würde. EmDash ist für Edge-natives Deployment, strukturierte Inhalte und eine Welt gebaut, in der KI-Assistenten zunehmend die Art sind, wie Menschen Informationen finden.
Ich habe EmDash noch nicht in der Produktion eingesetzt. Es wurde im Beta-Status gestartet und ich beobachte es. Es gibt einige echte Bedenken, die erwähnenswert sind:
- Das Ökosystem ist brandneu. 60.000 WordPress-Plugins versus... das nicht. Noch nicht.
- Die Plugin-Isolation funktioniert nur auf Cloudflares Runtime, was okay ist wenn du dich auf diese Infrastruktur festlegst, aber einschränkend wenn nicht.
- Es ist ein Beta-Produkt. Innewohnendes Risiko. Ich setze keine Betas vor Clients, die Stabilität brauchen.
Der ehrliche Konsens von Menschen, die es getestet haben, ist: technisch beeindruckend, praktisch unvollständig. Es lohnt sich, in 12-18 Monaten erneut vorbeizuschauen. Ich werde genau das tun.
---
Wie man tatsächlich zwischen diesen Optionen wählt
Das ist das Ding, der meiste „welches CMS ist das beste" Content online behandelt das wie einen Spezifikationsvergleich. Häkchen. Feature-Matrizen. So wählst du aber nicht wirklich eine Plattform für ein echtes Projekt.
So gehe ich tatsächlich vor:
- Frag, was der Klient in 18 Monaten braucht, nicht heute. Wenn sie ein einzelner Florist sind, ist WordPress auf Managed Hosting wahrscheinlich ausreichend. Wenn sie ein VC-gestütztes Startup sind, das 10x Traffic-Wachstum erwartet, entwirf jetzt schon für diese Skalierung.
- Frag, wer es nach dem Launch wartet. Ein Headless-Jamstack-Setup ist brilliant, bis der 58-jährige Marketing-Manager des Klienten einen Blogbeitrag aktualisieren muss. Dann ist es ein Support-Ticket, das nur noch auf Bearbeitung wartet. Stimm die technische Komplexität auf das Team ab.
- Frag, ob Inhalte an mehr als einen Ort gehen. Mehrere Frontends (Web + App + was auch immer) deuten fast immer auf Headless hin.
- Frag nach Integrationen. CRM, Buchungssysteme, Payment-Prozessoren, Analytics, mach diese Übersicht bevor du dich auf eine Plattform festlegst, nicht danach.
- Fragen Sie nach dem Budget für laufende Wartung. Eine selbst gehostete Strapi-Instanz braucht jemanden, der die Node.js-Version aktuell hält. Das kostet Zeit oder Geld. Rechnen Sie das ein.
---
Die Migrations-Realität, über die niemand spricht
Von GoDaddy (oder einem anderen proprietären Builder) wegzuziehen ist nicht trivial. Der Inhalt ist normalerweise in irgendeiner Form exportierbar, aber die Struktur oft nicht. GoDaddy gibt Ihnen keine sauberen Datenbankexporte oder Content-APIs. Sie kratzen normalerweise zusammen, kopieren und fügen von Hand ein oder verwenden Third-Party-Migration-Tools, die etwa 70% der Arbeit machen und den Rest zum manuellen Bereinigen überlassen.
Ich habe genug von diesen Migrationen durchgeführt um einen Prozess zu haben, aber ich will nicht so tun als wäre er elegant. Veranschlag echte Zeit dafür ein. Und überprüf absolut dass dein Domain-Transfer aus GoDaddy sorgfältig abgewickelt wird, sie haben eine Geschichte darin, diesen Prozess reibungsvoller zu gestalten als er sein müsste.
Die gute Nachricht: sobald du weg bist, bist du weg. Clients, die zu WordPress oder einem Headless CMS wechseln, gehen fast nie zurück.
---
FAQ
Ist GoDaddys Website-Builder für irgendetwas gut?
Ehrlich gesagt ja, für ganz spezifische Fälle. Eine Ein-Seiten-Website für einen lokalen Handwerker der nur eine Online-Präsenz und eine Telefonnummer braucht. Eine temporäre Landing Page. Etwas das eine nicht-technische Person innerhalb von Stunden live braucht und nie bedeutend ändern wird. Für diese Fälle ist die Geschwindigkeit beim Setup ein echtes Vorteil. Für alles mit Wachstumsambitionen läufts schnell aus dem Ruder.
Muss ich programmieren können, um zu WordPress zu wechseln?
Nicht unbedingt. Managed WordPress Hosting von Anbietern wie Kinsta, WP Engine oder sogar Hostinger macht die operative Seite viel zugänglicher. Du wirst immer noch etwas Komfort mit der Admin-Oberfläche haben wollen und idealerweise jemanden, den du anrufen kannst, wenn etwas kaputtgeht. Aber viele kleine Geschäftsinhaber betreiben WordPress-Websites, ohne eine Zeile Code zu berühren.
Was ist der Unterschied zwischen einem Headless CMS und einem regulären CMS?
Ein traditionelles CMS (wie klassisches WordPress) handhabt sowohl die Content-Speicherung als auch das Page-Rendering, es ist ein gekoppeltes System. Ein Headless CMS handhabt nur die Content-Speicherung und exponiert sie über eine API. Dein Frontend, gebaut in deinem Lieblings-Framework, holt sich den Content und entscheidet wie er angezeigt wird. Der Vorteil ist Flexibilität und Performance. Der Nachteil ist dass du einen Frontend-Entwickler brauchst, nicht nur einen Site-Builder.
Ist EmDash produktionsreif?
Für die meisten Unternehmen, meiner Meinung nach, nicht. Es wurde im April 2026 in Beta gestartet und das Ökosystem ist wirklich noch sehr jung. Die zugrunde liegende Architektur ist interessant und die Cloudflare-Unterstützung gibt ihr Glaubwürdigkeit. Aber ich würde die primäre Marketing-Website eines Kunden nicht auf einem Beta-CMS hosten, wenn WordPress und bewährte Headless-Alternativen existieren. Behalte diesen Bereich 2027 im Auge.
Kann ich WordPress als Headless CMS nutzen?
Ja, und es ist tatsächlich ein wirklich pragmatischer Mittelweg. WordPress hat eine eingebaute REST API und WPGraphQL ist ein ausgereiftes Plugin, das deinen Inhalt über GraphQL bereitstellt. Du bekommst also die vertraute Admin-Oberfläche, die deine Kunden bereits kennen, das massive Plugin-Ökosystem, aber du baust dein Frontend in Next.js oder Astro und erhältst die Performance-Vorteile eines modernen Jamstack-Setups. Wir haben mehrere Projekte auf diese Weise bei Seahawk ausgeliefert und es funktioniert gut.
---
Die Floristin von 2017 ist immer noch Kundin, falls das zählt. Sie nutzt jetzt WordPress mit einem ordentlichen Buchungs-Plugin und einem funktionierenden Veranstaltungskalender. Seit damals hat sie mich nicht mehr in Panik angerufen. Das ist eigentlich das Ziel – etwas bauen, das aufhört, ein Problem zu sein, damit die Leute ihre eigentliche Arbeit machen können.
Wähle das Langweilige. Wähle das Flexible. Wähle das, das du übergeben kannst.