Kiwop had jarenlang een website op WordPress. Het werkte, maar het vertegenwoordigde ons niet meer. We waren gegroeid richting maatwerkprojecten, headless architecturen en toegepaste kunstmatige intelligentie, terwijl onze eigen website nog steeds een PHP-monoliet was met jarenlang opgestapelde plugins. Het was alsof een timmerman zijn eigen voordeur kapot liet.
In januari 2026 besloten we te stoppen en helemaal opnieuw te beginnen. Geen redesign bovenop WordPress, maar een volledig nieuwe architectuur. Dit artikel vertelt waarom, hoe en welke resultaten we hebben behaald.
De vorige website: wat er niet werkte
Het was niet zo dat de website kapot was. Hij laadde, zag er goed uit en had content. Maar er stapelden zich problemen op die steeds erger werden:
Matige prestaties. WordPress met zijn cacheplugins, beeldoptimalisatie en page builders genereerde zwaar HTML. De Core Web Vitals op mobiel slaagden niet consequent, en Google straft een slechte gebruikerservaring steeds harder af.
Kwetsbare beveiliging. WordPress is het meest aangevallen CMS ter wereld. Het beheerpaneel staat op /wp-admin, de API-endpoints zijn bekend en elke plugin is een potentieel aanvalsoppervlak. Het bijgewerkt houden was een constante klus.
Starheid. Het wijzigen van het ontwerp van een sectie betekende sleutelen aan PHP-templates, hooks, inline CSS van de page builder en hopen dat er niets anders kapot ging. De content was gekoppeld aan de presentatie.
Technische schuld in content. Jarenlang publiceren had meer dan 240 artikelen van lage kwaliteit opgeleverd, bijna 200 onvertaalde WPML-duplicaten en tientallen thin content-pagina's. Google zag het allemaal, en de domeinautoriteit verwaterde.
De beslissing: headless architectuur
Als we "headless" zeggen, hebben we het niet over een technologische hype. We hebben het over het scheiden van twee dingen die niet per se samen hoeven te gaan: waar de content wordt beheerd en hoe die aan de gebruiker wordt getoond.
Wat levert dit het bedrijf op?
Echte snelheid, geen gepercipieerde. De frontend genereert puur HTML op de server. Er is geen PHP die bij elk verzoek interpreteert, er zijn geen plugins die onnodige scripts laden. De browser ontvangt precies wat nodig is, meer niet.
Beveiliging by design. Het CMS waar de content wordt bewerkt, is niet blootgesteld aan het internet. Er is geen /wp-admin om aan te vallen. Het aanvalsoppervlak wordt drastisch verkleind.
Volledige flexibiliteit. Het designteam kan elk visueel component wijzigen zonder de contentdatabase aan te raken. En het redactieteam kan publiceren zonder zich zorgen te maken over hoe het wordt gerenderd.
Schaalbaarheid. Een website in 7 talen serveren vanuit een enkele frontend met meerlaagse cache is haalbaar. Met WordPress en WPML vermenigvuldigde elke taal de complexiteit.
Astro + Payload CMS: waarom deze combinatie
We hebben verschillende opties geevalueerd. Next.js, Nuxt, Remix voor de frontend. Strapi, Directus, Sanity voor het CMS. We kozen voor Astro en Payload om zeer concrete redenen.
Astro genereert statisch HTML of server-side gerenderd HTML zonder standaard JavaScript naar de browser te sturen. Als een pagina geen interactiviteit nodig heeft, ontvangt de gebruiker puur HTML en CSS. Het resultaat: 0 milliseconden Total Blocking Time. Nul. De main thread van de browser blijft vrij.
Payload CMS is een headless CMS op PostgreSQL met een schone REST API en volledige TypeScript-typing. In tegenstelling tot Strapi of Sanity is Payload self-hosted: onze data staan in onze eigen database, niet bij een externe SaaS. Voor een agency die klantgegevens beheert, is dit niet onderhandelbaar.
De combinatie lost een reeel probleem op: content die professioneel wordt beheerd, gepresenteerd met een Lighthouse-score van 97 en 0 ms blokkering in de browser, zonder externe afhankelijkheden of vendor lock-in.
Het proces: 35 dagen, 230 commits
Het was geen project van zes maanden. Vanaf de eerste commit op 10 januari 2026 tot de productieversie verstreken 35 dagen. 230 commits. Een klein team met duidelijke doelstellingen.
Fase 1: structuur en componenten (week 1-2)
We definieerden de modulaire architectuur: 14 herbruikbare sectiecomponenten (hero, servicegrid, stappenproces, FAQ's, CTA's) die als bouwblokken worden gecombineerd om elke servicepagina samen te stellen. Elke dienst wordt gedefinieerd met een configuratiebestand per taal, zonder code aan te raken.
De belangrijkste beslissing was om geen enkel JavaScript-framework aan de clientzijde te gebruiken. Geen React, geen Vue, geen Svelte. Puur Astro met islands architecture voor de weinige componenten die interactiviteit nodig hebben (zoals de chatbot). Het resultaat: een JS-bundel van bijna nul voor 95% van de pagina's.
Fase 2: meertaligheid (week 3)
We gingen van 3 talen (Spaans, Engels, Catalaans) naar 7 (met Duits, Frans, Nederlands en Portugees erbij). Dit hield in:
- Een gecentraliseerd vertaalsysteem voor de volledige interface, beheerd vanuit een enkel bestand.
- Correcte hreflang met uitgeschakelde fallback om te voorkomen dat Google onvertaalde content indexeert.
- Schone URL's per taal zonder trailing slash (1.001 URL's geindexeerd in Google Search Console, allemaal consistent).
Een detail dat ons uren heeft gekost: de regex voor taaldetectie in URL's. Een onjuist patroon matchte /ca binnen /casos-de-exito, waardoor de Catalaanse routes braken. Het lijkt triviaal, maar op een website met meer dan 2.000 pagina's is zo'n bug catastrofaal voor SEO.
Fase 3: contentmigratie en opschoning (week 4)
We migreerden de volledige blog van WordPress naar Payload CMS. Maar het was geen directe dump: we grepen de kans om een grondige contentaudit uit te voeren.
- 243 giftige artikelen verwijderd (content van lage kwaliteit, irrelevant of verouderd)
- 199 WPML-duplicaten gedepubliceerd (Engelse en Catalaanse versies die onvertaalde kopieen van het Spaans waren)
- 31 thin content-pagina's verwijderd met 410-codes in nginx
- 3 paar dubbele artikelen geconsolideerd met 301-redirects
- 885 titels ingekort tot minder dan 60 tekens
- 333 meta descriptions aangepast tot minder dan 160 tekens
Deze opschoning was bewust. De Helpful Content Update van Google straft op siteniveau. 200 waardeloze pagina's hebben sleept de 700 goede pagina's mee naar beneden.
Fase 4: SEO en prestaties (week 5)
Audit van de heading hierarchy op alle 2.114 pagina's van de site: 0 fouten, 0 waarschuwingen. Elke pagina heeft een correcte semantische structuur, van H1 tot H4.
We implementeerden een cachesysteem met 4 lagen (Payload CMS, Redis SWR, nginx SSR en Cloudflare CDN) met geordend purgen. De volgorde is belangrijk: als je Cloudflare purget maar Payload nog oude cache heeft, cachet nginx onmiddellijk verouderde gegevens opnieuw. Het klinkt vanzelfsprekend op papier, maar we leerden het door te debuggen waarom wijzigingen niet in productie verschenen.
De rol van AI
Het zou oneerlijk zijn om het niet te noemen: we hebben AI als ontwikkeltool ingezet tijdens het hele proces. Niet om blindelings code te genereren, maar als een pair programming-partner die ons hielp bij het auditen van 2.000+ pagina's, het detecteren van SEO-inconsistenties op schaal en het automatiseren van repetitieve taken zoals het normaliseren van titels in 7 talen.
AI heeft de architectuur niet ontworpen en geen zakelijke beslissingen genomen. Maar het heeft de uitvoering aanzienlijk versneld, vooral in de fasen van audit en contentopschoning.
Resultaten: de cijfers
Prestaties (Lighthouse)
De Lighthouse-scores van de website in productie:
- Performance: 97/100 (mobiel en desktop)
- Toegankelijkheid: 100/100
- Best practices: 100/100
- SEO: 100/100
Core Web Vitals
- LCP (Largest Contentful Paint): 2,2 seconden — geslaagd (Google-drempel: < 2,5 s)
- TBT (Total Blocking Time): 0 milliseconden — geslaagd (drempel: < 200 ms)
- CLS (Cumulative Layout Shift): 0 — geslaagd (drempel: < 0,1)
Een TBT van 0 milliseconden betekent dat de browser op geen enkel moment wordt geblokkeerd. Een CLS van 0 betekent dat er niets verspringt terwijl de pagina laadt. Dit zijn geen theoretische getallen: het zijn echte metingen op de productiewebsite.
Impact op zoekmachines
De contentopschoning leverde een verwacht effect op: minder totale impressies (we verwijderden honderden pagina's), maar betere kwaliteit in wat overblijft.
- CTR: +27,8% (van 0,17% naar 0,22%)
- Gemiddelde positie: +9,3 posities (van 50,6 naar 41,3)
- Gemiddelde positie op mobiel: +13,6 posities (van 36,9 naar 23,3)
Minder volume, meer kwaliteit. De pagina's die overblijven ranken beter en converteren meer. Het is de juiste strategie wanneer de prioriteit is om klanten aan te trekken, niet om lege bezoeken te verzamelen.
Schaal
- 2.114 pagina's gecontroleerd en functioneel
- 7 talen vanuit een enkele codebase
- ~1.600 blogartikelen gepubliceerd (712 ES, 406 EN, 407 CA, 33 DE/FR/NL, 10 PT)
- Deployments zonder downtime met automatische rollback
Wat dit betekent voor onze klanten
Deze website is niet alleen onze etalage. Het is het praktische bewijs van wat we doen.
Dezelfde headless architectuur achter kiwop.com — scheiding van frontend en CMS, meerlaagse cache, native meertaligheid, PageSpeed-prestaties van 97+ — is precies wat we implementeren in klantprojecten.
Als uw huidige website:
- Meer dan 3 seconden nodig heeft om te laden op mobiel
- Afhankelijk is van WordPress met 20 plugins om te functioneren
- Terugkerende beveiligingsproblemen heeft
- Niet goed schaalt naar meerdere talen of markten
- Technische schuld opstapelt die elke wijziging vertraagt
Dan is er een bewezen alternatief. Niet theoretisch: u bekijkt het nu.
