Landing Pages mit KI erstellen: System & Produkzentriertheit statt KI-Slop

Ich bin hier relativ kompromisslos: Wer Landing Pages mit KI über einen Prompt und das beste Modell erstellt, produziert AI-Slop. Punkt. Und sobald du das skalierst – viele Seiten mit KI – fällt das hart auf die Füße, weil sich der Müll multipliziert. Eine schlechte Landing Page ist ein Problem. Hundert schlechte Landing Pages sind ein Ranking-Risiko.

Das Thema KI-Content-Workflows ist gerade extrem heiß. Jeder redet über agentic Workflows und automatisierte Pipelines. Was ich in Kundenprojekten tatsächlich sehe, ist meist das Gegenteil: ein Prompt, generischer Output, Frust. Das Problem liegt fast nie am Modell. Es liegt am fehlenden System drumherum.

In diesem Artikel teile ich das Setup, mit dem ich Landing Pages mit KI erstelle – bei eigenen Produkten wie Rawshot und CareerTrainer sowie in Kundenprojekten. Ein System, das skaliert, ohne generisch zu werden. Es geht nicht um ein Tool, sondern um die Architektur dahinter. Und genau die fehlt den meisten.

Das Missverständnis: KI-Landing-Pages sind nicht Masse, sondern System

Landing Pages mit KI zu erstellen hat einen schlechten Ruf – zu Recht, wenn man darunter versteht, tausend Template-Seiten aus einer Datenbank zu pressen. Diese Phase hat Google längst durchschaut, und KI-Suche erst recht.

Mein Verständnis ist ein anderes. Es geht nicht um "möglichst viele Seiten", sondern um "ein wiederholbares System, das viele Seiten in gleichbleibender Qualität produzieren kann". Der Unterschied klingt subtil, ist aber entscheidend: Im einen Fall optimierst du auf Menge, im anderen auf ein replizierbares Qualitätsniveau.

Lass uns das einordnen, damit du weißt, ob es für dich relevant ist. Ich rede nicht von Blogartikeln, sondern von einem Landing-Page-System – produkt- und lösungsorientierte Seiten. Das funktioniert besonders gut für B2B-Service-Anbieter und vor allem für B2B-Software. Bei Rawshot, unserer AI-Fashion-Fotografie-Software, bauen wir damit zum Beispiel Seiten zu konkreten Anwendungsfällen wie Jewelry-Fotografie. Bei CareerTrainer läuft dasselbe System für ein völlig anderes Produkt.

Warum der Prompt-Ansatz zwangsläufig zu AI-Slop führt

Weißt du, was beim naiven Ansatz wirklich passiert? Du gibst der KI keinen Kontext, also greift sie auf ihr Durchschnittswissen zurück. Das Ergebnis: eine Seite über "Jewelry-Fotografie im Allgemeinen" – austauschbar, ohne Brand, ohne Haltung, am Ende des Tages komplett irrelevant.

Das skaliert dann auch noch. Du produzierst nicht eine generische Seite, sondern hundert. Und jede sieht aus wie die deines Wettbewerbers, der dieselbe KI mit demselben Nicht-Kontext gefüttert hat. Das ist die Gleichschaltung, die wir aus dem klassischen SEO kennen – nur diesmal automatisiert und in Lichtgeschwindigkeit.

Damit ein KI-Workflow verwertbare Ergebnisse liefert, braucht es im Kern zwei Dinge: Prompt-Regeln und Kontext. Und ich sage dir gleich, welcher der beiden den Unterschied macht.

Kurz zu den Modellen, weil das oft gefragt wird: Wir arbeiten mit wechselnden LLMs – aktuell vor allem Claude Opus 4.7, dazu GPT-5.4 und für Teilaufgaben kleinere Modelle wie GPT-5.4 Nano. Welches Modell wann – das wechselt regelmäßig. Lass dich davon nicht ablenken. Das Modell ist der austauschbarste Teil der Gleichung.

Prompt-Regeln sind die Pflicht

Die Prompt-Regeln sind die klassische Ebene: sprachlicher Output, Formatierung, Tonalität. "Schreib das so und so." Wichtig, aber nicht der Hebel. Wer hier stehen bleibt, bekommt sauber formatierten Slop. Formatierung war nie das Problem.

Kontext ist die Kür – und der eigentliche Hebel

Hier entscheidet sich alles. Wir wollen auf einer Rawshot-Seite eben keinen austauschbaren Text. Wir wollen, dass unsere Brand berücksichtigt wird und unsere Systematik durchscheint: wie wir über AI-Fashion-Fotografie denken, was uns besonders macht, wie wir den Markt sehen.

Das geben wir der KI über ein Framework mit. Technisch kann das eine Markdown-Datei sein, ein YAML-File oder etwas anderes – die Umsetzung ist nebensächlich. Entscheidend ist der Inhalt: Was ist das Produkt, was macht uns besonders, welche Use Cases und Zielgruppen gibt es, wie sieht der Markt aus, wie denken wir über unsere Kategorie?

In der Fachsprache heißt das Context Engineering. Und der Begriff trifft den Kern: Die Frage ist nicht "Wie formuliere ich den perfekten Prompt?", sondern "Welcher Kontext ist nötig, damit hier ein gutes Ergebnis herauskommt?" Genau diese Verschiebung trennt eine Marketing-Engine vom Slop-Generator.

Das Herzstück: Architektur aus Blöcken statt Einzelstücke

Jetzt wird es konkret – und hier liegt der strategische Kern des ganzen Ansatzes. Jede Landing Page ist bei uns definiert durch eine bestimmte Abfolge von Blöcken. Wenn du Page-Builder aus WordPress kennst, kennst du das Prinzip. Typische Blöcke: Hero, Use Case, Features, FAQ. Diese Blöcke existieren universell im System, über alle Projekte hinweg.

Eine Engine schlägt ein Kunstwerk

Hier kommt die Position, bei der ich kompromisslos bin. Stell dir vor, du hast 100 Unterseiten. Ich will nicht, dass jede komplett individuell ist – und das ist keine Bequemlichkeit, sondern Strategie.

Eine Website, auf der jede Seite ein Unikat ist, mag schön aussehen. Aber es ist ein künstlerisches System: nicht wiederholbar, nicht skalierbar, nicht erweiterbar. Das ist keine Marketing-Engine, wie die Amerikaner sagen würden. Eine Engine ist ein wiederholbares, replizierendes System, das man beliebig erweitern und aktualisieren kann.

Genau das ist der Punkt, an dem Landing-Page-Erstellung mit KI entweder funktioniert oder kippt. Standardisierung ist nicht der Feind der Qualität – sie ist die Voraussetzung dafür, Qualität überhaupt skalieren zu können.

Page Types: Seiten nach Funktion klassifizieren

Über den Blöcken steht eine zweite Ebene: die Seitentypen. Wir definieren Page Types, die jeweils einer Funktion folgen. Bei Rawshot sind das Solution Pages oder Feature Pages. Im Service-Geschäft können das Lösungsseiten, Vergleichsseiten oder Jobs-to-be-Done-Seiten sein. Eine Jobs-to-be-Done-Seite adressiert ein konkretes Ziel des Kunden – etwa Neukundengewinnung. Der Kunde "stellt" das Tool für diesen Job ein, und die Seite zahlt genau darauf ein.

In diese Klassifizierung fließt die eigentliche Strategiearbeit: Keyword-Daten, eine Wettbewerbsanalyse, die Frage, was beim Wettbewerb funktioniert. Das ist der Teil, der nicht automatisiert wird. Und das ist auch der Grund, warum meine KI-Landing-Pages nicht zu Slop werden – die Denkarbeit passiert vorher, nicht im Prompt.

Ein Block, mehrere Layouts

Jeder Block hat eine Aufgabe und teils mehrere Darstellungsformen. Ein Feature-Block lässt sich als Grid oder als Liste anzeigen. Auf einer Feature Page, wo ich eine einzelne Funktion ausführlich beschreibe, will ich kein Grid – das ist viel zu kompakt. Da brauche ich eine mehrdimensionale Darstellung. Auf einer Übersicht mit vielen Features ist das Grid genau richtig. Das Layout folgt der Funktion, nicht der Laune.

Context Engineering bis auf Block-Ebene

Das ist der Teil, den die meisten unterschätzen – und der über generisch oder einzigartig entscheidet. Der Kontext hört nicht beim Produkt-Framework auf. Er geht runter bis auf den einzelnen Block.

Nimm die FAQs. Die sind in SEO und GEO hochrelevant, weil KI-Systeme spezifische Fragen und Antworten ausgesprochen gerne zitieren. Das setze ich strategisch ein: Ich gebe vor, welche Fragen aufgegriffen werden und wie sie beantwortet werden. Dafür habe ich ein eigenes Dokument, das ich so auch schon für Kunden entwickelt habe – wie werden FAQs generiert, wie lang, wie formatiert, unterstützt das System HTML oder nicht?

Wichtig: Dieses ausführliche Dokument fließt nicht eins zu eins in die KI. Es ist die Referenz dahinter; in die KI fließt die verdichtete Version. Solche Regeln schreibe ich für nahezu jeden Block. Eine Hero-Sektion besteht aus H1, H2 und Description – also habe ich definiert, wie die H1 aufgebaut ist. Beim Erstellen einer einzelnen Seite gebe ich zusätzlich ein Briefing mit, bei uns als JSON-Input. Ich plane die Seite, formatiere das Briefing sauber und schreibe Custom-Anweisungen rein – etwa eine konkrete H1. Das System erkennt das und setzt es an die richtige Stelle.

Der Workflow: Mensch vorne, KI in der Mitte, Mensch hinten

So entstehen viele Landing Pages, die alle dasselbe System nutzen. Genau das macht die Erstellung skalierbar – ohne redaktionelle Kette für jede Seite. Aber, und das ist mir wichtig: Es ist kein "Knopf drücken, fertig". Der Prozess hat drei Phasen:

1. Redaktionell vorne (manuell): Ich entscheide, welche Seiten entstehen und was inhaltlich drauf muss. Das ist die Denkarbeit – Strategie, Page Type, Briefing.
2. Generierung in der Mitte (KI): Wenn das System sauber steht, läuft alles dazwischen über KI. Hier wird produziert und regelmäßig aktualisiert.
3. Check hinten (manuell): Bevor etwas live geht, schaue ich manuell drüber.

Der entscheidende Punkt: Die menschliche Arbeit verschiebt sich an die Ränder – Strategie und Qualitätskontrolle. Genau deshalb wird das Ergebnis kein Slop. Die KI ersetzt nicht das Denken, sie übernimmt den reproduzierbaren Mittelteil.

Updates ohne Mehraufwand

Ein Beispiel, das den Wert greifbar macht: Wir ergänzen ein neues Feature in der App. Statt jede Seite einzeln anzufassen, ergänze ich es an einer zentralen Stelle in der Markdown-Datei. Der Feature-Block wird dann auf allen Seiten geprüft: Passt das Feature hier rein? Auf einer Seite zum Thema Telefonvertrieb-Training passt nicht jedes Feature. Von 20 Features passen vielleicht fünf. Die KI wählt aus, prüft, ob es die fünf relevantesten sind, und synchronisiert diesen Block mit der zentralen Anweisung. Ein Update, alle relevanten Seiten aktualisiert. Das ist Skalierung, die ein Einzelstück-Ansatz niemals leisten kann.

Vom JSON ins Frontend

Am Ende wird die Seite als lange JSON-Datei generiert. Die spielen wir im Frontend aus und geben sie an einen Block-Renderer, bei uns in Next.js, der das Design über eigene Regeln festlegt. Angenehmer Nebeneffekt: Inhalt und Design sind getrennt. Ich kann das Design später anpassen, ohne den Content neu zu erstellen.

Was das in der Praxis bringt

Bei Rawshot bringt dieses Setup mittlerweile einige Besucher pro Tag – und wir verbessern es kontinuierlich. Das ist der eigentliche Vorteil: Gerade mit einem kleinen, effizienten Team kannst du so ein System iterieren und konstant besser machen, statt bei jeder neuen Seite von vorn anzufangen.

Hier liegt der ganze Unterschied:

• AI-Slop entsteht, wenn du einen Prompt absetzt und auf das beste Modell hoffst. Skaliert auf 100 Seiten wird daraus ein Ranking-Risiko.
• Eine Engine entsteht, wenn Kontext, Block-Architektur und Page Types so aufgesetzt sind, dass das System onbrand, wiederholbar und erweiterbar produziert.

Fazit: Erst das System, dann die Skalierung

Landing Pages mit KI zu erstellen funktioniert. Aber nicht über Masse und nicht über den perfekten Prompt. Es funktioniert über Architektur: durchdachter Kontext, standardisierte Block-Struktur, klar definierte Seitentypen. Wer diese Reihenfolge umdreht und zuerst skaliert, produziert Slop in großem Stil.

Drei Punkte zum Mitnehmen:

• Standardisiere bewusst. Ein wiederholbares Block-System schlägt 100 individuelle Kunstwerke, sobald Skalierung das Ziel ist.
• Investiere in Kontext, nicht in Prompts. Context Engineering bis auf Block-Ebene entscheidet über onbrand oder generisch.
• Halte den Menschen an den Rändern. Strategie vorne, Qualitätscheck hinten – nur der reproduzierbare Mittelteil gehört der KI.

Wenn du überlegst, wie du Landing Pages mit KI für dein Unternehmen erstellst, ohne in der Slop-Falle zu landen – schreib mir gerne.