Baukästen gelten als templatebasiert und begrenzt. Headless löst genau diesen Einwand auf — ohne die Plattformvorteile aufzugeben.

Der übliche Einwand gegen Plattformen wie Wix lautet: templatebasiert, und bei SEO-intensiven Projekten oder starkem Wachstum stösst man an strukturelle Grenzen. Der Einwand ist berechtigt, solange man den mitgelieferten Editor als einzige Ausgabe versteht.

Der Einwand gegen Baukästen

Headless trennt beides: Die Inhalte liegen weiter in der Plattform und werden dort gepflegt. Die Ausgabe — also das, was Besucher sehen — wird frei gebaut. Damit fällt die Template-Grenze weg, während Hosting, Sicherheit, Skalierung und Auslieferung bei der Plattform bleiben.

1. Was Headless tatsächlich trennt

Der praktische Gewinn liegt bei Unternehmen mit gewachsenen Systemen. Produktdaten aus einem ERP oder PIM müssen nicht mehr doppelt gepflegt werden; sie werden einmal gepflegt und überall ausgespielt — Website, Portal, Katalog.

2. Für wen sich das rechnet

Der Preis dafür ist ehrlich zu nennen: Ein frei gebautes Frontend muss gebaut und gepflegt werden. Das lohnt sich dort, wo Datenmenge, Mehrsprachigkeit oder Systemanbindung im Spiel sind — nicht für eine fünfseitige Visitenkarte.

Viele Produktdaten aus einem vorhandenen System

Mehrere Sprachen oder Märkte

Ausgabe auf mehr als einem Kanal

Anspruch an Ladezeit und Auffindbarkeit

Für Besucher ist der Unterschied nicht sichtbar, für die Pflege schon. Redakteure arbeiten weiter in der gewohnten Oberfläche der Plattform. Sie ändern Texte, Bilder und Einträge, ohne das Layout zu berühren — das Frontend liest die Inhalte und setzt sie an die vorgesehenen Stellen.

Diese Website ist ein Beispiel dafür. Die Inhalte liegen im CMS von Wix, die Oberfläche ist mit Astro frei gebaut und nutzt Bewegungen und Effekte, die der Editor nicht darstellen könnte. Ausgeliefert wird sie trotzdem über die Infrastruktur der Plattform.

Wann es sich nicht lohnt

Für eine Website mit wenigen Seiten, die sich selten ändern, ist Headless meist zu viel. Der mitgelieferte Editor ist dort schneller eingerichtet, und die Grenzen der Vorlagen fallen kaum ins Gewicht. Ein eigenes Frontend bringt dann vor allem zusätzlichen Pflegeaufwand.

Auch das Team spielt eine Rolle. Ein frei gebautes Frontend braucht jemanden, der es versteht, aktualisiert und bei Änderungen der Plattform anpasst. Ohne diese Zuständigkeit wird aus einem flexiblen System eines, das niemand mehr anfassen möchte.

Die Entscheidung hängt deshalb nicht an der Technik, sondern an drei Fragen: Wie viele Inhalte gibt es, auf wie vielen Kanälen erscheinen sie, und wer pflegt das System in zwei Jahren? Erst wenn die Antworten für Headless sprechen, lohnt sich der Aufwand.