How to Build a Landing Page with WeWeb (Step by Step)

What You'll Build

By the end of this guide you'll have a complete landing page with:
- Hero section with headline, sub-headline, and CTA button
- Social proof row (logos or testimonial)
- Feature section (3-column grid)
- Pricing section
- FAQ accordion
- Lead capture form (connected to Supabase or a Make webhook)
- Published on a custom domain with HTTPS

Total build time: 4–6 hours for a first build, 1–2 hours once you've done it before.

This guide assumes you have a WeWeb account (free tier is sufficient to follow along) and basic familiarity with a visual builder. If you have used Webflow or Figma, WeWeb will feel familiar within an hour. If this is your first visual builder, budget an extra day for the learning curve. The WeWeb documentation is excellent and the community Discord has active support.

Step 1: Set Up Your Project

Create a new WeWeb project. Choose "Blank", don't use a template if you want full control over the structure.

First setup steps:
1. Set your default font in Project Settings → Fonts. Import a Google Font (Inter or Plus Jakarta Sans work well for SaaS).
2. Set your brand colours as design tokens in the Styles panel: primary, secondary, text, background, border.
3. Set the page width: max-width 1280px, centred, with 24px horizontal padding on mobile.

Invest 20 minutes here. Getting tokens right now saves hours of inconsistency later.

Design tokens are the foundation of a maintainable WeWeb project. Every colour, spacing unit, and font size should reference a token rather than a hardcoded value. When your client wants to change the brand colour from blue to green, a token-based system means one change updates every button, link, and highlight across the entire project. Without tokens, you are changing colours one element at a time, a task that takes hours and introduces inconsistencies.

Step 2: Build the Hero Section

The hero is the most important section, build it first.

Structure:
<section> (full viewport height, centred content)
  <div> (badge/pill, optional, e.g. "Now in beta")
  <h1> (primary headline, the outcome)
  <p> (sub-headline, who it's for, how it works)
  <div> (CTA buttons, primary + optional secondary)
  <div> (hero image or product screenshot)

WeWeb tips:
- Use a Section element, not a Container, so the background stretches full-width
- Set the H1 font size to a WeWeb breakpoint variable: 56px desktop, 40px tablet, 32px mobile
- Add a gradient or subtle noise texture to the background, pure black/white heroes look flat

The hero section will take the longest of any section to build because it requires the most iteration. Expect to write and rewrite the headline 3–5 times before it feels right. Test it with real people, not just your team, before committing to the design. The headline and sub-headline copy are more important than any visual element in the hero. A strong headline on a plain white background outperforms a weak headline on a beautifully designed dark hero every time.

Step 3: Social Proof and Features

Social proof row: place it directly below the hero. Use a Flexbox row with justify-content: center, gap: 32px. Add company logo images (SVG or WebP, grey/opacity 60%).

Feature section:
- Container with a 3-column Grid (CSS Grid, gap: 24px)
- Each card: icon (24px), H3 (feature name), P (one-sentence description)
- Add a subtle border (1px solid rgba(255,255,255,0.08)) for separation without weight

WeWeb shortcut: create one feature card, style it, then duplicate it 2× and update the content. Don't build each card from scratch.

For the feature grid, resist the temptation to add more than 4 features. Every additional feature reduces the attention paid to each individual one. The best feature sections are 3–4 carefully chosen capabilities that represent the most compelling reasons to choose your product. If you have 8 features worth highlighting, consider grouping them by theme (e.g., "Collaborate", "Automate", "Analyse") and showing 3 groups instead of 8 individual items.

Step 4: Pricing Section

A three-column pricing layout is the SaaS standard. Build it with CSS Grid: three equal columns, centre column highlighted (different background, "Most popular" badge).

Each pricing card needs:
- Plan name (H3)
- Price + billing period
- 4–6 feature bullets (use a WeWeb List component, not hardcoded divs, it's easier to update)
- CTA button

WeWeb trick: bind the pricing card content to a WeWeb variable (array of objects). This lets you change prices and features from one data object without editing each card individually. When your pricing changes, update one array, all three cards update automatically.

Pricing page psychology matters here: the middle plan should always be visually emphasised and positioned as the default recommendation. Set it with a different background colour (slightly lighter or with a coloured border), add a "Most popular" badge in your primary accent colour, and make the CTA button on the middle plan solid while the other two plans use outlined buttons. This visual hierarchy guides the majority of visitors toward the plan you want them to choose.

Step 5: FAQ Accordion

An accordion is one WeWeb component with a click toggle. Build it with:
- A container for each FAQ item
- H3 for the question (clickable)
- A div for the answer (visibility toggled by a WeWeb variable)

WeWeb variables approach:
1. Create a variable: openFaqIndex (type: Number, default: -1)
2. On each question click: set openFaqIndex = index of this item (or -1 if it's already open)
3. Show/hide each answer div: add a condition "openFaqIndex === thisIndex"

This creates a proper accordion where only one answer is open at a time, with zero JavaScript code written.

For SEO benefit, also add FAQPage schema in the page <head> that matches the FAQ accordion content. Google can extract FAQ content from both the visible HTML and the JSON-LD schema, having both increases the chance of your FAQ appearing as a rich result in search. The schema should be updated whenever you add or change FAQ content. If you bind your FAQ accordion to a Supabase table, you will also need to update the hardcoded JSON-LD schema manually or implement a build-time script that generates the schema from the same data source.

Step 6: Lead Capture Form

Add a form above the footer. Keep it minimal: Name, Work email, CTA button ("Book a demo" or "Start free trial").

Connecting the form to Supabase:
1. In WeWeb, add a Form component
2. Add an Action on submit: "Insert row" → your Supabase "leads" table
3. Add a second Action: show a success message (toggle visibility of a thank-you div)

Connecting to Make instead:
1. Create a Make webhook scenario
2. In WeWeb, use the "HTTP Request" action on form submit → POST to your Make webhook URL
3. In Make: add email notification + HubSpot/Notion/Airtable row creation

Always add a honeypot field (hidden input that real users never fill, bots do). Filter out any submission where the honeypot field is not empty.

Form field count is one of the most significant conversion variables. Every additional required field reduces form completion rate by approximately 10–15%. For a first-touch landing page, ask for the minimum: typically first name and work email. Additional qualification fields (company size, use case, phone number) should be moved to the follow-up sequence or the demo booking confirmation. The goal of the landing page form is to get the email, everything else can be gathered later.

WeWeb CMS for Landing Pages

WeWeb's CMS functionality allows you to manage landing page content without re-entering the WeWeb editor. This is particularly valuable for teams where a non-technical marketing person needs to update copy, swap testimonials, or change pricing without waiting for a developer's time.

Set up CMS collections for the repeatable content types on your landing page: testimonials, feature cards, FAQ questions, and pricing tiers. Each collection is a structured data type with fields that correspond to the content on the page. Bind your WeWeb components to the CMS collection data instead of hardcoded values. Now a team member can log in to WeWeb's CMS editor, update a testimonial or FAQ question, and republish the page, without touching a single component.

For enterprise clients, WeWeb's CMS can be pointed at an external Supabase table instead of WeWeb's internal CMS. This means the content is owned by the client in their own database, editable via a custom admin UI you build in WeWeb, and not dependent on the WeWeb platform for content management. This architecture gives maximum flexibility and avoids platform lock-in for content.

A/B Testing Setup in WeWeb

WeWeb does not have native A/B testing, but it is straightforward to implement using URL parameters and WeWeb variables. The approach: show variant A to visitors with no parameter (the control), show variant B to visitors with ?variant=b in the URL. Your ad campaigns send 50% of traffic to each URL variant.

Implementation: create a WeWeb variable called pageVariant with a default value of 'a'. Add an On Page Load action that reads the URL parameter and sets pageVariant to 'a' or 'b'. Then add conditional display on the elements you want to test, show heroHeadlineA when pageVariant = 'a', show heroHeadlineB when pageVariant = 'b'. Track conversions by variant using a PostHog event that includes the variant as a property.

For more sophisticated testing, use PostHog's feature flags to assign variant consistently by user session rather than URL parameter. PostHog's WeWeb plugin makes this connection without code. The advantage of session-based assignment is that a visitor who comes back to the page without the URL parameter sees the same variant, preventing the confounding effect of one visitor seeing both variants.

Form Handling and Lead Capture

Lead capture is the core purpose of most landing pages, and the path from form submission to your CRM or sales process should be tested end-to-end before launch. Many teams launch a landing page and only discover 3 weeks later that form submissions were silently failing due to a misconfigured Supabase RLS policy or a Make scenario that had been paused.

Build a test submission protocol: after any form change, submit a test lead with a recognisable email (test+landingpage@yourcompany.com) and verify it appears in your Supabase leads table, triggers the Make notification email, and creates a contact record in your CRM. This takes 5 minutes and catches integration failures immediately.

For high-volume landing pages (100+ submissions per day), add rate limiting to your form submission endpoint. In Xano, this is a simple middleware that checks the submission count from a given IP address in the last hour. Without rate limiting, a single bot campaign can fill your leads table with thousands of spam records that corrupt your conversion data and require manual cleanup. Combine rate limiting with the honeypot field and you eliminate over 95% of spam form submissions.

Tracking and Analytics Integration

A landing page without analytics is a guess. Analytics transforms a landing page from a one-time build into an ongoing optimisation project. The two tools we recommend for WeWeb landing pages are PostHog (for product analytics and session recording) and Plausible (for privacy-first traffic analytics), they serve different purposes and work well together.

PostHog setup in WeWeb: add the PostHog JavaScript snippet to your project's custom head code. Then add custom events in WeWeb Actions: trigger a posthog.capture('cta_clicked', {location: 'hero'}) event when the hero CTA is clicked, a posthog.capture('form_submitted') event on form submission, and a posthog.capture('pricing_viewed') event when the pricing section enters the viewport (use WeWeb's Intersection Observer binding). These three events give you the conversion funnel data you need to identify where visitors drop off.

Plausible provides traffic data without the privacy implications of Google Analytics and does not require a cookie consent banner under GDPR, a significant UX win for European landing pages. Add the Plausible script to your head code and configure custom goals for CTA clicks and form submissions. The Plausible dashboard gives you clean traffic sources, top pages, and goal conversion rates in a single view. Share the dashboard link with your client so they can monitor traffic without needing access to your full analytics setup.

Step 7: Publish to Your Domain

In WeWeb, go to Hosting → Custom Domain. 1. Add your domain (e.g., app.yoursite.com or yoursite.com) 2. WeWeb gives you a CNAME record to add in your DNS provider 3. Add the CNAME, wait for DNS propagation (5–30 minutes typically) 4. WeWeb auto-provisions an SSL certificate via Let's Encrypt

Before publishing:
- Check every section at 375px, 768px, and 1280px
- Run a Lighthouse audit (Chrome DevTools → Lighthouse tab), target 90+ performance
- Check page title and meta description in WeWeb's SEO settings
- Add your Google Analytics or Plausible snippet in Project Settings → Custom Code → <head>

Publish and you're live. Total time: one day.

After publishing, submit your URL to Google Search Console using the URL Inspection tool and request indexing. This does not guarantee faster indexing but it does signal to Google that the page exists and is ready to be crawled. For a landing page receiving paid traffic, also verify that your ad platform's conversion tracking pixel is firing correctly using the browser's Network tab, conversion tracking failures are a common cause of mis-attributed campaign data that leads to poor ad spend decisions.