Die Frage hinter der Frage
„Sollten wir auf WordPress bauen oder auf Custom gehen" ist selten eine Technologiefrage. Es ist eine Eigentumsfrage: Wer bearbeitet die Site im zweiten Jahr, wer patcht sie, wer wird angerufen, wenn das Kontaktformular mitten im Launch ausfällt. Ich habe über 12.000 WordPress-Sites durch die Agentur geschickt, die ich mitgegründet habe, und ich betreibe meine eigenen Sites auf Astro und Next.js, also halte ich hier keine Flagge. Die ehrliche Antwort hängt von der Form deines Geschäfts ab, und 2026 gibt es drei echte Optionen, nicht zwei.
Die drei Optionen, ordentlich definiert
WordPress, der klassische Build. Eine Anwendung verwaltet Bearbeitung, Templates und Bereitstellung. Themes und Plugins decken einen absurden Bereich von Anforderungen ab, der Block Editor ist zu einem wirklich fähigen Page Builder geworden, und jeder Marketer, den du einstellen wirst, hat wp-admin bereits benutzt.
Headless. Inhalte leben in einem CMS (WordPress mit WPGraphQL oder Sanity, Storyblok, Payload), und ein separates Front-End, das in Next.js oder Astro gebaut ist, rendert es. Das ist die Architektur, die die Jamstack-Ära benannt hat: Seiten vorab gebaut, von einem CDN bereitgestellt, mit APIs, die die dynamischen Teile handhaben. Das Buzzword verblasste; die Architektur gewann. Die meisten der schnellsten Content-Sites 2026 sind auf diese Weise gebaut, ob jemand Jamstack laut sagt oder nicht. Es gibt einen vollständigen Walkthrough in meinem Headless-WordPress-Leitfaden.
Maßgeschneidert. Das Frontend und das Datenmodell werden für dein Produkt entworfen: eine Next.js- oder Astro-Anwendung mit einer Datenbank, Authentifizierung falls du Benutzerkonten brauchst, und genau die Funktionen, die du angefordert hast – nichts mehr, nichts weniger. Die richtige Form, wenn die Website selbst das Produkt ist und nicht nur eine Broschüre.
Der Vergleich, Seite an Seite
| WordPress | Headless | Maßgeschneiderte Lösung | |
|---|---|---|---|
| Typische Baukosten | 3.000–30.000 USD | 15.000–60.000 USD | 25.000–150.000+ USD |
| Zeit bis zum ersten Launch | 2–6 Wochen | 6–12 Wochen | 10–20+ Wochen |
| Bearbeitungserlebnis | wp-admin, vertraut jedem Marketer | CMS-Studio, sauberes Interface, aber für die meisten Teams neu | was immer du baust, manchmal nichts |
| Performance-Grenze | gut, mit Disziplin | standardmäßig ausgezeichnet (statisch + CDN) | ausgezeichnet, du kontrollierst alles |
| Sicherheitsfläche | größte: Kern, Plugins und Admin zum Patchen | klein: statische Seiten, CMS kümmert sich um Authentifizierung | deins zum Entwerfen und Verteidigen |
| Laufende Wartung | Core- und Plugin-Updates, monatlich | Frontend-Abhängigkeiten + CMS-Abonnement | eine Entwicklerbeziehung, dauerhaft |
| Gestaltungsfreiheit | Theme-gebunden, es sei denn benutzerdefiniertes Theme | vollständig | vollständig |
| Personalpool | enorm | groß und wachsend | Framework-spezifisch, Senior-lastig |
| Am besten für | Marketing-Websites, Blogs, kleiner E-Commerce | Inhalte in großem Maßstab, mehrsprachig, Performance-kritisch | Produkte, Portale, maßgeschneiderte Workflows |
Ist WordPress 2026 veraltet?
Nein. Es betreibt immer noch etwa 43 % des Web, der Block-Editor ist unbemerkt gut geworden, und das Ökosystem bleibt der tiefste Burggraben in der Web-Software. Was auch wahr ist: Der Standard-Pfad (fünfzehn Plugins, billiges Hosting, kein Performance-Budget) erzeugt mittelmäßige Websites, und das war schon immer so. WordPress mit Disziplin betrieben (wenige Plugins, anständiges Hosting, ein Performance-Budget) ist immer noch der schnellste vernünftige Weg zu einer professionellen Marketing-Website.
Warum wechseln Leute dann weg?
Die ehrlichen Gründe: Teams, die das Update-Laufband satt haben, Performance-Grenzen bei Plugin-lastigen Builds und Entwickler, die modernes JavaScript-Tooling bevorzugen. Der ebenso ehrliche Gegenstrom: Teams kommen wegen der Bearbeitungserfahrung zurück, des enormen Personalpools und der Kosten. Beide Migrationen sind real, und ich habe Projekte in beide Richtungen geleitet; das vollständigere Bild findet sich in meinem Beitrag über WordPress-Alternativen. Ein Plattformwechsel behebt Architekturprobleme. Er behebt keine Inhalts-, Positionierungs- oder Eigentumsprobleme, und die sind normalerweise die eigentliche Krankheit.
Auch mit KI ist Custom nicht plötzlich einfach
Hier ist die Wendung für 2026. Claude, Cursor und agentengesteuerte Coding-Tools haben die Kosten für die Code-Produktion zusammenbrechen lassen. Ich habe mit diesen Tools an einem Tag eine funktionierende Website gebaut, und über MCP, das Model Context Protocol, kann ein KI-Assistent nun direkt mit deinem CMS, deiner Datenbank und deiner Deployment-Plattform kommunizieren. Der Abstand zwischen Idee und Demo war nie kürzer.
Production ist ein anderes Spiel. Die Demo umfasst keine Sicherungen, Auth-Randfälle, Monitoring, Dependency-Updates, Barrierefreiheit, SEO-Grundlagen oder den 2-Uhr-Incident. KI komprimiert den Build; sie absorbiert nicht die Verantwortung. Eine nach Gefühl codierte Website, die niemand wartet, wird innerhalb von Monaten zu Legacy-Software, nur schneller und billiger als die alte Sorte. Was KI wirklich geändert hat: Custom-Builds wurden günstiger und besser, weil Senior-Entwickler jetzt ein Vielfaches von dem liefern, das sie früher taten, und WordPress-Builds wurden auch besser, weil die gleichen Tools Themes und Plugins schreiben. Die Lücke verengte sich von beiden Seiten. Das Entscheidungsgerüst blieb intakt.
So triffst du eigentlich die richtige Entscheidung
Wähle WordPress, wenn die Website eine Marketing-Oberfläche ist, nicht-technische Personen sie wöchentlich bearbeiten und das Budget begrenzt ist. Wähle Headless, wenn Content-Operationen ernst gemeint sind (Volumen, Sprachen, mehrere Kanäle) und Performance ein Ranking- oder Conversion-Hebel ist, den du nutzen willst. Gehe Custom, wenn die Website das Produkt ist: Konten, Dashboards, Workflows, Integrationen – die Dinge, die ein Plugin nie richtig hätte machen können. Echte Zahlen für diesen Weg findest du in meiner Aufschlüsselung der Kosten für maßgeschneiderte Webentwicklung.
Dann wende den Test für Jahr zwei an, der alles oben Stehende übertrumpft. Wer ist dafür im Jahr zwei verantwortlich? Eine perfekt gewählte Plattform ohne Verantwortlichen scheitert trotzdem. Wähle den Stack, den dein tatsächliches Team oder dein tatsächliches Budget für externe Hilfe gesund halten kann – der Rest der Vergleichstabelle wird dann zum Detail.