Landing Page mit WeWeb bauen: Tutorial für Anfänger

Was du bauen wirst

Am Ende dieses Leitfadens hast du eine vollständige Landing Page mit: - Hero-Abschnitt mit Headline, Unterzeile und CTA-Button - Social-Proof-Zeile (Logos oder Testimonial) - Feature-Abschnitt (3-Spalten-Grid) - Preis-Abschnitt - FAQ-Akkordeon - Lead-Erfassungsformular (verbunden mit Supabase oder einem Make-Webhook) - Veröffentlicht auf einer eigenen Domain mit HTTPS

Gesamt-Bauzeit: 4 bis 6 Stunden für den ersten Aufbau, 1 bis 2 Stunden, sobald du es schon einmal gemacht hast.

Dieser Leitfaden setzt voraus, dass du einen WeWeb-Account hast (der kostenlose Tarif reicht zum Mitmachen aus) und mit einem visuellen Builder grundsätzlich vertraut bist. Wenn du bereits Webflow oder Figma genutzt hast, wird dir WeWeb innerhalb einer Stunde vertraut vorkommen. Ist dies dein erster visueller Builder, plane einen zusätzlichen Tag für die Lernkurve ein. Die WeWeb-Dokumentation ist hervorragend, und der Community-Discord bietet aktiven Support.

Schritt 1: WeWeb-Workspace einrichten

Erstelle einen kostenlosen WeWeb-Account unter weweb.io. Erstelle einen neuen Workspace und eine neue App. Wähle "From scratch" für eine leere Leinwand.

WeWebs Interface: Links die Komponentenleiste, in der Mitte der Canvas, rechts das Styles-Panel. Oben die Seitennavigation und der Publish-Button.

Ein erstes Setup-Tipp: Gehe zu App Settings → Fonts und lade deine Marken-Schriftarten hoch. Für deutsche Unternehmenswebsites sind Inter, Source Sans Pro oder eine eigene Unternehmensschrift üblich. WeWeb unterstützt Google Fonts und benutzerdefinierte Font-Uploads gleichermaßen. Definiere deine Farbpalette unter App Settings → Brand Colors.

Setze außerdem die Seitenbreite: max-width 1280px, zentriert, mit 24px horizontalem Padding auf Mobile. Investiere hier 20 Minuten, richtig gesetzte Design-Tokens jetzt sparen dir später Stunden an Inkonsistenzen.

Design-Tokens sind das Fundament eines wartbaren WeWeb-Projekts. Jede Farbe, jede Abstandseinheit und jede Schriftgröße sollte auf ein Token verweisen statt auf einen fest codierten Wert. Will dein Kunde die Markenfarbe von Blau zu Grün ändern, aktualisiert bei einem Token-basierten System eine einzige Änderung jeden Button, Link und jede Hervorhebung im gesamten Projekt. Ohne Tokens änderst du Farben Element für Element, eine Aufgabe, die Stunden dauert und Inkonsistenzen mit sich bringt.

Schritt 2: Den Hero-Abschnitt aufbauen

Das Hero ist das erste, was Besucher sehen, und der wichtigste Abschnitt der ganzen Seite. Aufbau: 1. Container-Element (volle Breite, min-height: 600px) 2. Innerer Container (max-width: 1200px, zentriert mit Padding) 3. Text-Gruppe: H1-Headline, H2-Unterzeile, CTA-Button 4. Hero-Bild oder Produkt-Screenshot rechts (auf Desktop)

WeWebs Flex- und Grid-Komponenten machen dieses Layout ohne Pixel-Mathe möglich. Setze die H1 auf dein Ergebnis-Statement ("Budgets 2× schneller freigeben"), die Unterzeile auf die Zielgruppe und den Mechanismus ("Für Finanz-Teams, automatisierte Genehmigungs-Workflows").

Für die deutsche Zielgruppe: Verwende "Sie" oder "du" konsistent, "Sie" für B2B/Enterprise-Zielgruppen, "du" für Startup- und Tech-Zielgruppen.

Weitere WeWeb-Tipps für den Hero: Verwende ein Section-Element statt eines Containers, damit sich der Hintergrund über die volle Breite erstreckt. Setze die H1-Schriftgröße auf eine WeWeb-Breakpoint-Variable: 56px Desktop, 40px Tablet, 32px Mobile. Füge einen Farbverlauf oder eine dezente Rauschtextur zum Hintergrund hinzu, ein reines Schwarz-Weiß-Hero wirkt schnell flach.

Der Hero-Abschnitt braucht von allen Abschnitten am längsten, weil er die meiste Iteration erfordert. Rechne damit, die Headline 3 bis 5 Mal umzuschreiben, bevor sie sich richtig anfühlt. Teste sie mit echten Menschen, nicht nur mit deinem Team, bevor du dich auf das Design festlegst. Headline- und Unterzeilentext sind wichtiger als jedes visuelle Element im Hero. Eine starke Headline auf einem einfachen weißen Hintergrund schlägt jedes Mal eine schwache Headline auf einem wunderschön gestalteten dunklen Hero.

Schritt 3: Social Proof und Logo-Leiste

Direkt unter dem Hero: Eine Logo-Leiste mit 5-8 Kundenlogos (grauskaliert, einheitliche Höhe).

In WeWeb: Füge ein Flex-Container-Element mit justify-content: space-between hinzu. Lade Logos als SVG oder PNG ein. Setze filter: grayscale(100%) im Styles-Panel, das gibt der Leiste ein professionelles, neutrales Aussehen.

Wenn du noch keine Logos hast: Verwende ein Testimonial-Zitat von einem Beta-Nutzer. Platziere es in einer hellen Hintergrundbox mit Zitat-Text, Name, Foto (wenn vorhanden) und Unternehmensname. Selbst ein Zitat von einem deutschen LinkedIn-Kontakt, der dein Produkt getestet hat, konvertiert besser als kein Social Proof.

Schritt 4: Feature-Abschnitt

Ein 3- oder 4-spaltige Feature-Grid: 1. WeWeb Grid-Element (3 Spalten auf Desktop, 1 Spalte auf Mobile) 2. Für jedes Feature: Icon-Container, H3-Titel, Beschreibungstext 3. Icons: Verwende Lucide Icons (eingebaut in WeWeb) oder lade SVG-Icons hoch

Für jeden Feature-Punkt: Schreibe [Ergebnis] als H3-Titel und [Wie es das liefert] als Beschreibungstext. Vermeide generische Feature-Namen wie "Einfach zu bedienen", sei spezifisch: "Genehmigungsanfragen in unter 30 Sekunden erstellen".

Mobile-Optimierung: WeWeb macht das Grid auf Mobile automatisch zu einer einspaltigen Darstellung, wenn du Responsive-Breakpoints konfigurierst. Teste auf 375px, dass deine Icons und Texte korrekt ausgerichtet sind.

WeWeb-Kurzweg: Erstelle eine Feature-Card, style sie, dupliziere sie dann zweimal und aktualisiere den Inhalt. Baue nicht jede Card von Grund auf neu.

Beim Feature-Grid solltest du der Versuchung widerstehen, mehr als 4 Features zu zeigen. Jedes zusätzliche Feature verringert die Aufmerksamkeit für die einzelnen Punkte. Die besten Feature-Abschnitte zeigen 3 bis 4 sorgfältig ausgewählte Fähigkeiten, die die überzeugendsten Gründe für dein Produkt darstellen. Hast du 8 erwähnenswerte Features, gruppiere sie nach Thema (z.B. "Zusammenarbeiten", "Automatisieren", "Analysieren") und zeige 3 Gruppen statt 8 einzelner Punkte.

Schritt 5: Preis-Abschnitt

Ein dreispaltiges Preis-Layout ist der SaaS-Standard. Baue es mit CSS Grid: drei gleich große Spalten, die mittlere Spalte hervorgehoben (anderer Hintergrund, "Am beliebtesten"-Badge).

Jede Preis-Card braucht: - Plan-Name (H3) - Preis + Abrechnungszeitraum - 4 bis 6 Feature-Stichpunkte (nutze eine WeWeb-List-Komponente statt fest codierter Divs, das lässt sich leichter aktualisieren) - CTA-Button

WeWeb-Trick: Binde den Inhalt der Preis-Card an eine WeWeb-Variable (Array von Objekten). So kannst du Preise und Features über ein einziges Datenobjekt ändern, statt jede Card einzeln zu bearbeiten. Ändert sich dein Pricing, aktualisierst du ein Array, und alle drei Cards aktualisieren sich automatisch.

Preisseiten-Psychologie spielt hier eine Rolle: Der mittlere Plan sollte immer visuell hervorgehoben und als Standardempfehlung positioniert sein. Setze ihn mit einer anderen Hintergrundfarbe (etwas heller oder mit farbigem Rahmen), füge ein "Am beliebtesten"-Badge in deiner primären Akzentfarbe hinzu, und mache den CTA-Button des mittleren Plans solide gefüllt, während die anderen beiden Pläne Outline-Buttons verwenden. Diese visuelle Hierarchie lenkt die Mehrheit der Besucher zu dem Plan, den du bevorzugst.

Schritt 6: FAQ-Akkordeon

Ein Akkordeon ist eine einzelne WeWeb-Komponente mit einem Klick-Toggle. Baue es mit: - Einem Container für jeden FAQ-Punkt - H3 für die Frage (klickbar) - Einem Div für die Antwort (Sichtbarkeit gesteuert durch eine WeWeb-Variable)

WeWeb-Variablen-Ansatz: 1. Erstelle eine Variable: openFaqIndex (Typ: Number, Standard: -1) 2. Bei jedem Klick auf eine Frage: setze openFaqIndex = Index dieses Elements (oder -1, wenn es bereits geöffnet ist) 3. Zeige/verstecke jedes Antwort-Div: füge eine Bedingung "openFaqIndex === thisIndex" hinzu

Das erzeugt ein echtes Akkordeon, bei dem immer nur eine Antwort gleichzeitig geöffnet ist, ganz ohne eine Zeile JavaScript zu schreiben.

Für den SEO-Nutzen solltest du außerdem FAQPage-Schema im <head> der Seite hinzufügen, das mit dem Inhalt des FAQ-Akkordeons übereinstimmt. Google kann FAQ-Inhalte sowohl aus dem sichtbaren HTML als auch aus dem JSON-LD-Schema extrahieren, beides zusammen erhöht die Chance, dass deine FAQ als Rich Result in der Suche erscheint. Das Schema sollte immer aktualisiert werden, wenn du FAQ-Inhalte hinzufügst oder änderst. Bindest du dein FAQ-Akkordeon an eine Supabase-Tabelle, musst du das fest codierte JSON-LD-Schema entweder manuell aktualisieren oder ein Build-Time-Skript implementieren, das das Schema aus derselben Datenquelle generiert.

Schritt 7: Lead-Erfassungsformular

Füge oberhalb des Footers ein Formular hinzu. Halte es minimal: Name, geschäftliche E-Mail, CTA-Button ("Demo buchen" oder "Kostenlos testen").

Formular mit Supabase verbinden: 1. Füge in WeWeb eine Form-Komponente hinzu 2. Füge eine Action beim Absenden hinzu: "Insert row" → deine Supabase-Tabelle "leads" 3. Füge eine zweite Action hinzu: zeige eine Erfolgsmeldung (Sichtbarkeit eines Danke-Divs umschalten)

Alternative Verbindung mit Make: 1. Erstelle ein Make-Webhook-Szenario 2. Nutze in WeWeb die Aktion "HTTP Request" beim Absenden des Formulars → POST an deine Make-Webhook-URL 3. In Make: füge eine E-Mail-Benachrichtigung sowie das Anlegen eines Datensatzes in HubSpot, Notion oder Airtable hinzu

Füge immer ein Honeypot-Feld hinzu (ein verstecktes Eingabefeld, das echte Nutzer nie ausfüllen, Bots aber schon). Filtere jede Einsendung heraus, bei der das Honeypot-Feld nicht leer ist.

Die Anzahl der Formularfelder ist eine der wichtigsten Conversion-Variablen. Jedes zusätzliche Pflichtfeld senkt die Formular-Abschlussrate um etwa 10 bis 15 %. Frage bei einer ersten Landing Page nur nach dem Minimum: typischerweise Vorname und geschäftliche E-Mail. Zusätzliche Qualifizierungsfelder (Unternehmensgröße, Anwendungsfall, Telefonnummer) solltest du in die Folge-Sequenz oder die Demo-Buchungsbestätigung verschieben. Das Ziel des Landing-Page-Formulars ist es, die E-Mail-Adresse zu bekommen, alles andere kann später erfasst werden.

WeWeb-CMS für Landing Pages

Mit der CMS-Funktion von WeWeb kannst du Landing-Page-Inhalte verwalten, ohne den WeWeb-Editor erneut zu öffnen. Das ist besonders wertvoll für Teams, bei denen eine nicht-technische Marketingperson Texte aktualisieren, Testimonials austauschen oder Preise ändern muss, ohne auf die Zeit eines Entwicklers zu warten.

Richte CMS-Collections für die wiederkehrenden Content-Typen deiner Landing Page ein: Testimonials, Feature-Cards, FAQ-Fragen und Preisstufen. Jede Collection ist ein strukturierter Datentyp mit Feldern, die den Inhalten auf der Seite entsprechen. Binde deine WeWeb-Komponenten an die CMS-Collection-Daten statt an fest codierte Werte. Jetzt kann sich ein Teammitglied im CMS-Editor von WeWeb anmelden, ein Testimonial oder eine FAQ-Frage aktualisieren und die Seite neu veröffentlichen, ohne eine einzige Komponente anzufassen.

Für Enterprise-Kunden kann das CMS von WeWeb statt auf das interne CMS auf eine externe Supabase-Tabelle verweisen. Das bedeutet, der Inhalt gehört dem Kunden in seiner eigenen Datenbank, ist über eine in WeWeb gebaute Custom-Admin-UI editierbar und ist nicht von der WeWeb-Plattform für das Content-Management abhängig. Diese Architektur bietet maximale Flexibilität und vermeidet Plattform-Lock-in für Inhalte.

A/B-Test-Einrichtung in WeWeb

WeWeb hat kein natives A/B-Testing, aber es lässt sich unkompliziert mit URL-Parametern und WeWeb-Variablen umsetzen. Der Ansatz: Zeige Variante A Besuchern ohne Parameter (die Kontrollgruppe), zeige Variante B Besuchern mit ?variant=b in der URL. Deine Ad-Kampagnen schicken 50 % des Traffics auf jede URL-Variante.

Umsetzung: Erstelle eine WeWeb-Variable namens pageVariant mit Standardwert 'a'. Füge eine On-Page-Load-Aktion hinzu, die den URL-Parameter ausliest und pageVariant auf 'a' oder 'b' setzt. Füge dann bedingte Anzeige für die Elemente hinzu, die du testen willst: zeige heroHeadlineA, wenn pageVariant = 'a', zeige heroHeadlineB, wenn pageVariant = 'b'. Tracke Conversions je Variante mit einem PostHog-Event, das die Variante als Property enthält.

Für anspruchsvolleres Testing nutze PostHogs Feature Flags, um die Variante konsistent pro Nutzersitzung statt per URL-Parameter zuzuweisen. PostHogs WeWeb-Plugin stellt diese Verbindung ohne Code her. Der Vorteil der sitzungsbasierten Zuweisung: Ein Besucher, der ohne URL-Parameter zurückkommt, sieht dieselbe Variante, was den verzerrenden Effekt verhindert, dass ein Besucher beide Varianten sieht.

Formularverarbeitung und Lead-Erfassung

Lead-Erfassung ist der Kernzweck der meisten Landing Pages, und der Weg von der Formularabgabe bis zu deinem CRM oder Vertriebsprozess sollte vor dem Launch end-to-end getestet werden. Viele Teams veröffentlichen eine Landing Page und entdecken erst 3 Wochen später, dass Formulareinsendungen stillschweigend fehlgeschlagen sind, wegen einer falsch konfigurierten Supabase-RLS-Richtlinie oder eines pausierten Make-Szenarios.

Baue ein Test-Einsendungs-Protokoll auf: Sende nach jeder Formular-Änderung einen Test-Lead mit einer erkennbaren E-Mail (test+landingpage@deinefirma.de) und überprüfe, dass er in deiner Supabase-Leads-Tabelle erscheint, die Make-Benachrichtigungs-E-Mail auslöst und einen Kontaktdatensatz in deinem CRM anlegt. Das dauert 5 Minuten und erkennt Integrationsfehler sofort.

Für Landing Pages mit hohem Volumen (100+ Einsendungen pro Tag) füge Rate-Limiting zu deinem Formular-Einsende-Endpunkt hinzu. In Xano ist das eine einfache Middleware, die die Anzahl der Einsendungen von einer bestimmten IP-Adresse in der letzten Stunde prüft. Ohne Rate-Limiting kann eine einzige Bot-Kampagne deine Leads-Tabelle mit tausenden Spam-Datensätzen füllen, die deine Conversion-Daten verfälschen und manuelle Bereinigung erfordern. Kombiniere Rate-Limiting mit dem Honeypot-Feld, und du eliminierst über 95 % der Spam-Formulareinsendungen.

Tracking- und Analytics-Integration

Eine Landing Page ohne Analytics ist eine Vermutung. Analytics macht aus einer Landing Page aus einem einmaligen Build ein fortlaufendes Optimierungsprojekt. Die zwei Tools, die wir für WeWeb-Landing-Pages empfehlen, sind PostHog (für Produkt-Analytics und Session-Recording) und Plausible (für datenschutzfreundliche Traffic-Analytics), sie erfüllen unterschiedliche Zwecke und ergänzen sich gut.

PostHog-Einrichtung in WeWeb: Füge das PostHog-JavaScript-Snippet zum Custom-Head-Code deines Projekts hinzu. Füge dann Custom Events in den WeWeb-Actions hinzu: löse ein posthog.capture('cta_clicked', {location: 'hero'})-Event aus, wenn der Hero-CTA geklickt wird, ein posthog.capture('form_submitted')-Event bei der Formularabgabe, und ein posthog.capture('pricing_viewed')-Event, wenn der Preis-Abschnitt in den sichtbaren Bereich scrollt (nutze WeWebs Intersection-Observer-Bindung). Diese drei Events liefern dir die Conversion-Funnel-Daten, um zu erkennen, wo Besucher abspringen.

Plausible liefert Traffic-Daten ohne die Datenschutz-Implikationen von Google Analytics und erfordert unter der DSGVO kein Cookie-Consent-Banner, ein deutlicher UX-Gewinn für europäische Landing Pages. Füge das Plausible-Skript zu deinem Head-Code hinzu und konfiguriere Custom Goals für CTA-Klicks und Formularabgaben. Das Plausible-Dashboard zeigt dir übersichtliche Traffic-Quellen, Top-Seiten und Goal-Conversion-Raten auf einen Blick. Teile den Dashboard-Link mit deinem Kunden, damit er den Traffic überwachen kann, ohne Zugriff auf dein komplettes Analytics-Setup zu benötigen.

Schritt 8: Auf deiner Domain veröffentlichen

Gehe in WeWeb zu Hosting → Custom Domain. 1. Füge deine Domain hinzu (z.B. app.deineseite.de oder deineseite.de) 2. WeWeb gibt dir einen CNAME-Eintrag, den du bei deinem DNS-Provider hinzufügst 3. Füge den CNAME hinzu und warte auf die DNS-Propagation (typischerweise 5 bis 30 Minuten) 4. WeWeb provisioniert automatisch ein SSL-Zertifikat über Let's Encrypt

Vor der Veröffentlichung: - Prüfe jeden Abschnitt bei 375px, 768px und 1280px - Führe ein Lighthouse-Audit durch (Chrome DevTools → Lighthouse-Tab), Ziel: 90+ Performance - Prüfe Seitentitel und Meta-Description in den WeWeb-SEO-Einstellungen - Füge dein Google-Analytics- oder Plausible-Snippet unter Project Settings → Custom Code → <head> hinzu

Veröffentlichen, und du bist live. Gesamtzeit: ein Tag.

Nach der Veröffentlichung melde deine URL über das URL-Inspection-Tool bei Google Search Console an und fordere eine Indexierung an. Das garantiert keine schnellere Indexierung, signalisiert Google aber, dass die Seite existiert und crawl-bereit ist. Für eine Landing Page mit bezahltem Traffic solltest du außerdem im Netzwerk-Tab des Browsers prüfen, dass das Conversion-Tracking-Pixel deiner Ad-Plattform korrekt auslöst, fehlerhaftes Conversion-Tracking ist eine häufige Ursache für falsch zugeordnete Kampagnendaten, die zu schlechten Ad-Spend-Entscheidungen führen.

Bonus: Abschließender CTA-Abschnitt

Wiederhole am Ende der Seite deinen Haupt-CTA in einem eigenen Abschnitt. Format: - H2-Headline (Zusammenfassung des Wertversprechens) - Optionaler Subtext - Primärer CTA-Button - Vertrauens-Mikrokopie: "Keine Kreditkarte erforderlich · DSGVO-konform · Kostenlos kündbar"

App Studio hat über 50 Apps und Landing Pages in Produktion geliefert. Wenn du schneller vorankommen möchtest, hilft dir unser Team. Mehr dazu bei unserem WeWeb-Entwickler-Angebot.