Wat je gaat bouwen
Aan het einde van deze gids heb je een complete landingspagina met: - Hero-sectie met kop, subkop en CTA-knop - Sociale-proof-rij (logo's of testimonial) - Functiessectie (raster met 3 kolommen) - Prijzensectie - FAQ-accordion - Contactformulier (gekoppeld aan Supabase of een Make-webhook) - Gepubliceerd op een eigen domein met HTTPS
Totale bouwtijd: 4 tot 6 uur voor een eerste build, 1 tot 2 uur zodra je het al eens hebt gedaan.
Deze gids gaat ervan uit dat je een WeWeb-account hebt (de gratis versie volstaat om mee te volgen) en enige basiskennis van een visuele builder. Heb je al met Webflow of Figma gewerkt, dan voelt WeWeb binnen een uur vertrouwd aan. Is dit je eerste visuele builder, reken dan op een extra dag voor de leercurve. De WeWeb-documentatie is uitstekend en de community op Discord biedt actieve ondersteuning.
Stap 1: Je project opzetten
Maak een nieuw WeWeb-project aan. Kies "Blank" (leeg), gebruik geen sjabloon als je volledige controle over de structuur wilt.
Eerste opzetstappen: 1. Stel je standaardlettertype in via Project Settings → Fonts. Importeer een Google Font (Inter of Plus Jakarta Sans werken goed voor SaaS). 2. Leg je merkkleuren vast als design tokens in het Styles-paneel: primair, secundair, tekst, achtergrond, rand. 3. Stel de paginabreedte in: max-width 1280px, gecentreerd, met 24px horizontale padding op mobiel.
Investeer hier 20 minuten. Tokens nu goed instellen bespaart later uren aan inconsistenties.
Design tokens zijn de basis van een onderhoudbaar WeWeb-project. Elke kleur, spacing-eenheid en lettergrootte zou moeten verwijzen naar een token in plaats van een hardgecodeerde waarde. Wil je klant de merkkleur van blauw naar groen veranderen, dan zorgt een op tokens gebaseerd systeem ervoor dat één wijziging elke knop, link en highlight in het hele project bijwerkt. Zonder tokens pas je kleuren één voor één per element aan, een taak die uren kost en inconsistenties met zich meebrengt.
Stap 2: De hero-sectie bouwen
De hero is de belangrijkste sectie, bouw die als eerste.
Structuur: <section> (volledige viewporthoogte, gecentreerde inhoud) <div> (badge/pil, optioneel, bijv. "Nu in bèta") <h1> (primaire kop, de uitkomst) <p> (subkop, voor wie het is, hoe het werkt) <div> (CTA-knoppen, primair + optioneel secundair) <div> (hero-afbeelding of productscreenshot)
WeWeb-tips: - Gebruik een Section-element, geen Container, zodat de achtergrond over de volle breedte uitrekt - Stel de lettergrootte van de H1 in via een WeWeb breakpoint-variabele: 56px desktop, 40px tablet, 32px mobiel - Voeg een gradient of subtiele noise-textuur toe aan de achtergrond, puur zwart-witte hero's ogen plat
De hero-sectie kost van alle secties de meeste tijd om te bouwen, omdat er de meeste iteratie voor nodig is. Reken erop dat je de kop 3 tot 5 keer herschrijft voordat het goed voelt. Test hem bij echte mensen, niet alleen je eigen team, voordat je het ontwerp definitief maakt. De tekst van kop en subkop is belangrijker dan welk visueel element dan ook in de hero. Een sterke kop op een gewone witte achtergrond presteert altijd beter dan een zwakke kop op een prachtig vormgegeven donkere hero.
Stap 3: Sociale proof en functies
Sociale-proof-rij: plaats deze direct onder de hero. Gebruik een Flexbox-rij met justify-content: center, gap: 32px. Voeg bedrijfslogo's toe (SVG of WebP, grijs/opacity 60%).
Functiessectie: - Container met een 3-koloms Grid (CSS Grid, gap: 24px) - Elke kaart: icoon (24px), H3 (functienaam), P (beschrijving van één zin) - Voeg een subtiele rand toe (1px solid rgba(255,255,255,0.08)) voor scheiding zonder visueel gewicht
WeWeb-snelkoppeling: maak één functiekaart, stijl hem, dupliceer hem daarna 2× en pas de inhoud aan. Bouw niet elke kaart vanaf nul.
Weersta bij het functieraster de verleiding om meer dan 4 functies toe te voegen. Elke extra functie vermindert de aandacht die aan elke individuele functie wordt besteed. De beste functiessecties bestaan uit 3 tot 4 zorgvuldig gekozen mogelijkheden die de meest overtuigende redenen vertegenwoordigen om voor jouw product te kiezen. Heb je 8 functies die het vermelden waard zijn, overweeg ze dan te groeperen per thema (bijv. "Samenwerken", "Automatiseren", "Analyseren") en 3 groepen te tonen in plaats van 8 losse items.
Stap 4: Prijzensectie
Een prijzenlayout met drie kolommen is de SaaS-standaard. Bouw deze met CSS Grid: drie gelijke kolommen, middelste kolom uitgelicht (andere achtergrond, badge "Meest populair").
Elke prijskaart heeft nodig: - Plannaam (H3) - Prijs + factureringsperiode - 4 tot 6 functiebullets (gebruik een WeWeb List-component, geen hardgecodeerde divs, dat is makkelijker bij te werken) - CTA-knop
WeWeb-truc: koppel de inhoud van de prijskaart aan een WeWeb-variabele (array van objecten). Zo kun je prijzen en functies wijzigen vanuit één data-object zonder elke kaart afzonderlijk te bewerken. Verandert je prijsstelling, dan werk je één array bij en alle drie de kaarten worden automatisch bijgewerkt.
Prijspaginapsychologie speelt hier een rol: het middelste plan moet altijd visueel worden benadrukt en gepositioneerd als de standaardaanbeveling. Geef het een andere achtergrondkleur (iets lichter of met een gekleurde rand), voeg een badge "Meest populair" toe in je primaire accentkleur, en maak de CTA-knop op het middelste plan solide terwijl de andere twee plannen omlijnde knoppen gebruiken. Deze visuele hiërarchie stuurt de meerderheid van de bezoekers naar het plan dat jij ze wilt laten kiezen.
Stap 5: FAQ-accordion
Een accordion is één WeWeb-component met een klik-toggle. Bouw hem met: - Een container per FAQ-item - H3 voor de vraag (klikbaar) - Een div voor het antwoord (zichtbaarheid geschakeld door een WeWeb-variabele)
Aanpak met WeWeb-variabelen: 1. Maak een variabele aan: openFaqIndex (type: Number, standaard: -1) 2. Bij elke klik op een vraag: zet openFaqIndex = index van dit item (of -1 als het al open is) 3. Toon/verberg elke antwoord-div: voeg een voorwaarde toe "openFaqIndex === thisIndex"
Zo ontstaat een echte accordion waarbij slechts één antwoord tegelijk open staat, zonder ook maar één regel JavaScript te schrijven.
Voeg voor het SEO-voordeel ook FAQPage-schema toe in de <head> van de pagina, dat overeenkomt met de inhoud van de FAQ-accordion. Google kan FAQ-inhoud halen uit zowel de zichtbare HTML als het JSON-LD-schema, het gebruik van beide vergroot de kans dat je FAQ als rich result verschijnt in de zoekresultaten. Het schema moet worden bijgewerkt telkens wanneer je FAQ-inhoud toevoegt of wijzigt. Koppel je je FAQ-accordion aan een Supabase-tabel, dan moet je ook het hardgecodeerde JSON-LD-schema handmatig bijwerken of een build-time script implementeren dat het schema genereert vanuit dezelfde databron.
Stap 6: Contactformulier
Voeg een formulier toe boven de footer. Houd het minimaal: naam, werk-e-mail, CTA-knop ("Boek een demo" of "Start gratis proefperiode").
Het formulier koppelen aan Supabase: 1. Voeg in WeWeb een Form-component toe 2. Voeg een Actie toe bij submit: "Insert row" → je Supabase-tabel "leads" 3. Voeg een tweede Actie toe: toon een succesbericht (zichtbaarheid van een dankjewel-div omschakelen)
Koppelen aan Make in plaats daarvan: 1. Maak een Make-webhookscenario aan 2. Gebruik in WeWeb de actie "HTTP Request" bij het versturen van het formulier → POST naar je Make-webhook-URL 3. Voeg in Make toe: e-mailnotificatie + het aanmaken van een rij in HubSpot/Notion/Airtable
Voeg altijd een honeypot-veld toe (verborgen invoerveld dat echte gebruikers nooit invullen, bots wel). Filter elke inzending eruit waarbij het honeypot-veld niet leeg is.
Het aantal formuliervelden is een van de meest bepalende conversievariabelen. Elk extra verplicht veld verlaagt het invulpercentage met ongeveer 10 tot 15%. Vraag voor een eerste-contact-landingspagina om het minimum: doorgaans voornaam en werk-e-mail. Aanvullende kwalificatievelden (bedrijfsgrootte, use case, telefoonnummer) hoor je te verplaatsen naar de follow-upreeks of de bevestiging van de demo-boeking. Het doel van het landingspagina-formulier is het e-mailadres binnenhalen, al het andere kun je later verzamelen.
WeWeb CMS voor landingspagina's
Met de CMS-functionaliteit van WeWeb kun je de inhoud van je landingspagina beheren zonder opnieuw de WeWeb-editor te openen. Dit is bijzonder waardevol voor teams waarin een niet-technische marketeer teksten moet bijwerken, testimonials moet verwisselen of prijzen moet wijzigen zonder te wachten op de tijd van een developer.
Stel CMS-collecties in voor de herhaalbare contenttypes op je landingspagina: testimonials, functiekaarten, FAQ-vragen en prijstiers. Elke collectie is een gestructureerd datatype met velden die overeenkomen met de inhoud op de pagina. Koppel je WeWeb-componenten aan de CMS-collectiedata in plaats van aan hardgecodeerde waarden. Nu kan een teamlid inloggen op de CMS-editor van WeWeb, een testimonial of FAQ-vraag bijwerken en de pagina opnieuw publiceren, zonder ook maar één component aan te raken.
Voor enterprise-klanten kan het CMS van WeWeb worden gekoppeld aan een externe Supabase-tabel in plaats van het interne CMS van WeWeb. Dat betekent dat de inhoud eigendom is van de klant in hun eigen database, bewerkbaar via een aangepaste admin-UI die je in WeWeb bouwt, en niet afhankelijk van het WeWeb-platform voor contentbeheer. Deze architectuur biedt maximale flexibiliteit en voorkomt platform lock-in voor content.
A/B-testen opzetten in WeWeb
WeWeb heeft geen ingebouwde A/B-testfunctionaliteit, maar het is eenvoudig te implementeren met URL-parameters en WeWeb-variabelen. De aanpak: toon variant A aan bezoekers zonder parameter (de controlegroep), toon variant B aan bezoekers met ?variant=b in de URL. Je advertentiecampagnes sturen 50% van het verkeer naar elke URL-variant.
Implementatie: maak een WeWeb-variabele aan genaamd pageVariant met een standaardwaarde van 'a'. Voeg een On Page Load-actie toe die de URL-parameter uitleest en pageVariant instelt op 'a' of 'b'. Voeg vervolgens voorwaardelijke weergave toe aan de elementen die je wilt testen, toon heroHeadlineA wanneer pageVariant = 'a', toon heroHeadlineB wanneer pageVariant = 'b'. Volg conversies per variant met een PostHog-event dat de variant als property bevat.
Gebruik voor geavanceerder testen de feature flags van PostHog om de variant consistent toe te wijzen per gebruikerssessie in plaats van via URL-parameter. De WeWeb-plugin van PostHog legt deze koppeling zonder code. Het voordeel van toewijzing op sessiebasis is dat een bezoeker die terugkeert naar de pagina zonder de URL-parameter dezelfde variant te zien krijgt, wat het verstorende effect voorkomt dat één bezoeker beide varianten te zien krijgt.
Formulierverwerking en leadcaptatie
Leadcaptatie is het kerndoel van de meeste landingspagina's, en het traject van formulierinzending naar je CRM of salesproces moet end-to-end getest worden vóór lancering. Veel teams lanceren een landingspagina en ontdekken pas 3 weken later dat formulierinzendingen stilletjes faalden door een verkeerd geconfigureerd Supabase RLS-beleid of een Make-scenario dat gepauzeerd stond.
Bouw een testinzendingsprotocol: na elke formulierwijziging stuur je een testlead met een herkenbaar e-mailadres (test+landingpage@jouwbedrijf.com) en controleer je of deze verschijnt in je Supabase-leads-tabel, de Make-notificatiemail activeert en een contactrecord aanmaakt in je CRM. Dit kost 5 minuten en vangt integratiefouten meteen op.
Voeg voor landingspagina's met een hoog volume (100+ inzendingen per dag) rate limiting toe aan je formulierinzendingsendpoint. In Xano is dit een eenvoudige middleware die het aantal inzendingen vanaf een bepaald IP-adres in het afgelopen uur controleert. Zonder rate limiting kan een enkele botcampagne je leads-tabel vullen met duizenden spamrecords die je conversiedata corrumperen en handmatige opschoning vereisen. Combineer rate limiting met het honeypot-veld en je elimineert meer dan 95% van de spam-formulierinzendingen.
Tracking en analytics-integratie
Een landingspagina zonder analytics is gokwerk. Analytics verandert een landingspagina van een eenmalige build in een doorlopend optimalisatieproject. De twee tools die we aanraden voor WeWeb-landingspagina's zijn PostHog (voor productanalytics en sessieopnames) en Plausible (voor privacy-vriendelijke verkeersanalyse), ze dienen een ander doel en werken goed samen.
PostHog instellen in WeWeb: voeg het PostHog JavaScript-snippet toe aan de custom head code van je project. Voeg vervolgens custom events toe in WeWeb Actions: activeer een posthog.capture('cta_clicked', {location: 'hero'})-event wanneer op de hero-CTA wordt geklikt, een posthog.capture('form_submitted')-event bij formulierinzending, en een posthog.capture('pricing_viewed')-event wanneer de prijzensectie de viewport binnenkomt (gebruik WeWeb's Intersection Observer-binding). Deze drie events geven je de conversiefunneldata die je nodig hebt om te zien waar bezoekers afhaken.
Plausible levert verkeersdata zonder de privacyproblemen van Google Analytics en vereist geen cookiebanner onder de AVG, een belangrijke UX-winst voor Europese landingspagina's. Voeg het Plausible-script toe aan je head code en configureer custom goals voor CTA-clicks en formulierinzendingen. Het Plausible-dashboard geeft je schone verkeersbronnen, toppagina's en doelconversiepercentages in één overzicht. Deel de dashboardlink met je klant zodat die het verkeer kan volgen zonder toegang nodig te hebben tot je volledige analyticsopzet.
Stap 7: Publiceren op je domein
Ga in WeWeb naar Hosting → Custom Domain. 1. Voeg je domein toe (bijv. app.jouwsite.com of jouwsite.com) 2. WeWeb geeft je een CNAME-record om toe te voegen bij je DNS-provider 3. Voeg de CNAME toe en wacht op DNS-propagatie (doorgaans 5 tot 30 minuten) 4. WeWeb provisioneert automatisch een SSL-certificaat via Let's Encrypt
Voor het publiceren: - Controleer elke sectie op 375px, 768px en 1280px - Voer een Lighthouse-audit uit (Chrome DevTools → tabblad Lighthouse), streef naar 90+ performance - Controleer paginatitel en meta-beschrijving in WeWeb's SEO-instellingen - Voeg je Google Analytics- of Plausible-snippet toe in Project Settings → Custom Code → <head>
Publiceer en je bent live. Totale tijd: één dag.
Dien na het publiceren je URL in bij Google Search Console via de URL-inspectietool en vraag indexering aan. Dit garandeert geen snellere indexering, maar het signaleert wel aan Google dat de pagina bestaat en klaar is om gecrawld te worden. Controleer voor een landingspagina die betaald verkeer ontvangt ook of de conversietrackingpixel van je advertentieplatform correct afgaat via het netwerktabblad van de browser, mislukte conversietracking is een veelvoorkomende oorzaak van verkeerd toegeschreven campagnedata die tot slechte advertentiebudgetbeslissingen leidt.