Erstellen einer Landingpage in Claude Code

Eine funktionierende Einrichtung zum Erstellen, Ausliefern und Verbessern von Marketing-Seiten mit Claude Code. Fünf Dinge erledigen den Großteil der Arbeit: ein Repo, ein Host, ein Brand Kit, Leistung und Trichterdaten. Wenn diese richtig sind, ist alles andere nur Iteration.

Zwei Möglichkeiten, die Seite vor der Auslieferung zu sehen (Abschnitt 4): ein lokaler Dev-Server für Sie und Claude, und Claude Design für alle Nicht-Techniker. Wenn Sie Design verwenden, lesen Sie zuerst die harte Regel in Abschnitt 4 – dort gibt es kein Rückgängig.

Der rote Faden: Der Job endet nicht mit der Bereitstellung. Eine Seite, die live und ungetrackt ist, ist eine Seite, die Sie nicht verbessern können.

Reihenfolge der Operationen

Führen Sie diese der Reihe nach aus. Jede macht die nächste günstiger.

Repo zuerst – vor jeglichem Code. Versionskontrolle ist der Rückgängig-Button für alles andere.
Host + Deploy-Pipeline als Zweites – während die Seite trivial ist und ein kaputter Deploy nichts kostet.
Brand Kit als Drittes – bevor ein Wort Copy geschrieben wird, damit der erste Entwurf bereits der Marke entspricht.
Baue die Seite – zuerst visuell/statisch, dann Interaktivität, zuletzt Tracking.
Am ersten Tag mit minimalem Tracking ausliefern – dann Geschwindigkeit und Copy anhand echter Daten optimieren.

1. Ein Repository verwenden (GitHub oder Äquivalent)

Wenn Sie bereits Claude Code verwenden, ist das offensichtlich. Wenn Sie nur hereinschnuppern, ist dies das Aufwärmen: Ein Repository gibt Ihnen Versionskontrolle, ein Cloud-Backup und – am wichtigsten – eine Deployment-Strategie.

main ist die Produktion und nichts landet dort außer durch einen Pull-Request, den Sie mergen. Setzen Sie diese Regel explizit in CLAUDE.md – siehe starters/CLAUDE.md.

Der Kreislauf

Dies ist der gesamte Zyklus. Führen Sie ihn für jede noch so kleine Arbeit aus.

Einigt euch auf eine Versionsnummer. Claude schlägt eine vor, Sie stimmen zu – oder Sie sagen einfach, welche Sie möchten. In beiden Fällen steht die Nummer bevor die Arbeit beginnt fest, und die Entscheidung liegt bei Ihnen, nicht bei Claude.
Claude erstellt den Branch – git checkout -b v1.03.
Sie erledigen die Arbeit im Branch. Commits landen dort und nirgendwo sonst.
Claude pusht den Branch zu GitHub.
Claude erstellt den Pull-Request.
Sie prüfen und genehmigen ihn in GitHub und mergen ihn. Dies ist der Deploy. Es ist der einzige Moment, in dem sich die Produktion ändert, und es ist immer eine menschliche Entscheidung.
git checkout main dann git pull. Überspringen Sie das nicht. Ihr lokales main ist jetzt genau einen Merge zurück, und einen neuen Branch von einem veralteten main zu starten, ist der Weg zu Divergenz, Phantom-Konflikten und einem git pull, das sich weigert, einen Fast-Forward durchzuführen.
Wiederholen ab Schritt 1 mit der nächsten Versionsnummer.

Claude schlägt vor, Sie entscheiden, Claude führt aus. Versionsnummern, Merges und Deploys liegen bei Ihnen; Branchen, Pushes und das Erstellen des PRs liegen bei Claude. Wenn ein Aufruf mehrdeutig ist, fragt Claude nach.

Versionsbezeichnung, die funktioniert: v1.0x für Patches (Copy, Konfiguration, kleine Korrekturen), v1.x für kleinere Arbeiten (eine neue Seite, ein neues Feature), v2.x für ein Redesign.

Zwei Prüfpunkte, die sich lohnen:

Überprüfen Sie den gesamten Branch-Diff vor dem Mergen, nicht nur jeden Commit. Einzeln gute Commits können sich zu einem echten Bug verbinden. Ein vollständiger "alles seit dem Branch-Punkt lesen"-Durchlauf – idealerweise von einem zweiten Prüfer oder einem frischen Agenten – fängt, was eine aufgabenweise Überprüfung strukturell nicht kann.
Führen Sie vor jedem Deploy, der Benutzerdaten sammelt, eine Sicherheitsüberprüfung durch. Ein Prüfdurchlauf auf einem Formular-Branch hat eine echte Schwachstelle aufgedeckt, bei der ein roher Object-Spread es einem Besucher ermöglichte, Werte für serververwaltete Felder zu übermitteln. Behandeln Sie es als ein Tor, nicht als eine Nettigkeit.

2. Hosten Sie es irgendwo mit einer echten Deploy-Pipeline

AWS Amplify funktioniert gut: ein kostenloser Tarif, der eine Landingpage mit niedrigem Traffic abdeckt, und eine kleine Rechnung darüber hinaus. Überprüfen Sie die aktuellen Bedingungen – AWS hat seinen kostenlosen Tarif 2025 umstrukturiert. Netlify, Vercel und Cloudflare Pages bieten die gleiche Struktur.

Der eigentliche Gewinn ist der Deploy-Pfad: Einen PR mergen, die Seite wird neu gebaut und live geschaltet.

Die Verbindung des Repos mit dem Host ist der Schritt, an dem die Leute hängen bleiben, und es ist ein Klickpfad, keine Konfigurationsdatei: Erstellen Sie in der Host-Konsole eine neue Web-App → autorisieren Sie sie gegen Ihr GitHub-Konto → wählen Sie das Repo und den main-Branch → es erkennt Ihre Build-Spezifikation → der erste Deploy läuft. Von da an wird bei jedem Push auf diesen Branch neu gebaut. Tun Sie dies, während die Seite eine einzelne "Hallo"-Seite ist, damit eine kaputte Pipeline Sie nichts kostet, um sie zu debuggen.

Richten Sie es am ersten Tag ein, solange es günstig ist:

Auto-Deploy von main.
Eine benutzerdefinierte Domain mit HTTPS.
Eine Abrechnungswarnung. Sie haben gerade eine Karte einem Cloud-Konto hinterlegt. Setzen Sie einen Budget-Alarm auf einen Betrag, der Sie überraschen würde – dauert zwei Minuten und verwandelt eine unwahrscheinliche böse Überraschung in eine E-Mail.
Sicherheitsheader – statische Hosts liefern standardmäßig keine aus.
Langzeit-Caching Cache-Control auf gehashten Build-Assets. Einfach, dauerhaft, und wird sonst für immer aufgeschoben, weil es nie etwas blockiert.

Domain und DNS, wo die Fallen vorhersehbar sind:

Eine Bare-Domain kann keinen CNAME verwenden – www.example.com kann, example.com nicht. Sie benötigen den ALIAS/ANAME-Eintrag Ihres DNS-Anbieters oder die eigene Apex-Option des Hosts. Entscheiden Sie frühzeitig, ob Ihre kanonische URL das www hat, und leiten Sie die andere darauf weiter.
Das HTTPS-Zertifikat benötigt einen DNS-Eintrag zur Validierung und wird nicht ausgestellt, bis dieser Eintrag aufgelöst wird. Geben Sie jeder DNS-Änderung einige Stunden, bevor Sie entscheiden, dass sie falsch ist – Ausbreitungsverzögerung sieht genauso aus wie ein Fehler.

Deploy-Fallen, die echte Zeit kosten:

Wissen Sie genau, welche Teile automatisch deployen und welche nicht. Wenn irgendein Teil Ihres Stacks (eine serverlose Funktion, ein Backend, ein Worker) durch einen separaten manuellen Befehl deployt, schreiben Sie das in CLAUDE.md in Großbuchstaben. Der klassische stille Fehler ist das Mergen eines Branches, bei dem die sichtbare Seite aktualisiert wird, das Backend nicht, und alles sieht gut aus.
Auto-Deploy entfernt Ihren letzten Kontrollpunkt. Bei Merge-to-Deploy ist die PR-Überprüfung das Tor. Die Verifizierung muss vor dem Merge erfolgen, nicht danach.
npm ci auf dem Build-Host ist strenger als Ihr lokales npm install. Eine Lockfile, die subtil nicht mit package.json synchron ist, installiert lokal auf einem neueren npm einwandfrei und schlägt beim Build auf dem älteren Host fehl. Build schlägt auf dem Host fehl, aber nicht lokal? Verdächtigen Sie zuerst die Lockfile.
Pinnen Sie Ihre Runtime in der Build-Spezifikation, nicht nur in einer Versionsdatei. Einem .nvmrc allein wird nicht zuverlässig Folge geleistet – rufen Sie den Versionsmanager auch in den Build-Befehlen auf.
Jede neue Umgebungsvariable muss in der Host-Konsole hinzugefügt werden, getrennt vom Code, der sie liest. Dies ist eine überraschend häufige Antwort auf "warum ist es kaputt?".
Content-Security-Policy ist der Header, der Sie beißen wird. Jeder Drittanbieter-Ursprung, mit dem Ihre Seite tatsächlich kommuniziert – Analytics, Tag-Manager, Pixel, Schriftarten, Formular-Endpunkte – muss in der richtigen Direktive auf die Whitelist gesetzt werden, sonst wird er in der Produktion stillschweigend blockiert, während er lokal einwandfrei funktioniert. Symptom: "Tracking funktioniert lokal, feuert live nichts." Überprüfen Sie die Browser-Konsole auf CSP-Verstöße, bevor Sie etwas anderes debuggen.
Verifizieren Sie anhand des bereitgestellten Artefakts, nicht der Quelldatei. Bestätigen Sie eine Korrektur durch Überprüfen der tatsächlichen Produktionsantwort (curl -I, Browser-Dev-Tools), nicht durch Lesen der Konfiguration, die sie produzieren sollte. Gleiches für "wurde meine Änderung wirklich bereitgestellt" – überprüfen Sie die Build-ID / den Zeitstempel, nicht nur, dass der Merge stattgefunden hat.

Wie das Formular tatsächlich absendet

Statisches Hosting hat kein Backend. Ein einfaches <form> auf einer statischen Seite tut nichts Nützliches – das überrascht Leute am ersten Tag, und es ist der ganze Sinn der Seite. Drei realistische Optionen:

Option	Gut, wenn	Achten Sie auf
Ein gehosteter Formular-Dienst	Sie möchten, dass es heute Nachmittag funktioniert	Monatliche Kosten pro Volumen; deren Branding; Ihre Daten leben bei ihnen
Eine serverlose Funktion (Lambda, Netlify/Cloudflare Functions)	Sie möchten Kontrolle und nahezu keine Kosten	Sie haben jetzt Validation, Spam und CORS zu verantworten
Das eingebettete Formular oder der Webhook Ihres CRMs	Der Lead muss sowieso im CRM landen	Einbettungsgewicht und Styling-Einschränkungen; oft langsam beim Laden

Welche Sie auch wählen:

CORS wird Ihr erster Fehler sein. Ein serverloser Endpunkt auf einem anderen Ursprung als Ihre Seite muss diesen Ursprung explizit auf die Whitelist setzen, sonst blockiert der Browser die Anfrage, bevor sie jemals gesendet wird. Fügen Sie auch localhost zur Whitelist hinzu, sonst können Sie nicht lokal testen.
Fügen Sie ein Honeypot-Feld hinzu (ein verstecktes Eingabefeld, das Menschen nie ausfüllen und Bots schon) und lehnen Sie alles ab, was es ausfüllt. Der günstigste existierende Spam-Filter.
Streuen Sie niemals einen rohen Request-Body direkt in Ihren Datenbank-Schreibvorgang. So kann ein Besucher Felder setzen, die Sie serverseitig kontrollieren wollten. Wählen Sie die gewünschten Felder explizit aus.
Halten Sie den Endpunkt warm, wenn Sie können. Eine serverlose Funktion, die kalt startet, lässt den wichtigsten Moment auf der Seite – das Absenden – kaputt erscheinen.

3. Geben Sie Claude ein Brand Kit – und zwingen Sie es zum Laden

Dies ist das Element mit der höchsten Hebelwirkung in der Liste. Mindestens enthält das Kit:

Ihr Angebot · Ihren Zielmarkt / Ihr Kundenprofil · Ihre Messaging-Strategie · Ihre Farben · Ihre Schriftarten · Ihr Logo

Legen Sie es in einem Ordner ab (brand/). Vorlage: starters/brand-kit/brand.md.

Dann zwingen Sie es, automatisch zu laden. Eine Anweisung in CLAUDE.md, die sagt "lies das Brand Kit", ist beratend – sie wird inkonsistent befolgt. Ein SessionStart-Hook, der die Dateien mit cat in den Kontext lädt, ist nicht optional und wird nicht übersprungen. Diese eine Änderung ist der Unterschied zwischen "manchmal markenkonform" und "standardmäßig markenkonform." Siehe starters/settings.json.

Laden Sie beim Sitzungsstart: das Brand Kit, ein kurzes Architektur-Dokument (wie die Seite gebaut, gehostet und deployed wird), und das aktuellste Sitzungsprotokoll.

Strukturieren Sie es gut:

Teilen Sie "wie die Marke aussieht" von "wie die Marke spricht". Halten Sie die immer aktive Datei schlank – Palette, Schriftarten, Logos, Angebot, Zielgruppe. Verweisen Sie auf tiefergehendes Voice/Messaging-Material als "lies dies bei Copy-Arbeit." Alles, was automatisch geladen wird, kostet Kontext in jeder Sitzung, für immer.
Geben Sie Farben Rollen, nicht nur Hex-Codes ("primäre Akzentfarbe – verwendet für den Haupt-CTA"). Rollen verhindern, dass Claude eine Farbe erfindet, wenn es eine braucht. Geben Sie die Regel klar an: Keine Farbe außerhalb des Kits erscheint irgendwo. Andernfalls schleichen sich markenfremde Standardfarben aus Vorlagen und Generatoren stillschweigend ein.
Zwei oder drei Vorher/Nachher-Tonbeispiele lehren Stimme schneller als jede Liste von Adjektiven.
Wenn Ihr Messaging geschäftlich sensibel ist, gitignorieren Sie es, aber referenzieren Sie es dennoch aus CLAUDE.md – Sie erhalten konsistentes Laden, ohne Strategie oder Preise in ein Repository zu veröffentlichen.
Extern synchronisierte Markendokumente werden alt. Wenn ein Voice- oder Zielgruppen-Dokument von einem gemeinsamen Laufwerk kopiert wird, verifizieren Sie es vor einem Copy-Durchlauf gegen seine Quelle – Marketingentscheidungen werden in Gesprächen getroffen, die nie zurück ins Dokument gelangen.

Copy-Disziplin, die das Brand Kit durchsetzen sollte:

Versprechen Sie niemals "keine Anmeldung / keine E-Mail erforderlich" auf einer Seite, deren Aufgabe das Sammeln einer E-Mail ist. Es wirkt bis zum Erscheinen des Formulars als friktionsreduzierend, und dann ist es ein Widerspruch genau in dem Moment, in dem Sie Vertrauen brauchen. Beruhigen Sie stattdessen über Zeit, Kosten und Ergebnis – "2 Minuten · kostenlos · Ihr Ergebnis direkt per E-Mail."
Überprüfen Sie die beruhigenden Mikro-Texte neu, wann immer sich das Angebot ändert. Sie werden zwischen Seitenvarianten kopiert und überleben das Angebot, für das sie geschrieben wurden, gerade weil sie hilfreich klingen.
Das Versprechen der Anzeige, das Versprechen der Seite und die tatsächliche Aufforderung des Formulars müssen alle übereinstimmen. Eine Diskrepanz zeigt sich als Abbruch an dem Schritt, an dem die Wahrheit ankommt, nicht an dem Schritt, an dem die Diskrepanz eingeführt wurde. Wenn ein Schritt undicht ist, vermuten Sie den Schritt davor.

4. Sehen Sie es, bevor Sie es ausliefern

Zwei Möglichkeiten, eine Seite anzusehen, ohne sie zu deployen. Verwenden Sie beide – sie sind für verschiedene Personen.

Lokaler Dev-Server

Für Sie und Claude, während des Builds. Claude kann den Dev-Server starten, einen echten Browser steuern, das Ergebnis screenshoten und die Konsolen- und Netzwerkprotokolle lesen – so wird "rendert dies korrekt" durch Hinsehen beantwortet, nicht durch Code-Inspektion.

Führen Sie niemals zwei Dev-Server für dasselbe Projekt gleichzeitig aus. Prüfen Sie zuerst auf einen vorhandenen Prozess und beenden Sie ihn, bevor Sie einen anderen starten – besonders wenn parallele Agenten jeweils einen hochfahren könnten.
Begrenzen Sie automatische Wiederholungsschleifen auf ~3 Versuche. Eine offene "lade immer wieder neu und versuche verschiedene Timings, bis es funktioniert"-Schleife, die einen Dev-Server plus Browser-Automatisierung umschließt, ist ein echtes Ressourcenerschöpfungsrisiko, nicht nur ein Ärgernis – sie hat bereits einen Computer komplett zum Absturz gebracht.
Überprüfen Sie die Bereinigung, anstatt ihr zu vertrauen. "Ich habe den Server gestoppt und die Tabs geschlossen" ist eine unbestätigte Behauptung wie jede andere – überprüfen Sie die Prozessliste.
Erwarten Sie, dass sich lokal und Produktion designbedingt unterscheiden. Alles, was hinter einer echten Analytics-ID oder einem Live-API-Endpunkt geschaltet ist, ist typischerweise lokal eine Null-Operation. Das ist erwartetes Verhalten, kein Fehler – dokumentieren Sie es, damit es nicht alle paar Wochen neu diagnostiziert wird.
Halten Sie Ihre End-to-End-Tests standardmäßig auf localhost gerichtet, wobei das Ausrichten auf die tatsächliche bereitgestellte URL ein bewusster, separater Akt ist – sonst führt ein routinemäßiger Testlauf eine echte Übermittlung gegen die Produktion durch.

Claude Design (claude.ai/design)

Für alle anderen. Claude kann eine Seite in ein Claude Design-Projekt pushen und Ihnen so eine teilbare URL geben, bei der ein Kunde, ein Designer oder ein nicht-technischer Partner Copy und Layout visuell im Browser ohne lokale Einrichtung bearbeiten kann. Hervorragend für die Freigabe, bevor eine Seite in die echte Site eingebunden wird.

Die eine harte Regel: Niemals blind in Design schreiben

Bevor Claude etwas in ein Claude Design-Projekt schreibt, muss Claude die aktuelle Remote-Version abrufen, einen Diff durchführen und mit Ihnen Rücksprache halten, bevor er überschreibt. Jedes Mal.

Es gibt keine Versionshistorie, kein Rückgängig und keinen Papierkorb auf der Design-Seite – eine Canvas-Datei ist zerbrechlicher als eine ungetrackte lokale Datei. Ein blindes Überschreiben der Bearbeitungen eines Mitarbeiters ist dauerhaft unwiederbringlich, und es hat bereits einen ganzen Abend handgeschriebener Copy gekostet.

Erstellen Sie die Seite als in sich geschlossenes statisches HTML/CSS/JS. Die eigentliche Site verwendet wahrscheinlich ein Framework und Build-Tools; eine Design-Vorschau sollte nicht. Claude kann eine einzelne HTML-Datei mit eingebetteten Stilen und Skripten erstellen, die dieselbe Struktur, denselben Inhalt und dieselbe Responsivität hat – sie einfach genug macht, um in einem Canvas geöffnet zu werden, ohne dass der Build den Kontext überlastet.
Entkoppeln Sie echte Daten von Layout-Änderungen. Wenn die Seite einen dynamischen Feed oder eine API-Abfrage hat, ersetzen Sie ihn in der Design-Vorschau durch statische Beispieldaten – JSON-Platzhalter, die dieselbe Struktur widerspiegeln. Ein Kunde, der eine Design-Freigabe bearbeitet, sollte nicht durch leerzustellende Fehlerzustände von Live-Endpunkten navigieren müssen, und er sollte auch keine echten Daten sehen können, die Sie aus Versehen exponiert haben.
Entfernen Sie interaktive Elemente, die sich in einer Canvas-Umgebung nicht richtig verhalten – Transitions-Interpolation, Hover-States, die das Layout beeinflussen, animierte Einstiege. Was im Browser subtil funktioniert, liest sich im Kontext des Canvas-Fensters wie ein Fehler, und diese Wahrnehmung überträgt sich direkt auf die Rückmeldung.

Wann Sie den lokalen Dev-Server verwenden

Während Sie oder Claude Code aktiv Code auf der Seite schreiben – Sie müssen Seiteneffekte sehen, die Browser-API nutzen (Lokalisierung, Speicher, Service Worker) oder eine Interaktion durchklicken, die mehr als eine statische Ansicht erfordert.

Wenn Sie nur das Layout der Seite oder die Inhaltsstruktur überprüfen, und insbesondere wenn diese Prüfung für jemand anderen ist, verwenden Sie Claude Design. Es ist schneller, erfordert keine laufende Maschine und erzeugt einen teilbaren Link, keine Erklärung.

Die Checkliste vor der Auslieferung

Bevor Sie den Merge-Knopf drücken – unabhängig davon, wer die Seite gebaut hat:

Lädt die Seite? (Wenn nicht, die Build-Protokolle prüfen – der häufigste Grund ist ein importierter Fehler, der den gesamten Build zum Absturz bringt, und das einzige Symptom ist ein leeres Dokument.)
Sind alle externen Skripte, Schriftarten und Analytics-Pixel geladen? (Browser-Netzwerk-Tab – filtern Sie nach 404s und 500ern. Ein fehlgeschlagener Analytics-Aufruf für eine externe Ressource wird auf der Seite als nichts angezeigt, also überprüfen Sie es.)
Funktioniert das primäre Formular / CTA, und erzeugt es eine Ausgabe am erwarteten Endpunkt? (Senden Sie einen Test ab, überprüfen Sie die Serverprotokolle. Wenn dies lokal funktioniert, aber live nicht, überprüfen Sie zuerst CORS, dann CSP.)
Sieht die Seite auf Mobilgeräten korrekt aus? (Chrome-Geräte-Emulation, dazu einen echten Telefonbildschirm – mindestens drehen. Responsive Fehler treten bei Layouts mit festen Pixeln und bei interaktiven Elementen mit festen Größen auf, deren gedrehte Version keinen Platz hat.)
Gibt es sichtbare serverseitige Variablen oder Debug-Ausgaben im gerenderten HTML oder in den Antwortheadern? (Eine serverseitig gerenderte Anwendung, die jeder Produktionsantwort __NEXT_DATA__ oder einen äquivalenten Debug-Block hinzufügt, tut dies standardmäßig. Finden und entfernen Sie diese vor dem Merge.)
Gibt die Seite im Produktionskontext gültige HTTP-Caching-Header aus? (curl -I gegen die Live-URL – bestätigen Sie Cache-Control und Expires.)
Wurde die Build-ID / der Zeitstempel des Deployments aufgezeichnet, und haben Sie die Ausgabe des gleichen Builds überprüft? (Die Frage "ist mein Fix live?" muss mit einem numerischen Vergleich beantwortet werden können, nicht mit "ich denke schon".)
Werden Analysedaten korrekt erfasst? (Live-Test mit einem Browser-Plugin oder einer dedizierten Testumgebung – nicht die lokale Umgebung, in der der Analytics-Aufruf typischerweise eine Null-Operation ist.)

5. Messen oder es ist nicht passiert

Eine Live-Seite ohne Tracking ist eine Seite, auf die Sie raten müssen. Und Raten ist das Gegenteil von Optimieren. Rahmen Sie als Trichter, der einen Besucher von der Anzeige zur Conversion führt: Ad Impressions → Landing Page Loads → Form Submissions → Conversion. Wenn Sie einen Schritt nicht messen, können Sie ihn nicht verbessern.

Der minimale Tracking-Stack

Ein Analytics-Dienst, ein Formular-Tracking und ein serverseitiges Ereignis für die Conversion-Ankunft. Das ist alles, was Sie brauchen, um den Trichter zu schließen. Ein Tag-Manager ist optional und kommt später, wenn sich die Anzahl der Tags lohnt, sie zentral zu verwalten.

Ein Analytics-Dienst (Google Analytics 4, Plausible, Fathom, PostHog). Sie benötigen Seitenaufrufe, Verweildauer auf der Seite und Trichterdurchlaufraten zwischen den Schritten.
Formular-Tracking, das jede Übermittlung erfasst, nicht nur die, die zu einer Conversion führen. Die Metrik, die Sie wirklich wollen, ist die Aufgabe-Rate (wie viele Besucher, die das Formular erreichen, füllen es aus und senden es ab).
Ein serverseitiges Conversion-Ereignis, sobald die Formulardaten den Server erreichen – unabhängig davon, ob die Conversion eine E-Mail-Anmeldung, ein Download oder eine Demo-Anfrage ist. Analytics-Skripte allein verpassen Conversions, weil Benutzer nach dem Absenden die Seite verlassen, bevor das Skript feuert.

Der Trichterrahmen gilt auch für Nicht-Formular-Seiten. Eine Landingpage, deren einzige Aufgabe das Erzeugen einer Anfrage ist, hat trotzdem einen Trichter: den Traffic zur Seite, die Verweildauer auf der Seite (als Proxy für Engagement) und die Absprungrate ohne Aktion. Jede Seite hat einen Zweck; messen Sie, ob sie ihn erfüllt.

Was zu messen ist

Aktivität vor der Seite und Aktivität auf der Seite. Die Aktivität vor der Seite sagt Ihnen, ob die richtigen Leute ankommen und ob sie tun, was Sie erwarten; die Aktivität auf der Seite sagt Ihnen, ob die Seite selbst ihre Arbeit macht.

Aktivität vor der Seite:

Traffic-Quelle (organische Suche, bezahlte Anzeige, soziales Netzwerk, Direkteingabe, Empfehlung) – verknüpft mit der Trichtermetrik, sodass Sie sehen können, welche Kanäle die höchste Conversion-Rate liefern, nicht nur die höchste Klickrate.
Absprungrate nach Quelle – eine hohe Absprungrate bei bezahlten Anzeigen deutet auf ein Fehlversprechen hin; eine hohe Absprungrate bei Direkteingabe deutet auf ein Markenbekanntheitsproblem hin; eine hohe Absprungrate bei organischer Suche deutet auf ein Content-Relevanzproblem hin.
Gerätetyp und Browser – der Trichter, der auf Mobilgeräten um 20 Prozentpunkte abfällt, ist ein Layout-Problem. Der Trichter, der auf Safari im privaten Modus abfällt, ist ein Cookie-Tracking-Problem. Unterscheiden Sie sie.

Aktivität auf der Seite:

Seitenaufrufe – eindeutig und wiederkehrend – misst die Reichweite, zeigt die Trennung zwischen erstmaligen und wiederkehrenden Besuchern. Konvertieren Wiederkehrer häufiger? Dann liegt es am Angebot, nicht an der Seite.
Verweildauer auf der Seite – eine hohe Verweildauer bedeutet in der Regel Engagement; eine niedrige Verweildauer bedeutet in der Regel mangelnde Relevanz. Aber lesen Sie dies immer im Kontext der Quelle: Eine bezahlte Anzeige, die jemanden anlockt, der 30 Sekunden bleibt, ist möglicherweise immer noch eine schlechte Quelle, selbst wenn die Verweildauer hoch ist, wenn die Conversion-Rate niedrig ist.
Scroll-Tiefe / Sichtbarkeit der Auszahlung (wie weit ein Besucher scrollt, bevor er geht) – misst, ob der Inhalt das Angebot rechtzeitig liefert. Ein scharfer Abfall bei 50 % Bildschirmhöhe bedeutet, dass der Inhalt über dem Falz nicht genug sagt.
Formular-Interaktionsrate (wie viele Besucher, die das Formular sehen, klicken hinein oder fokussieren ein Feld) – misst das Engagement jenseits des Scrollens. Dies ist die Metrik, die Sie optimieren, wenn die Verweildauer gut aussieht, aber die Absenderate niedrig ist: Das Problem ist das Formular selbst, nicht die Seite.

Das erste, was Sie optimieren: Der Schritt mit dem größten Verlust im Trichter. Wenn 80 % der Besucher von der Anzeige zur Seite kommen, aber nur 2 % das Formular ausfüllen, ist Ihr Problem das Formular (Copy-Überzeugungskraft, Feldanzahl, wahrgenommenes Risiko), nicht der Traffic. Die meisten Problemlösungen beginnen mit der Frage "verlieren wir sie am Anfang, in der Mitte oder am Ende?".

Conversion-Tracking mit Benutzerdaten (rechtlich)

Holen Sie vor dem Setzen von Tracking-Cookies eine Einwilligung ein, wenn Sie Besucher in einer Gerichtsbarkeit mit Cookie-Einwilligungsgesetzen bedienen – was für praktisch jede öffentliche Website der Fall ist. Das Fehlen einer Einwilligungslösung ist eine Compliance-Lücke, kein technisches Versäumnis, und der Zeitaufwand für die Implementierung ist geringer als der Zeitaufwand für die Behebung der Folgen.

Verwenden Sie einen Einwilligungs-Manager (CMP) wie Cookiebot, Osano oder OneTrust – ein Skript, das blockiert, bis der Benutzer zustimmt, und das die Zustimmung in einem Cookie speichert. Testen Sie es, indem Sie Ihre Seite im privaten Modus laden – es sollten vor der Zustimmung keine Cookies gesetzt werden.
Konfigurieren Sie Ihr Analytics-Tool, um die Einwilligung zu respektieren. Die meisten großen Tools haben jetzt eine Einwilligungs-Modus-API; aktivieren Sie sie und stellen Sie sicher, dass sie vor dem Tool-Code geladen wird. Ein nicht konfiguriertes Tool, das zuerst geladen wird, sammelt Daten, unabhängig davon, was der CMP tut.
Server-seitiges Tracking umgeht den Browser-Cookie-Schutz und unterliegt den gleichen Einwilligungsgesetzen wie clientseitiges Tracking – es ist nicht automatisch konform. Das Verschieben des Trackings auf den Server verschiebt nicht die rechtliche Verantwortung; es erfordert nur andere technische Kontrollen, um die Compliance durchzusetzen.
Führen Sie vor dem Start einen kurzen Datenschutz-Check durch: An welche Dienste senden Sie die Daten? Speichern sie die Daten auf Servern in Regionen, in die Sie sie nicht senden möchten? Verkaufen sie die Daten weiter? Jeder Dienst in der Kette ist ein Datenschutz-Risikopunkt, und die Haftung für eine Verletzung liegt immer bei demjenigen, der die Daten gesammelt hat.

Anhang: Startdateien

Der Ordner starters/ enthält Vorlagen zum Kopieren:

Datei	Zweck
`starters/CLAUDE.md`	`CLAUDE.md` mit der Merge-Regel, die einen Branching-Workflow erzwingt. Kopieren Sie diese in Ihr Stammverzeichnis.
`starters/settings.json`	VS Code `settings.json`, das den automatischen SessionStart-Hook konfiguriert, der das Brand Kit, das Architektur-Dokument und das letzte Sitzungsprotokoll lädt. Kopieren Sie diese in `.vscode/`.
`starters/brand-kit/brand.md`	Vollständige Brand-Kit-Vorlage mit Ihrem Angebot, Markt, Voice, Farben (mit Rollen), Schriftarten und Logo-Spezifikationen. Füllen Sie sie aus und legen Sie sie in `brand/brand.md` ab.

Anhang: Leistung

Eine Seite, die langsam lädt, ist eine Seite, die nicht konvertiert. Google schätzt, dass eine Verzögerung der Seitenladezeit um eine Sekunde die Conversion-Rate um 20 % senkt. Optimieren Sie nicht um der Optimierung willen; optimieren Sie, weil die Conversion-Rate die einzige Metrik ist, die zählt.

Das Erste, was zu tun ist: Messen Sie die aktuelle Leistung mit einem Tool wie Lighthouse, PageSpeed Insights oder WebPageTest. Wenn die Punktzahlen gut sind (90+ auf Mobilgeräten und Desktop), haben Sie ein Problem mit der Copy, nicht mit der Leistung.

Wenn die Leistung schlecht ist, optimieren Sie in dieser Reihenfolge:

Bilder – das häufigste und einflussreichste Problem. Verwenden Sie moderne Formate (WebP, AVIF), komprimieren Sie sie und laden Sie sie lazy. Ein einziges unkomprimiertes Hero-Bild kann die Ladezeit einer ansonsten schnellen Seite verdoppeln.
Schriftarten – der zweithäufigste und am meisten vernachlässigte Übeltäter. Verwenden Sie font-display: swap, damit Text sofort in einer Fallback-Schriftart gerendert wird, während die Webschriftart geladen wird. Erwägen Sie, Schriftarten auf moderne, leistbare Formate zu subsetten. Eine unoptimierte Schriftart fügt 200-400 ms unsichtbare Ladezeit zur First Paint hinzu.
JavaScript-Bundle-Größe – wenn Sie ein Framework verwenden, achten Sie auf Bundle-Gewicht. Entfernen Sie toten Code, teilen Sie Module auf und lazy-loaden Sie Komponenten.
Server-Antwortzeit – wenn die Seite serverseitig gerendert wird, bestätigen Sie, dass die Antwortzeit unter 200 ms liegt. Alles darüber hinaus deutet auf eine nicht optimierte Abfrage, einen nicht gecachten API-Aufruf oder einen ineffizienten Build hin.

Metriken, die für eine Landingpage zählen:

First Contentful Paint (FCP) – der erste Inhalt, der auf dem Bildschirm erscheint. Streben Sie unter 1,5 Sekunden auf Mobilgeräten an.
Largest Contentful Paint (LCP) – das größte sichtbare Element (normalerweise das Hero-Bild oder die Überschrift). Streben Sie unter 2,5 Sekunden an.
Cumulative Layout Shift (CLS) – wie stark das Layout während des Ladens springt. Streben Sie unter 0,1 an. Nichts zerstört das Vertrauen in eine Marke mehr als ein springender Button.
Interaction to Next Paint (INP) – wie schnell die Seite auf eine Benutzerinteraktion reagiert. Streben Sie unter 200 ms an. Wenn ein Formular-Klick einen Freeze verursacht, bricht der Benutzer ab.

Die eine wichtige Sache zur Leistung: Eine Seite, die langsam lädt, aber gutes Copy und ein klares Angebot hat, konvertiert immer noch besser als eine schnelle Seite mit schlechtem Copy. Optimieren Sie zuerst das Angebot; dann optimieren Sie die Geschwindigkeit.

Anhang: Verwendung mit Claude Code

Platzieren Sie diese Datei in einem Unterverzeichnis Ihres Projekts oder des Wissensspeichers von Claude, und referenzieren Sie sie mit einem @-Befehl oder einem Datei-Upload. Die Fähigkeit wird aktiviert, wenn Sie Phrasen wie "Erstelle mir eine Landingpage", "Richte ein Landingpage-Projekt ein", "Wie hoste und deploye ich diese Seite", "Gib Claude meine Marke", "Meine Landingpage konvertiert nicht", "Füge Tracking zu meiner Seite hinzu" oder wenn Sie die Geschwindigkeit und Trichterabbruchrate einer Live-Seite überprüfen, verwenden.

david-samurai/LandingPageSkill

Was ist LandingPageSkill?

In Ihrer bevorzugten KI fragen

Dokumentation