Leer hoe je een SaaS-website plant, bouwt en lanceert die marketingpagina's en documentatie ondersteunt met duidelijke structuur, SEO, snelle performance en eenvoudige updates.
Een SaaS-website die marketingpagina's en documentatie combineert heeft twee taken: nieuwe bezoekers overtuigen om te beginnen, en bestaande gebruikers helpen succesvol te zijn. Als je het behandelt als “één site met één doel”, optimaliseer je meestal maar één kant — en de andere zal stilletjes onderpresteren.
Marketingpagina's moeten een bezoeker naar een duidelijke volgende stap bewegen: een trial starten, een demo boeken of prijzen bekijken. Documentatie moet wrijving verminderen na aanmelding: snel vragen beantwoorden, helpen bij setup en integratieproblemen wegnemen.
Schrijf één zin die je in elke planningsvergadering kunt herhalen, bijvoorbeeld:
“Converteer gekwalificeerde prospects terwijl je klanten in staat stelt zichzelf te ondersteunen.”
De meeste SaaS-sites bedienen meerdere doelgroepen, elk met een andere intentie:
Als je de doelgroep voor een pagina niet kunt benoemen, zakt die pagina weg in vaag taalgebruik.
Resultaten houden je team gefocust op gedrag, niet op het aantal pagina's:
Kies een kleine set metrics die je maandelijks controleert: marketingconversieratio, activatieratio, gebruik van docs-zoekfunctie, top mislukte zoekopdrachten en supportticketvolume per onderwerp.
Bepaal wie schrijft, reviewt en publiceert marketing- en docs-content. Duidelijk eigenaarschap voorkomt verouderde docs en inconsistente productboodschappen — en zorgt voor soepelere lanceringen wanneer meerdere teams tegelijk updates moeten doen.
Informatiearchitectuur bepaalt hoe je beide gebruikersreizen duidelijk laat voelen — zonder je header-navigatie in een rommellade te veranderen.
De meeste teams kunnen “marketing + docs” afdekken met een handvol top-level gebieden:
Houd de globale navigatie gericht op wat een eerstebezoeker verwacht te vinden. Alles wat overblijft (security, status, changelog, partners, legal) kan in de footer of binnen de relevante sectie staan.
Voor de meeste SaaS-producten is documentatie onder /docs de eenvoudigste keuze.
Docs onder /docs (zelfde domein)
Docs op een subdomein (bijvoorbeeld docs.[your-domain])
Als je al weet dat je docs uitgebreid zullen zijn en door een apart team/tooling onderhouden worden, kan een subdomein gerechtvaardigd zijn. Anders is /docs meestal de stabiele standaard.
Denk in termen van veelvoorkomende paden en zorg dat de URL's en navigatie ze ondersteunen.
Marketing-journey voorbeeld:
Support-journey voorbeeld:
Navigatierollen zijn belangrijk:
URL's zijn beloften. Ze later veranderen breekt bladwijzers, inkomende links en vertrouwen.
Een praktische benadering:
Als je moet herstructureren, plan dan vanaf dag één redirects. Een schone architectuur en stabiele URL's maken je SaaS-site makkelijker te navigeren, makkelijker te onderhouden en makkelijker om te laten groeien.
Wanneer je een SaaS-site bouwt die zowel verkoopt als gebruikers ondersteunt, is de snelste weg om een kleine set pagina's te lanceren die drie vragen beantwoorden: Wat is het? Kan ik het vertrouwen? Wat moet ik nu doen?
Begin met de essentials die bezoekers verwachten en die je team vaak zal raadplegen:
Houd elke pagina gefocust op één beslissing. Je kunt later altijd uitbreiden.
Voor gebruikers die een trial willen starten, zijn bewijs en vertrouwen belangrijk. Voeg vroeg eenvoudige geloofwaardigheidssignalen toe:
Zodra de kernpagina's bestaan, voeg pagina's toe die bij je verkoopproces passen:
Deze pagina's moeten wrijving wegnemen: duidelijke formuliervelden, verwachtingen (“we reageren binnen 1 werkdag”) en vervolgstappen.
Je documentatie moet een nieuwe gebruiker snel laten slagen:
Voeg deze toe zodra de basis stabiel is: changelog (/changelog), optionele roadmap, about en careers. Ze helpen met transparantie, werving en gebruikersvertrouwen — zonder je initiële lancering te blokkeren.
Je techstack moet passen bij hoe vaak content verandert, wie publiceert en of de site app-achtige gedrag nodig heeft. Voor de meeste SaaS-teams is de sweet spot een marketingsite + docs die snel aanvoelt, eenvoudig te updaten is en niet voor elke tekstwijziging engineers nodig heeft.
Een SSG (zoals Next.js static export, Astro, Docusaurus, Hugo) bouwt pagina's vooraf. Dit is een goede match wanneer je marketingpagina's en docs grotendeels voorspelbaar zijn.
Gebruik een statische aanpak wanneer je wilt:
Het is ook een schone manier om docs in Markdown te houden en toch zoek- en versiefunctionaliteit te ondersteunen.
Een server-rendered setup (of een volledige app) loont wanneer de website zich als een productervaring moet gedragen.
Kies dit als je nodig hebt:
Je kunt nog steeds de meeste marketingpagina's statisch genereren en alleen de echt dynamische delen server-renderen.
Een CMS-gestuurde site werkt goed als niet-technische teams vaak publiceren en gestructureerde content (prijsniveaus, klantverhalen, vergelijkingstabellen) met consistentie nodig hebben.
Markdown/MDX is ideaal voor docs: snel te schrijven, makkelijk te reviewen in Git en vriendelijk voor versioning. CMS-velden zijn goed voor gestructureerde marketingcontent waar consistentie belangrijk is.
Zet vanaf dag één drie omgevingen op:
Die workflow houdt publiceren veilig, zelfs wanneer marketing en docs wekelijks wijzigingen publiceren.
Als je nog sneller wilt beginnen, kunnen platforms zoals Koder.ai je helpen het initiële marketing- + docs-ervaring te prototypen vanuit een simpele chat — en daarna de broncode exporteren naar een traditioneel pipeline zodra je structuur, navigatie en kernpagina's gevalideerd zijn.
Goed design voor een SaaS-site heeft een split personality: marketingpagina's moeten overtuigen en gebruikers naar een volgende stap leiden, terwijl docs wrijving verminderen en gebruikers snel laten slagen. De truc is om beide als één product te laten voelen.
Voordat je pagina's bouwt, definieer een klein designsystem: typografieschaal, kleurpalet, spacingregels en een handjevol kerncomponenten (buttons, alerts, cards, tabs). Dit voorkomt dat je marketingpagina's “ontworpen” voelen terwijl je docs “standaard” lijken.
Een praktische aanpak: kies 2–3 fontgroottes voor body + headings, één primaire merk-kleur en een neutrale schaal voor randen en achtergronden. Standaardiseer spacing (bijv. 8px-stappen) zodat layouts consistent blijven over landingspagina's en docs.
Maak herbruikbare paginablokken die je als bouwstenen kunt samenstellen:
Wanneer deze secties spacing, typografie en knopstijlen delen, voelt je site samenhangend aan naarmate content groeit.
Docs-UX draait om leesbaarheid. Gebruik een duidelijke kophiërarchie, royale line-height en een contentbreedte die lange zinnen én brede codeblokken ondersteunt. Laat codeblokken horizontaal scrollen in plaats van regels wrappen in onleesbare lijnen. Houd pagina's scanbaar met korte intro's, “before you start”-notities en callouts voor waarschuwingen.
Behandel toegankelijkheid als basis:
Op mobiel test je twee dingen vroeg: het topnavigatiemenu en de docs-zijbalk. Als een van beide moeilijk te openen, sluiten of begrijpen is, haken gebruikers vaak af — vooral als ze snel een probleem willen oplossen.
Goede SaaS-sites beschrijven niet alleen een product — ze leiden de lezer van nieuwsgierigheid naar vertrouwen. Dat pad bouw je met duidelijke messaging, eenvoudige copy en doelgerichte calls to action (CTA's) die passen bij wat iemand op die pagina wil doen.
Bepaal voor je schrijft wat succes is per pagina. Geef elke belangrijke pagina een primaire CTA (het belangrijkste wat je wilt) en een secundaire CTA (een minder zware vervolgstap).
Voorbeelden:
Houd CTA-tekst en plaatsing consistent zodat bezoekers de site niet op elke pagina opnieuw hoeven te leren.
Begin met de uitkomsten die de klant belangrijk vindt en leg dan kort uit hoe jij die levert. Vervang vage beweringen (“streamline your workflow”) door concrete resultaten (“verminder onboardingtijd van dagen naar uren”).
Vermijd jargon waar mogelijk. Als je vaktermen moet gebruiken, definieer ze in gewone taal. Korte zinnen winnen — vooral voor headings, subheads en knoptekst.
Plaats bewijs dicht bij belangrijke beslissingen (features, pricing, signup). Gebruik cijfers alleen als je ze kunt verifiëren en geef context:
Balans metrics met menselijk bewijs: quotes, mini-case studies en echte workflowvoorbeelden.
Onduidelijke prijzen blokkeren aanmeldingen. Vermeld plan-namen, kernlimits, add-ons en wat er gebeurt als een gebruiker een limiet overschrijdt. Voeg een FAQ toe die bezwaren beantwoordt (security, facturatie, annulering, support).
Waar je een feature beschrijft, link direct naar de meest relevante handleiding: “Zie hoe het werkt” → /docs/getting-started of /docs/integrations/slack. Dit bouwt vertrouwen en vermindert pre-sales vragen — en houdt de lezer in beweging.
Goede docs voelen “voor de hand liggend” aan. Het geheim is een voorspelbare structuur en navigatie die op elke pagina twee vragen beantwoordt: Waar ben ik? en Wat lees ik hierna?
Bouw een docs-zijbalk met een klein aantal categorieën, gelabeld in gewone taal. Organiseer op taken en uitkomsten in plaats van interne teamnamen.
Veelvoorkomende top-level categorieën:
Houd labels consistent met hoe je product dingen noemt. Als je UI “Workspaces” zegt, noem ze dan niet “Projects” in de docs.
Op langere pagina's plaats je een on-page inhoudsopgave bovenaan zodat lezers direct naar de juiste sectie springen. Voeg Next/Previous-links onderaan toe om een soepele leesroute te stimuleren — vooral door setup- en onboardingsequenties.
Consistentie is een feature. Gebruik één gidstemplate zoals:
Problem → Steps → Expected result → Troubleshooting
Dat patroon helpt lezers snel te scannen en maakt het makkelijker voor je team om nieuwe artikelen te schrijven zonder de structuur opnieuw uit te vinden.
Voeg lichte feedbackopties op elke pagina toe: een “Was dit nuttig?”-controle en een duidelijke link om contact op te nemen met support (bijvoorbeeld /contact of /support). Feedback houdt docs in lijn met echte vragen en geeft gefrustreerde lezers een snelle uitweg zonder te moeten zoeken.
Een SaaS-site verandert constant: prijsaanpassingen, nieuwe features, docs-fixes en productaankondigingen. Het doel is updates makkelijk te maken voor mensen, terwijl de site voorspelbaar blijft voor navigatie, zoekfunctie en SEO.
Behandel elk paginatype als gestructureerde content. Als je Markdown/MDX gebruikt, definieer consistente front matter zodat pagina's gelijst, doorzocht en correct weergegeven kunnen worden.
Veelvoorkomende velden om te standaardiseren:
title (wat in de paginakop verschijnt)description (meta + cards)tags of category (groepering en filtering)last_updated (vertrouwenssignaal voor docs)sidebar_position (docs-volgorde)Consistentie voorkomt “mystery pages” die niet in menu's verschijnen of verkeerd renderen in lijsten.
Een lichte pipeline vermindert fouten:
Draft → Review → Publish
Drafts kunnen in een branch (Git) of in een headless CMS gemaakt worden. Reviews moeten helderheid, correctheid en of links/CTA's nog naar de juiste plekken wijzen controleren (bijv. /pricing of /docs).
Vermijd het goedkeuren van veranderingen op basis van geplakte tekst of screenshots. Gebruik preview-links zodat reviewers de pagina in context zien (navigatie, mobiele layout en cross-links).
Typische opties:
Leg beslissingen één keer vast: voice, kophiërarchie, code/voorbeeldconventies en hoe screenshots moeten worden gemaakt en bijgewerkt. Dit maakt docs samenhangend, zelfs als meerdere mensen bijdragen.
Bepaal wie wat bezit:
Kies ook een beslisser voor gedeelde pagina's (homepage, navigatielabels) zodat wijzigingen niet vastlopen.
SEO wordt makkelijker wanneer marketingpagina's en docs op één site staan: je bouwt autoriteit, deelt interne links en voorkomt dat signalen over subdomeinen verdeeld raken.
Begin met fundamenten op elke indexeerbare pagina:
Maak een simpele regel voor URL's en links: gebruik altijd relatieve paden (bijv. /pricing, /docs/api/auth). Dit houdt omgevingen (staging, productie) consistent en vermindert gebroken links.
Het grootste risico bij gecombineerde sites is dat dezelfde uitleg op meerdere plekken voorkomt (bijv. “Hoe SSO werkt” op een featurepagina en in docs).
Als overlap onvermijdelijk is:
Voeg schema alleen toe als het accuraat is:
Bouw clusters waarbij blogposts brede vragen beantwoorden en lezers naar de volgende stap leiden:
Deze structuur helpt zowel rankings als conversies — zonder docs salesy te laten klinken.
Een SaaS-site die marketingpagina's en docs mixt moet snel en betrouwbaar aanvoelen. Kleine regressies (een zware script, een nieuw lettertype, een te grote screenshot) tellen snel op.
Stel een paar meetbare doelen en controleer ze bij elke release:
Optimaliseer wat gebruikers eerst downloaden:
font-display: swap en overweeg zelf-hosting om derde-partij requests te verminderen.Overweeg ook caching en levering: serveer statische assets met lange cache-headers en gebruik een CDN als je hosting dat niet al doet.
Verzamel alleen wat je nodig hebt. Als je vragen met minder tools kunt beantwoorden, doe dat.
Voeg lichte monitoring toe en link naar een statuspagina als je die hebt (bijv. /status). Als je die niet hebt, bied dan ten minste een incident-updatepad (footerlink naar je supportpagina) zodat gebruikers weten waar ze moeten kijken als er iets kapot gaat.
Een SaaS-site met marketingpagina's en docs is nooit “klaar”. De snelste manier om hem te verbeteren is kijken hoe mensen hem daadwerkelijk gebruiken: wat ze zoeken, waar ze vastlopen en welke pagina's aanmeldingen opleveren.
Begin met een basis site-brede zoekfunctie die zowel marketingpagina's als documentatie dekt. Zelfs een eenvoudige oplossing is beter dan geen — vooral bij docs-zware producten.
Als het live is, evalueer zoekgedrag regelmatig en stem bij op basis van bewijs. De grootste vroege winst is het oplossen van “geen resultaten”-queries door ontbrekende pagina's, synoniemen of betere koppen toe te voegen.
Docs-search verschilt van marketing-search. Mensen zijn taakgericht en ongeduldig, dus kleine UX-details doen ertoe:
Pageviews alleen vertellen je niet wat werkt. Meet events die beslissingen representeren:
Zorg dat marketing en support de data vertrouwen. Houd naamgeving consistent en documenteer het in een eenvoudige interne pagina (bijv. /docs/analytics-events).
Zet lichte dashboards op voor twee doelgroepen:
Sluit dan de lus: zet terugkerende supporttickets en veelvoorkomende zoekopdrachten om in doc-updates, nieuwe voorbeelden of verbeterde troubleshooting-secties. Na verloop van tijd wordt je docs een zelfhelend systeem dat support vermindert en conversies verhoogt.
Een goede SaaS-website-lancering is geen “publish and hope”. Het is een gecontroleerde release met checks die gênante issues (gebroken pagina's, ontbrekende metadata, dode signup-links) vangen voordat klanten ze zien — en een onderhoudsroutine die voorkomt dat marketingpagina's en docs verouderen.
Voordat je iets aankondigt, doe één volledige controle die focust op integriteit en indexering:
Als je migreert vanaf een oude site, maak dan een eenvoudige spreadsheet met oude URL → nieuwe URL en bewaar die naast je repo zodat toekomstige wijzigingen het originele plan niet overschrijven.
Klik niet alleen wat rond. Test de “jobs” die marketing en docs verbinden:
Behandel deze als releaseblockers. Als een flow faalt, voel je dat onmiddellijk in conversies en supportvolume.
Redirects zijn niet alleen voor migraties. SaaS-sites evolueren voortdurend: je hernoemt features, herstructureert docs en herschrijft productpagina's.
Maak één regel: verwijder nooit een URL zonder ofwel (a) die te redirecten of (b) bewust een 410 terug te geven voor content die je écht weg wilt hebben. Voor docs zijn redirects vrijwel altijd de juiste keuze.
Stem ook een toekomstgerichte URL-policy af (bijv. vermijd versienummers in URL's tenzij je docs echt gaat versioneren). Dat houdt toekomstige refactors kleiner.
Lanceringdag heeft een lichte planning:
Als het mogelijk is, houd dan een “hotfix window” open met het team voor de eerste 24–48 uur.
Een eenvoudige cadans voorkomt langzaam verval:
Een website is een productoppervlak. Behandel het als zodanig: blijf continu verbeteren en meet de impact.
Begin met het schrijven van één zin die beide uitkomsten bevat, bijvoorbeeld: “Converteer gekwalificeerde prospects terwijl je klanten in staat stelt zelf ondersteuning te vinden.” Wijs daarna voor elke pagina een primaire taak toe:
De meeste gecombineerde SaaS-sites bedienen minimaal vier groepen:
Als je het publiek voor een pagina niet kunt noemen, herschrijf dan de scope van de pagina totdat je dat wel kunt.
Gebruik een klein aantal top-level secties en zet de rest in de footer:
De globale navigatie blijft marketinggericht; de docs-navigatie hoort in de docs-zijbalk (Getting started, Guides, API, Troubleshooting).
Voor de meeste SaaS-producten is hosten onder /docs de beste standaard:
Kies een apart subdomein alleen als je docs echt andere tooling, permissies of een aparte onderhoudsworkflow vereisen die anders iedereen zou vertragen.
Behandel URL's als beloften:
/docs/sso)/docs/integrations/slack)Plan URL-conventies vroeg, vooral als je later docs gaat versioneren.
Lever de pagina's die antwoorden op: Wat is het? Kan ik het vertrouwen? Wat doe ik nu?
Minimale marketingset:
Minimale docs-set:
Kies op basis van wie content bijwerkt en hoe vaak:
Een veelvoorkomend hybride model: Markdown/MDX voor docs + CMS-velden voor gestructureerde marketingcontent.
Geef iedere belangrijke pagina een primaire en secundaire CTA en houd wording consistent:
Gebruik een voorspelbare docs-structuur en templates:
Standaardiseer een template zoals Problem → Steps → Expected result → Troubleshooting zodat elke pagina vertrouwd aanvoelt.
Meet gedrag dat aan uitkomsten gekoppeld is, niet alleen pageviews:
Bekijk dit maandelijks en zet terugkerende zoekopdrachten en tickets om in doc-updates, nieuwe troubleshooting-items en betere interne links (bijv. van features naar /docs/getting-started en terug naar ).
Zet bewijs (logo's, testimonials, case studies) dicht bij beslissingspunten om aarzeling te verminderen.
/pricing