{"id":43354,"date":"2026-09-29T09:00:00","date_gmt":"2026-09-29T07:00:00","guid":{"rendered":"https:\/\/csw.agency\/?p=43354"},"modified":"2026-09-28T09:17:36","modified_gmt":"2026-09-28T07:17:36","slug":"headless-cms","status":"publish","type":"post","link":"https:\/\/csw.agency\/en\/headless-cms\/","title":{"rendered":"When a headless CMS is worth your while"},"content":{"rendered":"

Ein Headless CMS<\/strong> verwaltet Eure Inhalte und liefert sie \u00fcber eine Schnittstelle an beliebige Oberfl\u00e4chen aus, ohne selbst eine Website darzustellen. Das lohnt sich, wenn dieselben Inhalte auf mehreren Kan\u00e4len laufen oder Euer Frontend Anforderungen hat, die ein klassisches System bremst. F\u00fcr die typische Unternehmenswebsite mit einer Redaktion ohne eigene Entwickler bleibt das klassische System meist die g\u00fcnstigere Wahl. Wie oft sich diese Frage stellt, zeigt die Nutzungsstatistik von W3Techs<\/a>: WordPress l\u00e4uft auf 40,2 % aller Websites und bei 58,7 % der Websites mit bekanntem CMS (Stand 28. September 2026).<\/p>\n

So funktioniert ein Headless CMS<\/h2>\n

Ein klassisches CMS (Content-Management-System)<\/a> erledigt zwei Aufgaben in einem System. Es speichert Texte, Bilder und Seitenstruktur, und es erzeugt daraus mit Theme und Templates die fertigen HTML-Seiten. Beim Headless-Ansatz f\u00e4llt der zweite Teil weg, der sprichw\u00f6rtliche Kopf. Das CMS h\u00e4lt die Inhalte nur noch als strukturierte Daten vor und gibt sie \u00fcber eine API<\/em> aus, meist als JSON \u00fcber REST oder GraphQL, und die Darstellung \u00fcbernimmt ein eigenes Frontend<\/a>, das Entwickler zum Beispiel mit Next.js, Nuxt oder Astro bauen.<\/p>\n

Daf\u00fcr braucht Ihr nicht zwingend ein neues System. WordPress bringt eine REST-API im Kern mit, und das WordPress-Handbuch zur REST API<\/a> nennt ausdr\u00fccklich den Fall, WordPress-Inhalte in v\u00f6llig getrennte Anwendungen zu holen. Daneben gibt es Systeme, die von Anfang an headless gebaut sind: gehostete Dienste wie Storyblok oder Contentful und quelloffene L\u00f6sungen wie Strapi, das sich wahlweise selbst hosten oder als Cloud-Dienst nutzen l\u00e4sst<\/a>. Die Systeme unterscheiden sich vor allem in Redaktionsoberfl\u00e4che und Betrieb. Das Prinzip ist bei allen gleich: Die Inhalte liegen in einem Pool, die Ausgabe entsteht woanders.<\/p>\n

\"Headless<\/figure>\n

Das Schaubild zeigt den Unterschied im Aufbau. Links sind Inhalte und Darstellung fest miteinander verbunden und bedienen genau eine Website. Rechts versorgt ein Content-Pool \u00fcber die API mehrere Ausgabekan\u00e4le gleichzeitig, etwa Website, Smartphone-App, Tablet und einen Bildschirm im Laden.<\/p>\n

Was Headless f\u00fcr SEO und Redaktion bedeutet<\/h2>\n

F\u00fcr Suchmaschinen z\u00e4hlt, was im ausgelieferten HTML steht. Google verarbeitet JavaScript-Seiten in drei Schritten, n\u00e4mlich Crawling, Rendering und Indexierung, und laut Googles Leitfaden zu JavaScript-SEO<\/a> kann eine Seite unterschiedlich lange in der Warteschlange f\u00fcr das Rendering stehen. Baut Euer Frontend die Inhalte erst im Browser zusammen, riskiert Ihr Verz\u00f6gerungen bei der Indexierung, und nicht jeder Bot f\u00fchrt JavaScript<\/a> \u00fcberhaupt aus. Google empfiehlt deshalb serverseitiges Rendering oder Pre-Rendering und bezeichnet das fr\u00fcher verbreitete dynamische Rendering in seiner Dokumentation zum dynamischen Rendering<\/a> als Behelfsl\u00f6sung.<\/p>\n

Die zweite Baustelle ist die Redaktion. Im klassischen WordPress sieht Euer Team per Klick auf \u201eVorschau\u201c, wie ein Beitrag aussehen wird. Im Headless-Setup muss diese Vorschau eigens programmiert werden, Next.js stellt daf\u00fcr etwa einen Draft Mode f\u00fcr unver\u00f6ffentlichte CMS-Inhalte<\/a> bereit, der zwischengespeicherte Seiten f\u00fcr Redakteure umgeht. Auch Meta-Titel, Canonical-Tags, XML-Sitemap und strukturierte Daten<\/a> entstehen im Frontend-Code. Was ein SEO-Plugin im klassischen System per Formularfeld erledigt, wird damit zur Aufgabe f\u00fcr die Entwicklung. Plant daf\u00fcr von Anfang an Zeit ein, denn eine fehlende Vorschau bremst die Redaktion bei jedem einzelnen Beitrag.<\/p>\n

Wann sich ein Headless CMS lohnt<\/h2>\n

Der Mehraufwand rechnet sich, wenn mindestens einer der folgenden Punkte auf Euer Projekt zutrifft. Trifft keiner zu, bezahlt Ihr f\u00fcr Flexibilit\u00e4t, die Ihr nicht nutzt, und f\u00fcr ein zweites System, das gewartet werden will. Neben dem CMS-Tarif, den etwa die Preis\u00fcbersicht von Storyblok<\/a> nach Nutzern, API-Abrufen und Datenvolumen staffelt, zahlt Ihr Entwicklung und Hosting des eigenen Frontends. Eine Unternehmenswebsite mit 20 Seiten und einer Redaktion ohne Entwickler erf\u00fcllt die Kriterien meist nicht. Pr\u00fcft die Liste gemeinsam mit Redaktion und Entwicklung, denn beide Seiten tragen die Folgen der Entscheidung:<\/p>\n