Statisch of dynamisch: wat betekent dat voor het beheer van je website?

Een statische website levert vooraf gemaakte pagina’s. Een dynamisch opgebouwde pagina wordt op het moment van een verzoek samengesteld. Dat onderscheid vertelt nog niet wie teksten kan aanpassen of welke functies bezoekers kunnen gebruiken. Ook een statisch geleverde website kan een CMS, zoekfunctie en aanvraagformulier hebben. De bruikbare vraag is: welke informatie moet wanneer veranderen, voor wie en onder wiens controle?

Bij statische levering staat de pagina al klaar voordat de bezoeker hem opvraagt. Bij dynamische generatie maakt een server de pagina op basis van het verzoek, eventueel met gegevens uit een database. MDN beschrijft deze twee manieren van pagina’s uitleveren. In een moderne website kunnen ze naast elkaar bestaan.

Een belangrijke valkuil is het woord dynamisch. Het kan slaan op een bewegend scherm, een pagina met CMS-inhoud of informatie die persoonlijk wordt opgehaald. Dat zijn verschillende eigenschappen. Vraag een leverancier daarom welk gedrag hij bedoelt, in plaats van alleen een vinkje achter “dynamische website” te zetten.

1. Bewerken. Wie voert teksten, afbeeldingen en productinformatie in? Is er een redactieomgeving, met de juiste velden, rechten en een voorbeeldweergave?
2. Publiceren. Wanneer wordt goedgekeurde informatie zichtbaar? Worden pagina’s opnieuw opgebouwd, wordt een cache vernieuwd of wordt de inhoud bij ieder bezoek opgehaald?
3. Gebruiken. Wat doet de bezoeker? Lezen, zoeken, een aanvraag sturen, inloggen of een bestelling plaatsen? Welke dienst controleert en bewaart die handelingen?

Een CMS bepaalt hoe je inhoud beheert. Het schrijft niet automatisch voor hoe de bezoeker die inhoud ontvangt. De CMS-documentatie van Astro laat bijvoorbeeld zien hoe een aparte redactieomgeving inhoud aan de website levert. Dezelfde frontend kan vooraf gemaakte en op verzoek opgebouwde routes combineren. Dit is een technisch voorbeeld, geen reden om ieder project op dat platform te bouwen.

Laat in een offerte dus zowel de redactionele werkwijze als de publicatiestappen beschrijven. “Zelf te beheren” zegt weinig wanneer je voor een nieuwe dienstpagina alsnog een ontwikkelaar nodig hebt, of wanneer niemand kan zien waarom een wijziging niet live komt.

Niet iedere wijziging vraagt om een volledig dynamische site. Een dagelijks aangepast artikel kan via een publicatiestap goed werken. Omgekeerd mag een klantprijs niet als publieke informatie in een vooraf gebouwde pagina terechtkomen. Begin bij de betekenis van de gegevens en de gevolgen van veroudering; kies daarna de techniek.

Voor SAMEN Eten & Drinken combineerden we aanbod- en prijspagina’s met een reserveringssysteem op maat. Een high tea vraagt andere gegevens dan een bedrijfsborrel, dus kregen die aanvragen eigen formulieren. De taak bepaalt welke invoer nodig is; het etiket van de website zegt daar op zichzelf weinig over.

Stel dat een groothandel openbare productuitleg toont, terwijl vaste klanten hun eigen prijzen zien en bestellingen terugvinden. Dit is een fictief voorbeeld om de afweging zichtbaar te maken. De productuitleg kan vooraf worden gepubliceerd. Inloggen en persoonlijke prijzen vragen daarnaast om een beveiligde dienst die de klant herkent en zijn rechten controleert.

Als die dienst tijdelijk niet bereikbaar is, kan de openbare productinformatie beschikbaar blijven. De site moet dan duidelijk aangeven dat een actuele prijs niet geladen kan worden. Een oude prijs als zeker presenteren, of de bestelling toch bevestigen, is geen passende noodoplossing. Bij het afronden controleert de backend de geldige prijs en beschikbaarheid opnieuw.

Dat vraagt om afspraken over de overdracht tussen systemen: welk systeem is leidend, hoe worden fouten herkend en wie herstelt ze? Een aantrekkelijk scherm lost die verantwoordelijkheid niet op.

Beoordeel snelheid op echte pagina’s met echte afbeeldingen, scripts en formulieren. Vooraf leveren beperkt het werk dat bij een pagina-aanvraag nodig is, maar een zware video of onnodige scripts kunnen dat voordeel tenietdoen. Ook dynamisch opgebouwde websites kunnen onderdelen cachen. Een label in de offerte vervangt geen meting.

Een statische voorkant maakt beheer en beveiliging evenmin overbodig. Er zijn nog steeds accounts, afhankelijkheden en mogelijk formulieren of gekoppelde systemen. Leg vast wie updates uitvoert, back-ups terugzet en toegangsrechten intrekt. Bespreek dit als onderdeel van onderhoud en doorontwikkeling.

Voor vindbaarheid is relevant of de belangrijke inhoud en links toegankelijk zijn. Google adviseert server-side rendering of vooraf renderen en legt uit dat JavaScript-inhoud extra verwerking kan vragen. “Statisch” of “dynamisch” op zichzelf levert geen hogere positie op. Een technisch uitleesbare pagina moet nog steeds de juiste vraag zorgvuldig beantwoorden.

Vraag niet alleen naar bouwkosten. Neem ook redactie, hosting, licenties, wijzigingen, monitoring en herstel mee. Een beperkte publicatiewebsite kan eenvoudig blijven. Een combinatie van CMS, frontend en meerdere koppelingen kan juist extra afspraken en specialistisch onderhoud vragen. Meer losse systemen zijn niet vanzelf meer vrijheid.

Laat een leverancier benoemen wat een medewerker zelfstandig kan, welke wijzigingen ontwikkelwerk zijn en wat er gebeurt bij een overstap. Vraag naar een inhoudsexport, eigendom van accounts en de procedure voor terugzetten. Zo vergelijk je concrete verplichtingen in plaats van een algemene belofte dat een oplossing goedkoper of toekomstbestendig is.

Kies voor oplevering een representatieve wijziging, bijvoorbeeld een nieuwe dienst met tekst, afbeelding en contactactie. Laat de persoon die later de redactie doet deze taak zelf uitvoeren. Gebruik de volgende controlepunten als acceptatieproef:

1. Kan de redacteur een concept maken en bekijken zonder het al te publiceren?
2. Wie mag goedkeuren en publiceren, en is zichtbaar welke versie online staat?
3. Verschijnt de wijziging binnen de afgesproken tijd op de pagina, in navigatie en op relevante overzichten?
4. Wat gebeurt er bij een mislukte publicatie of verouderde cache? Is de vorige versie veilig terug te zetten?
5. Werken de contactactie en bevestiging op mobiel, en is mislukte verzending herkenbaar?
6. Kan een collega het beheer overnemen met eigen toegang en een begrijpelijke werkinstructie?

Noteer per punt wie verantwoordelijk is en welk bewijs je verwacht. Bijvoorbeeld een geslaagde terugzetactie of een aanvraag die aantoonbaar in het juiste systeem aankomt. Daarmee toets je de website als werkproces, niet alleen als ontwerp.

Schrijf op wie publiceert, welke gegevens direct actueel moeten zijn en welke handelingen bezoekers moeten afronden. Daarmee wordt duidelijk waar een eenvoudige publicatiewebsite volstaat en waar aanvullende systemen nodig zijn. Bekijk onze aanpak voor websites en WordPress, of start je projectaanvraag met die taken als uitgangspunt.