transjt blog – Figma Design to HubSpot CMS

KI-basierte Website-Baukästen: Den generierten Code in ein CMS einbinden

Geschrieben von transjt.ai (Figma zu WordPress / HubSpot) | 20.8.2026

Die letzte Meile, die niemand einkalkuliert

Beschreiben Sie Claude Code, Lovable, v0 oder bolt.new eine Landingpage, und innerhalb von weniger als einer Minute haben Sie etwas auf dem Bildschirm. Es sieht gut aus. Es ist responsiv. Es ist tatsächlich ein funktionierendes Frontend. Und dann kommt das Projekt zum Stillstand – denn ein funktionierendes Frontend ist noch keine Website, die Ihr Marketingteam betreiben kann.

In der Lücke zwischen diesen beiden Dingen sterben die meisten KI-generierten Builds still und leise. Nicht, weil der Code schlecht ist, sondern weil jedes dieser Tools React erzeugt und weder WordPress noch HubSpot React als Content-Layer verwenden. Jemand muss das übersetzen – und dieser Jemand ist in der Regel ein Entwickler, der zwei Wochen Zeit übrig hat.

Was diese Tools einem tatsächlich liefern

Die acht Builder, nach denen wir am häufigsten gefragt werden, lösen alle dasselbe erste Problem – den Weg von einer Idee zu einer gerenderten Benutzeroberfläche –, unterscheiden sich jedoch stark darin, was Ihnen am Ende bleibt.

Tool Wo Sie arbeiten Was dabei herauskommt
Lovable Browser, befehlszeilengesteuert React mit Vite, synchronisiert mit GitHub
v0 Browser, Vercels „Prompt-to-UI“ Next.js, stark auf Tailwind und shadcn/ui ausgerichtet
bolt.new Browser, StackBlitz WebContainers Ein vollständiges Projekt, das in einer Sandbox läuft
Replit Cloud-Arbeitsbereich Eine auf dem eigenen Hosting von Replit bereitgestellte App
Claude Code Dein Terminal Dateien in Ihrem Repository, bereits in Git
Builder.io Visueller Editor oder Visual Copilot Mit dem Builder SDK verknüpfte Komponenten
Figma Make In Ihrer Figma-Datei React-Komponenten mit Ihren Design-Tokens
Rocket Browser, auf rocket.new Eine generierte Full-Stack-Anwendung

Lesen Sie die dritte Spalte noch einmal. Jede Zeile ist eine JavaScript-Anwendung. Keine davon ist ein CMS-Theme.

Warum die Übergabe fehlschlägt

1. Die Rendering-Modelle sind nicht kompatibel

WordPress rendert PHP-Vorlagen. HubSpot rendert HubL-Module serverseitig. React rendert im Browser oder auf einem Node-Server. Das sind keine stilistischen Vorlieben – es handelt sich um unterschiedliche Ausführungsmodelle, und kein Export-Button kann sie miteinander in Einklang bringen. Deshalb ist „einfach den Code exportieren“ niemals das Ende der Diskussion.

2. Die Bearbeitbarkeit geht verloren

Der Sinn eines CMS besteht darin, dass jemand, der keinen Code schreibt, an einem Freitagnachmittag eine Überschrift ändern kann. Eine React-Komponente hat keine bearbeitbaren Felder, keine Drag-and-Drop-Felder, nichts, was der Seiteneditor sehen kann. Wenn man die Komponente als eingebettete App einbindet, hat man technisch gesehen eine Website veröffentlicht, dabei aber den einzigen Grund beseitigt, warum das Unternehmen ein CMS wollte.

3. Alles rund um die Seiten fehlt

Eine Navigation, die die Struktur der Website kennt. Ein Blog mit Kategorien und Paginierung. Formulare, die mit dem CRM verbunden sind. Mehrsprachiges Routing. Weiterleitungen. Deine KI-Lösung hat eine Startseite; eine Website verfügt über all das – und nichts davon wird automatisch für dich generiert.

Was „produktionsreif“ bedeuten muss

Bevor man eine KI-Erstellung als veröffentlichungsfähig betrachtet, lohnt es sich, sie anhand der tatsächlichen Anforderungen des CMS zu überprüfen:

  • Native Vorlagen – echtes PHP für WordPress, echtes HubL für HubSpot, kein Iframe, keine eingebettete Single-Page-App und kein JavaScript-Code.
  • Definierte bearbeitbare Felder – jede Überschrift, jedes Bild und jeder CTA, die im Editor angezeigt werden, mit sinnvollen Standardwerten.
  • Wiederverwendbare Module – Abschnitte, die Ihr Team zu Seiten neu kombinieren kann, die Sie nie entworfen haben.
  • Server-gerendertes HTML – damit Suchmaschinen Inhalte indexieren können und nicht nur eine leere Hülle.
  • Funktionierende Website-Infrastruktur – Menüs, Blog, Formulare, Sprachvarianten und kanonische URLs.

Die meisten KI-Lösungen erfüllen am ersten Tag keine dieser Anforderungen. Das ist keine Kritik an den Tools – sie wurden entwickelt, um Benutzeroberflächen zu generieren, nicht um ein Content-Management-System bereitzustellen.

Zwei Ziele, eine Entscheidung

Welches CMS Sie als Ziel wählen, spielt eine geringere Rolle, als man vermuten würde, und der entscheidende Faktor ist selten technischer Natur.

Entscheiden Sie sich für WordPress, wenn Sie das Hosting selbst verwalten möchten, das Plugin-Ökosystem nutzen wollen und Ihrem Team einen Editor an die Hand geben möchten, mit dem es bereits vertraut ist. Sie erhalten Theme-Dateien, die Ihnen gehören, und nichts, was nicht mehr funktioniert, weil ein Anbieter seine Preise geändert hat.

Entscheiden Sie sich für HubSpot, wenn die Website eng mit dem CRM verzahnt sein muss – wenn Seiten anhand von Kontaktdaten personalisiert werden sollen und das Marketing Kampagnen erstellen möchte, ohne ein Ticket erstellen zu müssen.

Die bereits erstellte Website spielt dabei keine Rolle. Das gleiche Repository lässt sich in beide Richtungen konvertieren.

Die Lücke automatisch schließen

Genau diesen Übersetzungsschritt – Komponenten in Module, Stile in ein Theme, Layout in Vorlagen – automatisiert transjt. Verweisen Sie es auf das GitHub-Repository, mit dem Ihr KI-Tool bereits synchronisiert ist, und es erzeugt ein natives Theme: HubL-Module mit bearbeitbaren Feldern für HubSpot, PHP-Vorlagen für WordPress, wobei die Struktur Ihres Builds erhalten bleibt und nicht nur annähernd nachgebildet wird.

Was sich in der Praxis ändert, ist die Form des Projekts. Die zwei Wochen Übergangsarbeit sind keine Phase mehr. Der Build, den Sie am Dienstag erstellt haben, kann am Mittwoch bereits eine Website sein, an der Ihr Team arbeitet – und, was wichtig ist, auch noch sechs Monate später, ohne dass ein Entwickler hinzugezogen werden muss.

Wo soll man anfangen

Wenn Sie bereits wissen, mit welchem Tool Sie entwickelt haben, unterscheiden sich die Einzelheiten so stark, dass es sich lohnt, die entsprechenden Informationen zu lesen: v0 verwendet standardmäßig Next.js und erfordert einen Schritt, den Lovable nicht benötigt; Builder.io hat eine SDK-Abhängigkeit, die entfernt werden muss; und die Ausgabe von Claude Code befindet sich bereits in Git, sodass überhaupt nichts exportiert werden muss. Jeder Weg wird separat unter „AI to Website“ beschrieben.

Und falls Sie noch nichts erstellt haben: Generieren Sie das Frontend mit dem Tool, das Ihnen am besten gefällt. Die Konvertierung hängt nicht mehr von dieser Wahl ab.