Headless CMS

Häufige Fehler bei Headless-Projekten

Headless wird oft aus den falschen Gründen gewählt. Der häufigste ist Geschwindigkeit — dabei lässt sich eine klassische Site mit sauberem Caching und optimierten Bildern meist ähnlich schnell machen, ohne die zusätzliche Komplexität eines getrennten Frontends. Headless lohnt sich, wenn dieselben Inhalte mehrere Ausspielkanäle bedienen oder das Frontend Anforderungen hat, die ein Theme nicht abbildet. Für eine Unternehmensseite mit zwanzig Unterseiten ist es meist zu viel Apparat. Zweiter Fehler: Die Vorschau wird vergessen. Redakteure, die im CMS schreiben, aber ihre Änderung erst nach einem Deployment sehen, arbeiten faktisch blind — und die Akzeptanz bricht innerhalb weniger Wochen ein. Drittens werden Aufbauzeiten unterschätzt: Bei einigen tausend Inhalten dauert ein vollständiger Rebuild lange genug, dass eine Tippfehlerkorrektur nicht mehr eben schnell live geht. Wer das früh weiß, plant inkrementelle Builds ein. Und viertens fällt die Suchmaschinenoptimierung hinten runter, weil Titel, Beschreibungen und Weiterleitungen im Frontend neu gebaut werden müssen und dabei gern Lücken bleiben. Fünfter Punkt: Die laufenden Kosten werden unterschätzt. Zum Hosting des Frontends kommen Build-Minuten, ein separat betriebenes CMS und im Zweifel ein Bilddienst — in Summe oft mehr als klassisches Hosting, was bei kleinen Projekten den Nutzen auffrisst. Headless ist ein Werkzeug für bestimmte Anforderungen, keine grundsätzlich bessere Bauweise. Die ehrliche Frage vor jedem Headless-Projekt lautet deshalb, welches konkrete Problem sich damit lösen lässt, das anders nicht lösbar wäre.