Dienstag, halb zehn. Die neue Kollegin soll die dritte Referenz von diesem Jahr online stellen. Sie loggt sich ein, sieht ein Feld namens „Text 2" und ruft dich an. Du weißt es auch nicht. Der Typ, der die Seite damals gebaut hat, antwortet seit acht Monaten nicht mehr auf Mails.

Das ist die Frage, um die es in diesem Artikel wirklich geht. Nicht, wie du in Webflow eine Collection anklickst, das erklären dir zwanzig andere Seiten in fünf Minuten. Sondern: Ist deine Website in zwei Jahren noch bedienbar, wenn jemand Neues rangehen muss und der Erbauer nicht erreichbar ist?

Die kurze Antwort vorweg, sie zieht sich durch den ganzen Text: Ein CMS ist gut gebaut, wenn jemand, der vom Bau nichts weiß, es nach fünf Minuten bedienen kann, ohne etwas kaputtzumachen.

Ich gehe die Entscheidungen durch, die beim Bau getroffen werden und die du als Unternehmer nie zu Gesicht bekommst, obwohl du sie später bezahlst. Am Ende stehen sieben Fragen, mit denen du deine eigene Seite in zehn Minuten prüfen kannst. Ohne Technikwissen.

Brauche ich für meine Website überhaupt ein CMS, oder reichen statische Seiten?

Du brauchst ein CMS, sobald sich ein Inhaltstyp wiederholt und wachsen wird. Bleibt alles einmalig und ändert sich zweimal im Jahr, reichen statische Seiten völlig aus.

CMS heißt erstmal nur: ein Verwaltungsbereich, in dem Inhalte getrennt vom Layout liegen. Du schreibst den Text, das System kümmert sich darum, wie er aussieht. Klingt banal, ist aber der Unterschied zwischen „ich stelle die neue Referenz eben selbst online" und „ich schreibe meiner Agentur eine Mail und warte drei Tage".

Der Test dafür ist simpler, als die meisten denken. Geh deine Seite durch und frag bei jedem Inhalt: Gibt's davon irgendwann einen zweiten? Referenzen? Wiederholen sich. Team? Wechselt. Blogartikel? Werden hoffentlich mehr. Impressum? Gibt's genau einmal.

Für einen einzelnen Hammer brauchst du keine Werkzeugwand mit aufgemalten Umrissen. Hängen da sechzig Teile, willst du auf einen Blick sehen, was fehlt und wo es hingehört. Genau diese Entscheidung triffst du hier, nur eben mit Inhalten statt mit Werkzeug.

Und wichtig: Diese Frage stellt sich nicht nur am ersten Tag. Sie stellt sich für die nächsten zwei Jahre. Wer beim Launch drei Referenzen hat und in zwei Jahren dreißig, hat spätestens bei Nummer acht ein Problem, wenn jede einzelne von Hand gebaut werden muss.

Was ist eine Collection eigentlich, in einfachen Worten?

Eine Collection ist eine Schublade für eine Art von Inhalt, die immer gleich aufgebaut ist. Jede Schublade hat feste Fächer, und jeder Eintrag darin füllt dieselben Fächer.

Beispiel Referenzen. Die Schublade heißt „Referenzen". Ihre Fächer: Kundenname, Branche, Bild, Projektbeschreibung, Jahr. Jedes einzelne Projekt, das du da reinlegst, ist ein Collection-Item, also ein Eintrag. Das Projekt für die Schreinerei aus Leverkusen ist ein Item, das für die Steuerkanzlei ein zweites. Beide haben dieselben Fächer, nur anderen Inhalt.

Dann gibt's noch das Referenzfeld. Das ist ein Fach, das nicht selbst Text enthält, sondern auf einen Eintrag aus einer anderen Schublade zeigt. Deine Referenz zeigt zum Beispiel auf den Eintrag „Handwerk" aus der Schublade „Branchen". Der Vorteil: Du pflegst „Handwerk" einmal, nicht vierzig Mal in vierzig Einträgen. Änderst du die Bezeichnung, ändert sie sich überall gleichzeitig. Zeigt ein Fach auf mehrere Einträge gleichzeitig, heißt es Mehrfachreferenzfeld, mehr Unterschied ist da nicht.

Dass die Fächer festliegen, fühlt sich für manche nach Einschränkung an. Ist aber genau der Punkt. Die Werkzeugwand mit den aufgemalten Umrissen ist auch eine Einschränkung: Die Zange gehört an genau eine Stelle. Dafür sieht jeder sofort, wo sie hinkommt und ob eine fehlt. Die Alternative ist die Zettelwirtschaft, bei der jeder Inhalt irgendwo anders liegt und nur eine Person im Haus weiß, wo.

Wann gehört ein Inhalt ins CMS, und wann bleibt er eine statische Seite?

Ins CMS gehört, was sich wiederholt oder wachsen wird. Statisch bleibt, was es genau einmal gibt.

Ins CMS gehören also: Referenzen, Teammitglieder, Blogartikel, Standorte, und auch Leistungen, wenn sie alle gleich aufgebaut sind. Statisch bleiben: Startseite, Über uns, Kontakt, Impressum, Datenschutz. Da gibt's nichts zu wiederholen.

Woran du merkst, dass beim Bau falsch entschieden wurde, merkst du nicht am Aussehen. Du merkst es an der Rechnung. Wenn für jede neue Referenz dein Dienstleister ran muss, weil sie damals von Hand gebaut wurde, dann liegt der Inhalt statisch da, wo er ins CMS gehört hätte. Jede neue Referenz kostet dich dann Geld und Wartezeit, und irgendwann lässt du sie einfach weg. So sterben Referenzseiten: nicht mit einem Knall, sondern weil es zu umständlich ist.

Der umgekehrte Fall existiert genauso. Wenn deine „Über uns" Seite im CMS liegt, weil jemand sie flexibel bauen wollte, klickst du für eine Zeile Text durch drei Ebenen, obwohl es die Seite genau einmal gibt.

Damit wir uns richtig verstehen, weil das gern durcheinandergeht: Hier geht's nicht darum, welche Seiten deine Website braucht, in welcher Reihenfolge die Abschnitte stehen und wie viele Klicks bis zum Kontaktformular liegen. Das ist Seitenstruktur, und die entscheidet, ob Besucher bei dir anfragen. Diese Ebene hab ich getrennt aufgeschrieben.

Dieser Artikel liegt eine Etage tiefer: bei der Struktur deiner Daten. Also nicht, ob Besucher etwas finden, sondern ob dein Team es pflegen kann. Zwei verschiedene Baustellen, und die zweite bekommt fast nie Aufmerksamkeit, weil man sie nicht sieht.

Wann brauchst du eine neue Collection, und wann reicht ein zusätzliches Feld?

Eine eigene Collection brauchst du, wenn der Inhaltstyp eine eigene Seite mit eigener Adresse bekommt oder eigenständig an mehreren Stellen wiederverwendet wird. Ein zusätzliches Feld reicht, wenn es nur eine Eigenschaft innerhalb eines Typs ist, den du schon hast.

Konkret an den Referenzen: Das Kundenzitat gehört als Feld in die Referenz. Es existiert nur im Zusammenhang mit diesem einen Projekt, es braucht keine eigene Adresse, niemand sucht danach. Die Branche dagegen kann eine eigene Schublade verdienen, aber nur wenn du wirklich vorhast, eine Seite „Referenzen aus dem Handwerk" zu bauen, die eigenständig gefunden werden soll. Willst du die Branche bloß als Wort unter dem Projekttitel anzeigen, reicht ein Feld.

Die Frage dahinter ist immer dieselbe: Steht das Ding für sich allein, oder ist es eine Eigenschaft von etwas anderem?

Wird das zu fein geschnitten, bläht sich das CMS auf. Dann hast du vierzig beschriftete Kisten im Keller, und in jeder liegt eine Schraube. Ordentlich ist das theoretisch, aber niemand findet mehr etwas, und für eine simple Textänderung öffnest du drei Kisten. Der Redakteur verliert die Übersicht und ruft wieder bei dir an, und du landest genau da, wo du nie hinwolltest.

Wird es zu grob geschnitten, passiert das Gegenteil: Alles landet in einem Textfeld, Formatierung inklusive, und jede Änderung ist Handarbeit. Dazwischen liegt die Entscheidung, die dein Dienstleister trifft, oft in fünf Sekunden, und die dich fünf Jahre begleitet.

Wie groß darf dein Webflow-CMS werden, bevor die Grenzen deines Plans zuschlagen?

Für eine normale Unternehmenswebsite reichen die Grenzen locker. Eng wird es erst bei großen Katalogen, oder wenn beim Bau für jede Kleinigkeit eine eigene Schublade angelegt wurde.

Zur Einordnung eine Tabelle. Und dazu eine Ansage, die ich wichtig finde: Die folgenden Zahlen stammen aus einem Agentur-Blog (RapidDev, „CMS Limits in 2026 in Webflow", Stand März 2026), nicht von Webflow selbst. Nimm sie als Größenordnung, nicht als Vertrag.

Systemfelder wie Name und Slug zählen bei den 30 Feldern übrigens nicht mit.

Wo du die verlässlichen Zahlen bekommst: in deinen eigenen Site Settings. Da steht, was dein Plan hergibt, tagesaktuell und ohne Umweg über irgendeinen Blog. Das ist die beste Quelle, die du hast, und sie kostet dich zwei Klicks.

Eine Grenze verdient extra Aufmerksamkeit, weil sie am ehesten weh tut: verschachtelte Referenzen. Also der Fall, dass du auf einer Seite eine Liste ausgibst, und in jedem Eintrag dieser Liste steckt nochmal eine Liste. Referenzen, und pro Referenz die verwendeten Leistungen. Es gibt eine Obergrenze dafür, wie viele solcher verschachtelten Listen auf einer Seite laufen und wie viele Einträge pro Ebene ausgegeben werden.

Wie hoch die genau liegt, dazu widersprechen sich die Quellen deutlich, und deshalb schreib ich dir hier keine Zahl hin. Lieber keine Zahl als eine falsche, die dann in der nächsten Runde von irgendeiner KI weitergereicht wird. Was du wissen musst, ist die Folge: Reißt du die Grenze, fehlen Einträge auf der Live-Seite. Ohne Fehlermeldung, ohne Warnung. Im Bearbeitungsmodus sind sie sauber da, draußen für den Besucher nicht. Das fühlt sich an, als wäre das CMS kaputt, ist aber ein Strukturfehler. Auch hier gilt: deine Site Settings, dein Plan, deine Zahlen.

Was kann dein Team im Webflow Editor wirklich selbst ändern, ohne Entwickler?

Texte, Bilder, Links und CMS-Einträge. Layout und Gestaltung nicht. Und das ist keine Schikane, sondern der Schutz, der dafür sorgt, dass sich überhaupt jemand traut, etwas anzufassen.

Webflow trennt zwei Oberflächen. Der Editor, ab August 2026 „Edit Mode", ist die vereinfachte Ansicht für alle, die keine Technik machen. Du klickst auf einen Text, du schreibst, du speicherst. Du legst neue Einträge in einer Collection an. Ans Layout kommst du nicht ran, weil du gar nicht drankommst. Der Designer dagegen ist der volle Bauzugriff: Struktur, Gestaltung, Components, eigener Code. Der braucht einen vollwertigen Sitz und gehört in die Hände von jemandem, der weiß, was er tut.

Dazu kommen Rollen. Klassisch gibt es Owner, Admin, Site Manager und Designer als volle Sitze, dazu Content Editor und Marketer als eingeschränkte. Ein Content Editor darf Text, Bilder und Links pflegen, ein Marketer zusätzlich mit freigegebenen Bausteinen arbeiten, aber keinen eigenen Code einbauen. Diese Aufteilung habe ich aus einem Agentur-Blog vom Juli 2026, nicht aus der Webflow-Dokumentation selbst, also prüf im Zweifel deinen eigenen Workspace.

Der Punkt, auf den es mir ankommt, ist ein anderer. Ein Site Manager kann pro Element gezielt festlegen, was ein Redakteur anfassen darf und was gesperrt bleibt. Das heißt: Sauber gebaut bedeutet nicht, dass dein Team weniger darf. Es bedeutet, dass es gefahrlos mehr darf. In der Werkstatt gibst du dem Azubi auch die Maschinen. Nur hat die Kreissäge einen Schutz, und der ist nicht da, um ihn zu ärgern.

Genau hier scheitern die meisten Builds, die ich mir anschaue. Nicht daran, dass Webflow zu wenig kann, sondern daran, dass beim Bau niemand entschieden hat, wer später was anfassen soll. Dann bekommt entweder das ganze Team Vollzugriff, und irgendwann verrutscht ein Layout und keiner weiß wie. Oder es bekommt niemand Zugriff, und jede Kleinigkeit läuft über den Dienstleister.

Wenn du an einer noch früheren Stelle stehst und dich fragst, ob Webflow für dich überhaupt das richtige System ist, hab ich das hier getrennt auseinandergenommen: Webflow oder WordPress: was passt zu deinem Unternehmen.

Wann braucht ein Baustein eine Component, wann reicht eine Klasse?

Kommt ein Baustein dreimal oder öfter vor und soll überall gleich funktionieren, wird er eine Component. Kommt er einmal vor, bleibt er ein einfaches Layout.

Eine Component ist ein Baustein, der einmal gebaut und dann an vielen Stellen eingesetzt wird. Änderst du das Original, ziehen alle Kopien mit. Denk an einen Stempel: einmal geschnitzt, hundertmal abgedrückt, und wenn du den Stempel änderst, ändern sich alle künftigen Abdrücke.

Woran du merkst, dass das gefehlt hat: Fünf Karten auf deiner Seite, die eigentlich identisch sein sollten, sehen alle ein bisschen anders aus. Bei einer sitzt das Bild zwei Pixel höher, bei einer anderen ist der Button einen Tick heller, der Abstand nach unten ist mal zwanzig, mal achtundzwanzig. Keiner kann sagen warum, es war halt Handarbeit. Und wenn du den Text auf dem Button ändern willst, zahlst du das fünf Mal statt einmal.

Der teurere Fehler geht in die andere Richtung: aus allem eine Component machen. Auch aus dem Grundgerüst der Seite, aus Abschnitten, aus Layouts, die es genau einmal gibt. Sieht im Bauplan ordentlich aus, macht dein Leben aber schwer. Denn dann lässt sich eine simple Ausnahme nicht mehr anpassen, ohne dass es an vier anderen Stellen mitzieht. Du sagst „auf der Karriereseite soll der Kasten mal ohne Bild sein", und plötzlich ist das ein halber Tag Arbeit statt fünf Minuten. Aus deiner Sicht sieht das aus wie „das CMS ist starr". In Wahrheit hat jemand zu früh zu viel festgezurrt.

Die ehrliche Prüfung dafür kostet dich einen Anruf: Frag, wie lange es dauert, auf genau einer Seite eine Ausnahme zu bauen. Wenn die Antwort „geht schnell" ist, passt die Struktur. Wenn ein Seufzer kommt, weißt du Bescheid.

Warum ist Variable First keine Designer-Spielerei, sondern spart dir später Geld?

Weil Farben, Abstände und Schriftgrößen an einer zentralen Stelle liegen und nicht zweihundertmal einzeln in der Seite verstreut. Änderst du deine Hausfarbe, wird sie einmal geändert und zieht überall durch.

Der Fall kommt öfter, als du denkst. Neues Logo, angepasste Farbe, andere Schrift, weil das Corporate Design überarbeitet wurde. Liegen die Werte zentral, ist das eine Änderung. Eine Farbe geändert, und die komplette Seite zieht mit. Easy!

Liegen sie nicht zentral, klappert jemand jede Seite ab, sucht jedes Element, in dem der alte Farbwert steckt, und rechnet das nach Stunden ab. Und weil garantiert drei Stellen übersehen werden, hast du danach noch drei Monate lang das alte Orange irgendwo im Footer stehen. Ein beschrifteter Sicherungskasten gegen die Kabelschublade, in der alles ineinander liegt: Beides funktioniert, solange nichts geändert werden muss.

Das ist der Grund, warum du beim Launch nichts davon siehst. Am ersten Tag sehen beide Websites gleich aus. Der Unterschied entsteht erst bei der ersten Änderung, und danach bei jeder weiteren. Gespart wird nicht beim Bau, gespart wird über die Laufzeit.

Und weil das schwer zu prüfen ist, wenn man nicht selbst baut, hier die Abkürzung: Frag deinen Dienstleister, was es kostet, die Hausfarbe zu ändern. Kommt „eine Viertelstunde", ist alles gut. Kommt „das müssen wir uns mal anschauen", hast du deine Antwort auch.

Warum ist "Text 1, Text 2, Bild neu final" ein Alarmzeichen für dein CMS?

Weil Feldnamen die einzige Anleitung sind, die dein Team jemals bekommt. Heißen die Felder „Text 1" und „Text 2", hat sich beim Bauen niemand Gedanken gemacht, wofür sie später gebraucht werden.

Zurück zur neuen Kollegin von ganz oben. Sie soll eine Referenz anlegen und sieht: Name, Text 1, Text 2, Text 3, Bild, Bild neu, Bild neu final. Sie macht das einzig Vernünftige und schreibt die Projektbeschreibung in Text 1.

Was dann passiert: Text 1 ist in Wahrheit die Überschrift auf der Detailseite. Ihre drei Sätze stehen jetzt fett und in Riesenschrift über dem Bild. Text 2 wäre der Teaser für die Übersichtsseite gewesen, der bleibt leer, also klafft in der Kachel ein Loch. „Bild neu final" wird überhaupt nirgends ausgespielt, das ist ein Rest aus einer Korrekturrunde von vor zwei Jahren. Und das Beste: Sie sieht von alledem nichts, bis die Seite live ist und der Chef anruft.

Und was macht sie beim nächsten Mal? Sie fasst nichts mehr an. Sie schreibt dir eine Mail und bittet dich, das zu übernehmen. Da kracht's in der Birne, und zwar bei genau der Person, die dir eigentlich Arbeit abnehmen sollte.

Ich hab dafür ein Bild, das jeder erkennt, der in den 90ern aufgewachsen ist: das Regal mit den VHS-Kassetten, auf denen „Aufnahme 3" steht. Kein Mensch weiß, ob da die Bundesliga, ein Spielfilm oder die Hochzeit von Tante Rita drauf ist. Also schaut keiner mehr rein, und irgendwann fliegt alles weg.

Der Fix kostet beim Bau zehn Minuten. Felder heißen wie das, was reinkommt: „Projekttitel", „Kurzbeschreibung für die Übersicht", „Bild für die Detailseite", „Bild für die Kachel". Dazu ein Satz Hilfetext pro Feld, direkt im Verwaltungsbereich, mit der Empfehlung zur Länge. Fertig. Das ist die billigste Investition im ganzen Projekt und die einzige Stelle, an der du als Laie die Qualität der Arbeit direkt beurteilen kannst, ohne eine Zeile Code zu verstehen.

Was passiert konkret, wenn ein Webflow-CMS falsch geschnitten ist?

Vier Schadensbilder, und alle vier zeigen sich erst Monate nach dem Launch. Hier stehen sie mit Ursache und dem, was du davon tatsächlich mitbekommst.

Was alle vier gemeinsam haben: Am Tag des Livegangs ist keins davon sichtbar. Die Seite sieht gut aus, alle sind zufrieden, die Rechnung ist bezahlt. Das Problem ist zeitversetzt. Es taucht auf, wenn Inhalte dazukommen, wenn Personen wechseln, wenn jemand etwas ändern will, was beim Bau keiner auf dem Zettel hatte.

Deshalb wirst du bei der Abnahme auch nie danach fragen. Du siehst ja nur die Vorderseite. Was du prüfen kannst, ist die Rückseite, und dafür gibt's im nächsten Abschnitt eine Liste.

Woran erkennst du in wenigen Fragen, ob dein Webflow-CMS pflegbar aufgebaut ist?

An sieben Fragen, die du alle ohne Technikwissen beantworten kannst. Setz dich zehn Minuten mit der Person zusammen, die die Inhalte tatsächlich pflegt, und geht sie gemeinsam durch. Nicht mit dem Dienstleister, sondern mit der Person, die klickt.

Kurz in eigener Sache, das gehört hier offen hin: Ich verdiene mein Geld damit, genau solche CMS zu bauen. Die Liste ist also auch eine Liste, mit der du mich prüfen kannst. Wenn ein Build von mir daran scheitert, ist das mein Problem und nicht deins. Fair ist fair.

1. Wenn eine neue Kollegin ohne Technikwissen übernimmt, kann sie einen neuen Eintrag anlegen, ohne dass irgendwo etwas kaputtgeht?
2. Verstehe ich in der Verwaltungsoberfläche auf Anhieb, wofür jedes Feld da ist, oder muss ich raten?
3. Muss ich für jede neue Rubrik den Dienstleister anrufen, oder kann ich das selbst anlegen?
4. Wenn ich im Bearbeitungsmodus versehentlich irgendwo klicke, kann ich das Layout kaputt machen, oder ist das abgesichert?
5. Gibt es Felder, die niemand mehr benutzt oder bei denen keiner mehr weiß, wofür sie da sind?
6. Wie viele Klicks brauche ich für zehn neue Einträge, und brauche ich dafür eine Anleitung?
7. Wenn in zwei Jahren jemand komplett Neues die Seite übernimmt, versteht die Person den Aufbau ohne lange Einarbeitung?

Vier Mal „weiß nicht" oder „muss ich fragen" ist kein Weltuntergang, aber ein Hinweis, wo du hinschauen solltest. Die meisten dieser Punkte lassen sich reparieren, ohne dass jemand die Website neu baut.

Und dann gibt's noch den Test, den du dir nicht aussuchst. Webflow stellt den Legacy Editor zum 4. August 2026 ein. An seine Stelle tritt der Edit Mode direkt auf der Seite, dazu ein neues Modell für Sitze und Rollen mit Client Seats. Angekündigt hat Webflow das im Dezember 2024, die Details kamen im Februar 2026, die Umstellung läuft seit dem 4. Mai 2026. Quelle ist Webflow selbst: der Community-Post „Legacy Editor deprecation and Introduction of Client Seats" auf community.webflow.com/updates, dazu der Beitrag auf webflow.com/blog.

Das ist keine Panikmache. Im Gegenteil, so ein Umbruch ist der ehrlichste Test, den ein Build bekommen kann. Websites, bei denen die Inhalte sauber im CMS liegen, die Felder verständlich benannt sind und beim Bau jemand entschieden hat, wer was anfassen darf, gehen da durch, ohne dass es jemandem auffällt. Die Redaktion loggt sich in eine andere Oberfläche ein und arbeitet weiter.

Bei gewucherten Seiten fällt in so einem Moment auf, was jahrelang nur deshalb funktioniert hat, weil eine bestimmte Person wusste, wo sie hinklicken muss. Ein Systemwechsel ist wie ein Umzug: Er zeigt, wie du gewohnt hast. Kellerregal mit beschrifteten Kisten, oder drei Kubikmeter „muss ich irgendwann mal sortieren", die du dann in Müllsäcken zum Nachmieter runterträgst.

Zugegeben, du kannst so ein Datum nicht planen. Aber du kannst dafür sorgen, dass es dich kaltlässt. Genau dafür ist der ganze Aufwand da, den ich hier beschrieben habe: nicht damit die Seite am ersten Tag schön ist, sondern damit sie am siebenhundertsten noch bedienbar ist.

Du willst eine Website, die dein Team selbst pflegt, ohne bei jeder Kleinigkeit anzurufen, und eine Struktur, die auch dann noch verständlich ist, wenn ich mal nicht am Telefon bin? Erzähl mir von deinem Projekt.