Warum wir kommunale Websites mit Payload CMS und Puck bauen

Viele Kommunen stehen vor demselben Befund: Der Hauptauftritt läuft auf einem großen, teils proprietären System. Daneben existieren Dutzende Websites für Museen, Bäder, Kitas und Projekte – jede in einem anderen System, jede mit eigenem Update-Zyklus. Und die Redaktion jongliert zwischen starren Formularen und dem Wunsch nach mehr Gestaltungsfreiheit.

Wir setzen kommunale Websites deshalb bevorzugt mit Payload CMS als Redaktionssystem und Puck als visuellem Editor um. Warum diese Kombination für Verwaltungen besonders gut passt – und wann nicht –, erklären wir hier.

Was sind Payload und Puck?

Payload ist ein Open-Source-CMS auf Basis von TypeScript und Node.js, das direkt in Next.js-Anwendungen läuft. Es ist „headless“: Inhalte werden getrennt von der Darstellung verwaltet und über Schnittstellen (REST, GraphQL) bereitgestellt. Gleichzeitig bringt es eine vollständige Redaktionsoberfläche mit – mit Entwürfen, Versionen, Live-Vorschau, geplanter Veröffentlichung, Mehrsprachigkeit und fein abgestuften Rechten. Payload steht unter der freien MIT-Lizenz.

Puck ist ein Open-Source-Editor für visuelles Seitenbauen. Entwickler*innen legen fest, welche Bausteine es gibt – etwa Text, Akkordeon, Kontaktkarte oder Spalten. Die Redaktion stellt daraus per Drag-and-Drop Seiten zusammen und sieht sofort, wie sie auf Smartphone und Desktop aussehen. Die Inhalte landen als strukturierte Daten in Ihrer eigenen Datenbank, nicht bei einem externen Anbieter.

Sieben Gründe für Kommunen

1. Digitale Souveränität statt Abhängigkeit

Open Source bedeutet: keine Lizenzgebühren pro Website, Server oder Redakteur*in und keine Bindung an einen einzelnen Hersteller. Der Quellcode ist offen, prüfbar und bleibt nutzbar – auch wenn sich ein Dienstleister ändert. Das passt zu den Open-Source-Strategien, die Bund und Länder für die öffentliche Verwaltung verfolgen.

2. Betrieb dort, wo Sie es entscheiden

Payload wird selbst betrieben: in einem Rechenzentrum in Deutschland, in Ihrer eigenen Infrastruktur oder beim kommunalen IT-Dienstleister. Daten verlassen diesen Rahmen nicht. Für Datenschutzbeauftragte und Informationssicherheit ist das ein entscheidender Unterschied zu reinen Cloud-Diensten.

3. Barrierefreiheit, die im Alltag nicht verloren geht

Das größte Risiko für Barrierefreiheit ist nicht der Relaunch, sondern der Redaktionsalltag: ein Bild ohne Alternativtext, eine übersprungene Überschriftenebene, ein Button mit „hier klicken“. Mit Payload und Puck lassen sich solche Regeln technisch absichern – Pflichtfelder für Alternativtexte, nur geprüfte Bausteine, Farben ausschließlich aus dem Design-System mit festgelegten Kontrasten.

4. Gestaltungsfreiheit ohne Wildwuchs

Redaktionen wünschen sich Flexibilität, Pressestellen ein einheitliches Erscheinungsbild. Puck verbindet beides: Seiten frei zusammenstellen, Akkordeons verschachteln, Spalten setzen – aber immer im Rahmen des Corporate Designs, weil es nur die Bausteine gibt, die dafür freigegeben sind.

5. Viele Auftritte, eine Plattform

Museum, Bäder, Kita-Portal, Wirtschaftsförderung und Kampagnen können auf derselben technischen Instanz laufen – mit eigener Adresse, eigenem Design und eigenen Redaktionsrechten. Updates, Sicherheit und Barrierefreiheit werden einmal für alle gepflegt statt für jedes System einzeln.

6. Einmal pflegen, überall ausspielen

Weil Payload Inhalte über Schnittstellen bereitstellt, versorgt dieselbe Quelle die Website, eine Stadt-App, Infoscreens im Rathaus, Open-Data-Portale und – über MCP-Server – auch KI-Assistenten. Keine zweite Redaktion, kein Abgleich von Hand.

7. Zukunftssicher und gut besetzbar

TypeScript, React und Next.js gehören zu den am weitesten verbreiteten Web-Technologien. Das erleichtert Wartung, Weiterentwicklung und die Suche nach Fachkräften oder weiteren Dienstleistern – ein Punkt, der bei proprietären Spezialsystemen oft unterschätzt wird.

Im Vergleich

Drupal, TYPO3 und WordPress sind bewährte Open-Source-Systeme, die wir ebenfalls betreuen. Drupal ist im öffentlichen Sektor weit verbreitet und technisch stark, verlangt aber viel Erfahrung in Konfiguration und Pflege. Der Unterschied zu Payload und Puck liegt weniger in einzelnen Funktionen als im Ansatz: Dort werden Design-System und Regeln direkt im Code abgebildet – das macht die Qualität im Redaktionsalltag verlässlicher.

Und was ist mit Sitecore?

Sitecore ist eine leistungsfähige Plattform – gebaut für große Marketing-Organisationen. Ihre Stärken sind Personalisierung, Kundenprofile, Marketing-Automatisierung und Testverfahren für Kampagnen. Für einen Konzern, der Millionen Kund*innen individuell anspricht, kann das den Preis rechtfertigen. Für eine Kommune sieht die Rechnung meist anders aus:

• Bezahlt wird für Funktionen, die kaum genutzt werden. Bürger*innen brauchen verlässliche Informationen und Online-Dienste – keine Kundenprofile und keine personalisierten Kampagnen. Die Lizenz deckt diese Funktionen trotzdem ab.
• Viele dieser Funktionen passen nicht zur Datensparsamkeit. Personalisierung und Verhaltensanalyse setzen in der Regel eine Einwilligung voraus – genau das, was eine öffentliche Website mit Cookie-Banner und Tracking möglichst vermeiden sollte.
• Die Kosten laufen dauerhaft. Zu Lizenz- oder Abo-Gebühren kommen spezialisierte Partner, ein eigener Technologie-Stack und Upgrades, die häufig als eigene Projekte budgetiert werden müssen.
• Die Abhängigkeit ist hoch. Proprietäre Software, wenige spezialisierte Dienstleister und – in neueren Editionen – der Betrieb in der Cloud des Herstellers stehen im Gegensatz zu den Open-Source- und Souveränitätszielen der öffentlichen Verwaltung.
• Es geht um öffentliche Mittel. Jeder Euro, der dauerhaft in Lizenzen fließt, fehlt für das, was Bürger*innen wirklich merken: verständliche Inhalte, Barrierefreiheit, Online-Dienste und eine gut ausgestattete Redaktion.

Sitecore ist also kein schlechtes Produkt – es ist für eine andere Aufgabe gebaut. Wer heute eine Sitecore-Website betreibt, muss nicht bei null anfangen: Inhalte lassen sich automatisiert übernehmen, und jede alte Adresse wird per 301 auf die neue Struktur weitergeleitet. Ein Umstieg lässt sich zudem zum Ende einer Vertragslaufzeit planen, sodass keine Kosten doppelt anfallen.

Woran Sie merken, dass sich ein Wechsel lohnt

Ob ein neues System sinnvoll ist, zeigt sich selten an einzelnen Funktionen – sondern im Alltag. Diese Anzeichen hören wir in Verwaltungen immer wieder:

• Der Betrieb ist teuer – und die Website wird trotzdem nicht besser. Lizenz, Hosting und Wartung verschlingen jedes Jahr ein Budget, das für Inhalte und neue Funktionen fehlt.
• Die Redaktion kann nichts selbst umsetzen. Ein neuer Seitentyp, ein anderes Layout, ein zusätzlicher Baustein – jede Änderung wird zum Auftrag mit Angebot, Wartezeit und Rechnung.
• Fachleute sind schwer zu finden und teuer. Nur wenige Dienstleister kennen das System, und Ausfälle oder Wechsel werden zum Risiko.
• Updates werden aufgeschoben. Weil jedes größere Update ein eigenes Projekt ist, bleibt das System lieber auf altem Stand.
• Das neue Corporate Design lässt sich kaum umsetzen. Was im Brand Manual beschlossen ist, kommt nicht oder nur mit großem Aufwand ins Web.
• Cookie-Banner und Zusatz-Werkzeuge gleichen Lücken aus. Tracking, Overlays und Einzellösungen kommen hinzu, statt dass das Fundament stimmt.
• Viele Auftritte, viele Systeme. Museen, Bäder und Projekte laufen auf eigenen Plattformen – mit eigenen Kosten und eigenen Sicherheitslücken.

Wenn Sie drei oder mehr Punkte wiedererkennen, lohnt sich ein Gespräch. Mit Payload und Puck ändert sich vor allem eines: Ihre Redaktion stellt Seiten im Baukasten selbst zusammen, und neue Bausteine kann jedes Team mit Erfahrung in React und TypeScript entwickeln – ein großer, bezahlbarer Markt statt weniger Spezialist*innen.

Wann es nicht passt

• Sehr kleine Auftritte ohne Weiterentwicklung: Für eine einfache Seite mit wenigen Unterseiten kann ein schlankes WordPress schneller und günstiger sein.
• Gut laufende Bestandssysteme: Wenn Ihr TYPO3 oder Drupal aktuell, barrierefrei und gut gepflegt ist, gibt es oft keinen Grund zum Wechsel.
• Ohne technischen Partner: Payload ist ein Werkzeug für Entwickler*innen. Sie brauchen einen Dienstleister oder eigenes Personal, das Bausteine baut und das System betreut. Der Vorteil: Weil Payload auf weit verbreiteter Technik beruht, sind Sie dabei nicht an einen einzigen Anbieter gebunden – auch nicht an uns.

So gelingt der Umstieg

1. Bestandsaufnahme: Welche Websites, Systeme und Inhalte gibt es? Unser Crawler erfasst jede Adresse.
2. Design-System: Ihr Corporate Design wird zu barrierefreien Bausteinen.
3. Import: Inhalte werden automatisiert übernommen und redaktionell nachgearbeitet.
4. Weiterleitungen: Jede alte Adresse wird per 301 auf die neue geleitet – ohne 404.
5. Schulung: Die Redaktion lernt den Baukasten mit ihren eigenen Inhalten kennen.