Vad du kommer att bygga
I slutet av den här guiden har du en komplett landningssida med: - Hero-avsnitt med rubrik, underrubrik och CTA-knapp - Social proof-rad (logotyper eller vittnesmål) - Funktionsavsnitt (3-kolumns grid) - Prisavsnitt - FAQ-accordion - Leadfångstformulär (kopplat till Supabase eller en Make webhook) - Publicerat på en anpassad domän med HTTPS
Total byggtid: 4-6 timmar för ett första bygge, 1-2 timmar när du har gjort det förut.
Den här guiden förutsätter att du har ett WeWeb-konto (gratisnivån räcker för att följa med) och grundläggande bekantskap med ett visuellt byggverktyg. Om du har använt Webflow eller Figma känns WeWeb bekant inom en timme. Om det här är ditt första visuella byggverktyg, räkna med en extra dag för inlärningskurvan. WeWeb-dokumentationen är utmärkt och community-Discorden har aktiv support.
Landningssidan kan ha en svensk version och en engelsk version med olika URL-slugs för att nå olika målgrupper.
Steg 1: Sätt upp ditt projekt
Skapa ett nytt WeWeb-projekt. Välj "Blank", använd inte en mall om du vill ha full kontroll över strukturen.
Första inställningssteg: 1. Sätt ditt standardtypsnitt i Project Settings → Fonts. Importera ett Google Font (Inter eller Plus Jakarta Sans fungerar bra för SaaS). 2. Sätt dina varumärkesfärger som designtokens i Styles-panelen: primär, sekundär, text, bakgrund, kant. 3. Sätt sidbredden: max-width 1280px, centrerad, med 24px horisontell utfyllnad på mobil.
Investera 20 minuter här. Att få tokens rätt nu sparar timmar av inkonsekvens senare.
Designtokens är grunden för ett underhållbart WeWeb-projekt. Varje färg, avståndsenhet och teckenstorlek bör referera till en token istället för ett hårdkodat värde. När din kund vill ändra varumärkesfärgen från blått till grönt innebär ett tokenbaserat system att en enda ändring uppdaterar varje knapp, länk och highlight i hela projektet. Utan tokens ändrar du färger ett element i taget, en uppgift som tar timmar och introducerar inkonsekvenser.
Steg 2: Bygg hero-avsnittet
Hero-avsnittet är det viktigaste, bygg det först.
Struktur: - section-element (full viewporthöjd, centrerat innehåll) - div med badge/pill (valfritt, t.ex. "Nu i beta") - h1 (primär rubrik, resultatet) - p (underrubrik, vem det är för, hur det fungerar) - div (CTA-knappar, primär + valfri sekundär) - div (hero-bild eller produktskärmbild)
WeWeb-tips: - Använd ett Section-element, inte en Container, så bakgrunden sträcker sig full bredd - Sätt H1-teckenstorleken med en WeWeb-breakpoint-variabel: 56px desktop, 40px tablet, 32px mobil - Lägg till en gradient eller subtil noise-textur på bakgrunden, rena svart/vita hero-avsnitt ser platta ut
Hero-avsnittet kommer att ta längst tid av alla avsnitt att bygga eftersom det kräver mest iteration. Räkna med att skriva om rubriken 3-5 gånger innan den känns rätt. Testa den med riktiga personer, inte bara ditt team, innan du låser designen. Rubrik- och underrubrikstexten är viktigare än något visuellt element i hero-avsnittet. En stark rubrik på en vanlig vit bakgrund slår en svag rubrik på en vackert designad mörk hero varje gång.
Steg 3: Social proof och funktioner
Social proof-rad: placera den direkt under hero. Använd en Flexbox-rad med justify-content: center, gap: 32px. Lägg till företagslogotyper (SVG eller WebP, grå/opacitet 60 %).
Funktionsavsnitt: - Container med ett 3-kolumns Grid (CSS Grid, gap: 24px) - Varje kort: ikon (24px), H3 (funktionsnamn), P (en menings beskrivning) - Lägg till en subtil kant (1px solid rgba(255,255,255,0.08)) för separation utan tyngd
WeWeb-genväg: skapa ett funktionskort, styla det, duplicera det 2× och uppdatera innehållet. Bygg inte varje kort från grunden.
För funktionsgriden, stå emot frestelsen att lägga till fler än 4 funktioner. Varje ytterligare funktion minskar uppmärksamheten som ägnas åt var och en. De bästa funktionsavsnitten är 3-4 noggrant utvalda förmågor som representerar de mest övertygande anledningarna att välja din produkt. Om du har 8 funktioner värda att lyfta fram, överväg att gruppera dem tematiskt (t.ex. "Samarbeta", "Automatisera", "Analysera") och visa 3 grupper istället för 8 enskilda punkter.
Steg 4: Prisavsnitt
En tre-kolumns prislayout är SaaS-standarden. Bygg den med CSS Grid: tre lika kolumner, mittenkolumnen markerad (annan bakgrund, "Mest populär"-badge).
Varje priskort behöver: - Plannamn (H3) - Pris + faktureringsperiod (i SEK för den svenska marknaden om tillämpligt) - 4-6 funktionspunkter (använd en WeWeb List-komponent, inte hårdkodade divs, det är enklare att uppdatera) - CTA-knapp
WeWeb-trick: bind priskortets innehåll till en WeWeb-variabel (array av objekt). Det låter dig ändra priser och funktioner från ett dataobjekt utan att redigera varje kort individuellt. När dina priser ändras uppdaterar du en array, alla tre korten uppdateras automatiskt.
Prissidans psykologi spelar roll här: mittenplanen bör alltid visuellt betonas och positioneras som standardrekommendationen. Sätt den med en annan bakgrundsfärg (något ljusare eller med en färgad kant), lägg till en "Mest populär"-badge i din primära accentfärg, och gör CTA-knappen på mittenplanen fylld medan de andra två planerna använder outlined-knappar. Den här visuella hierarkin styr majoriteten av besökarna mot den plan du vill att de ska välja.
Steg 5: FAQ-accordion
En accordion är en WeWeb-komponent med en klick-toggle. Bygg den med: - En container för varje FAQ-objekt - H3 för frågan (klickbar) - En div för svaret (synlighet växlas av en WeWeb-variabel)
WeWeb-variabelmetod: 1. Skapa en variabel: openFaqIndex (typ: Number, standard: -1) 2. Vid varje frågas klick: sätt openFaqIndex = index för detta objekt (eller -1 om det redan är öppet) 3. Visa/dölj varje svarsdiv: lägg till ett villkor "openFaqIndex === thisIndex"
Det här skapar en korrekt accordion där bara ett svar är öppet åt gången, med noll JavaScript-kod skriven.
För SEO-nytta, lägg också till FAQPage-schema i sidans <head> som matchar FAQ-accordionens innehåll. Google kan extrahera FAQ-innehåll från både den synliga HTML:en och JSON-LD-schemat, att ha båda ökar chansen att din FAQ visas som ett rich result i sökresultaten. Schemat bör uppdateras varje gång du lägger till eller ändrar FAQ-innehåll. Om du binder din FAQ-accordion till en Supabase-tabell behöver du också uppdatera det hårdkodade JSON-LD-schemat manuellt, eller implementera ett byggtidsskript som genererar schemat från samma datakälla.
Steg 6: Leadfångstformulär
Lägg till ett formulär ovanför sidfoten. Håll det minimalt: namn, arbets-e-post, CTA-knapp ("Boka en demo" eller "Starta gratis provperiod").
Koppla formuläret till Supabase: 1. Lägg till en Form-komponent i WeWeb 2. Lägg till en Action vid submit: "Insert row" → din Supabase "leads"-tabell 3. Lägg till en andra Action: visa ett bekräftelsemeddelande (växla synlighet på en tack-div)
Koppla till Make istället: 1. Skapa ett Make webhook-scenario 2. I WeWeb, använd "HTTP Request"-åtgärden vid formulärinlämning → POST till din Make webhook-URL 3. I Make: lägg till e-postnotis + kontaktskapande i HubSpot/Notion/Airtable
Lägg alltid till ett honeypot-fält (dolt inmatningsfält som riktiga användare aldrig fyller i, bots gör det). Filtrera bort inlämningar där honeypot-fältet inte är tomt.
Antal formulärfält är en av de mest betydande konverteringsvariablerna. Varje ytterligare obligatoriskt fält minskar formulärets fullföljandegrad med ungefär 10-15 %. För en första-kontakt-landningssida, be om minimum: vanligtvis förnamn och arbets-e-post. Ytterligare kvalificeringsfält (företagsstorlek, användningsfall, telefonnummer) bör flyttas till uppföljningssekvensen eller demo-bokningsbekräftelsen. Målet med landningssidans formulär är att få e-postadressen, allt annat kan samlas in senare.
WeWeb CMS för landningssidor
WeWebs CMS-funktionalitet låter dig hantera landningssidans innehåll utan att gå in i WeWeb-redigeraren igen. Det här är särskilt värdefullt för team där en icke-teknisk marknadsföringsperson behöver uppdatera copy, byta ut vittnesmål eller ändra priser utan att vänta på en utvecklares tid.
Sätt upp CMS-kollektioner för de återkommande innehållstyperna på din landningssida: vittnesmål, funktionskort, FAQ-frågor och prisnivåer. Varje kollektion är en strukturerad datatyp med fält som motsvarar innehållet på sidan. Bind dina WeWeb-komponenter till CMS-kollektionens data istället för hårdkodade värden. Nu kan en teammedlem logga in i WeWebs CMS-redigerare, uppdatera ett vittnesmål eller en FAQ-fråga, och publicera om sidan, utan att röra en enda komponent.
För enterprise-kunder kan WeWebs CMS pekas mot en extern Supabase-tabell istället för WeWebs interna CMS. Det betyder att innehållet ägs av kunden i deras egen databas, redigerbart via ett anpassat admin-UI du bygger i WeWeb, och inte beroende av WeWeb-plattformen för innehållshantering. Den här arkitekturen ger maximal flexibilitet och undviker plattformsinlåsning för innehåll.
A/B-testning i WeWeb
WeWeb har ingen inbyggd A/B-testning, men det är enkelt att implementera med URL-parametrar och WeWeb-variabler. Metoden: visa variant A för besökare utan parameter (kontrollgruppen), visa variant B för besökare med ?variant=b i URL:en. Dina annonskampanjer skickar 50 % av trafiken till varje URL-variant.
Implementation: skapa en WeWeb-variabel som heter pageVariant med standardvärdet 'a'. Lägg till en On Page Load-åtgärd som läser URL-parametern och sätter pageVariant till 'a' eller 'b'. Lägg sedan till villkorlig visning på elementen du vill testa, visa heroHeadlineA när pageVariant = 'a', visa heroHeadlineB när pageVariant = 'b'. Spåra konverteringar per variant med ett PostHog-event som inkluderar varianten som en egenskap.
För mer avancerad testning, använd PostHogs feature flags för att tilldela variant konsekvent per användarsession istället för URL-parameter. PostHogs WeWeb-plugin gör den här kopplingen utan kod. Fördelen med sessionsbaserad tilldelning är att en besökare som kommer tillbaka till sidan utan URL-parametern ser samma variant, vilket förhindrar den förvirrande effekten av att en besökare ser båda varianterna.
Formulärhantering och leadfångst
Leadfångst är kärnsyftet med de flesta landningssidor, och vägen från formulärinlämning till ditt CRM eller din säljprocess bör testas end-to-end före lansering. Många team lanserar en landningssida och upptäcker först 3 veckor senare att formulärinlämningar tyst misslyckades på grund av en felkonfigurerad Supabase RLS-policy eller ett Make-scenario som hade pausats.
Bygg ett testinlämningsprotokoll: efter varje formulärändring, skicka in ett testlead med en igenkännbar e-post (test+landingpage@yourcompany.com) och verifiera att det dyker upp i din Supabase leads-tabell, triggar Make-notismejlet, och skapar en kontaktpost i ditt CRM. Det tar 5 minuter och fångar integrationsfel omedelbart.
För landningssidor med hög volym (100+ inlämningar per dag), lägg till hastighetsbegränsning (rate limiting) på din formulärinlämningsendpoint. I Xano är det en enkel middleware som kontrollerar antalet inlämningar från en given IP-adress under den senaste timmen. Utan hastighetsbegränsning kan en enda bot-kampanj fylla din leads-tabell med tusentals skräppostposter som förstör din konverteringsdata och kräver manuell städning. Kombinera hastighetsbegränsning med honeypot-fältet så eliminerar du över 95 % av skräppostinlämningarna.
Spårning och analysintegration
En landningssida utan analys är en gissning. Analys förvandlar en landningssida från ett engångsbygge till ett pågående optimeringsprojekt. De två verktyg vi rekommenderar för WeWeb-landningssidor är PostHog (för produktanalys och sessionsinspelning) och Plausible (för integritetsvänlig trafikanalys), de tjänar olika syften och fungerar bra tillsammans.
PostHog-konfiguration i WeWeb: lägg till PostHogs JavaScript-snippet i projektets anpassade head-kod. Lägg sedan till anpassade events i WeWeb Actions: trigga ett posthog.capture('cta_clicked', {location: 'hero'})-event när hero-CTA:n klickas, ett posthog.capture('form_submitted')-event vid formulärinlämning, och ett posthog.capture('pricing_viewed')-event när prisavsnittet kommer in i viewporten (använd WeWebs Intersection Observer-koppling). Dessa tre events ger dig den konverteringstratt-data du behöver för att identifiera var besökare hoppar av.
Plausible ger trafikdata utan integritetsimplikationerna av Google Analytics och kräver ingen cookie-samtyckesbanner enligt GDPR, en betydande UX-vinst för europeiska landningssidor. Lägg till Plausible-skriptet i din head-kod och konfigurera anpassade mål för CTA-klick och formulärinlämningar. Plausible-dashboarden ger dig rena trafikkällor, toppsidor och målkonverteringsgrader i en enda vy. Dela dashboard-länken med din kund så de kan övervaka trafik utan att behöva tillgång till din fullständiga analysuppsättning.
Steg 7: Publicera till din domän
I WeWeb, gå till Hosting → Custom Domain. 1. Lägg till din domän (t.ex. app.dinsajt.se eller dinsajt.se) 2. WeWeb ger dig en CNAME-post att lägga till hos din DNS-leverantör 3. Lägg till CNAME-posten, vänta på DNS-spridning (5-30 minuter vanligtvis) 4. WeWeb provisionerar automatiskt ett SSL-certifikat via Let's Encrypt
Innan publicering: - Kontrollera varje avsnitt vid 375px, 768px och 1280px - Kör en Lighthouse-granskning (Chrome DevTools → Lighthouse-fliken), sikta på 90+ i prestanda - Kontrollera sidtitel och meta description i WeWebs SEO-inställningar - Lägg till ditt Google Analytics- eller Plausible-snippet i Project Settings → Custom Code → <head>
Publicera, och du är live. Total tid: en dag.
Efter publicering, skicka in din URL till Google Search Console med URL-inspektionsverktyget och begär indexering. Det garanterar inte snabbare indexering men det signalerar till Google att sidan finns och är redo att genomsökas. För en landningssida som får betald trafik, verifiera också att din annonsplattforms konverteringsspårningspixel triggas korrekt med webbläsarens Nätverk-flik, misslyckad konverteringsspårning är en vanlig orsak till felaktigt tillskriven kampanjdata som leder till dåliga annonsbudgetbeslut.