Claude Code Landing Page, die nicht nach KI aussieht

Du hast Claude Code um eine Landing Page gebeten und die bekommen, die alle bekommen: eine Überschrift mit Farbverlauf, drei Karten mit Icons, „Trusted by 10,000+ teams“ für ein Produkt ohne einen einzigen Nutzer und ein Testimonial von einer Person, die es nicht gibt. Eine Claude Code Landing Page wirkt KI-gemacht, wenn der Agent alles erfinden muss. Gib ihm echte Abschnitte, deine Tokens und eine Regeldatei, und derselbe Agent liefert eine Seite, die nach deinem Produkt aussieht.

In diesem Tutorial baust du eine Landing Page mit Claude Code: die Startseite einer kleinen Rechnungs-App in Next.js, mit genau diesem Setup. Die Abschnitte kommen aus Wingo UI (Hero Section, Pricing Section, FAQ Section und CTA Section), aber die Reihenfolge der Arbeit gilt für jede Bibliothek mit MCP-Server. Mehr zu Agenten und UI findest du unter UI mit KI-Agenten bauen.

Warum wirkt eine Claude Code Landing Page KI-gemacht?

Jede Entscheidung, die der Prompt offenlässt, bekommt die häufigste Antwort. Ein zentrierter Hero über einem lila Glow ist häufig. Drei Feature-Karten, eine Logo-Leiste, eine Kundenzahl und drei Zitate sind es auch. Nichts davon ist für sich falsch. Zusammen, und ohne etwas aus deinem Produkt, ergeben sie den Look, den inzwischen jeder erkennt.

Zwei veröffentlichte Ansätze machen denselben Kompromiss. Der landing-page-Skill in jezweb/claude-skills (opens in a new tab) (zuletzt aktualisiert am 21. August 2026) schreibt eine einzige HTML-Datei mit Tailwind aus einem CDN, und das Tutorial von GemPages (opens in a new tab) (aktualisiert am 8. Juni 2026) verlangt sauberes, semantisches HTML mit eingebettetem CSS. Für eine einmalige Seite ist das in Ordnung. Die Startseite einer Next.js-App willst du so aber nicht bauen, denn dort soll die Seite Komponenten, Tokens und Dark Mode mit dem Rest teilen.

Das deutlichste Erkennungszeichen ist erfundener Proof. Ein Modell, das um Social Proof gebeten wird, schreibt Social Proof, mit Zahlen. Das ist ein Designproblem und ein Vertrauensproblem, und die Lösung gehört in die Regeldatei, die jede Session liest, statt in einen einzelnen Prompt.

Was richtest du vor dem ersten Prompt ein?

Vier Dinge, und jedes nimmt dem Modell eine Gruppe von Entscheidungen ab:

Schritt 1: Wie verbindest du Claude Code mit echten Abschnitten?

Führ diese Befehle im Projekt-Root aus. login speichert einen Key für die CLI (für kostenlose Einträge reicht ein kostenloser Account), und agents install claude schreibt den MCP-Eintrag in .mcp.json, einen Block in CLAUDE.md und einen Skill wingo-ui in .claude/skills/. Diese Einträge weisen Claude Code an, erst die Bibliothek zu durchsuchen, bevor es UI schreibt. Ohne WINGO_UI_API_KEY in deiner Umgebung läuft der MCP-Eintrag über einen lokalen stdio-Proxy, der den Key aus login nutzt:

npx wingo-ui@latest init
npx wingo-ui@latest login
npx wingo-ui@latest agents install claude

Wenn du den Server lieber von Hand hinzufügst, steht der Befehl in der MCP-Doku:

claude mcp add --transport http wingo-ui https://wingo-ui.com/mcp --header "Authorization: Bearer $WINGO_UI_API_KEY"

Starte Claude Code neu und prüf /mcp. Für eine Landing Page zählen diese Tools: search_components (findet Abschnitte über Stichwörter), get_component und get_block (Props mit ihren Defaults, die Parts und der Installationsbefehl), get_design_rules und get_theme_tokens. Damit liest Claude layout?: "centered" | "split" | "stacked" | ... aus der verlässlichen Quelle, statt einen Prop-Namen zu raten.

Installier danach die Abschnitte. Wenn du das selbst machst, geht es in der ersten Agent-Session nur um Text und Aufbau. Hero und Pricing Section sind Pro-Einträge, diese Zeile braucht also einen Pro-Key; die anderen vier installierst du mit einem kostenlosen:

npx wingo-ui@latest add hero-section pricing-section faq-section cta-section marketing-header marketing-footer

Schritt 2: Wie setzt du Tokens, damit Claude keine Farben mehr aussucht?

Lass die Komponenten in Ruhe und ändere die Tokens. Die Abschnitte lesen semantische Variablen, also macht ein einziger Block in app/globals.css aus unserem Orange deine Markenfarbe, in beiden Themes. Der Theme-Generator exportiert denselben Block, wenn du die Farbe lieber visuell auswählst:

/* app/globals.css, unter den Tokens, die init geschrieben hat */
:root {
  --brand: #0f766e;
  --brand-foreground: #ffffff;
  --brand-soft: #e6f4f1;
  --brand-soft-foreground: #0b5c55;
}

.dark {
  --brand: #14b8a6;
  --brand-foreground: #04201d;
  --brand-soft: #0b2a27;
  --brand-soft-foreground: #5eead4;
}

Leg dann die Entscheidungen für die ganze Seite als Provider-Defaults fest. So ist schon das kürzeste JSX, das Claude schreibt, markenkonform. Jeder Abschnitt liest seine Defaults über seinen Slug, und explizite Props gewinnen weiterhin:

// app/providers.tsx
"use client";

import type { ReactNode } from "react";
import { UIProvider } from "@/lib/ui-config";

const DEFAULTS = {
  "hero-section": { background: "grid", ctaTone: "brand", socialProof: false },
  "pricing-section": { tone: "brand" },
  "cta-section": { ctaTone: "brand", socialProof: false, showChecklist: false },
};

export function Providers({ children }: { children: ReactNode }) {
  return <UIProvider defaults={DEFAULTS}>{children}</UIProvider>;
}

Am wichtigsten ist hier socialProof: false. Hero und CTA Section bringen Beispiel-Proof mit („Loved by 12,000 teams“, Avatare, eine Bewertung), damit ihre Demos fertig aussehen. Dieser Text gehört zur fiktiven Firma Acme, nicht zu dir. Ist er standardmäßig aus, muss Claude Proof bewusst ergänzen, mit echten Daten.

Schritt 3: Was gehört in einen Claude Code Landing Page Skill?

Eine Regeldatei mit den Fakten und den Verboten, dazu ein kleiner Skill, der sie lädt, sobald es um die Landing Page geht. Die Fakten gehören in die Datei, denn was das Modell lesen kann, muss es nicht erfinden:

<!-- docs/LANDING.md -->
# Regeln für die Startseite

Produkt: Northwind Invoices, Rechnungen für Freelancer.
Angebot: Rechnung in zwei Minuten verschicken, automatische Erinnerungen, Kartenzahlungen.
Zielgruppe: Freelancer und Zwei-Personen-Studios in den USA. Preise in USD.

## Abschnitte, in dieser Reihenfolge
1. Header (marketing-header)
2. Hero (hero-section, layout split, echter Screenshot in BrowserFrame)
3. Preise (pricing-section, Pläne aus lib/plans.ts)
4. FAQ (faq-section, 4 bis 6 Fragen aus docs/support-questions.md)
5. Abschließender CTA (cta-section)
6. Footer (marketing-footer)

## Niemals
- Zahlen, Kundenzahlen, Bewertungen, Logos oder Zitate, die nicht in docs/proof.md stehen
- Beispieltext aus den Defaults einer Komponente (Acme, 12,000 teams, eine 14-tägige Testphase, Most popular, eine Antwortzeit des Supports)
- Text mit Farbverlauf, Emoji als Icons, Hex-Farben oder Klassen aus der Tailwind-Palette (bg-purple-500)
- Mehr als ein Button in Markenfarbe pro Abschnitt

## Prüfen, bevor du fertig meldest
- die Seite per grep nach Ziffern durchsuchen und jede Zahl mit docs/proof.md abgleichen
- Screenshots bei 390px und 1440px, hell und dunkel

<!-- .claude/skills/landing-page/SKILL.md -->
---
name: landing-page
description: Für jede Änderung an der Marketing-Startseite (app/page.tsx oder components/home/*). Liest zuerst docs/LANDING.md.
---

Lies docs/LANDING.md, bevor du etwas schreibst. Durchsuche Wingo UI mit search_components,
bevor du einen Abschnitt von Hand schreibst, und lies seine Props mit get_component. Ersetze
jedes Default-Label, das eine Tatsache behauptet. Führ am Ende die Checks aus LANDING.md aus.

Die Beschreibung des Skills sieht Claude Code zu Beginn jeder Session, deshalb nennt sie die Dateien, bei denen er greifen soll. Unser Beitrag zu AGENTS.md vs CLAUDE.md zeigt, wohin die Regeln gehören, die immer gelten, und das Tutorial zum Claude Code Design System ergänzt einen Hook, der jede bearbeitete Datei per grep nach Hex-Farben durchsucht.

Schritt 4: Welche Prompts funktionieren für eine Claude Code Landing Page?

Kurze Prompts, die genau einen Abschnitt abdecken und Komponente, Text, Ausschlüsse und Check nennen. Ein Claude Code Landing Page Prompt für die ganze Seite auf einmal gibt dem Modell wieder zu viele offene Entscheidungen. Hier ist die Reihenfolge für unsere Seite.

Prompt 1: planen, nichts installieren

Lies docs/LANDING.md. Sag mir für jeden Abschnitt, welche Wingo-UI-Komponente du nimmst, welche Props du setzt und welchen Text du noch von mir brauchst. Schreib noch keinen Code.

So kommen Lücken ans Licht, solange sie noch billig zu beheben sind. Steht im Plan ein Testimonial-Abschnitt, hat die Regeldatei versagt, und du korrigierst sie dort.

Prompt 2: der Hero

Bau den Hero in app/page.tsx mit HeroSection, layout split. Titel und Beschreibung aus docs/LANDING.md. Hauptaktion „Kostenlos starten“ zu /signup, zweite Aktion „Preise ansehen“ zu #pricing. Ersetze das Default-Mockup durch public/shots/invoice-editor.png in BrowserFrame. Keine Announcement-Pill.

Den Screenshot zu nennen ist wichtig. Das Default-Medium ist ein gezeichneter Workspace des Beispielprodukts, und eine Zeichnung der App von jemand anderem ist das nächste Erkennungszeichen.

Prompt 3: Preise aus echten Daten

Füg PricingSection mit der id "pricing" und den Plänen aus lib/plans.ts hinzu. Hervorgehobener Plan: pro, die Pill mit der Beschriftung „Empfohlen“. Blende den Vergleichslink aus, wir haben keine Vergleichsseite. Setz die Fußnote auf „Preise in USD. Jederzeit kündbar.“ Lies zuerst get_component und erfinde keine Prop-Namen.

Die Zeilen zu Fußnote und Pill stehen da, weil die Defaults „Paid plans start with a 14-day free trial“ und „Most popular“ lauten. Hat dein Produkt keine Testphase und noch keine Kunden, ist beides auf deiner Seite falsch.

Prompt 4: FAQ und abschließender CTA

Füg FaqSection mit den Fragen aus docs/support-questions.md hinzu, layout centered, jsonLd an, keine Kategorien, keine Kontaktkarte. Danach eine CtaSection: Titel „Verschick deine nächste Rechnung mit Northwind Invoices“, Hauptaktion „Kostenlos starten“ zu /signup, zweite Aktion „Zur Doku“ zu /docs.

Prompt 5: der Check

Führ die Checks am Ende von docs/LANDING.md aus. Liste jede Zahl auf der Seite mit ihrer Quelle auf, und jede Stelle, an der eine Komponente noch ihren Default-Text zeigt. Mach dann Screenshots von / bei 390px und 1440px in hell und dunkel und sag mir, was sich überlappt oder schlecht umbricht.

Behalte diesen Schritt, auch wenn die Seite gut aussieht. Ein Agent, der sein Ergebnis mit einer schriftlichen Liste abgleicht, hat etwas Konkretes zu finden, etwa Beispieltext, den er übersehen hat; fragst du nur „Sieht das gut aus?“, hat er nichts, woran er prüfen kann.

Wie sieht die fertige Seite im Code aus?

Die Seite bleibt eine Server Component, also stehen die Metadaten direkt daneben, und jeder Abschnitt ist eine Client-Komponente, die direkt importiert wird. Props, die der Provider schon setzt, fehlen hier:

// app/page.tsx
import type { Metadata } from "next";
import Image from "next/image";
import { BrowserFrame, HeroSection } from "@/components/blocks/hero-section";
import { PricingSection, type PricingSectionPlan } from "@/components/blocks/pricing-section";
import { FaqSection, type FaqItem } from "@/components/blocks/faq-section";
import { CtaSection } from "@/components/blocks/cta-section";

export const metadata: Metadata = {
  title: "Northwind Invoices: Rechnungen für Freelancer",
  description: "Verschick eine Rechnung in zwei Minuten, bekomm automatische Erinnerungen und nimm Kartenzahlungen an.",
};

const PLANS: PricingSectionPlan[] = [
  {
    id: "free",
    name: "Free",
    description: "Für deine ersten Kunden.",
    price: 0,
    features: ["3 Kunden", "Unbegrenzte Rechnungen", "Kartenzahlungen"],
    cta: { label: "Kostenlos starten", href: "/signup" },
  },
  {
    id: "pro",
    name: "Pro",
    description: "Für eine volle Kundenliste.",
    price: { monthly: 12, yearly: 10 },
    featuresTitle: "Alles aus Free, dazu:",
    features: ["Unbegrenzte Kunden", "Automatische Erinnerungen", "Wiederkehrende Rechnungen", "Dein Logo auf Rechnungen"],
    cta: { label: "Mit Pro starten", href: "/signup?plan=pro" },
  },
];

const FAQ: FaqItem[] = [
  { question: "Behaltet ihr einen Teil meiner Zahlungen ein?", answer: "Nein. Du zahlst die Gebühr des Kartenanbieters und sonst nichts." },
  { question: "Kann ich Kunden aus einer Tabelle importieren?", answer: "Ja. Lade eine CSV mit einer Spalte für Name und einer für E-Mail hoch." },
  { question: "Was passiert, wenn ich Pro kündige?", answer: "Du behältst jede Rechnung und fällst auf drei aktive Kunden zurück." },
];

export default function HomePage() {
  return (
    <main>
      <HeroSection
        announcement=""
        layout="split"
        title="Rechnung in zwei Minuten verschicken, pünktlich bezahlt werden"
        description="Northwind Invoices erstellt die Rechnung aus deinen Stunden, erinnert, wenn sie überfällig ist, und nimmt Kartenzahlungen an."
        labels={{ primary: "Kostenlos starten", secondary: "Preise ansehen" }}
        hrefs={{ primary: "/signup", secondary: "#pricing" }}
        media={
          <BrowserFrame url="invoices.example.com">
            <Image src="/shots/invoice-editor.png" alt="Der Rechnungseditor mit zwei Positionen und einem Senden-Button" width={1600} height={1000} priority />
          </BrowserFrame>
        }
      />
      <PricingSection
        id="pricing"
        title="Ein fester Preis, kein Anteil an deinen Rechnungen"
        description="Starte kostenlos mit drei Kunden. Wechsle zu Pro, wenn es mehr werden."
        plans={PLANS}
        featuredPlan="pro"
        showCompare={false}
        labels={{
          billedMonthly: "monatlich abgerechnet",
          billedYearly: "jährlich abgerechnet",
          popular: "Empfohlen",
          footnote: "Preise in USD. Jederzeit kündbar.",
        }}
      />
      <FaqSection
        description="Zahlungen, Importe und was beim Kündigen passiert."
        items={FAQ}
        showCategories={false}
        contact={false}
        jsonLd
      />
      <CtaSection
        title="Verschick deine nächste Rechnung mit Northwind Invoices"
        description="Kostenlos für deine ersten drei Kunden. Keine Karte nötig."
        labels={{ primary: "Kostenlos starten", secondary: "Zur Doku" }}
        hrefs={{ primary: "/signup", secondary: "/docs" }}
      />
    </main>
  );
}

Zwei der ersetzten Defaults übersieht man leicht: die Pill „Most popular“ am hervorgehobenen Plan (eine Behauptung, die ein neues Produkt nicht machen kann) und die Kontaktkarte der FAQ Section, die eine Antwort innerhalb eines Werktags verspricht. Umschließ {children} in app/layout.tsx mit den Providers aus Schritt 2, und setz Header und Footer ebenfalls dorthin, wenn andere Marketing-Seiten sie teilen. Gib dem Header deine eigenen items und dem Footer deine eigenen columns, legalLinks und socials, denn ihre Defaults sind die Beispielnavigation von Acme.

Wie prüfst du die Seite vor dem Launch?

Schau sie dir selbst an, nach dem Check des Agenten. Geh dabei vier Punkte durch:

1. Zahlen. Durchsuch die gerenderte Seite nach Ziffern. Jede braucht eine Quelle, die du einem Kunden zeigen könntest.
2. Default-Text. Such nach dem Namen des Beispielprodukts. In den Abschnitten von Wingo UI ist das „Acme“.
3. Smartphone-Breite. Bei 390px stapelt sich der Split-Hero, die Aktionen gehen auf volle Breite, und die Preiskarten werden zu einer Leiste. Lies die Überschrift in dieser Breite; lange Wörter in großer Schrift sind die Stelle, an der der Umbruch schiefgeht.
4. Beide Themes. Deine Markenfarbe hat nicht ohne Grund einen hellen und einen dunklen Wert. Prüf, ob der Hauptbutton und die weichen Farbflächen im Dark Mode gut lesbar sind.

Unser Guide zur Next.js SaaS Landing Page zeigt, was jeder Abschnitt beweisen muss und was du streichst, solange du noch keinen Proof hast.

Solltest du stattdessen mit der kompletten Vorlage starten?

Wenn deine Seite der üblichen SaaS-Reihenfolge folgt, ja. Die Vorlage Landing Page setzt Hero, Logos, Bento-Features, eine Produkttour, Zahlen, Zitate, einen Pricing-Teaser, das FAQ und den CTA zusammen. Ein Prop design (classic, bold, editorial, minimal) wählt den Look aller Abschnitte auf einmal, und mit den show*-Props lässt du Abschnitte weg, die du nicht ehrlich füllen kannst. Für eine Startseite mit Claude Code ist das der kürzeste Weg: ein Prompt, um die Inhalte zu tauschen, einer, um Abschnitte auszuschalten, einer für den Check.

Einzelne Abschnitte sind die bessere Wahl, wenn du eine andere Reihenfolge brauchst, einen Abschnitt, den die Vorlage nicht hat, oder nur drei davon, wie in diesem Tutorial. Die Vorlage Landing Page, Hero Section und Pricing Section gehören zu Wingo UI Pro; FAQ Section, CTA Section, Marketing Header und Marketing Footer sind kostenlos.

Tiefer auf die Agent-Seite geht der Guide zum MCP für Komponentenbibliotheken ein: was der Server zurückgibt und wie eine komplette Session abläuft. Das shadcn-MCP-Setup für Claude Code zeigt, wie du zwei Registries nebeneinander betreibst.

Was ist der nächste Schritt?

Fang mit den kostenlosen Teilen an. Ein kostenloser Account (nur E-Mail, keine Karte) gibt der CLI und dem MCP-Server einen Key für jeden kostenlosen Eintrag. Führ npx wingo-ui@latest login und npx wingo-ui@latest agents install claude aus und installier dann das abschließende Band und das FAQ:

npx wingo-ui@latest add cta-section faq-section

Schreib danach deine docs/LANDING.md, bevor du den ersten Prompt abschickst. Gutes Claude Code Landing Page Design beginnt mit der Regeldatei: Sie ist der Teil, der dafür sorgt, dass die Seite deine bleibt.

Häufige Fragen

Kann Claude Code eine Landing Page bauen?

Ja. Claude Code schreibt die Dateien in dein Projekt, installiert Pakete und kann deinen Dev-Server starten, also baut es eine komplette Landing Page in Next.js oder reinem HTML. Wie sie aussieht, hängt vom Ausgangsmaterial ab: Ohne Komponenten, Tokens und Regeln greift es auf die Muster zurück, die es am häufigsten gesehen hat.

Gibt es einen Claude Code Landing Page Skill?

Es gibt Skills aus der Community, etwa den landing-page-Skill in jezweb/claude-skills, der eine einzige HTML-Datei mit Tailwind aus einem CDN erzeugt (Stand November 2026). Für eine Seite in einer bestehenden Next.js-App passt ein kurzer eigener Projekt-Skill besser, der auf deine Regeldatei und deine Komponenten verweist.

Wie sieht ein guter Claude Code Landing Page Prompt aus?

Er deckt genau einen Abschnitt ab und nennt vier Dinge: die Komponente, den echten Text oder woher er kommt, was wegbleibt und wie das Ergebnis geprüft wird. „Bau eine Landing Page für meine App“ überlässt all das dem Modell.

Warum sieht meine KI-generierte Landing Page so generisch aus?

Weil jede Entscheidung, die du nicht getroffen hast, mit der häufigsten Antwort gefüllt wird: ein zentrierter Hero mit Verlauf, drei Karten mit Icons, eine ausgedachte Kundenzahl und erfundene Testimonials. Triff diese Entscheidungen vor dem ersten Prompt, mit Tokens, einer Liste der Abschnitte und einer Regeldatei.

Vorlage oder einzelne Abschnitte für die Landing Page?

Nimm die komplette Vorlage, wenn deine Seite der üblichen SaaS-Reihenfolge folgt und du schnell einen fertigen Look willst. Nimm einzelne Abschnitte, wenn du eine andere Reihenfolge oder nur einige davon brauchst, denn jeder wird über seine eigenen Props konfiguriert.