16 mei 2025·8 min
Hoe je een website maakt voor SaaS-changelog en release-opmerkingen
Leer hoe je een SaaS-changelog en release notes-website maakt: structuur, schrijftips, categorieën, zoeken, abonnementen, SEO en onderhoudsstappen.
Leer hoe je een SaaS-changelog en release notes-website maakt: structuur, schrijftips, categorieën, zoeken, abonnementen, SEO en onderhoudsstappen.
Een SaaS changelog-site is een openbare pagina (of minisite) waar je productupdates publiceert in een consistente, makkelijk bladerbare archief. Zie het als je “wat is er veranderd, wanneer en waarom” thuisbasis — vooral waardevol voor klanten die dagelijks op je app vertrouwen.
Gebruikers zoeken naar een changelog wanneer iets anders voelt (“Waar is die knop gebleven?”), wanneer ze beslissen of ze een functie willen inschakelen, of wanneer ze beoordelen hoe actief het product onderhouden wordt. Een duidelijke updategeschiedenis vermindert verwarring en helpt mensen vertrouwen te houden in wat ze gebruiken.
Deze termen worden vaak door elkaar gehaald, maar ze hebben licht verschillende rollen:
Veel SaaS-teams publiceren beide op dezelfde site: een korte samenvatting bovenaan, met uitklapbare details voor wie dat nodig heeft.
Een goed beheerde changelog-site ondersteunt meerdere doelen tegelijk:
Beslis wat klantgericht is versus intern. Openbare notities moeten focussen op impact voor gebruikers, gevoelige details vermijden en eenvoudige taal gebruiken. Interne notities mogen technischer zijn (bijv. infrastructuurwijzigingen) en horen in je interne docs — niet op je publieke changelog.
Voordat je een sjabloon kiest of begint te publiceren: bepaal voor wie de changelog is. Een enkele “release notes-pagina” probeert vaak iedereen te bedienen — en helpt uiteindelijk niemand.
De meeste SaaS-changelogs hebben minstens drie doelgroepen, elk met andere informatiebehoefte:
Je kunt ook een interne doelgroep hebben (Support, CS, Sales). Zelfs als de changelog openbaar is, bespaart schrijven met intern hergebruik in gedachten tijd: support kan naar een specifieke entry linken in plaats van uitleg te herschrijven.
Pas de schrijfstijl aan op productcomplexiteit en verwachtingen van gebruikers:
Houd de voice consistent: als je UI vriendelijk is, kan de changelog ook vriendelijk zijn — zonder te informeel of vaag te worden.
Een publieke productupdates-pagina helpt met transparantie, vertrouwen en deelbare links. Een login-only changelog kan beter zijn als je gevoelige enterprise-functies, klant-specifiek werk of beveiligingsdetails uitrolt die niet geïndexeerd mogen worden.
Als je twijfelt: publiceer openbaar maar reserveer bepaalde items voor geauthenticeerde gebruikers.
Definieer wat “goed” betekent. Veelgebruikte doelen zijn minder “wat is er veranderd?” tickets, snellere adoptie en hogere feature-usage. Kies één of twee meetpunten (supportticketvolume, feature-activatiepercentage, paginaweergaven van de changelog) en beoordeel ze maandelijks zodat de changelog nuttig blijft — en niet alleen druk.
Een changelog werkt alleen als mensen het consequent kunnen vinden — en snel bij de update komen die hen raakt. Schets voordat je één release note schrijft de pagina's en paden die gebruikers vanaf je hoofddomein, app en helpcenter nemen.
Voor de meeste SaaS-producten heb je geen complexe informatiearchitectuur nodig. Begin met een klein aantal voorspelbare URL's:
Als je nog minder pagina's wilt, kun je /subscribe samenvoegen met /changelog als een vaste call-to-action.
Plaats je changelog waar gebruikers het al verwachten:
Welke optie je ook kiest: houd de URL kort, permanent en makkelijk te typen.
Voeg een duidelijke link naar de changelog toe vanaf:
Stel standaard een latest-first lijst in zodat gebruikers direct zien wat nieuw is. Bied daarna browsen met eenvoudige filters (bijv. per productgebied of “Bug fixes” vs “New”). Dit combineert snelheid voor gelegenheidslezers met controle voor wie naar een specifieke wijziging zoekt.
Een goede release note is voorspelbaar: lezers moeten in de eerste regels meteen begrijpen wat er is veranderd, wanneer en of het hen raakt. Bepaal voordat je schrijft een klein aantal verplichte velden en houd je daar aan bij elk bericht.
Als je deze velden consequent houdt, wordt je release notes-pagina een betrouwbaar index in plaats van een ongestructureerde stroom mededelingen.
Gebruik versies als je build-gebaseerde software uitbrengt of als support een precies referentiepunt nodig heeft (mobiele apps, desktop apps, API-versies, self-hosted). Een gebruiker die een bug meldt kan zeggen “Ik zit op 2.14.3,” en je team kan het reproduceren.
Gebruik datum-gebaseerde releases als je continu uitrolt en veranderingen achter feature flags plaats vinden. Veel SaaS-teams voegen intern nog een buildnummer toe, maar tonen openbaar de releases op datum omdat dat makkelijker is voor klanten.
Een hybride werkt goed: toon een datum als primaire anker en geef een versie/build in kleinere tekst voor support.
Optionele velden zijn waardevol, maar alleen als ze doelgericht blijven:
Title
Date • Version • Category • Affected area (optional)
Summary (1–2 sentences)
Details
- Bullet 1
- Bullet 2
Rollout status (optional)
Known issues (optional)
Deze structuur houdt elk item leesbaar, maakt filteren later makkelijker en zet je klaar voor consistente tags en zoekfuncties.
Een changelog is het makkelijkst te scannen wanneer elke update twee vragen snel beantwoordt: wat voor soort wijziging is dit? en welk deel van het product raakt het? Categorieën en tags doen dat — zonder dat mensen elk bericht hoeven te lezen.
Gebruik een kleine taxonomie die de meeste releases dekt en consistent blijft over tijd:
Houd categorieën beperkt. Als een wijziging niet past, pas dan de formulering van de notitie aan voordat je een nieuwe categorie verzint.
Tags moeten beschrijven waar de wijziging is gebeurd, met woorden die klanten al herkennen uit je UI en docs. Veelvoorkomende voorbeelden zijn Billing, API, Dashboard en Mobile.
Een goede vuistregel: elk bericht krijgt 1–3 tags. Genoeg om te filteren, niet genoeg om te overweldigen.
Tag-spread maakt filters nutteloos. Stel lichte richtlijnen op:
Mensen zoeken op de woorden die ze in het product zien. Gebruik dezelfde feature-namen in UI, helpdocs en notities (bijv. “Saved Views”, niet in het ene “View Presets” en in het andere “Saved Filters”). Overweeg een korte interne naamgevingsgids zodat iedereen updates met hetzelfde vocabulaire publiceert.
Release notes zijn geen dagboek van wat je team bouwde — ze zijn een gids voor wat er voor gebruikers is veranderd. Het doel: mensen snel laten begrijpen wat de waarde is, of ze getroffen worden en wat (indien van toepassing) ze moeten doen.
Een goede titel beantwoordt in één regel “waarom zou ik dit belangrijk vinden?”
Slecht: “Project Falcon rollout”
Beter: “Snellere factuurexports (tot 3× sneller)”
Beter: “Nieuw: dashboards delen met view-only links”
Voeg bij extra context een korte subtitel toe die gebruikergeoriënteerd blijft: “Beschikbaar voor Pro- en Business-plannen.”
Begin met 2–5 korte bullets zodat gebruikers snel kunnen scannen. Voeg daarna een Details-paragraaf toe voor het “wat/waarom/hoe” context.
Voorbeeldstructuur:
Details: Je kunt nu een beveiligde link genereren om een dashboard te delen zonder een nieuwe gebruiker aan te maken. Links kunnen op elk moment worden ingetrokken via Instellingen → Delen.
Neem dit op wanneer de wijziging gedrag, permissies, facturering of workflows beïnvloedt.
Wie is getroffen? Beheerders die deelinstellingen beheren; iedereen die gedeelde links ontvangt.
Wat moet ik doen? Standaard niets. Wil je delen beperken, schakel dan “Publieke links” uit in Instellingen → Delen.
Schrijf in gebruikerswoorden, niet in interne projectlabels. Vervang “gemigreerd naar v2 pipeline” door “uploads zijn betrouwbaarder” (en leg uit hoe dat de gebruikerservaring verandert). Als je een technisch woord moet noemen, definieer het in één korte zin.
Kies duidelijkheid boven volledigheid: als het niet actiegericht of betekenisvol is voor gebruikers, laat het weg.
Een changelog is gemakkelijk te scannen met vijf posts. Heb je er vijftig, dan wordt het “Ik weet dat je het hebt uitgebracht… maar waar is het?” Zoek- en browsehulpmiddelen houden je pagina nuttig, vooral voor supportteams, klanten die je product evalueren en iedereen die later een specifieke fix zoekt.
Voeg bovenaan de changeloglijst een opvallend zoekveld toe. Geef prioriteit aan zoeken in titels, tags en de eerste alinea van elk bericht. Overweeg matches te markeren en veelvoorkomende zoekopdrachten te ondersteunen zoals feature-namen, integraties (“Slack”) of foutcodes.
Als je changelog meerdere producten of modules heeft, laat dan zoeken binnen een geselecteerd productgebied toe om ruis te verminderen.
Filters moeten het vocabulaire van gebruikers gebruiken, niet interne teamnamen.
Nuttige filters zijn onder meer:
Maak filters bij voorkeur multi-select en maak de “wis alles” knop duidelijk.
Voor langere release notes, voeg ankerlinks bovenaan toe (bijv. New features, Improvements, Fixes). Voeg ook “Kopieer link” ankers bij koppen zodat support gebruikers naar de exacte sectie kan verwijzen.
Gebruik paginering of “Laad meer” na een redelijke hoeveelheid posts (10–20) en toon het totaal aantal. Houd pagina's snel: server-render de lijst, lazy-load zware elementen en vermijd complexe client-side filtering die blokkeert bij grote archieven. Snel laden zorgt dat bladeren betrouwbaar aanvoelt.
Een changelog is het meest nuttig als mensen het niet zelf hoeven te onthouden. Abonnementen maken van je release notes-pagina een lichte communicatiemethode — zonder gebruikers te verplichten tot sociale media of supporttickets.
Streef naar drie opties:
Plaats duidelijke calls-to-action bovenaan de pagina (boven de lijst met items): “Subscribe” en “View latest updates.” Als je een aparte updates-index hebt, verwijs er ook naar (bijv. /changelog).
Als het kan, bied Direct, Wekelijks en Maandelijks aan. Direct werkt goed voor kritieke wijzigingen en snel bewegende producten; samenvattingen zijn beter voor drukbezette stakeholders.
Abonnementen zijn waardevoller als gebruikers kunnen filteren wat ze ontvangen. Als je changelog tags of categorieën gebruikt (zoals Billing, API, Security, Mobile), laat abonnees kiezen welke gebieden ze willen volgen — en vertel hoe ze later voorkeuren kunnen aanpassen in de e-mailvoettekst.
Als je een feed publiceert, houd het voorspelbaar en gemakkelijk te onthouden, zoals /rss (of /changelog/rss). Toon het naast de Subscribe-knop en label het duidelijk (“RSS feed”) zodat niet-technische gebruikers weten dat het optioneel is.
Een changelog helpt alleen als mensen het kunnen vinden — via zoekmachines, je in-app links en zelfs “site:yourdomain.com” queries van supportteams. Goede SEO is hier geen marketingtruc; het draait om duidelijkheid en consistentie.
Behandel elk releasebericht als een eigen pagina met een beschrijvende titel die overeenkomt met wat gebruikers zoeken (en wat ze in browsertabbladen scannen). Gebruik schone, leesbare URL's die later niet veranderen.
Voorbeeld:
/changelog/new-permissions-controlsVoeg een unieke meta description per bericht toe. Houd het simpel: wat is er veranderd, wie wordt geraakt en wat is het belangrijkste voordeel.
Je changelogpagina moet een duidelijke structuur hebben:
Toon altijd een zichtbare publicatiedatum (en gebruik een consistent formaat). Zoekmachines en gebruikers vertrouwen op datums voor actualiteit en context.
Zelfs kleine releases moeten twee vragen beantwoorden: wat is er veranderd en waarom het belangrijk is. Als er setup voor nodig is, link naar ondersteunende docs (relatief), zoals /docs/roles-and-permissions of /guides/migrate-api-keys.
Maak een changelog indexpagina (bijv. /changelog) die releases lijst met titels, datums, korte samenvattingen en paginering. Dit helpt indexering, maakt oudere updates vindbaar en voorkomt dat waardevolle notities verdwijnen in een oneindige scroll.
Een changelog is alleen nuttig als mensen het snel kunnen scannen, begrijpen wat er is veranderd en er zonder frictie doorheen kunnen navigeren. Goed ontwerp draait hier om duidelijkheid, niet om decoratie.
Gebruik leesbare typografie: een comfortabel lettergrootte (16–18px voor bodytekst), duidelijke regelhoogte en sterk contrast tussen tekst en achtergrond. Release notes bevatten vaak veel details, dus royale tussenruimte helpt gebruikers koppen, datums en bullets te scannen zonder de draad te verliezen.
Houd koppen consistent (bijv. versie/datum → samenvatting → details). Vermijd lange, volle breedte paragrafen; korte blokken lezen beter op desktop en mobiel.
Maak de changelog bruikbaar zonder muis. Zorg dat alle interactieve elementen — zoeken, filters, tag-chips, “Laad meer” en paginering — bereikbaar zijn met de Tab-toets in een logische volgorde.
Gebruik toegankelijke labels op links en knoppen. “Lees meer” moet bijvoorbeeld “Lees meer over API-verbeteringen” worden zodat het buiten context ook zinvol is. Als je icoon-only knoppen hebt (zoals een filter-icoon), voeg een aria-label toe.
Als je screenshots toevoegt, geef alt-tekst die beschrijft wat er is veranderd, niet hoe de afbeelding eruitziet (bijv. “Nieuwe wisselknop voor jaarlijkse plannen in de billing-instellingen”). Vermijd afbeeldingen met alleen tekst: als de enige manier om de update te lezen een screenshot is, zijn veel gebruikers uitgesloten.
Gebruik eenduidige datumnotatie zoals 2025-12-26. Dit voorkomt verwarring voor internationale gebruikers en helpt support teams releases nauwkeurig te refereren.
Je filters en tabellen moeten op kleine schermen werken. Geef de voorkeur aan responsieve layouts waarbij filters inklappen in een paneel, tags netjes doorlopen en tabellen opgestapelde kaarten worden wanneer nodig. Als gebruikers op mobiel “Bug fixes” niet snel vinden, denken ze dat de changelog niet onderhouden wordt.
Een changelog verdient vertrouwen als het voorspelbaar is. Dat betekent niet dat het vaak moet zijn — het betekent dat gebruikers weten wat ze kunnen verwachten: hoe updates worden geschreven, wie goedkeurt en wat er gebeurt als iets na publicatie verandert.
Je workflow begint bij het platform:
Kies wat past bij jullie gewoonten. Het “beste” gereedschap is degene die je daadwerkelijk gebruikt.
Als je zelf bouwt, kan een vibe-coding platform zoals Koder.ai het initiële implementatietraject versnellen: je beschrijft de pagina's die je wilt (bijv. /changelog, zoeken, tags, RSS, e-mailsubscribe) in chat en genereert een werkende React-frontend met een Go + PostgreSQL backend. Dat is vooral handig als je een aangepaste changelog-ervaring wil zonder weken aan engineeringtijd te besteden.
Houd fases expliciet zodat niets in iemands hoofd blijft hangen. Een veelgebruikte, lichte flow is:
Draft → Review → Approve → Publish → Update (indien nodig)
Schrijf kort op wat elke fase betekent (één zin is genoeg) en waar het werk gebeurt (doc, issue, CMS-draft, pull request). Consistentie is belangrijker dan formaliteit.
Als je gefaseerde releases doet, geef dat dan duidelijk aan:
Dit voorkomt “Ik heb deze functie niet” supporttickets en vermindert frustratie.
Bewerkingen zijn normaal — stille herschrijvingen niet. Beslis:
Wijs rollen toe zodat de changelog niet “ieders taak” wordt (en dan niemand's): wie schrijft, wie keurt en wie categorieën/tags onderhoudt over tijd.
Een changelog verdient z'n plek als het gebruikt wordt — en als het in de loop der tijd betrouwbaar blijft. Een lichte meet- en onderhoudsstrategie helpt je zien wat gebruikers belangrijk vinden, support te verminderen en oudere notities netjes te houden.
Begin met een paar signalen waarop je kunt reageren:
Als je een “What’s new”-link in het product hebt, meet dan de click-through rate naar je release notes-pagina en welke items gebruikers openen.
Je changelog kan terugkerende vragen verminderen — als het ze duidelijk beantwoordt. Na elke grote release let op:
Als ticketvolume niet daalt, zie het als een schrijfvraag (ontbrekende context, onduidelijke impact) of een ontdek-probleem (gebruikers vinden de relevante notitie niet).
Elk item moet lezers een volgende stap geven:
Houd feedback licht. Eén open tekstvak werkt vaak beter dan complexe enquêtes.
Maandelijks (of per kwartaal voor kleinere producten):
Verwijder geen historie. Doe in plaats daarvan:
Een goed onderhouden archief bouwt geloofwaardigheid op — en voorkomt dat je team dezelfde veranderingen steeds opnieuw moet uitleggen.
Een SaaS changelog-site is een openbare pagina (of kleine site) die een doorlopende, gemakkelijk doorzoekbare archief bijhoudt van productupdates — wat er is veranderd, wanneer en kort waarom het relevant is. Het helpt gebruikers te bepalen of iets een bug is of een bewuste wijziging en laat zien dat het product actief onderhouden wordt.
Changelog-regels zijn meestal kort en makkelijk scanbaar (bijv. Added, Improved, Fixed, Deprecated) en beantwoorden “Wat is er geleverd?”. Release notes geven extra context en instructies — wie erdoor wordt geraakt, hoe je de wijziging gebruikt en of er acties nodig zijn — en beantwoorden “Wat betekent dit voor mij?”. Veel teams publiceren beide op dezelfde pagina: eerst een samenvatting en daaronder uitklapbare details.
Een goed beheerde changelog kan:
Als je maar één ding meet: begin met het aantal tickets rond grote wijzigingen.
De meeste producten bedienen meerdere doelgroepen:
Schrijf eerst voor de primaire doelgroep en voeg optionele secties toe (zoals “Wie is getroffen?”) wanneer dat nodig is.
Standaard: openbaar wanneer transparantie en deelbare links belangrijk zijn. Kies login-only als notities gevoelige enterprise-functies, klant-specifiek werk of beveiligingsdetails bevatten die niet geïndexeerd mogen worden.
Een praktische middenweg is de hoofdpagina openbaar te houden en bepaalde berichten alleen voor geauthenticeerde gebruikers te markeren.
Houd de structuur eenvoudig en makkelijk te onthouden:
Link ernaar vanuit je footer, het in-app helpmenu en de helpcenter-startpagina zodat gebruikers het snel vinden.
Een voorspelbare “altijd opnemen” set ziet er meestal zo uit:
Gebruik versies als support precisie nodig heeft (mobile/desktop apps, API's, self-hosted) zodat gebruikers kunnen zeggen “Ik zit op 2.14.3.” Gebruik datum-gebaseerde releases bij continue levering en feature-flag uitrol.
Een goede hybride is datum-eerst voor leesbaarheid, met build/versie in kleinere tekst voor support.
Begin met een klein, stabiel categorie-set (bv. New, Improved, Fixed, Deprecated, Security) en voeg productgebied-tags toe die overeenkomen met de woorden die gebruikers in de UI zien (Billing, API, Dashboard, Mobile).
Om tag-spread te voorkomen:
Bied meerdere manieren om updates te volgen:
Laat gebruikers indien mogelijk kiezen tussen , of , en bied tag-/categorie-voorkeuren zodat ontvangen updates relevant blijven.
Consistentie maakt je changelog tot een betrouwbaar index in plaats van een stroom aankondigingen.