Unsere Zukunft ohne WordPress: Warum wir zu Payload wechseln

MManfred

Fast 40 % aller Websites weltweit laufen auf WordPress. Die Plattform ist aus gutem Grund so weit verbreitet. Sie ist zuverlässig, hat ausgereifte Workflows und ein riesiges Ökosystem aus Themes, Plugins und Dienstleistern.

Wir selbst haben WordPress viele Jahre eingesetzt. Gerade deshalb wissen wir genau, wo die Grenzen und Probleme liegen. Aus diesem Grund stellen wir unsere eigenen Webprojekte auf eine neue Basis um: Payload CMS. Intern läuft das unter der Projektbezeichnung ARR. ARR umfasst die Plattform selbst, das Deployment-Image und die komplette Deployment-Pipeline. Die Pipeline reicht von der KI-unterstützten Content-Erstellung über Design-System-Management und -Implementierung bis zum automatisierten Deployment als CI-Pipeline.

WordPress: das Für und Wider

Das Gute zuerst. WordPress ist kein Nischenprodukt, sondern die Referenz im Content-Management. Die Installationsbasis ist riesig. Für fast jedes Problem gibt es ein Plugin. Agenturen wie wir können auf einen großen Pool an Know-how zurückgreifen. Stabilität und Planbarkeit sind (waren?) hier keine Marketingbehauptung, sondern gelebte Praxis.

Das Problem ist leider dieselbe Zahl. Fast 40 % Marktanteil bedeuten auch: WordPress ist eines der größten Angriffsziele im Internet. Im Zeitalter der KI werden neue Sicherheitslücken permanent entdeckt und ausgenutzt. Jede Installation muss gepatcht, abgesichert und überwacht werden.

Dazu kommt die Plugin- und Theme-Landschaft. Jeder einzelnen Erweiterung muss man vertrauen. Jede muss gepflegt werden. Jede erweitert die Angriffsfläche. Für uns als Dienstleister bedeutet das: Der Aufwand für einen sicheren WordPress-Betrieb wächst schneller als der Nutzen für den Kunden.

Ein drittes Argument wiegt für uns schwer. Die Workflows von WordPress sind auf die klassische Logik „Content pflegen, Seite online stellen" ausgelegt. Sie passen nicht zu dem, wie wir heute mit KI-gestützten Prozessen arbeiten wollen. Das gilt für die Inhaltserstellung, das Design und das Deployment.

Wohin wir wechseln: Payload CMS

Payload ist ein Open-Source-Content-Management-System auf Basis von TypeScript und Next.js. Auf derselben technologischen Basis entwickeln wir auch unsere anderen Webprojekte. Payload ist „headless": Die Inhalte werden über saubere APIs bereitgestellt. Das Design ist vollständig unter unserer Kontrolle. Es gibt keine vorgefertigte Theme-Struktur, die uns einengt.

Warum Payload für uns die richtige Wahl ist:

  • Code-First statt Klick-Baukasten. Inhalte, Datenmodelle und Logik werden als Code definiert. Das macht sie versionierbar, reviewbar und reproduzierbar. Was bei WordPress im Admin-Interface verstreut liegt, ist bei Payload ein lesbares, testbares Artefakt.
  • Selbst gehostet, kein Vendor-Lock-in. Wir betreiben Payload auf unserer eigenen Infrastruktur mit eigener Datenbank. Kein Abo-Zwang, keine Abhängigkeit von einem SaaS-Anbieter, volle Datenhoheit. Das ist auch im Hinblick auf die DSGVO ein wichtiger Punkt.
  • Moderne Sicherheitslage. Keine Plugin-Flut von Drittanbietern. Alles, was läuft, ist Code, den wir selbst kontrollieren. Wir entscheiden, welche Bausteine eine Installation wirklich braucht. Das sind deutlich weniger als bei einem typischen WordPress-Setup.
  • API-first für KI-Workflows. Inhalte, Medien und Design-Tokens lassen sich programmatisch per REST-API lesen und schreiben. Genau diese Schnittstelle brauchen unsere KI-gestützten Prozesse.
  • Schlank statt überladen. Payload bringt nur mit, was eine Installation wirklich braucht. Keine Theme-Flut, keine Pflicht-Plugins, keine Altlasten aus zwanzig Jahren Marktplatz-Historie. Eine frische, minimale Codebasis heißt: weniger Code zu lesen, weniger Stellen für Fehler, schnellere Builds und Iterationen.

Payload ist kein Nischenexperiment. Zu den Unternehmen und Organisationen, die Payload produktiv einsetzen, gehören unter anderem Microsoft (für das KI-Design-Tool „Designer"), Vodafone, ASICS, Mazda, Sonos und Blue Origin. Wer Content-Plattformen für globale Marken baut, setzt darauf, dass Payload diese Anforderungen erfüllt. Wir profitieren von derselben Reife und demselben Ökosystem.

ARR: von der Inhaltserstellung bis zum Deployment

Der Umstieg auf Payload wäre nur die halbe Miete, wenn wir danach weiterhin jeden Schritt von Hand erledigen müssten. ARR automatisiert den kompletten Weg:

  • Inhaltserstellung: Texte und Seiten liegen als Markdown-Dateien in unserem Content-Repository. Das Repository ist die Single Source of Truth für alles, was veröffentlicht wird. Markdown lässt sich von Menschen genauso wie von KI-Agenten einfach und schnell bearbeiten. Kein Copy-Paste in ein Admin-Interface, keine versehentlich nicht gespeicherten Änderungen.
  • Design: Das Styling der Seiten ist nicht im Code der Anwendung fest verdrahtet. Es wird als Design-Tokens pro Marke bereitgestellt und per API auf die jeweilige Site geschoben. Dahinter steckt unser internes Design-System Biti. Ein Image, viele Sites, jede mit ihrer eigenen Gestaltung.
  • Synchronisation: Ein eigenes Sync-Werkzeug überträgt die Inhalte per REST-API zu Payload. Medien, Metadaten für SEO und die URL-Struktur werden dabei mit übertragen. Auch der Blog-Beitrag, den Sie gerade lesen, ist ein Produkt dieses Systems.
  • Menschliches Gate: Agenten können Inhalte nur vorbereiten. Die finale Fassung und das Veröffentlichen bleiben immer eine bewusste Entscheidung von Menschen. Automatisierung ja, aber mit klaren Entscheidungs- und Kontrollpunkten.
  • Deployment: Änderungen am Code laufen über Pull Requests, eine Build-Pipeline und gepinnte Container-Images auf unsere Server. Das Ausrollen auf die Zielsysteme orchestriert Kestra. Das ist reproduzierbar, nachvollziehbar und ohne manuelle Eingriffe.

Das Ergebnis: Neuer Inhalt durchläuft den Weg von Spezifikationen in Markdown über Entwurf und Inhalt als Markdown-Datei bis zur veröffentlichten Seite ohne Medienbruch. Alles ist mit Git versioniert. Jeder Schritt bleibt dokumentiert und nachprüfbar.

Was das für unsere Kunden bedeutet

  • Schnellere Umsetzung: Inhalte können mit KI-Unterstützung in einem Bruchteil der bisher nötigen Zeit erstellt und ausgerollt werden.
  • Weniger Angriffsfläche: Keine Plugin-Abhängigkeiten, selbst kontrollierter Code, moderne Architektur.
  • Volle Datenhoheit: Inhalte und Hosting bleiben bei uns bzw. beim Kunden. Kein Vendor-Lock-in, keine Abhängigkeit von SaaS-Anbietern.
  • Design-Freiheit: Statt vorgefertigter Themes bestimmt das Designsystem die Optik.

Fazit

WordPress war ein guter Begleiter. Es hat uns genau dorthin gebracht, wo wir heute stehen. Aber die Anforderungen haben sich geändert: mehr Sicherheit, mehr Automatisierung, mehr KI. Payload, bereitgestellt via ARR, ist unsere Antwort darauf. Eine Plattform, die wir kontrollieren. Eine Pipeline, die den Weg von der Idee bis zur veröffentlichten Seite ohne Reibung abbildet.

Das ist eine Entscheidung für unsere eigene Infrastruktur, nicht das Ende von WordPress bei WIT. Bestehende WordPress-Projekte unserer Kunden werden nicht über Nacht abgeschaltet. Sie werden nur auf Anfrage und nach Bedarf migriert. Betreutes Hosting für WordPress mit Divi und WPML (Lizenzen verfügbar) für Ihre eigenen Projekte bleibt weiterhin im Angebot. Neue WordPress-Projekte fangen wir aber nicht mehr an. Neue Projekte starten direkt auf der neuen Basis.

Manfred Wisniewski ist der Inhaber von WIT. Dieser Beitrag wurde mit KI-Unterstützung von ihm erstellt und geprüft.