Warum sich jede Cursor-Landingpage gleich liest

Cursor gibt dir weit mehr Kontrolle als ein Prompt-to-App-Builder, und trotzdem gleicht sich das Ergebnis an, aus Gründen, die vor dem Editor liegen.

• Das Modell ist der Designer. Cursor schickt deine Anfrage an ein Modell, das du aus einer kurzen Liste wählst, und dieselben wenigen Modelle schreiben die meisten neuen Landingpages im Web. Sie teilen dieselben Voreinstellungen.
• Der Standard-Stack ist der beliebte Stack. Um eine Landingpage gebeten, greifen Modelle zu dem, was sie am häufigsten gesehen haben: Next.js oder React, Tailwind, shadcn/ui, lucide-Icons. Gute Werkzeuge, identisches Ergebnis.
• Der Agent füllt die Lücken. Bitte um „eine Landingpage für meine API“, und er entscheidet über die Abschnitte, ihre Reihenfolge und jedes Wort und wählt dabei jeweils die häufigste Antwort.
• Platzhaltertext überlebt. Das „Schneller bauen. Klüger ausliefern.“ aus dem ersten Entwurf sollte ersetzt werden, und auf vielen veröffentlichten Seiten ist das nie passiert.

Der Code ist oft gut. Die Seite ist trotzdem austauschbar, weil die Entscheidungen, die eine Seite konkret machen, nie jemand getroffen hat.

IntentGrid schreibt die Worte für jeden Besucher neu: Überschriften, Fließtext, Feature-Beschreibungen und Button-Beschriftungen, je nachdem, wie dieser Besucher gekommen ist (Traffic-Quelle, Kampagne, ungefähre Stadt, Gerät, Sprache, Ortszeit). Es geht von dem Text aus, den du schon hast, und Markennamen, Preise, Daten und Zahlen stehen auf einer Nicht-anfassen-Liste.

Dein Repository fasst es nicht an. Für die Demo gibt es nichts zu installieren, keine Änderung an deinen Komponenten, deinem CSS, deinem Layout oder deinem Build und nichts, was Cursor mergen müsste. Ein generisches Layout repariert es nicht, und Traffic bringt es dir auch nicht.

Der funktionierende Teil ist heute eine Demo, die eine neu geschriebene Kopie jeder ö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 erklärt die Details.

Was die Demo sieht, hängt davon ab, was du Cursor hast bauen lassen. Eine Next.js-Seite rendert ihre Seiten standardmäßig vorab oder auf dem Server, also enthält das HTML deinen Text bereits und die Demo hat etwas zum Neuschreiben. Eine mit Vite gebaute React-Single-Page-App schickt stattdessen ein leeres Root-Element und ein Script; der Text erscheint erst, wenn JavaScript läuft, und weil die Demo Scripts entfernt, kann die Vorschau fast leer zurückkommen.

Das prüfst du in zehn Sekunden: Öffne „Seitenquelltext anzeigen“ (nicht „Untersuchen“) und such nach deiner Überschrift. Fehlt sie, hat die Demo wenig, womit sie arbeiten kann, und genauso jeder Crawler, der kein JavaScript ausführt, darunter viele KI-Crawler. Für eine Marketingseite lohnt sich die Reparatur ohnehin, und statische Generierung für die Route der Landingpage ist meist eine kleine Änderung.

Gleiches Layout, gleiche Preise, gleiche Aussagen. Jede Version nutzt nur, was die Originalseite ohnehin sagt: in diesem erfundenen Fall YAML-Konfiguration und eine Statusseite, die sich automatisch aktualisiert.

Weil der Code dir gehört, kannst du das meiste davon im Editor reparieren, und einiges davon dauert nur Minuten.

• Schreib Einschränkungen in eine Rules-Datei. Projektregeln liegen in .cursor/rules und lassen sich auf jede Anfrage anwenden, also schreib die Design- und Textregeln einmal auf: eine Akzentfarbe, kein Gradient-Hero, keine Reihe aus drei Karten, eine Liste verbotener Phrasen.
• Leg den Text in eine einzige Datei. Halte jede Überschrift, Zwischenüberschrift und Button-Beschriftung in einem Content-Modul, statt sie übers JSX zu verstreuen. Du schreibst Worte viel öfter neu, wenn sie alle an einem Ort stehen.
• Verbiete die Durchschnittsphrasen: „optimieren“, „nahtlos“, „entfesseln“, „befähigen“, „boosten“, „auf das nächste Level“. Dann lass Cursor jeden Satz auf der Seite finden, der auch auf der Seite eines Konkurrenten stehen könnte.
• Schreib die Überschrift selbst, mit den Worten, die ein Nutzer in einem Issue, einer Support-Mail oder einer Forenantwort geschrieben hat, statt mit denen, die das Modell angeboten hat.
• Bau von Hand eine Variante pro Kanal. Wenn der meiste Traffic von zwei Orten kommt, lies den utm_source-Parameter aus und tausch für jeden die Überschrift aus. Behalte den Standard für alle anderen, Crawler eingeschlossen, und behalte eine URL.
• Render die Landingpage auf dem Server. Wenn der Seitenquelltext keinen Text zeigt, mach die Marketing-Routen statisch. Das hilft Crawlern und der IntentGrid-Demo gleichermaßen.

Ausführlicher geht es um die Design-Hälfte unter warum vibe-gecodete Websites gleich aussehen.