WordPress, Individualsoftware oder Headless CMS? Die richtige Basis wählen

Auf Ihrem Tisch liegen drei Angebote. Die erste Agentur sagt: „Mit WordPress sind wir in acht Wochen live.“ Die zweite will etwas Eigenes entwickeln, „genau so, wie Sie arbeiten“. Die dritte spricht von Next.js, Headless CMS und Seiten, die schneller laden, als man klicken kann. Alle drei klingen überzeugt, und alle drei erklären Ihnen in einem Satz, warum die anderen beiden danebenliegen. Irgendwann bewerten Sie nicht mehr, welche Plattform zu Ihrem Unternehmen passt, sondern wer am besten präsentiert.

Dieser Beitrag vergleicht die drei Wege aus Sicht des Unternehmens, das fünf Jahre mit der Website leben muss, nicht aus Sicht des Anbieters, der sie baut. Es geht um den Alltag Ihrer Redaktion, um Plugins und Sicherheit, Ladezeiten, Mehrsprachigkeit, Schnittstellen, Hosting und Wartung, um die Posten hinter den Gesamtbetriebskosten und um den Aufwand, falls Sie eines Tages wechseln wollen. Am Ende stehen eine Entscheidungstabelle und eine kurze Liste erster Schritte.

Was steckt eigentlich hinter den drei Optionen?

WordPress vereint die Redaktionsoberfläche und die Seiten, die Besucher sehen, in einer Anwendung. Es läuft auf PHP und MySQL (oder MariaDB), die Seiten werden über ein Theme auf dem Server erzeugt, und was der Kern nicht kann, kommt per Plugin dazu. Gemeint ist hier das quelloffene WordPress, das Sie bei Ihrem eigenen Hoster installieren. WordPress.com ist dagegen ein gehosteter Dienst auf derselben Software, mit eigenen Regeln und Tarifen.

Ein Headless CMS trennt diese beiden Hälften. Inhalte werden in einer Redaktionsoberfläche gepflegt und über eine API ausgeliefert; die Website selbst ist eine separate Frontend-Anwendung, meist mit einem Framework wie Astro oder Next.js gebaut. Grob gibt es zwei Lager: kommerzielle Clouddienste wie Contentful und quelloffene Systeme wie Strapi oder Payload, die Sie auf eigenen Servern betreiben können. Sanity liegt dazwischen. Die Redaktionsoberfläche Sanity Studio ist Open Source, die Inhalte liegen aber im gehosteten Datenspeicher von Sanity.

Bei Individualsoftware werden Datenmodell, Verwaltungsoberfläche, Rechte und Geschäftsregeln eigens für Sie geschrieben. Niemand fängt dabei bei null an; die Arbeit setzt auf einem Framework wie Laravel, Django oder einem Node.js-Stack auf. Der Kompromiss ist schnell erklärt: Individualsoftware hat keine der Grenzen eines Standardsystems, aber auch keine seiner fertigen Funktionen.

Dazu kommen Mischformen. WordPress lässt sich als reines Redaktionssystem nutzen und über die REST-API oder das Plugin WPGraphQL an ein eigenes Frontend anbinden. Ebenso verbreitet ist ein Headless CMS für Marketingseiten neben einem individuell entwickelten Händlerportal. Oft lautet die eigentliche Frage nicht „welches System?“, sondern „welches System für welchen Teil?“.

Wie verändert sich der Alltag Ihrer Redaktion?

Wahrscheinlich sind nicht Sie es, der täglich mit der Website arbeitet, sondern Ihre Marketingleiterin, ein Produktmanager oder die neue Werkstudentin. Dort, auf deren Bildschirm, spürt man die Plattformentscheidung am deutlichsten.

Der Block-Editor von WordPress ist vertrautes Terrain. Was man schreibt, sieht der fertigen Seite ähnlich, die Vorschau ist einen Klick entfernt, und Rollen wie Administrator, Redakteur, Autor und Mitarbeiter sind eingebaut. Probleme entstehen meist durch zu viel Freiheit. Sobald Pagebuilder-Plugins jedem Redakteur eigene Layouts erlauben, hat die Website ein Jahr später dreißig Seiten, die aussehen, als gehörten sie zu fünf verschiedenen Firmen.

Im Headless CMS landen Inhalte in vorab definierten Feldern: Überschrift, Teaser, Bild, Artikelnummer, verwandte Leistungen. Das Design steckt fest im Frontend und lässt sich aus der Redaktion heraus nicht zerschießen. Diese Einheitlichkeit ist ein echter Gewinn, hat aber ihren Preis. Der Wunsch „Ich will beim Schreiben sehen, wie es auf der Seite aussieht“ braucht zusätzlichen Aufbau. Draft Mode in Next.js oder die visuellen Bearbeitungswerkzeuge von Sanity lösen das, sofern jemand sie zu Projektbeginn einplant und nicht erst nach dem Launch.

Bei Individualsoftware ist die Verwaltungsoberfläche genau das, was spezifiziert wurde, und nichts darüber hinaus. Eine gut gestaltete eigene Oberfläche kann besser zu Ihren Abläufen passen als WordPress. Dafür wird jedes neue Feld und jeder neue Seitentyp zu einem Entwicklungsauftrag. Für ein Team, das zweimal pro Woche Neuigkeiten veröffentlicht, nervt diese Reibung schnell.

Nehmen wir einen mittelständischen Maschinenbauer, der seinen Produktkatalog zweisprachig pflegt und ein paar Meldungen im Monat veröffentlicht. Produktseiten sind strukturierte Daten (Maße, Zertifikate, kompatible Teile), Meldungen dagegen Fließtext. Das Unternehmen braucht also gleichzeitig ein feldgenaues Modell für Produkte und einen bequemen Editor für News. Alle drei Optionen können das; der Unterschied liegt darin, wie viel Aufwand es kostet und wessen Aufwand es ist.

Plugins und Sicherheit: Wo sammelt sich das Risiko?

Der WordPress-Kern ist heute solide; das Risiko sammelt sich drumherum. Patchstack, ein auf WordPress-Sicherheit spezialisiertes Unternehmen, meldet in seinem Anfang 2026 veröffentlichten Jahresbericht, dass 91 Prozent der 2025 bekannt gewordenen neuen Schwachstellen in Plugins steckten und 9 Prozent in Themes. Im Kern wurden nur sechs gemeldet, alle mit niedriger Priorität. Das Problem ist also nicht WordPress selbst, sondern dass jede zusätzliche Komponente einen eigenen Autor, einen eigenen Pflegerhythmus und ein eigenes Risiko mitbringt.

Eine Website mit vierzig Plugins ist nicht automatisch gefährlich. Gefährlich sind das Formular-Plugin, das seit zwei Jahren niemand aktualisiert hat, das Premium-Theme aus einer dubiosen Download-Quelle und das Backup-Tool, das „vorübergehend“ installiert und dann vergessen wurde. Seit WordPress 5.5 können sich Plugins automatisch aktualisieren. Das beschleunigt Sicherheitsupdates und bedeutet zugleich, dass ein Update die Seite über Nacht lahmlegen kann. Getestete Backups und eine namentlich benannte Person, die Updates im Blick hat, sind deshalb keine Kür.

In einer Headless-Architektur ist die Redaktionsoberfläche von der öffentlichen Website getrennt. Wird die Seite statisch erzeugt, gibt es nicht einmal eine Datenbank, mit der ein Angreifer sprechen könnte. Das verkleinert die Angriffsfläche erheblich, beseitigt sie aber nicht: API-Schlüssel, Webhook-Adressen, Berechtigungen in Ihren Cloudkonten und Lieferkettenrisiken über npm-Pakete werden zu Ihren neuen Hausaufgaben.

Individualsoftware bekommt keine Patches aus einer Community. Jemand muss die Sicherheitsupdates des Frameworks verfolgen, Abhängigkeiten mit Werkzeugen wie Dependabot oder Renovate prüfen und vor dem Livegang einen Penetrationstest beauftragen. Kümmert sich niemand, ist eigener Code unter Umständen verwundbarer als die älteste WordPress-Installation im Netz.

Egal, welchen Weg Sie wählen, vier Regeln bleiben gleich:

• Zwei-Faktor-Authentifizierung für jedes Admin-Konto und nicht mehr Rechte, als jede Person braucht.
• Backups, deren Wiederherstellung tatsächlich getestet wurde. Ein vorhandenes Backup ist noch kein funktionierendes.
• Eine namentlich benannte Person oder ein Team, im Vertrag festgehalten, das für Updates zuständig ist.
• Regelmäßiges Aufräumen ungenutzter Plugins, Konten und API-Schlüssel.

Ladezeit und Sprachen: Was entscheidet die Plattform?

Über beides wird in Präsentationen viel behauptet und selten gemessen. Zuerst zum Tempo.

Ladezeit: Kommt sie von der Plattform oder vom Aufbau?

Von beidem, aber vor allem vom Aufbau. Mit einem schlanken Theme, Seiten-Cache und CDN lädt WordPress schnell. Mit einem schweren Pagebuilder, einem Dutzend Tracking-Skripten und unkomprimierten Bildern kriecht auch das modernste Framework.

Was Frameworks wie Astro und Next.js ändern, ist der Standardfall. Astro erzeugt Seiten von Haus aus als statisches HTML und schickt JavaScript nur für die Komponenten an den Browser, die Interaktion brauchen; Astro nennt das „Islands“. Next.js lässt Sie pro Seite wählen zwischen statischer Erzeugung, Rendering auf dem Server zum Zeitpunkt der Anfrage und Neugenerierung in Intervallen. Werden Seiten vorab erzeugt und über ein CDN ausgeliefert, bleibt keine Datenbankabfrage übrig, auf die der Besucher warten müsste.

Auch hier lauert eine Falle. Eine Headless-Website, die zu viel JavaScript im Browser ausführt, wird am Ende so träge wie der schwerfälligste WordPress-Aufbau. Ein Technologie-Etikett ist keine Messung. Testen Sie deshalb vor der Entscheidung die Websites, die die Anbieter bereits umgesetzt haben. Welche Werte dabei zählen, erklären wir in unserem Beitrag zu den Core Web Vitals.

Mehrsprachigkeit: Welche Plattform trägt mehrere Sprachen gut?

Planen Sie eine Website auf Deutsch, Französisch und Italienisch für den Schweizer Markt, kann dieser Punkt allein die Entscheidung bringen.

Der WordPress-Kern hat keine mehrsprachige Inhaltsverwaltung. Die offizielle Roadmap führt sie als vierte Phase, „Kernunterstützung für mehrsprachige Websites“; aktuell wird an Phase drei gearbeitet, der gemeinsamen Bearbeitung. Bis dahin arbeiten Sie mit Plugins wie WPML oder Polylang. Die erledigen ihre Aufgabe, doch jede Sprache verhält sich wie ein eigener Datensatz, und die Verträglichkeit mit Theme und anderen Plugins muss bei jedem Update neu geprüft werden.

In den meisten Headless-Systemen ist Lokalisierung Teil des Inhaltsmodells. In Contentful werden Sprachen pro Umgebung angelegt, und Sie legen Feld für Feld fest, was übersetzt wird. Strapi 5 bringt Internationalisierung im Kern mit, in Payload markieren Sie übersetzbare Felder in der Konfiguration. Im Frontend hat Astro ein eingebautes i18n-Routing, und in Next.js ist sprachbasiertes Routing ein etabliertes Muster. hreflang-Tags, Sprachumschalter und URL-Struktur muss das Frontend-Team trotzdem bauen; nichts davon entsteht von selbst.

Bei Individualsoftware gehört Mehrsprachigkeit vom ersten Tag an ins Datenmodell. Wer Sprachen später nachrüstet, landet bei einem Umbau, der fast jede Tabelle berührt. Wenn auch nur die Möglichkeit besteht, in zwei Jahren eine zweite Sprache hinzuzufügen, sagen Sie es in der Konzeptphase.

Schnittstellen, Hosting und Wartungsaufwand

Schnittstellen

Kaum eine Unternehmenswebsite steht allein. Formulare laufen ins CRM, etwa HubSpot oder Salesforce, Produktdaten kommen aus dem ERP, Newsletter-Anmeldungen gehen ans E-Mail-Tool. Für WordPress gibt es für fast alles ein Plugin; die Qualität hängt vom Autor ab, und zwei Plugins, die sich um dieselben Daten streiten, sind keine Seltenheit. Bei Headless und Individualsoftware werden Schnittstellen programmiert. Das kostet mehr Aufwand, dafür wissen Sie genau, was wann wohin fließt. Sollen Preise und Bestände aus SAP oder Microsoft Dynamics kommen, ist das auf jeder Plattform Integrationsarbeit.

Hosting

WordPress braucht einen Server mit PHP und MySQL oder einen Managed-WordPress-Hoster. Ein Headless-Aufbau hat mindestens zwei Teile, Inhaltssystem und Frontend, dazu eine Build- und Deployment-Pipeline sowie Webhooks, die die Seite bei Inhaltsänderungen neu erzeugen. Laut Next.js-Dokumentation läuft eine Anwendung auf einem Node.js-Server, in einem Docker-Container, als statischer Export ohne serverabhängige Funktionen oder über Adapter für Plattformen wie Vercel. Die statische Ausgabe von Astro lässt sich auf jedem gewöhnlichen Webserver veröffentlichen.

Das Hosting entscheidet auch darüber, wo personenbezogene Daten liegen. Prüfen Sie bei einem Cloud-CMS, in welcher Region Inhalte und Formulardaten gespeichert werden, und schließen Sie einen Auftragsverarbeitungsvertrag nach Art. 28 DSGVO ab. Bei selbst betriebenen Systemen liegen diese Daten auf einer Infrastruktur, die Sie auswählen.

Wartung

Bei WordPress heißt Wartung: Updates für Kern, Theme und Plugins, PHP-Versionswechsel und Backups. Auf der Headless-Seite kommen große Framework-Versionen hinzu, der Release-Kalender von Node.js und Upgrades des Inhaltssystems selbst. Der Wechsel von Strapi 4 auf Strapi 5 etwa brachte Breaking Changes mit sich und kam mit eigenem Migrationsleitfaden und Werkzeugen zur Codeumwandlung. Individualsoftware hat all das, plus die Frage, wer das System noch versteht und wie gut.

Gesamtbetriebskosten: Posten, die im Angebot fehlen

Das Angebot für den Aufbau ist die Spitze des Eisbergs. Um die Optionen über drei Jahre zu vergleichen, lassen Sie sich die folgenden Posten von jedem Anbieter getrennt aufschlüsseln. Zahlen brauchen Sie dafür anfangs nicht einmal; schon zu sehen, welche Posten es überhaupt gibt, verändert das Bild.

• Aufbau: Design, Frontend, Inhaltsmodell, Übernahme bestehender Inhalte.
• Lizenzen. Jährliche Verlängerungen für Premium-Themes und Plugins, Tarifgrenzen bei Cloud-CMS nach Nutzern, Einträgen, Sprachen oder API-Nutzung, dazu Enterprise-Funktionen. Bei Strapi stecken Single Sign-on, Review-Workflows und Audit-Logs in kostenpflichtigen Tarifen.
• Hosting: Server, CDN, Datenbank, Build-Minuten, Frontend-Plattform.
• Wartungsstunden: Updates, Versionswechsel, Sicherheitsüberwachung, Backup-Kontrollen.
• Die Zeit Ihres Teams. Eine langsame, unübersichtliche Oberfläche frisst jeden Tag Minuten; das stellt Ihnen niemand in Rechnung, bezahlt wird es trotzdem.
• Änderungswünsche: ein neuer Seitentyp, ein neues Feld, eine neue Schnittstelle.
• Schulung und Dokumentation: Wer arbeitet eine neue Redakteurin ein, und mit welchen Unterlagen?
• Ausstiegskosten: der Aufwand, falls Sie irgendwann auf ein anderes System wechseln.

Der häufigste Fehler, den wir sehen: Das niedrigste Angebot für den Aufbau wird mit den niedrigsten Kosten verwechselt. Eine hastig aufgesetzte WordPress-Seite auf zwanzig Plugins zeigt ihren wahren Preis im zweiten Jahr über Wartungsstunden und im dritten über den nötigen Neubau. Wie Sie Angebote Zeile für Zeile lesen, beschreibt unser Beitrag zu den Kostenfaktoren einer Website.

Anbieterabhängigkeit und Wechselaufwand

Abhängigkeit ist nicht eine Sache, sondern mindestens vier.

• Plattformabhängigkeit: Bei einem Cloud-CMS liegen Ihre Inhalte auf der Infrastruktur dieses Unternehmens. Exportieren lassen sie sich per API, doch wenn sich Konditionen ändern, ist Ihre Verhandlungsposition schwach.
• Codeabhängigkeit. Hat eine einzige Agentur Ihre Individualsoftware geschrieben und Quellcode, Dokumentation und Serverzugänge behalten, gehört Ihnen das System auf dem Papier und ihr in der Praxis.
• Formatabhängigkeit: Pagebuilder-Plugins speichern Inhalte in eigenen Shortcodes oder Datenformaten. Am Tag, an dem Sie das Plugin entfernen, zerfallen die Seiten in Fragmente aus sinnlosem Markup.
• Personenabhängigkeit, also das, was passiert, wenn der einzige Mensch, der das System versteht, das Unternehmen verlässt.

Open-Source-Lizenzen verringern dieses Risiko, beseitigen es aber nicht. Zwei aktuelle Beispiele: Das Payload-Team ist 2025 zu Figma gewechselt, und das Unternehmen hinter Astro gehört seit Januar 2026 zu Cloudflare. Beide Projekte haben erklärt, unter der MIT-Lizenz quelloffen zu bleiben, und das ist beruhigend. Trotzdem prägt der neue Arbeitgeber der Entwickler die Roadmap eines Werkzeugs mit. Zu wissen, wer hinter einem Werkzeug steht, gehört zur technischen Prüfung.

Wie schwer ein Umzug wird, hängt von der Richtung ab. WordPress speichert Inhalte als HTML, markiert mit Block-Kommentaren. Diese Inhalte in ein strukturiertes Headless-Modell zu überführen heißt, sie Feld für Feld zu zerlegen und zu bereinigen. Bilder, Autorendaten, SEO-Titel und Weiterleitungen alter URLs sind eigene Arbeitspakete. Was eine fehlende Weiterleitungsstrategie mit der Sichtbarkeit in der Suche anrichten kann, beschreibt unsere Checkliste zum Website-Relaunch ohne SEO-Verluste.

Entscheidungstabelle: Welche Option passt zu welcher Lage?

Die Tabelle ist kein Naturgesetz, sondern fasst die Entscheidungen zusammen, die sich in der Praxis am häufigsten als richtig erweisen. Passt Ihre Lage auf mehrere Zeilen, geben meist die Organisation Ihrer Redaktion und der Wartungsaufwand, den Sie tragen können, den Ausschlag.

Eine Zeile fehlt mit Absicht: Entscheidungen nach dem Motto „Alle nehmen jetzt Next.js“ oder „WordPress ist veraltet“. Beides ist kein Grund, sondern eine Beobachtung über Moden. Die sinnvolle Frage lautet, wer Inhalte wie oft und in wie vielen Sprachen pflegt und wer das System die nächsten fünf Jahre am Laufen hält.

Wo fangen Sie an?

1. Erstellen Sie eine Inhaltsinventur: Welche Seitentypen gibt es, und wer pflegt sie wie oft in welchen Sprachen?
2. Listen Sie jedes System auf, mit dem die Website sprechen muss: CRM, ERP, E-Mail-Tool, Zahlung, Karten, Terminbuchung.
3. Lassen Sie jeden Anbieter die Kostenposten oben getrennt ausfüllen, und rechnen Sie mit drei Jahren statt einem.
4. Stellen Sie allen Anbietern dieselben Fragen. Wer spielt Updates ein? Auf wessen Namen laufen die Konten? Wie bekommen wir unsere Inhalte, wenn wir gehen?
5. Machen Sie einen kurzen Praxistest mit einer Redakteurin: eine Meldung und eine Produktseite in zwei Systemen anlegen und notieren, wo es hakt.
6. Prüfen Sie für die favorisierte Plattform das Unternehmen dahinter, die Lizenz und die Versionsgeschichte der letzten zwei Jahre.
7. Halten Sie Entscheidung und Begründung auf einer Seite fest, damit die Antwort auf „Warum haben wir das damals so gemacht?“ auch in zwei Jahren noch auffindbar ist.

Wir bei AYTE Digital bauen auf allen drei Wegen und entscheiden in einem Konzeptgespräch, welchen wir empfehlen, je nach Ihrem Redaktionsablauf und dem Wartungsaufwand, den Sie realistisch tragen können. Wenn es hilft, gehen wir Ihre bestehende Website oder vorliegende Angebote gemeinsam durch und füllen die Tabelle für Ihre Lage aus.