ko-system/landing-page

Landing Page (Zielseite)

Eine Landing Page hat eine einzige Aufgabe: einen bestimmten Besucher zu einer Handlung zu bewegen. Jeder Abschnitt baut entweder das Argument für diese Handlung auf oder beseitigt einen Grund, sie nicht auszuführen. Entscheide zuerst die Handlung, dann gestalte.

1. Entscheide vor dem Bau

Schreibe diese Punkte auf (in DESIGN.md, falls die App eine hat), bevor du JSX anfasst:

• Zielgruppe: Wer kommt hier an und was wissen sie bereits?
• Primäre Handlung: ein Verb („Kostenlos testen“, „Tisch reservieren“, „Angebot anfordern“). Jede Seite hat genau ein primäres CTA-Label; wiederhole es, variiere es nicht.
• Sekundäre Handlung: optional und mit geringerer Verbindlichkeit („Preise ansehen“, „Demo ansehen“).
• Tatsächlich vorhandene Beweise: echte Zahlen, Kundennamen, Zitate, Bewertungen. Erfinde niemals Testimonials, Logos, Benutzerzahlen oder Preise. Wenn der Eigentümer sie nicht geliefert hat, lasse den Abschnitt weg oder verwende einen deutlich markierten TODO im Inhaltsdaten – nicht im sichtbaren Text.

2. Abschnittsreihenfolge (Standard)

#	Abschnitt	Zweck	Block
1	Header	Marke, 3-5 Navigationslinks, primärer CTA	SiteHeader
2	Hero	Versprechen + primärer CTA above the fold	Hero
3	Beweisstreifen	Logos, Bewertung oder eine harte Zahl	LogoMarquee oder Inline-Statistiken
4	Problem/Ergebnis	Warum der Status quo schadet, was sich ändert	Section + SectionHeader
5	Funktionen	3-6 Vorteile, jeder an ein Ergebnis geknüpft	FeatureGrid oder BentoGrid
6	So funktioniert`s	3-4 Schritte, wenn der Prozess unbekannt ist	StepList
7	Testimonials	Echte Zitate mit Name und Rolle	Testimonials
8	Preise	Pläne oder „ab“-Preis und was enthalten ist	PricingTable
9	FAQ	Einwände klar beantwortet	Faq
10	Finaler CTA	Versprechen wiederholen + gleicher primärer CTA	CtaBand
11	Footer	Kontakt, rechtliches, sekundäre Links	SiteFooter

Streiche Abschnitte, die keine echten Inhalte haben. Eine kurze, ehrliche Seite ist besser als eine lange, aufgeblähte. Mindestens die Abschnitte 1, 2, 5 und 10 beibehalten.

3. Hero-Regeln

• Genau ein <h1> auf der Seite, im Hero. Hero rendert seinen title bereits als h1; füge kein weiteres h1 hinzu. Abschnittsüberschriften sind h2.
• Die Überschrift gibt das Ergebnis für die Zielgruppe in unter ~10 Wörtern an. Der Untertitel (ein oder zwei Sätze, unter ~25 Wörtern) sagt, wie, für wen oder was ihn anders macht.
• Primärer CTA sichtbar ohne Scrollen bei 375x667 und 1280x800. Setze ihn in die actions-Eigenschaft von Hero; verlinke zum echten Ziel (Route, mailto:, tel:, Formular-Anker), niemals href="#".
• Medien: ein echter Produktscreenshot, ein Foto oder eine Illustration, die das Ergebnis zeigt. Setze explizite width/height auf das Bild und lade das Hero-Bild nicht lazy (es ist normalerweise das LCP-Element).
• Optionale Vertrauenszeile unter dem CTA: „Keine Kreditkarte erforderlich“, „4,8/5 von 1.200 Bewertungen".

4. Texthierarchie

1. Überschrift (h1): Ergebnis. 2. Untertitel: Mechanismus oder Zielgruppe. 3. CTA: Verb + Objekt.
2. Abschnittsüberschriften (h2): Nutzenaussagen, keine Etiketten („Bücher an einem Tag abschließen", nicht „Funktionen").
3. Fließtext: kurze Absätze, unter ~80 Zeichen pro Zeile (max-w-prose oder max-w-xl).

Schreibe spezifische, einfache Texte in der Sprache der App. Kein Lorem Ipsum, kein „Revolutionieren Sie Ihren Workflow", kein „Funktion 1". Siehe references/copy-formulas.md.

5. Layout und visueller Rhythmus

• Verwende semantische Tokens (bg-background, bg-secondary, text-muted-foreground), niemals rohe Farbklassen. Wechsle den Section tone="muted"-Wert, um Blöcke zu trennen, anstatt überall Rahmen und Schatten hinzuzufügen.
• Variiere die Abschnittsformen: ein Raster, dann eine geteilte Bild/Text-Komposition, dann ein breites Zitat. Vermeide eine Seite, die nur aus gestapelten, identischen Kartenrastern besteht.
• Ein auffälliges Element pro Seite (das Hero-Visual oder eine Schriftbehandlung). Den Rest ruhig halten.
• Umfasse Inhaltsgruppen mit <Reveal> und gestaffelter Verzögerung delay={index * 80}; BentoGrid, Testimonials und PricingTable zeigen sich bereits selbst an.
• Mobile First: Einzelspalte unter md, CTA-Buttons auf Smartphones volle Breite (w-full sm:w-auto), Touch-Ziele mindestens 44px.

6. Konversionsdetails

• Wiederhole den primären CTA nach den Funktionen oder den Preisen und im finalen CtaBand.
• Anker-Navigation: Gib Abschnitten ids (<Section id="pricing">) und verlinke auf #pricing; füge scroll-mt-20 hinzu, damit der sticky-Header die Überschriften nicht überdeckt.
• Formulare auf der Seite: Frage nach dem Minimum (E-Mail oder Name + Telefon). Zeige Inline-Validierung und einen klaren Erfolgszustand (siehe das forms-validation-Skill).
• Preise: Zeige die Währung und den Abrechnungszeitraum, hebe einen Plan hervor und gib an, was nach dem Klicken passiert (Testlaufzeit, Kündigung).
• Barrierefreiheit: sichtbarer Fokus, Alternativtext bei aussagekräftigen Bildern, Kontrast 4,5:1, Buttons, die sagen, was sie tun.

7. Erledigt-Checkliste

• Ein h1, im Hero; Abschnittsüberschriften sind h2 in der richtigen Reihenfolge.
• Primärer CTA above the fold auf Mobilgeräten und Desktops, zeigt auf ein echtes Ziel.
• Jede Behauptung, Zahl, jedes Logo und jedes Zitat ist echt oder der Abschnitt wurde entfernt.
• Hero-Bild hat width/height und wird nicht lazy geladen; andere Bilder werden lazy geladen.
• Seitentitel und Meta-Beschreibung gesetzt (siehe das seo-metadata-Skill).
• Bei 375px, 768px und 1280px Breite mit einem Screenshot überprüft.
• audit_landing_sections ausgeführt und Fehler behoben.

Skript

audit_landing_sections liest die Seitendatei und die lokalen Komponenten, die sie importiert. Argumente (alle optional): { "file": "src/pages/Index.tsx" }. Ohne file versucht es src/pages/Index.tsx, app/page.tsx, src/app/page.tsx, pages/index.tsx und src/pages/index.tsx. Es gibt checks (pass, warn oder fail), erkannte sections und placeholders zurück. Es ist heuristisch: Bestätige Fehler durch Lesen des Codes, bevor du etwas änderst.