Anzeige - Homepage-Baukasten im Praxis-Test: Für welche Projekte sich das Werkzeug wirklich lohnt

Die meisten Leute hier im Forum bauen ihre Sites in WordPress oder schreiben den Code lieber gleich selbst, und das bleibt für komplexe Projekte auch die richtige Entscheidung. Trotzdem landen in der Praxis immer wieder Aufträge auf dem Tisch, bei denen ein Baukasten schlicht das bessere Werkzeug ist: das Kundenprojekt mit knappem Budget, das eigene Portfolio, das sowieso nie fertig gepflegt wird, die Landingpage für eine befristete Kampagne oder die Seite, die der Kunde danach ohne Rückfragen an den Designer selbst und dauerhaft weiterführen soll. Gerade bei einer Kampagnenseite, die nach sechs Wochen wieder offline geht, lohnt sich der Aufwand eines vollständigen CMS-Setups selten, und genau dort zeigt sich der eigentliche Nutzen eines Baukastens im Alltag. Wie stark generative KI diese Kategorie gerade verschiebt, zeigt in diesem Artikel von it-boltwise.de: Layouts entstehen zunehmend automatisiert, die eigentliche Designentscheidung und die Abstimmung mit dem Kunden bleiben trotzdem Handarbeit.

Sechs Baukästen im nüchternen Vergleich​

Ein Blick auf die aktuell relevanten Anbieter zeigt, wie unterschiedlich die Schwerpunkte liegen. Wix punktet bei aufwendigen Animationen und App-Integrationen aus dem eigenen Marktplatz, verlangt dafür aber Geduld beim Aufräumen des Editor-Codes, sobald ein Kunde später mehr Kontrolle will. Squarespace liefert die saubersten Templates für Fotografie- und Portfolio-Seiten, bleibt bei Formularlogik und individuellem CSS aber restriktiv, was für reine Bildstrecken kaum stört. Jimdo zielt auf kleine Betriebe, die in wenigen Stunden online sein wollen, nicht auf gestalterischen Feinschliff oder komplexe Menüstrukturen. IONOS kombiniert Baukasten und klassisches Hosting in einem Vertrag, was bei Serverstandort-Fragen für deutsche Kunden praktisch ist und Rückfragen zur Rechnung erspart. WordPress.com, die gehostete Variante, sitzt irgendwo zwischen Baukasten und CMS und verwirrt Kunden regelmäßig, weil sie es mit dem selbst gehosteten WordPress verwechseln, obwohl beide Systeme unterschiedliche Regeln für Plugins und Themes haben. Der one.com Homepage Baukasten deckt das Segment kleiner Business-Seiten und Portfolios ab und richtet sich an Kunden, die Hosting, Domain und Editor aus einer Hand wollen, ohne sich um Server, Backups oder Updates zu kümmern.

Baukasten	Zielgruppe	Eigenes CSS/Code	Export möglich
Wix	Kreative, kleine Shops	Ja, über Velo/Editor-Code	Nein
Squarespace	Fotografen, Portfolios	CSS ja, Server-Code nein	Nein
Jimdo	Kleine lokale Betriebe	Stark eingeschränkt	Nein
IONOS	KMU mit eigenem Hosting-Wunsch	Begrenzt, tarifabhängig	Nein
WordPress.com	Blogs, kleine Business-Seiten	Nur mit Business-Plan	Inhalte per XML-Export
one.com	Kleine Business-Seiten, Portfolios	Eigenes CSS in höheren Tarifen	Nein

Kriterien, die für Designer tatsächlich zählen​

Bei der gestalterischen Freiheit zeigt sich der größte Unterschied zum Handcoding: Eigene Schriften lassen sich meist hochladen, aber echte Rastersysteme mit freier Spaltenzahl oder sauberen Abständen bieten die wenigsten Baukästen. Breakpoints sind in der Regel auf Desktop, Tablet und Mobile fixiert, eigene Zwischenstufen fehlen komplett. Bei Web-Fonts ist die Auswahl oft auf eine kuratierte Liste beschränkt, eigene Font-Dateien lassen sich nur bei wenigen Anbietern nachladen. Wer in Adobe XD ohnehin mit eigenen Farbpaletten und Verläufen arbeitet, merkt sofort, wo der Baukasten die Übersetzung verweigert.

Individuelles CSS lässt sich bei den meisten Anbietern nachträglich einbinden, allerdings oft nur als globaler Zusatzcode und nicht pro Element. Bei manchen Tarifen ist Custom Code sogar komplett gesperrt und erst ab einem höheren Abo-Level verfügbar, was bei der Kalkulation eines Projekts oft übersehen wird. Wer JavaScript-Interaktionen jenseits vorgefertigter Widgets braucht, stößt schnell an die Grenze der Editor-Logik.

Bilder werden serverseitig automatisch komprimiert, teils ohne moderne Formate wie WebP oder AVIF anzubieten. Gerade bei großformatigen Headerbildern führt das doppelte Komprimieren zu sichtbaren Artefakten, die im Vorschau-Modus des Editors kaum auffallen, auf dem fertigen Live-System aber schon. Wer Assets vorher sauber in Adobe XD importiert und optimiert, sieht die Kompression im Baukasten hinterher oft ein zweites Mal, unkontrolliert.

Ladezeit und Core Web Vitals leiden strukturell darunter, dass der Baukasten für jeden denkbaren Anwendungsfall vorbereitet sein muss und entsprechend mehr JavaScript ausliefert als eine schlanke Einzelseite. In der Praxis bedeutet das: Ein handcodiertes One-Pager schlägt einen Baukasten bei der Ladezeit fast immer, selbst wenn beide optisch identisch wirken. Die von Google definierten Metriken LCP, INP und CLS, dokumentiert bei web.dev, lassen sich in Baukästen kaum gezielt optimieren, weil die Ladereihenfolge vom System vorgegeben wird.

SEO-Grundlagen wie Meta-Angaben, strukturierte Daten oder saubere URLs sind inzwischen bei allen sechs Anbietern vorhanden, Mehrsprachigkeit dagegen unterschiedlich tief eingebaut, von einfacher Übersetzung bis zu echten Sprachversionen mit eigener URL-Struktur. Wer für einen Kunden mehrere Sprachversionen plant, sollte vorab prüfen, ob der Baukasten getrennte URLs pro Sprache erlaubt oder nur eine einzige Seite mit Sprachumschalter anbietet, was für die Suchmaschinenindexierung einen spürbaren Unterschied macht. Dabei zeigt sich auch, ob hreflang-Angaben automatisch gesetzt werden oder manuell nachgepflegt werden müssen, was bei größeren Projekten mit mehreren Zielmärkten schnell zum echten Zeitfresser wird. Beim Serverstandort und der DSGVO lohnt sich vorab ein Blick auf die Hinweise der Aufsichtsbehörden, etwa die Informationen des Bundesbeauftragten für den Datenschutz, bevor man einem Kunden zusichert, dass die Seite konform läuft.

Der wunde Punkt bleibt die Kundenübergabe: Baukasten-Websites lassen sich, WordPress.com mit seinem Inhalts-Export teilweise ausgenommen, praktisch nicht exportieren. Der Kunde bleibt an Editor und Vertrag des Anbieters gebunden, was bei der Auftragsklärung offen angesprochen gehört, nicht erst bei der Kündigung. Das gehört in jedes Angebot als expliziter Satz, nicht als Fußnote, damit der Kunde die Entscheidung informiert trifft.

Wann ein Baukasten nichts taugt​

Komplexe Shops mit Variantenlogik, Rabattstaffeln oder Lagerverwaltung sprengen die Baukasten-Logik schnell, hier fährt man mit einer dedizierten Shop-Software oder einem individuell entwickelten System besser. Gleiches gilt für individuelle Interaktionen, etwa Konfiguratoren oder datengetriebene Visualisierungen, die sich nicht in vorgefertigte Widgets pressen lassen. Auch mehrstufige Genehmigungs-Workflows oder Mitgliederbereiche mit granularen Rechten sprengen häufig das, was ein Baukasten an Logik mitbringt. Und sobald ein Projekt ein eigenes Designsystem mit definierten Komponenten, Tokens und Variantenlogik verlangt, wird der Baukasten zur Zwangsjacke statt zum Werkzeug.

Am Ende bleibt die Entscheidung eine Frage der Auftragslage, nicht der Überzeugung. Diese Wahl entscheidet auch über den Support-Aufwand, den man sich danach selbst einhandelt. Wer Kundenprojekte mit engem Budget oder Seiten betreut, die später ohne Designer weiterleben sollen, spart mit einem Baukasten reale Abstimmungsstunden. Wer dagegen an einem eigenen Designsystem oder einer komplexen Anwendung arbeitet, verliert mit jedem Baukasten-Kompromiss genau die Kontrolle, die im Tagesgeschäft den Unterschied zwischen Auftrag und Freelance-Frust ausmacht.