Content-First: Warum Inhalte vor dem Design entstehen sollten

Ich habe sechs Jahre in einer Werbeagentur gearbeitet. Ich kenne das Spiel. Der Kunde kommt mit einem vagen Briefing, das Kreativteam entwirft drei wunderschöne Layouts, der Kunde wählt eines aus, und dann beginnt das große Füllen. Plötzlich stellt sich heraus, dass die Texte nicht existieren. Dass niemand weiß, welche Produkte auf welcher Seite stehen sollen. Dass die Fachabteilung seit Wochen keine Rückmeldung gibt. Das Ergebnis: Lorem Ipsum wird durch hastig zusammengeschriebene Absätze ersetzt, die Bilder sind Stockfotos, und die fertige Website sieht aus wie eine Hochglanzbroschüre — nur ohne Inhalt, der jemanden interessiert.

Das ist kein Einzelfall. Das ist die Regel. Und es ist einer der Hauptgründe, warum so viele B2B-Websites nach dem Relaunch genauso schlecht performen wie vorher. Die Farben sind frischer, die Schriften moderner, aber die eigentliche Aufgabe einer Website — relevante Informationen an die richtige Zielgruppe zu bringen — bleibt ungelöst.

Content-First bedeutet: Zuerst klären, was gesagt werden soll. Dann entscheiden, wie es aussehen soll. Das klingt offensichtlich. Ist es aber nicht — zumindest nicht in der Praxis der meisten Digitalagenturen und Inhouse-Teams.

Design-First fühlt sich produktiv an. Nach zwei Wochen gibt es etwas Sichtbares. Ein Figma-File mit zwanzig Screens, das in der Geschäftsführung herumgereicht wird. Alle sind begeistert. Es sieht modern aus, die Animationen sind smooth, die Farbwelt passt zur Marke. Das Problem: Diese zwanzig Screens basieren auf Annahmen. Annahmen über Textlängen, über Produktkategorien, über die Struktur der Navigation, über die Anzahl der Referenzen, die man zeigen möchte.

Wenn dann die echten Inhalte kommen, bricht das Kartenhaus zusammen. Die Headline ist zu lang für das Layout. Die Produktbeschreibung passt nicht in die vorgesehene Box. Es gibt nicht drei Referenzen, sondern siebzehn — oder nur eine. Die Bilder, die der Kunde liefert, haben ein anderes Format als die Platzhalter im Design. Jetzt beginnt das Anpassen, das Kürzen, das Zurechtstutzen von Inhalten, damit sie ins Design passen. Nicht umgekehrt.

Das ist der Moment, in dem aus einem vielversprechenden Projekt Mittelmäßigkeit wird. Die Inhalte werden dem Design untergeordnet. Ein CTO, der eine komplexe technische Lösung erklären will, bekommt gesagt: „Bitte maximal drei Zeilen.“ Ein Produktmanager, der differenzieren will, hört: „Das passt nicht ins Grid.“ Das Design diktiert den Inhalt. Es sollte umgekehrt sein.

Content-First ist kein Framework und kein Buzzword. Es ist eine Reihenfolge. Bevor ein Designer einen Pixel bewegt, müssen grundlegende Fragen beantwortet sein: Welche Zielgruppen adressieren wir? Welche Fragen haben diese Zielgruppen? Welche Inhalte beantworten diese Fragen? In welcher Tiefe? In welchem Tonfall? Welche bestehenden Inhalte können weiterverwendet werden, und welche müssen neu entstehen?

Diese Fragen klingen trivial. Aber in den meisten B2B-Webprojekten, die ich in den letzten Jahren begleitet habe, wurden sie entweder gar nicht oder viel zu spät gestellt. Stattdessen beginnt das Projekt mit Moodboards und Wireframes. Die Inhaltsfrage wird vertagt, weil sie unbequem ist. Weil sie bedeutet, dass jemand im Unternehmen tatsächlich Entscheidungen treffen muss. Welche Produkte betonen wir? Was ist unsere Kernbotschaft? Wer ist eigentlich unsere Zielgruppe — und wer nicht?

Content-First zwingt dazu, diese Entscheidungen früh zu treffen. Das ist unbequem. Aber es verhindert, dass man am Ende ein Design hat, das auf falschen Annahmen basiert.

Jedes Content-First-Projekt beginnt mit einer Bestandsaufnahme. Wir nennen das Content Audit. Es ist die unbeliebteste Phase eines Webprojekts, weil sie Arbeit bedeutet und keine glänzenden Ergebnisse liefert. Aber sie ist entscheidend.

Ein Content Audit bedeutet: Jede bestehende Seite erfassen, bewerten und kategorisieren. Was funktioniert? Was ist veraltet? Was fehlt komplett? Bei einem mittelständischen B2B-Unternehmen mit einer gewachsenen Website sprechen wir schnell über 200 bis 500 Seiten. Produktseiten, die seit 2018 nicht aktualisiert wurden. Blog-Artikel, die niemand liest. Landing Pages für Kampagnen, die längst vorbei sind. Doppelte Inhalte, die sich widersprechen.

Ohne diesen Audit baut man eine neue Website auf einem Fundament aus Vermutungen. Man nimmt die alte Navigation, hübscht sie auf und hofft, dass es diesmal besser wird. Das ist kein Relaunch. Das ist Kosmetik.

Der Audit gibt dem gesamten Projekt eine inhaltliche Grundlage. Er zeigt, wo die Lücken sind. Er zeigt, welche Inhalte tatsächlich Traffic bringen und welche nur Ballast sind. Und er zeigt oft, dass die Seitenstruktur der alten Website historisch gewachsen ist — nicht strategisch geplant.

Aus dem Audit entsteht eine Inhaltsarchitektur. Nicht zu verwechseln mit einer Sitemap — die kommt später. Die Inhaltsarchitektur definiert, welche Inhaltstypen es gibt und wie sie zueinander in Beziehung stehen. Ein Maschinenbauunternehmen hat vielleicht Produkte, Branchen, Anwendungsbeispiele, Referenzen und technische Dokumentationen. Die Frage ist: Wie hängen diese zusammen? Gehört eine Referenz zu einem Produkt oder zu einer Branche? Oder zu beidem? Kann ein Anwendungsbeispiel mehreren Produkten zugeordnet werden?

Diese Fragen bestimmen die Struktur der Website grundlegender als jedes Layout. Und sie lassen sich nur beantworten, wenn man sich mit den Inhalten beschäftigt, bevor man mit dem Design beginnt.

Hier wird es technisch — und hier trennt sich die Spreu vom Weizen. Content Modeling ist der Prozess, Inhalte so zu strukturieren, dass sie technisch abbildbar, wiederverwendbar und zukunftssicher sind. Es geht darum, Inhalte nicht als Seiten zu denken, sondern als strukturierte Daten.

Ein Beispiel: Ein Softwareunternehmen hat verschiedene Produkte. Jedes Produkt hat Features, Preismodelle, Integrationen und Kundenstimmen. Im klassischen Ansatz erstellt jemand eine Produktseite in WordPress und tippt alles in einen WYSIWYG-Editor. Das funktioniert — bis man den dritten Relaunch macht und merkt, dass die Inhalte in einer Sackgasse stecken. Sie sind an ein bestimmtes Layout gekoppelt. Sie lassen sich nicht für andere Kanäle wiederverwenden. Sie haben keine Struktur, die eine API bedienen könnte.

Content Modeling löst dieses Problem. Man definiert: Ein Produkt hat einen Namen, eine Kurzbeschreibung, eine Langbeschreibung, eine Liste von Features (jeweils mit Titel, Beschreibung und optionalem Icon), Preismodelle (jeweils mit Tier, Preis und enthaltenen Leistungen), Integrationen (Referenzen auf andere Dokumente) und Kundenstimmen (Referenzen auf Testimonials). Das ist kein Layout. Das ist ein Datenmodell. Und auf Basis dieses Datenmodells kann man verschiedene Darstellungen bauen — eine Produktseite, eine Vergleichsansicht, eine API-Response für eine Partnerintegration, einen PDF-Export für den Vertrieb.

Ich sage nicht, dass WordPress schlecht ist. Für einen Blog oder eine einfache Unternehmensseite reicht es oft aus. Aber für strukturiertes Content Modeling ist WordPress nicht gebaut. Custom Fields in WordPress sind ein Addon, kein Grundprinzip. Advanced Custom Fields, Custom Post Types, Gutenberg-Blöcke — alles nachträglich aufgeschraubt. Das funktioniert, solange die Anforderungen überschaubar bleiben. Sobald ein Unternehmen anfängt, Inhalte kanalübergreifend zu denken — Website, App, Digital Signage, Partnerportale — stößt dieser Ansatz an Grenzen.

Gleiches gilt für Page Builder wie Elementor oder WPBakery. Sie lösen ein Designproblem, nicht ein Inhaltsproblem. Sie machen es einfach, hübsche Seiten zu bauen. Aber sie zementieren die Kopplung von Inhalt und Darstellung. Jeder Relaunch bedeutet: alles nochmal anfassen. Jeder Kanal bedeutet: Inhalte manuell duplizieren. Das skaliert nicht.

Ein Headless CMS wie Sanity macht Content Modeling zum Grundprinzip. Es gibt kein Frontend, kein Theme, kein Template. Es gibt ein Schema, das die Inhaltsstruktur definiert, und eine API, die diese Inhalte ausliefert. Was mit den Inhalten passiert — wie sie dargestellt werden — ist Sache des Frontends. Das kann eine Next.js-Anwendung sein, eine Mobile App, ein Intranet oder ein automatisierter PDF-Export.

Diese Trennung ist kein Selbstzweck. Sie erzwingt einen Content-First-Ansatz. Wer ein Sanity-Schema definiert, muss sich zuerst mit der Frage beschäftigen: Welche Inhalte brauche ich? Wie sind sie strukturiert? Welche Beziehungen gibt es zwischen ihnen? Das Schema wird zur inhaltlichen Blaupause des Projekts — noch bevor ein einziger Screen designt wird.

In der Praxis heißt das: Wir setzen uns mit dem Kunden zusammen und definieren Content Types. Nicht Seiten. Nicht Layouts. Inhaltstypen. Ein Blogpost hat einen Titel, ein Veröffentlichungsdatum, einen Autor, Tags, einen Teaser und einen strukturierten Inhalt. Ein Case Study hat einen Kunden, eine Branche, eine Herausforderung, eine Lösung, Ergebnisse und Zitate. Diese Strukturen werden im CMS abgebildet — und das Design richtet sich danach, nicht umgekehrt.

Ein Detail, das den Unterschied macht: Sanity nutzt Portable Text für Fließtextinhalte. Im Gegensatz zu HTML, das klassische CMS-Systeme speichern, ist Portable Text ein strukturiertes JSON-Format. Das bedeutet: Der Inhalt ist nicht an eine bestimmte Darstellung gebunden. Eine Überschrift ist eine Überschrift — ob sie als h2 mit 50px auf der Website oder als fetter Text in einer App dargestellt wird, entscheidet das Frontend. Ein Link enthält die Ziel-URL und Metadaten, nicht einen HTML-Anchor-Tag mit inline Styles.

Das ist kein akademisches Detail. In der Praxis bedeutet es, dass Inhalte migrierbar, transformierbar und zukunftssicher sind. Wer heute von WordPress zu Sanity wechselt, nimmt seine Inhalte als strukturierte Daten mit — nicht als HTML-Suppe, die man parsen und aufräumen muss. Und wer in drei Jahren das Frontend wechselt, muss die Inhalte nicht anfassen.

Ich möchte keine Namen nennen. Aber Muster erkenne ich nach über einem Jahrzehnt in der Branche sehr deutlich.

Da ist das Industrieunternehmen, das 80.000 Euro für ein Redesign bezahlt hat. Agentur, Workshops, Moodboards, Prototypen — alles nach Lehrbuch. Nur hat niemand die Fachabteilungen rechtzeitig eingebunden. Als das Design fertig war, fehlten 70 Prozent der Texte. Die Produktmanager waren im Tagesgeschäft gefangen und konnten nicht liefern. Die Website ging mit Platzhaltertexten live. Sechs Monate später waren sie immer noch da.

Da ist der SaaS-Anbieter, der seine Marketing-Website dreimal in zwei Jahren relauncht hat. Jedes Mal neues Design, jedes Mal neue Agentur, jedes Mal das gleiche Problem: Die Inhalte wurden nie grundlegend überarbeitet. Man hat die gleichen schwammigen Texte in immer neue Layouts gegossen. Die Conversion Rate blieb konstant schlecht. Nicht weil das Design schlecht war — sondern weil die Botschaft nicht stimmte.

Da ist der Mittelständler, der auf TYPO3 gesetzt hat und dessen Redakteure sich weigern, die Website zu pflegen, weil das Backend so komplex ist, dass jede Textänderung eine halbe Stunde dauert. Die Inhalte veralten, weil der Prozess zu aufwändig ist. Die Website wird zum digitalen Friedhof — schön gestaltet, aber tot.

All diese Projekte haben eines gemeinsam: Der Inhalt war ein Nachgedanke. Er wurde nicht als eigenständige Disziplin behandelt, sondern als etwas, das man am Ende einfüllt. Wie Wasser in eine Vase.

Bei happycoding haben wir einen Prozess entwickelt, der Content-First ernst nimmt. Er sieht anders aus als das, was die meisten Kunden erwarten — und er ist anfangs gewöhnungsbedürftig. Aber er funktioniert.

In den ersten Wochen eines Projekts gibt es kein einziges Design-Deliverable. Stattdessen erarbeiten wir mit dem Kunden die inhaltliche Strategie. Wer sind die Zielgruppen? Was sind ihre Pain Points? Welche Fragen stellen sie in welcher Phase der Customer Journey? Daraus entsteht eine Content Map — eine Übersicht aller Inhalte, die die Website braucht, geordnet nach Zielgruppe und Entscheidungsphase.

Parallel dazu beginnt das Content Modeling. Wir definieren gemeinsam die Content Types in Sanity, erstellen die Schemas und füllen sie mit ersten echten Inhalten. Nicht mit Lorem Ipsum. Mit echten Texten, echten Produktbeschreibungen, echten Kundenzitaten. Das ist mühsam. Es erfordert, dass der Kunde mitarbeitet und Inhalte liefert, bevor es etwas Hübsches zu sehen gibt. Aber es ist der einzige Weg, ein Design zu schaffen, das auf echten Inhalten basiert.

Erst wenn ein Großteil der Inhalte steht, beginnen wir mit dem Design. Und plötzlich passiert etwas Magisches: Das Design wird besser. Weil die Designer wissen, wie lang die Texte wirklich sind. Weil sie sehen, welche Inhalte Priorität haben. Weil sie verstehen, wie die Daten strukturiert sind und welche Variationen es gibt. Ein Produktlisting mit drei Einträgen sieht anders aus als eines mit dreißig. Ein Testimonial mit zwei Sätzen braucht ein anderes Layout als eines mit einem ganzen Absatz. Diese Informationen hat man nur, wenn der Inhalt vor dem Design existiert.

Natürlich gibt es Widerstand. Kunden wollen Designs sehen. Sie wollen in der Geschäftsführung etwas präsentieren können. „Wir haben jetzt vier Wochen gearbeitet und haben nur Texte und ein CMS-Schema?“ Das ist ein Verkaufsproblem, kein Qualitätsproblem. Und es legt sich, sobald die Kunden merken, dass der anschließende Designprozess schneller und reibungsloser läuft. Dass es keine endlosen Korrekturschleifen gibt, weil das Design auf Realität basiert statt auf Fantasie. Dass die Entwicklung zügig vorankommt, weil die Inhaltsstruktur klar definiert ist.

Am Ende ist ein Content-First-Projekt nicht langsamer als ein Design-First-Projekt. Es ist oft sogar schneller. Weil die typischen Engpässe — fehlende Texte, unklare Strukturen, Änderungswünsche nach der Entwicklung — gar nicht erst entstehen.

Content-First ist keine Philosophie, die man unabhängig vom Tech-Stack verfolgen kann. Die Werkzeuge müssen mitspielen. Und hier wird klar, warum wir auf einen modernen Stack setzen: Next.js für das Frontend, Sanity als Headless CMS, Tailwind für das Styling. Diese Kombination unterstützt Content-First auf jeder Ebene.

Sanity ermöglicht es, Content Types flexibel zu definieren und zu ändern, ohne dass die bestehenden Inhalte verloren gehen. Wenn sich im Laufe des Projekts herausstellt, dass ein Produkt nicht nur Features braucht, sondern auch technische Spezifikationen — kein Problem. Schema erweitern, fertig. In einem klassischen CMS wie TYPO3 oder Sitecore wäre das ein Änderungsantrag, ein Sprint, ein Deployment. In Sanity ist es eine Zeile Code.

Next.js mit seinem App Router und Server Components erlaubt es, das Frontend exakt auf die Inhaltsstruktur zuzuschneiden. Dynamische Routen basieren auf Content Types, nicht auf statischen Seitenvorlagen. Wenn ein neuer Inhaltstyp im CMS erstellt wird, kann das Frontend ihn sofort rendern — ohne dass ein Template-Designer ein neues Layout bauen muss.

Und Tailwind? Tailwind ermöglicht es, responsive Layouts zu bauen, die sich an unterschiedliche Inhaltsmengen anpassen. Kein festes Grid, das bei zu langen Texten bricht. Keine pixel-perfekten Layouts, die nur mit der exakten Textmenge funktionieren, die der Designer im Figma-File hatte. Utility-first CSS ist die natürliche Ergänzung zu einem Content-First-Ansatz, weil es Flexibilität statt Starrheit bietet.

Im B2C-Bereich kann ein starkes Branding und emotionales Design über schwache Inhalte hinwegtäuschen. Zumindest kurzfristig. Im B2B funktioniert das nicht. B2B-Entscheider suchen Informationen. Sie vergleichen Lösungen. Sie lesen technische Dokumentationen. Sie wollen Referenzen sehen. Sie brauchen Inhalte, die ihre spezifischen Fragen beantworten — nicht Marketing-Floskeln in einem schicken Layout.

Eine B2B-Website ist im Kern ein Informationsprodukt. Und wie bei jedem Produkt bestimmt die Qualität des Kerns über den Erfolg — nicht die Verpackung. Ein Maschinenbauunternehmen, das seine Produktseiten mit echten technischen Daten, Anwendungsbeispielen und Vergleichstabellen füllt, wird mehr qualifizierte Leads generieren als eines mit einem preisgekrönten Design und leeren Versprechungen.

Trotzdem wird Content-First gerade im B2B-Mittelstand sträflich vernachlässigt. Die Gründe sind immer die gleichen: zu wenig Ressourcen für die Inhaltserstellung, keine klare Zuständigkeit, fehlende Prozesse. Die Marketingabteilung hat zwei Leute, die auch noch Social Media, Events und den Newsletter machen. Wer soll da 50 Produktseiten schreiben?

Hier hilft ein pragmatischer Ansatz. Nicht alles muss zum Launch perfekt sein. Content-First bedeutet nicht, dass alle Inhalte vor dem Design fertig sein müssen. Es bedeutet, dass die Struktur steht und die wichtigsten Inhalte existieren. Eine MVP-Strategie für Content: Die zehn wichtigsten Produktseiten zuerst, die zehn wichtigsten Fragen der Zielgruppe zuerst, die drei stärksten Referenzen zuerst. Den Rest füllt man iterativ nach — aber auf Basis einer klaren Struktur, nicht ins Blaue hinein.

Content-First kostet mehr am Anfang. Zumindest fühlt es sich so an. Die Inhaltsarbeit passiert früher im Projekt und bindet Ressourcen, die sonst erst später gebraucht würden. Aber die Gesamtkosten sinken. Weniger Korrekturschleifen im Design, weniger Änderungen in der Entwicklung, weniger Nacharbeit nach dem Launch. Die Website performt von Tag eins, weil die Inhalte durchdacht sind und zur Zielgruppe passen.

Noch wichtiger: Die Website bleibt aktuell. Weil ein gut strukturiertes CMS wie Sanity es Redakteuren leicht macht, Inhalte zu pflegen. Weil die Content Types klar sind und es keine Unklarheit gibt, was wo hingehört. Weil das Schema Validierung eingebaut hat und Redakteure geführt werden, statt vor einer leeren Seite zu sitzen.

Der größte ROI von Content-First ist aber langfristiger Natur: Wiederverwendbarkeit. Wer seine Inhalte strukturiert in einem Headless CMS pflegt, kann sie morgen für eine App nutzen, übermorgen für ein Partnerportal, nächstes Jahr für einen KI-Chatbot, der Kundenanfragen beantwortet. Die Inhalte sind nicht in einem monolithischen System eingesperrt. Sie sind frei. Und das ist in einer Welt, in der sich Kanäle und Technologien ständig ändern, der wichtigste Vorteil überhaupt.

Content-First erfordert eine unbequeme Wahrheit: Die meisten Unternehmen haben kein Designproblem. Sie haben ein Inhaltsproblem. Ihre Websites sehen nicht schlecht aus. Die Texte sind schlecht. Die Struktur ist schlecht. Die Informationsarchitektur ist schlecht. Und kein noch so gutes Design kann das kaschieren.

Wer dieses Problem lösen will, muss bereit sein, am Anfang unbequeme Fragen zu stellen und unbequeme Antworten zu akzeptieren. Welche Inhalte brauchen wir wirklich? Was können wir weglassen? Wer schreibt die Texte — und hat diese Person die nötige Kompetenz? Welche Struktur brauchen unsere Inhalte, damit sie nicht nur heute funktionieren, sondern auch in drei Jahren?

Ein moderner Tech-Stack mit Sanity, Next.js und einer durchdachten Content-Architektur gibt die Werkzeuge dafür an die Hand. Aber Werkzeuge allein reichen nicht. Es braucht den Willen, den Prozess umzudrehen. Erst Inhalt, dann Design. Erst Substanz, dann Form. Das ist Content-First. Und es ist der Unterschied zwischen einer Website, die gut aussieht, und einer Website, die funktioniert.