Die KI-generierte Next.js-Seite: warum sie vertraut aussieht und was wo gerendert wird

Next.js ist ein Framework, kein Design. Der vertraute Look kommt von dem, was standardmäßig obendrauf gelegt wird.

• Derselbe Starter-Stack. Next.js mit Tailwind und shadcn/ui ist die häufigste Antwort eines Modells, also wiederholen sich Komponenten, Abstände und Radius von Seite zu Seite.
• Überbleibsel aus dem Starter. Die Starter-Schrift, ein generischer Titel und eine leere Beschreibung schaffen es überraschend oft bis in die Produktion.
• Eine Landingpage für alles. Eine einzige Route trägt den ganzen Pitch, geschrieben für einen Durchschnittsbesucher, statt einer Seite pro Frage, die Leute tatsächlich stellen.
• Die durchschnittliche SaaS-Stimme: „Schneller ausliefern“, „Für moderne Teams gebaut“, „Kostenlos starten“. Korrekt, unanfechtbar und auf jeder anderen Seite.

Jeder dieser Punkte ist ein paar Minuten Arbeit im Code.

IntentGrid schreibt die Worte neu, die ein Besucher liest: Ü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 passt den Text an, den du schon renderst, und Markennamen, Preise, Daten und Zahlen bleiben, wie sie geschrieben sind.

Dein Repository, deine Komponenten, deinen Build und dein Caching fasst es nicht an, und eine Framework-Integration braucht es nicht. Es ändert kein Design, und eine Traffic-Quelle ist es 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 den Unterschied.

Im App Router sind Seiten standardmäßig Server Components und werden auf dem Server gerendert oder beim Build vorgerendert. Komponenten mit “use client” werden trotzdem zuerst auf dem Server zu HTML gerendert und erst danach im Browser interaktiv gemacht. Bei den meisten Next.js-Seiten steht der Text also in der HTML-Antwort, und die Demo kann ihn neu schreiben.

Die Ausnahmen zählen für Crawler genauso wie für die Demo: Text, der im Browser nach dem Laden der Seite geholt wird, Komponenten, die mit abgeschaltetem Server-Rendering geladen werden, und Inhalte, die erst nach einem Klick gerendert werden. Die Demo entfernt Scripts und sieht die Seite so, wie sie zuerst ankommt, und das ist ungefähr auch das, was ein Crawler sieht, der kein JavaScript ausführt.

Eine Version davon kannst du selbst bauen. Lies in der Seite den Suchparameter utm_source aus, ordne deinen zwei oder drei größten Quellen je eine Überschrift zu und fall für alle anderen auf den Standard zurück, unter derselben URL. Crawler kommen ohne den Parameter und bekommen den Standard.

Kenn die Kosten. Wer Suchparameter ausliest, sorgt dafür, dass die Seite pro Request gerendert wird, statt als vorgebaute Datei ausgeliefert zu werden. Für eine Landingpage ist das in Ordnung, aber du solltest es bewusst tun. Und jede Variante ist Text, den du ab jetzt von Hand pflegst. An diesem Punkt verdient sich ein Tool seinen Platz, und nicht früher.

Gleiches Layout, gleiche Preise, gleiche Aussagen. Jede Version nutzt nur, was die Originalseite ohnehin sagt: in diesem erfundenen Fall eine Installation per Script-Tag, eine Konfigurationsdatei und weniger Support-Tickets als erklärtes Ziel.

Das sind Codeänderungen, du kannst sie also mit dem KI-Tool machen, das die Seite gebaut hat.

• Gib shadcn/ui ein eigenes Theme. Ändere die CSS-Variablen für Farbe und Radius, damit die Komponenten nicht mehr aussehen wie bei allen anderen.
• Ersetze die Starter-Schrift über next/font, und setz mit der Metadata-API pro Route einen echten Titel und eine echte Beschreibung.
• Teil die eine lange Seite auf. Gib jeder echten Frage eine eigene Route mit eigenem Titel, damit Such- und Antwortmaschinen direkt auf der passenden Antwort landen können.
• Halte den Text in einer Content-Datei, getrennt vom JSX, damit neue Worte eine schnelle Änderung sind und keine Suche.
• Prüf das Rendering mit curl. Hol deine URL im Terminal und durchsuch die Ausgabe nach deiner Überschrift. Fehlt sie, wird irgendetwas nur im Browser gerendert.

Die Design-Hälfte, und warum jedes KI-Tool bei diesen Voreinstellungen landet, findest du unter warum vibe-gecodete Websites gleich aussehen.