WordPress vs Payload CMS: Entscheidungskriterien für Projekte

Du kennst den Moment vielleicht: Die Website „funktioniert“ – bis sie es plötzlich nicht mehr tut. Nicht, weil sie down ist, sondern weil sie das Team ausbremst. Ein kleines Content-Update wird zur Ticketschleife, ein Plugin-Update zur Zitterpartie, neue Landingpages fühlen sich wie Copy & Paste an. Und irgendwann steht im Raum: „Müssen wir das System wechseln?“

In unseren Projekten ist das selten eine rein technische Diskussion. Es ist eine Organisationsfrage. Wer darf Inhalte veröffentlichen? Wer trägt Verantwortung für Updates? Was passiert, wenn die Person, die „das WordPress kann“, das Unternehmen verlässt? Und wie schnell musst du eigentlich reagieren können, wenn sich Angebote, Förderlogiken oder Kampagnen drehen?

Unser Blick: Konflikt Flexibilität gegen Komplexität

Wir sehen oft einen typischen Wachstumsdruck: Erst ist die Website ein Schaufenster, dann wird sie ein Arbeitswerkzeug. Sie soll Leads bringen, Bewerbungen einsammeln, Events abbilden, Inhalte in mehreren Sprachen liefern, vielleicht sogar an eine App oder einen Mitgliederbereich andocken. Spätestens dann wird das CMS zum Betriebssystem deiner Kommunikation.

Hier kommt unsere erste Heuristik ins Spiel, die wir intern „Drei-Fragen-Check“ nennen. Wenn du alle drei Fragen mit Ja beantwortest, lohnt es sich, Payload ernsthaft zu prüfen – egal, wie gut WordPress sich gerade noch anfühlt: 1) Müssen Inhalte in mehr als einem Kanal landen (Website, App, Newsletter, Portal)? 2) Gibt es klare Freigaben und Rollen, die ihr wirklich lebt? 3) Ist eure Website mehr Produkt als Kampagne, also langfristig weiterzuentwickeln?

Wenn dagegen ein kleines Team schnell publizieren will, Inhalte vor allem auf der Website bleiben und du ein robustes, bekanntes Ökosystem brauchst, dann ist WordPress oft die pragmatische Antwort. Nicht „weil es alle nutzen“, sondern weil Betrieb und Redaktionsrealität zusammenpassen.

Und genau da wird der Vergleich relevant: nicht im Maschinenraum, sondern im Alltag.

WordPress hat einen Grund, warum es so oft auf dem Tisch liegt: Du bekommst schnell etwas live, Redakteur:innen finden sich intuitiv zurecht, und für fast jede Anforderung existiert ein Plugin. In der Praxis heißt das: Wenn du eine klassische Website mit Seiten, Blog, Formularen und einem überschaubaren Team betreibst, kann WordPress ein sehr solides Zuhause sein.

Wo WordPress stark ist

Wir erleben WordPress besonders dann als sinnvoll, wenn die Organisation einen klaren Kommunikationsrhythmus hat: Inhalte werden geplant, veröffentlicht, selten „in Systeme“ weitergereicht. Ein gutes Setup mit sauberem Theme, reduziertem Plugin-Set und klaren Rollen kann Jahre tragen. Und ja: WordPress kann schnell sein – aber das ist eine Frage von Disziplin. Performance entsteht hier nicht automatisch, sondern durch Entscheidungen: Bildgrößen, Caching, Block-Overhead, unnötige Skripte.

Wo es kippt

Die Grenze zeigt sich meist nicht im Frontend, sondern in den Abhängigkeiten. WordPress-Projekte werden schnell zu „Plugin-Landschaften“. Das fühlt sich anfangs wie Flexibilität an, wird später aber Governance: Welche Plugins sind kritisch? Wer testet Updates? Was ist der Plan, wenn ein Plugin nicht mehr gepflegt wird?

Unsere zweite Heuristik nennen wir „Plugin-Schulden-Index“. Nicht als Excel-Tool, sondern als Gespräch: Wenn mehr als ein kleiner Kern eurer wichtigsten Funktionen durch Drittanbieter-Plugins abgedeckt ist (z. B. Multilingual, SEO, Formulare, Custom Fields, Membership), dann steigt eure Betriebs- und Sicherheitslast spürbar. Das ist nicht per se schlimm – aber es muss gewollt sein. Denn mit jeder Abhängigkeit wächst der Aufwand für Tests, Backups, Staging und Rollbacks.

Wir empfehlen in solchen Fällen fast immer ein Setup, das den Betrieb ernst nimmt: Staging-Umgebung, automatisierte Backups, Update-Prozess und klare Verantwortlichkeiten. Wenn du das nicht organisatorisch abbilden kannst oder willst, wird WordPress irgendwann nicht zu „schlecht“, sondern zu „zu teuer im Alltag“.

Ein typischer Ausweg ist dann nicht sofort ein komplettes Replatforming, sondern ein ehrlicher Rebuild innerhalb von WordPress: weniger Plugins, klareres Content-Modell, bessere Templates. Und manchmal ist genau das die richtige Entscheidung.

Wenn wir CMS-Entscheidungen begleiten, reden wir irgendwann weniger über „Kann das System X?“ und mehr über „Wer macht es wirklich?“ Genau hier scheitern viele Vergleiche: Features wirken greifbar, Betrieb wirkt unsichtbar. Aber Betrieb ist das, was du jeden Monat bezahlst – in Zeit, Nerven und Risiko.

Ownership ist eine Rollenfrage

Ein CMS braucht Eigentümer:innen. Nicht juristisch, sondern praktisch: Wer überwacht Updates? Wer entscheidet, welche Erweiterung rein darf? Wer pflegt Rechte und Rollen? Bei WordPress liegt diese Verantwortung oft in einer Mischung aus Agentur, IT und „jemandem aus dem Team, der sich kümmert“. Das kann funktionieren – solange es klar ist.

Bei Payload verschiebt sich Ownership häufig stärker in Richtung Produktteam oder Entwicklungspartner, weil ein Teil der Logik im Code liegt. Das klingt nach „mehr Aufwand“, ist aber oft „mehr Klarheit“: Änderungen sind versioniert, überprüfbar, testbar. Das senkt Überraschungen – setzt aber voraus, dass du ein Minimum an Prozess akzeptierst.

Unsere Betriebs-Brille: Das TCO Gespräch

Wir nutzen dafür eine einfache Gesprächsstruktur, die sich bewährt hat. Wir nennen sie „TCO in drei Töpfen“ (Total Cost of Ownership, aber ohne Controlling-Sprech): Erstens laufende Wartung (Updates, Monitoring, Backups), zweitens Veränderung (neue Inhalte, neue Module, neue Kampagnen), drittens Zwischenfälle (Sicherheitslücken, Plugin-Konflikte, Notfall-Rollbacks).

Viele Teams budgetieren nur Topf zwei – die sichtbare Weiterentwicklung. Topf eins und drei werden „nebenbei“ gemacht. Wenn du ehrlich hinschaust, ist das der Moment, in dem WordPress-Projekte teuer werden können: nicht, weil WordPress teuer ist, sondern weil das System dich dazu einlädt, Betrieb zu unterschätzen.

Vendor Risiko ist nicht nur eine Frage von Lizenz

Ein weiterer Punkt, der selten offen besprochen wird: Vendor-Risiken entstehen auch in Open-Source-Ökosystemen. Bei WordPress können sie sich über Plugins und Themes einschleichen. Bei Payload eher über die Frage, wie gut euer Setup dokumentiert ist und ob ihr eine saubere Codebasis habt.

Unser Tipp aus der Praxis: Egal, wofür du dich entscheidest – investiere früh in Dokumentation und einen reproduzierbaren Build-Prozess. Das ist nicht glamourös, aber es ist die Art von Nachhaltigkeit, die digitale Arbeit wirklich stabil macht.

Sicherheit ist der Teil der CMS-Wahl, den niemand als „Feature“ bestellt – bis es einen Vorfall gibt. Und weil wir mit vielen impact-orientierten Organisationen arbeiten, ist der Schaden nicht nur finanziell. Es geht um Vertrauen.

Unterschiedliche Angriffsflächen

WordPress ist weit verbreitet. Das macht es attraktiv für automatisierte Angriffe, vor allem dort, wo Installationen veraltet sind oder Plugins Schwachstellen haben. Das heißt nicht, dass WordPress unsicher ist. Es heißt: Du brauchst eine Update-Routine, die nicht optional ist.

Payload ist in vielen Setups weniger „von außen“ angreifbar, weil es nicht typischerweise aus tausend Plugin-Bausteinen besteht. Aber dafür hängt Sicherheit stärker an eurem Deployment, euren Umgebungsvariablen, euren Zugangsdaten und daran, wie ihr eure API schützt. Es ist ein anderes Risiko-Profil: weniger Massenangriff, mehr „Betriebshygiene“.

Was wir unter guter Update Strategie verstehen

In unseren Projekten trennen wir klar zwischen „Update machen“ und „Update verantworten“. Verantworten heißt: Du hast eine Staging-Umgebung, du testest kritische Flows (Formulare, Checkout, Suche), du hast ein Rollback, und du weißt, wer nachts erreichbar wäre, wenn etwas schiefgeht.

Für WordPress bedeutet das oft: Plugin-Reduktion, klare Abhängigkeiten, und ein Hosting, das Security ernst nimmt. Für Payload bedeutet es: saubere CI/CD, regelmäßige Dependency-Updates im Node-Ökosystem und eine klare Rechteverwaltung in Admin und API.

Unser Praxisindikator: Rechte sind Produkt, nicht Einstellung

Ein Unique Angle, den wir selten in CMS-Vergleichen lesen, aber ständig erleben: Viele Sicherheitsprobleme sind eigentlich Rollenprobleme. Wenn zu viele Menschen zu viel dürfen, entstehen Fehler – nicht aus Absicht, sondern aus Stress.

Darum behandeln wir Berechtigungen wie UX: Welche Rollen gibt es wirklich? Wer braucht Vorschau, wer darf publishen, wer darf Strukturen ändern? In Payload lässt sich das sehr granular abbilden. In WordPress geht es auch, aber du landest oft bei Rollen-Plugins und Zusatzlogik.

Wenn du unsicher bist, ist das ein guter Test: Schreib eure realen Rollen auf ein Blatt Papier. Wenn das schon schwer ist, ist nicht das CMS euer Problem – sondern die fehlende Governance. Dann lohnt es sich, dort anzusetzen, bevor du migrierst.

Performance ist für uns nicht nur „nice to have“. Sie ist Teil von Barrierefreiheit, Teil von Conversion, und sie ist auch Teil von digitaler Nachhaltigkeit: Weniger Daten, weniger Rechenzeit, weniger Energie – bei dir und bei deinen Nutzer:innen.

Was wir nicht tun: Wir werfen Zahlen in den Raum, die wir nicht sauber belegen können. Es gibt gute Arbeiten über den Fußabdruck digitaler Infrastruktur, etwa zur Größenordnung globaler Emissionen durch digitale Technologien. <cite data-type="source" data-url="https://theshiftproject.org/en/lean-ict/">The Shift Project (2019)</cite>

Für die CMS-Entscheidung hilft dir aber vor allem eine pragmatische Wahrheit aus Projekten: Performance entsteht selten im CMS-Kern, sondern in dem, was du drum herum baust.

WordPress: Gewicht durch Komfort

WordPress kann sehr schnell sein – aber viele WordPress-Seiten werden schwer, weil der Baukasten bequem ist. Page Builder, zusätzliche Frontend-Libraries, Slider, Tracking, fünf Formular-Tools parallel. Das summiert sich. In der Praxis merken wir das an zwei Stellen: Core Web Vitals leiden und mobile Nutzer:innen springen früher ab.

Wenn du WordPress nutzt, lohnt sich oft ein „Gewichts-Reset“: Medien konsequent optimieren (z. B. AVIF/WebP), Script-Overhead reduzieren, Caching sauber konfigurieren, und ein Theme nutzen, das nicht alles mitbringt, nur weil es könnte. Hier verlinken wir gern auf PageSpeed Insights als gemeinsames Diagnose-Tool, weil es Diskussionen objektiver macht.

Payload: Performance durch Entkopplung

Payload wird oft zusammen mit modernen Frontends eingesetzt, die statisch oder hybrid rendern können. Das macht es leichter, sehr schlanke Seiten auszuliefern, gutes Caching zu nutzen und weniger Ballast mitzuschicken. In Kombination mit einem Frontend wie Astro sehen wir häufig, dass Performance nicht „optimiert“ werden muss, weil der Standard schon effizienter ist.

Nachhaltigkeit heißt auch: weniger Wartungsenergie

Ein weiterer Unique Angle aus unserer Perspektive: Nachhaltigkeit ist nicht nur Pageweight, sondern auch Teamenergie. Wenn dein CMS ständig Pflegefeuer auslöst, bindet das Ressourcen, die du eigentlich in Inhalte, Wirkung und Produktverbesserung stecken willst.

Darum fragen wir am Ende immer: Welche Lösung hält euch mental und organisatorisch leichter? Eine nachhaltige Website ist für uns eine, die schnell lädt – und die nicht jede Woche an deiner Aufmerksamkeit zieht.