Warum deine Bolt.new-App generisch aussieht und die Demo womöglich eine leere Seite sieht

Bolt.new ist auf Tempo vom Prompt bis zur laufenden App gebaut, und Tempo begünstigt Voreinstellungen.

• Ein üblicher Start-Stack. Wenn du nichts anderes verlangst, greift Bolt.new meist zu React, Vite und Tailwind mit einem bekannten Icon-Set, also zu denselben Bausteinen, die die meisten generierten Apps nutzen.
• Prompts für die ganze App. „Bau einen Essensplaner mit Landingpage“ verlangt ein Produkt und sein Marketing in einem Atemzug, und die Landingpage bekommt die wenigste Aufmerksamkeit.
• Kein Textschritt. Das Modell schreibt jedes Wort im ersten Durchgang, und nichts im Ablauf fordert irgendwen auf, es zu ersetzen, also ist der erste Entwurf das, was Besucher lesen.

Die App hinter der Seite ist oft beeindruckend. Die Landingpage davor ist der Teil, der sich generiert liest.

IntentGrid schreibt die Worte für jeden Besucher neu: Überschriften, Fließtext, Feature-Beschreibungen und Button-Beschriftungen, je nachdem, wie dieser Besucher gekommen ist. Es arbeitet mit dem Text, den deine Seite schon hat, und hält Markennamen, Preise, Daten und Zahlen auf einer Nicht-anfassen-Liste.

Dein Bolt.new-Projekt, deinen Code, dein Styling und dein Deployment fasst es nicht an, und eine client-gerenderte Seite, die keinen Text ausliefert, kann es nicht reparieren. Auf so einer Seite steht im HTML nichts, was es neu schreiben könnte.

Heute ist der funktionierende Teil eine Demo, die eine neu geschriebene Kopie einer öffentlichen URL in einer Sandbox auf intentgrid.ai rendert; die Anpassung auf deiner eigenen Domain ist Early Access und wird pro Seite von Hand eingerichtet. So funktioniert es beschreibt den Mechanismus vollständig.

Wenn eine Bolt.new-App eine Vite-Single-Page-App ist, liefert ihr Server index.html aus: einen Titel, eine Meta-Description, ein leeres Root-Element und ein Script. Jede Überschrift erscheint erst, nachdem dieses Script gelaufen ist. Die Demo holt das HTML und entfernt Scripts, also findet sie bei diesen Apps meist fast nichts zum Neuschreiben, und die Vorschau kommt beinahe leer zurück. Das ist eine Grenze der Demo, und wir sagen es lieber hier, als dass du es selbst herausfindest.

Dieselbe Hülle bekommt jeder Crawler, der kein JavaScript ausführt, darunter viele KI-Crawler, und der Head dieser Datei ist alles, was eine Linkvorschau liest. Um zu sehen, was sie sehen, öffne „Seitenquelltext anzeigen“ (nicht „Untersuchen“) auf deiner deployten URL. Steht deine Überschrift nicht darin, können weder die Demo noch diese Crawler sie lesen.

Gleiches Layout, gleiche Preise, gleiche Aussagen. Jede Version nutzt nur, was die Originalseite ohnehin sagt: in diesem erfundenen Fall Planung mit den Zutaten, die du schon hast, und eine generierte Einkaufsliste. Bei einem client-gerenderten Build müsste der Text erst im HTML stehen, bevor die Demo irgendetwas davon neu schreiben kann.

Grob danach sortiert, wie viel jeder Punkt für den Aufwand bewirkt:

• Schreib einen echten Titel und eine echte Meta-Description in index.html. Bei einer client-gerenderten App ist das oft der einzige Text, den ein nicht rendernder Crawler oder eine Linkvorschau je liest.
• Bring die Landingpage ins HTML. Bitte Bolt.new, die Marketing-Routen vorab zu rendern oder die Landingpage als statische Seite vor die App zu bauen.
• Schreib den Hero selbst neu, in Worten, die ein echter Nutzer benutzt hat. Ein von Hand geschriebener Satz schlägt beliebig viele Neugenerierungen.
• Verlang ein anderes Layout beim Namen. Sag, was du statt Gradient-Hero und drei Karten willst: einen Produkt-Screenshot, ein kurzes Demo-Video, ein einziges starkes Praxisbeispiel.
• Verbiete die Stangenware-Phrasen einmal, ausdrücklich: „mühelos“, „nahtlos“, „All-in-one“, „boosten“. Dann lass es jeden Satz markieren, der auch auf der Seite eines Konkurrenten stehen könnte.

Um die Design-Hälfte des Problems geht es unter warum vibe-gecodete Websites gleich aussehen.