De meeste mkb-websites zien er van binnen hetzelfde uit. WordPress, een thema van een paar tientjes en twintig tot veertig plugins. Eén voor formulieren, één voor SEO, één voor caching, één om de caching-plugin te laten samenwerken met de beveiligingsplugin.
Dat werkt. Tot de site traag wordt, een update iets breekt of er een melding komt dat een plugin lek is. Dan wordt er een plugin bijgezet om het op te lossen.
Ik bouw al jaren websites, ook veel in WordPress. Voor bedrijven die hun website serieus nemen, kies ik het niet meer. In dit artikel leg ik uit waarom, en hoe ik het nu wél doe.
Waarom de gemiddelde mkb-site traag is
Een WordPress-site bouwt elke pagina opnieuw op zodra iemand erom vraagt. De server start PHP, haalt content uit een database, laadt het thema, laat elke plugin zijn ding doen en plakt er een HTML-pagina van in elkaar. Bij elke bezoeker weer.
Daar komen de plugins bovenop. Elke plugin neemt zijn eigen JavaScript, CSS en soms lettertypes mee, op elke pagina, of je die functie daar nu gebruikt of niet. Een thema dat aan duizenden klanten verkocht wordt, zit vol met functies die jij nooit aanzet. Ze worden toch geladen.
De gebruikelijke oplossing is nóg een plugin: een caching-plugin die pagina’s tijdelijk bewaart. Dat helpt, maar het is een pleister. Het fundament blijft een server die bij elke wijziging opnieuw moet nadenken, en een stapel code van derden die je zelf niet in de hand hebt.
De pagina is al klaar voordat iemand erom vraagt
De grootste verandering zit in een simpel idee: bouw een pagina één keer, niet bij elke bezoeker.
Ik bouw sites met Astro . Astro maakt van je content kant-en-klare HTML-pagina’s op het moment dat je publiceert. Een bezoeker krijgt die pagina direct. Er draait geen database mee en er hoeft niets opgebouwd te worden.
Niet elke pagina kan vooraf klaar zijn. Een zoekresultaat, een prijs die verandert of een pagina met voorraad moet actueel zijn. Daarvoor rendert Astro de pagina op de server (SSR) en zet het resultaat in een cache aan de rand van het netwerk. De eerste bezoeker laat de pagina maken, de volgende duizend krijgen de kopie. Verandert de content, dan wordt alleen die pagina ververst.
Het resultaat: de server doet bijna niets, ook niet als je een drukke dag hebt of in de krant staat.
Cloudflare: je site staat naast je bezoeker
Een klassieke website staat op één server in één datacenter. Komt je bezoeker uit Groningen en staat je server in Frankfurt of Virginia, dan reist elke aanvraag dat hele stuk heen en terug.
Ik host sites op Cloudflare . Je website staat dan niet op één plek, maar op honderden servers wereldwijd, ook in Amsterdam. Een bezoeker krijgt de pagina van de server die het dichtst bij is.
Daar komen een paar dingen gratis bij die je bij een gewone host apart moet regelen: een SSL-certificaat, bescherming tegen aanvallen en compressie. Cloudflare comprimeert alles met Brotli, de opvolger van gzip. Je HTML, CSS en JavaScript gaan daardoor een stuk kleiner over de lijn.
Content beheren zonder dat je server meedenkt
De vraag die ik dan altijd krijg: “Maar kunnen we het dan nog zelf aanpassen?” Ja. Beter zelfs.
In WordPress zitten je content, je ontwerp en je techniek in één systeem. Pas je een tekst aan, dan zit je in hetzelfde systeem dat ook je site draait. Een verkeerde klik in een pagebuilder en je layout ligt eruit.
Ik werk met een headless CMS, zoals Sanity . Daarin beheer je alleen de inhoud: teksten, afbeeldingen, producten, vacatures. Het CMS weet niets van je ontwerp. Druk je op publiceren, dan wordt alleen de pagina die veranderde opnieuw gebouwd of ververst. Je website hoeft het CMS niet te vragen wat er op een pagina staat zodra er een bezoeker langskomt.
Voor je redactie betekent het een omgeving die precies past bij wat zij doen. Bij een recent project zet de redactie pagina’s in elkaar uit vaste blokken, plakt ze een tabel uit Excel direct in een artikel en ziet ze een preview op de echte pagina voordat iets live gaat. Zonder dat het ontwerp kan breken.
Afbeeldingen: één keer uploaden, altijd de juiste maat
Afbeeldingen zijn op bijna elke site het zwaarste onderdeel. Op een WordPress-site zie ik vaak foto’s van 4 tot 8 MB die rechtstreeks uit de camera komen, of een optimalisatie-plugin die alles op je eigen server uitrekent.
Ik zet de originele afbeeldingen in opslag op Cloudflare (R2). Een bezoeker vraagt nooit het origineel op. Cloudflare maakt aan de rand van het netwerk de versie die nodig is: 400 pixels breed voor een telefoon, 1600 voor een groot scherm. In een modern formaat als AVIF of WebP, als de browser dat ondersteunt. Die versie wordt bewaard, dus hij wordt maar één keer gemaakt.
Je redactie uploadt één foto. De rest gaat vanzelf, zonder plugin en zonder dat je server ervoor aan het werk moet.
Kleine HTML, alleen de CSS die je gebruikt
Snelheid zit ook in wat je níét verstuurt.
- Kleine HTML. Geen pagebuilder die elk blok in vijf extra
div’s verpakt. De homepage van deze site is 47 kB aan HTML, en gaat met Brotli in minder dan 10 kB over de lijn. - Alleen de CSS die je gebruikt. Ik schrijf CSS met Tailwind, dat bij het bouwen alleen de stijlen meeneemt die echt in je pagina’s staan. Geen stylesheet van een thema met stijlen voor honderd functies die je nooit gebruikt.
- Bijna geen JavaScript. Astro stuurt standaard geen JavaScript mee. Alleen onderdelen die echt iets moeten doen, zoals een filter of een formulier, krijgen het. En pas als ze in beeld komen.
- Geen externe lettertype-diensten. Lettertypes staan op hetzelfde domein als je site. Dat scheelt een omweg naar een andere server, en je hebt geen gedoe met privacy.
Fouten vind je voordat je bezoeker ze vindt
Bij een WordPress-site merk je een fout vaak pas als een bezoeker hem ziet: een witte pagina na een update, een formulier dat stilletjes niets meer verstuurt, een PHP-melding bovenaan je homepage.
Zoals ik bouw, zit er een stap tussen: de build. Voordat een versie live gaat, wordt de hele site in één keer opgebouwd en gecontroleerd. Klopt de code, past elke pagina in het contentmodel, ontbreekt er geen verplicht veld? Faalt er iets, dan gaat de nieuwe versie niet live en blijft de oude gewoon staan.
Er zijn ook geen plugins die je elke week moet bijwerken. Er is geen database die gehackt kan worden en geen inlogpagina op je eigen domein waar bots de hele dag wachtwoorden op proberen. Het grootste deel van het onderhoud van een WordPress-site verdwijnt gewoon.
Klaar voor werken met AI
Er is nog een voordeel dat een paar jaar geleden niet speelde: deze opzet werkt goed samen met AI.
Cloudflare en Sanity hebben allebei een eigen MCP-server. Via zo’n server kan een AI-agent, zoals Claude, rechtstreeks met je systemen werken. In Sanity zoekt een agent content op, vult velden aan of zet een vertaling klaar als concept. Bij Cloudflare kijkt hij mee in de logs, de instellingen en de deploys.
Dat werkt omdat alles hier gestructureerd is. Content staat in velden met een vaste vorm, niet als één blok HTML in een database. De site zelf is code in een repository, met een build die controleert of alles klopt. Een agent weet dus waar hij aan zit, en een fout van een agent komt niet zomaar live.
In WordPress is dat lastiger. Content, opmaak en plugininstellingen zitten door elkaar, en een agent die iets aanpast, past het direct aan op je live site.
Ik werk zelf elke dag zo, met Claude naast Sanity en Cloudflare. De agent doet het herhaalwerk, ik controleer en beslis.
Wat dit oplevert
- Snelheid die blijft. Niet alleen bij de oplevering, maar ook na twee jaar content toevoegen. Er is geen stapel plugins die langzaam groeit.
- Betere vindbaarheid. Google meet laadsnelheid mee via de Core Web Vitals. Een snelle, schone pagina is daar de beste basis voor.
- Minder onderhoud en minder risico. Geen wekelijkse updates, geen lekke plugins, geen hostingpakket dat je moet opschalen omdat je site te zwaar is.
- Een redactie die zelfstandig werkt. Je team past content aan zonder developer en zonder angst dat de layout breekt.
- Klaar voor AI. Agents kunnen veilig meewerken aan je content en je site, omdat alles gestructureerd is en door de build gaat.
Wanneer WordPress wél prima is
Eerlijk is eerlijk: niet elke website heeft dit nodig. Een eenvoudige site voor een zzp’er, een vereniging of een klein project met een beperkt budget kan prima op WordPress met een goed thema. Dat is snel online en iedereen kan ermee werken.
Deze aanpak is voor bedrijven waarvoor de website echt iets moet doen. Waar de site leads binnenhaalt, een catalogus of kennisbank bevat, meerdere talen heeft of een redactie die er elke week mee werkt. Daar betaalt een goed fundament zich terug, in snelheid, in vindbaarheid en in uren onderhoud die je niet meer kwijt bent.