Mit Replit Agent gebaut? Warum sich die Seite liest wie alle anderen

Replits Stärke ist, dass das Ganze von vorne bis hinten funktioniert. Die Marketingseite ist der Teil, den niemand spezifiziert hat.

• Die App ist das Briefing. Prompts beschreiben, was das Produkt tut, also wird die Landingpage nebenbei geschrieben, direkt aus der Feature-Liste.
• Beliebte Voreinstellungen. Ohne andere Anweisung stützen sich generierte Frontends auf das, was Modelle am häufigsten gesehen haben, etwa React mit Tailwind und ein Standard-Komponentenset.
• Text als Feature-Liste. Ohne Leser im Briefing wiederholt der Hero die Features im sichersten Register: „Deine All-in-one-Plattform für …“.
• Ein Durchgang, dann live. Das Deployment ist gleich zur Hand, also ist der erste Textentwurf sehr oft der, der öffentlich wird.

Nichts davon ist Replit-spezifisch. Es passiert, wenn das Bauen schnell wird und das Schreiben nicht.

IntentGrid schreibt die Worte für jeden Besucher neu: Überschriften, Fließtext, Feature-Beschreibungen und Button-Beschriftungen, je nachdem, wie er 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 bleiben, wie sie geschrieben sind.

Dein Replit-Projekt, deinen Code, deine Datenbank und dein Deployment fasst es nicht an, und die Daten deiner Nutzer sieht es nie. Es ändert kein Design, und Traffic bringt es dir nicht.

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, was heute läuft.

Replit baut den Stack, den der Agent wählt oder den du verlangst. Ist das Frontend eine client-gerenderte Single-Page-App, liefert die deployte URL eine fast leere HTML-Hülle, und die Demo, die Scripts entfernt, hat kaum etwas zum Neuschreiben. Rendert dein Backend das HTML selbst, wie eine Flask- oder Express-App, die Templates ausliefert, steht der Text in der Antwort, und die Demo kann damit arbeiten.

Zum Prüfen öffnest du „Seitenquelltext anzeigen“ (nicht „Untersuchen“) auf deiner deployten URL und suchst nach deiner Überschrift. Ein praktischer Hinweis: Wenn dein Deployment im Leerlauf herunterskaliert, kann die erste Anfrage nach einer ruhigen Phase langsam sein, und der Abruf der Demo läuft womöglich in einen Timeout. Ruf die Seite einmal selbst auf und füg sie dann ein.

Gleiches Layout, gleiche Preise, gleiche Aussagen. Jede Version nutzt nur, was die Originalseite ohnehin sagt: in diesem erfundenen Fall Nachhilfe in Mathe und Physik, Buchung vom Handy und Bewertungen von Schülern.

Replit Agent setzt diese Änderungen um, wenn du ausdrücklich danach fragst.

• Trenn die Marketingseite von der App. Verlang die Landingpage unter der Root-URL, als schlichtes HTML von deinem Backend gerendert, mit der App hinter einem Login. Crawler und die Demo bekommen dann beide echten Text.
• Schreib das Briefing für einen Leser: für wen das ist, was diese Leute heute nutzen und wovon sie genug haben. Verlang einen Hero, der genau das sagt, nicht die Feature-Liste.
• Verlang einen Abschnitt, den die Voreinstellungen nie erzeugen würden: einen echten Screenshot der App, ein durchgespieltes Beispiel, die kurze Geschichte eines Nutzers.
• Gib jeder Route einen eigenen Titel und eine eigene Beschreibung, nicht nur den App-Namen.
• Dann schreib die Überschrift selbst neu. Es ist ein Satz, und es ist der, den die meisten Besucher lesen.

Die Design-Seite davon, und warum jedes KI-Tool bei denselben Voreinstellungen landet, findest du unter warum vibe-gecodete Websites gleich aussehen.