KennisbankHeadless website

Hoe topmerken snelle, vindbare headless websites lanceren.

Een headless website is een site in je eigen code, los van een websitebouwer of WordPress. Helly Hansen, Personio en Smashing Magazine stapten over, en jonge AI-bedrijven als Vellum deden het in 2026 in een week. Wat ze ermee winnen, wat het onderzoek wel en niet zegt, en hoe we zo’n site voor onze klanten bouwen.

  • Helly HansenNoors outdoormerk, sinds 1877

  • PersonioEuropese HR-software voor het mkb

  • Smashing MagazineVakblad voor webdesign en webontwikkeling

Strategie · 41 bronnen23 minuten lezen

Zo gaat een wijziging live op een site die we in code bouwen. De 126 locaties zijn die van het CDN van Vercel.

De cijfers

Vier cijfers die de verschuiving laten zien.

Elk cijfer linkt naar het onderzoek, en met het nummer rechtsonder link je direct naar een cijfer. Gebruik ze gerust, met bronvermelding.

23,5%

van de WordPress-sites heeft een goede serverreactie op mobiel. Bij sites op Vercel is dat 65,4%.

Bron: HTTP Archive, aug. 2026#01

+8%

meer verkopen bij Vodafone in een A/B-test, met een 31% betere LCP.

Bron: web.dev, 2021#02

569mln

verzoeken van GPTBot in één maand op het netwerk van Vercel. Net als de crawler van Claude voert hij geen JavaScript uit.

Bron: Vercel, dec. 2024#03

1week

om de hele site van Vellum van Webflow naar code te verhuizen, met een AI-assistent. De Google-posities bleven.

Bron: Vellum, mei 2026#04

De strategie in het kort

Topmerken stappen steeds vaker over op een headless website: een site in eigen code, vooraf gebouwd tot kant-en-klare HTML en gepubliceerd op een CDN dicht bij elke bezoeker. Google en AI-crawlers lezen zo’n pagina direct, zonder eerst JavaScript uit te voeren. En elke wijziging krijgt een eigen preview voordat hij live gaat.

Snel ben je daarmee niet vanzelf: websitebouwers als Webflow en Framer halen net zo vaak goede Core Web Vitals als sites in Astro. Het verschil zit in wat je meestuurt, en in wat je bezit. Een site in code is van jou, draait overal en groeit mee zonder herbouw. Zo bouwen we ook de nieuwe sites van onze klanten.

Het probleem: websites verouderen sneller

In onze thesis telden we de mijlpalen die veranderden hoe een website eruit moet zien of moet werken: nieuwe apparaten, designtalen, zoekupdates en wetten. In 2000–2004 waren het er twee. In 2020–2024 waren het er acht, en in 2025 alleen al drie: Material 3 Expressive, Liquid Glass van Apple en de European Accessibility Act.

Wie bijblijft, vernieuwt vaker. Orbit Media bekeek 50 toonaangevende marketingsites in het Internet Archive. Die kregen gemiddeld elke 2 jaar en 1 maand een nieuwe site. Bij 78 klanten van het bureau zelf zat er gemiddeld 6 jaar en 4 maanden tussen twee grote redesigns.

Waarom wachten de meeste bedrijven zo lang? In een enquête van Databox onder ruim 145 vooral kleinere bedrijven noemde 40% zorgen over SEO als de grootste reden om hun site niet te vernieuwen. Tijd en budget kwamen daarna.

Wat de thesis concludeert: herbouw je site niet elke zes jaar, maar vernieuw hem klein en vaak. Wij noemen dat vervellen. Daar hoort een fundament bij dat veranderen goedkoop en veilig maakt. Over dat fundament gaat deze strategie.

Van platform naar code: waar een pagina ontstaat

Elke webpagina wordt ergens in elkaar gezet. Waar dat gebeurt, bepaalt hoe snel hij is en wat Google en AI-crawlers ervan zien. Grofweg zijn er drie manieren.

  • Bij elk bezoek, op de server. Zo werkt WordPress. Voor elke bezoeker haalt de server de inhoud uit een database en bouwt hij de pagina op met een thema en plug-ins. Een cache kan dat versnellen.
  • In de browser. Een JavaScript-app stuurt eerst een bijna lege pagina en bouwt die daarna op in de browser van de bezoeker. Dat is handig voor software, en minder voor een site die gevonden moet worden.
  • Vooraf. De pagina’s worden één keer gebouwd tot kant-en-klare HTML en als vaste bestanden op een CDN gezet: een netwerk van servers over de hele wereld. Elke bezoeker krijgt de pagina van een server in de buurt.

Websitebouwers zitten daartussenin. Webflow zet je site op een CDN, en Framer en Wix laten hem op hun eigen servers draaien. Je huurt daar de techniek, en verhuizen gaat maar beperkt. Bij een site in code is de techniek van jou.

Wat headless en statisch betekenen

Bij een headless website staat de inhoud los van de vormgeving. Teksten en beelden staan in een headless CMS of gewoon in bestanden, en de site haalt ze daar op bij het bouwen. Er is geen vast thema dat bepaalt hoe je site eruitziet. Personio werkt zo, met Contentful als CMS.

Een statische site is een site die vooraf gebouwd is: de server stuurt vaste bestanden, zonder bij elk bezoek iets op te bouwen. Statisch zegt niets over hoe de site eruitziet. Formulieren, animaties en een chat werken gewoon.

Zo gaat een wijziging live

  1. Code

    Je site staat als code in een GitHub-repository. Die is van jou, en elke wijziging blijft bewaard.

  2. Preview

    Elke wijziging krijgt automatisch een eigen previewlink. Die houdt Vercel buiten Google.

  3. CDN

    Goedgekeurd? Dan staat de nieuwe versie op het CDN. Bij Vercel zijn dat 126 locaties in 51 landen.

  4. Gelezen

    Bezoekers, Google en AI-crawlers krijgen direct de complete HTML. Gaat er iets mis, dan zet je de vorige versie direct terug.

De vier opties naast elkaar

Vier manieren om een website te publiceren
WordPressWebsitebouwerJavaScript-appVooraf gebouwd
Waar de pagina ontstaatBij elk bezoek, op de server, uit een database.Op het platform van de bouwer, zoals Webflow of Framer.In de browser van de bezoeker.Eén keer, bij het publiceren. Daarna als vast bestand op een CDN.
Wat een crawler als eerste zietDe complete pagina.De complete pagina.Een bijna lege pagina, tot de JavaScript draait.De complete pagina.
OnderhoudWordPress, je thema en je plug-ins bijwerken.Regelt het platform.Pakketten en frameworks bijwerken.Geen plug-ins of database om bij te werken.
VerhuizenKan: alles gaat mee naar een andere host.Beperkt, zie hieronder.Kan: de code is van jou.Kan: de code is van jou en draait op elke host.
Zelf aanpassenIn de editor van WordPress.In de visuele editor van het platform.Via code, of een gekoppeld CMS.Via code, of een gekoppeld CMS.
Past bijSites die draaien op plug-ins, zoals boekingen.Teams die zelf vaak pagina’s bouwen.Software: dashboards, portalen, tools.Sites die snel moeten zijn, gevonden moeten worden en mee moeten groeien.

Verhuizen vanaf een websitebouwer: Framer biedt geen HTML-export, een Wix-site moet op de servers van Wix draaien, en een export uit Webflow kan alleen met een Workspace-abonnement en mist je CMS, formulieren en zoekfunctie.

Snelheid: wat het onderzoek echt zegt

Google meet de snelheid van sites bij echte bezoekers in Chrome: de Core Web Vitals. Het HTTP Archive koppelt die metingen aan de techniek waarop een site draait. Wij haalden de cijfers van augustus 2026 op, voor mobiel.

Sites met goede Core Web Vitals op mobiel, augustus 2026
  1. Wix81,2%
  2. Hugo77,9%
  3. Webflow71,2%
  4. Astro71,0%
  5. Framer70,6%
  6. Alle sites53,0%
  7. WordPress48,7%
  8. Sites op Vercel42,9%
  9. Next.js35,1%

Aandeel sites (origins) met een goede LCP, INP en CLS bij echte bezoekers in Chrome, voor een selectie van platforms en technieken. Bron: HTTP Archive Tech Report, dataset augustus 2026, wereldwijd. Percentages door ons berekend uit de ruwe cijfers.

Drie dingen vallen op.

  • Het is geen strijd tussen code en websitebouwers. Webflow en Framer scoren net zo goed als Astro. Wie een bouwer gebruikt, zit qua snelheid meestal goed.
  • Het verschil zit in wat je meestuurt. Next.js is ook code, maar slaagt bij maar 35,1% van de sites, minder dan WordPress. Een verklaring is de hoeveelheid JavaScript. In 2024 stuurde een vooraf gebouwde Next.js-site 583 KB JavaScript mee, een Astro-site 164 KB. Dat zijn de medianen uit de Web Almanac 2024.
  • Hosting alleen maakt je niet snel. Van de sites op Vercel slaagt 42,9%. Een snel CDN helpt, maar een zware pagina blijft zwaar.

Het grootste verschil met WordPress zit bij de server. Die moet beginnen met antwoorden voordat de browser iets kan laten zien.

Sites met een goede serverreactie (TTFB) op mobiel, augustus 2026
  1. Squarespace79,3%
  2. Framer66,9%
  3. Sites op Vercel65,4%
  4. Hugo65,0%
  5. Astro64,2%
  6. Webflow59,9%
  7. Alle sites45,8%
  8. Next.js45,7%
  9. WordPress23,5%

TTFB is de tijd tot de server begint met antwoorden. Het is geen Core Web Vital, maar alles wat erna komt wacht erop. Als richtlijn noemt web.dev 0,8 seconde of minder. Bron: HTTP Archive Tech Report, augustus 2026.

Hier staat WordPress onderaan. Maar 23,5% van de WordPress-sites heeft een goede serverreactie op mobiel, tegen 65,4% van de sites op Vercel. Dat past bij hoe WordPress werkt: de server bouwt de pagina bij elk bezoek opnieuw op, tenzij er een cache voor zit. Een vooraf gebouwde pagina hoeft alleen nog verstuurd te worden. Het Web Almanac zag in 2024 hetzelfde patroon: van de sites die het als vooraf gebouwd herkende, had 41% goede Core Web Vitals, tegen 33% van de dynamische sites.

Waarom snelheid geld oplevert

Snelheid is geen doel op zich. Het telt omdat bezoekers afhaken. In twee A/B-tests die Google publiceerde, vergeleken bedrijven een snellere versie van een pagina met het origineel:

  • Vodafone: een 31% betere LCP leverde 8% meer verkopen op, en 15% meer leads per bezoek (web.dev).
  • Rakuten 24: de versie die geoptimaliseerd was voor de Core Web Vitals, haalde in een maand 53,37% meer omzet per bezoeker en 33,13% meer conversie (web.dev).

In een groter onderzoek van Deloitte, in opdracht van Google, ging een mobiele site die 0,1 seconde sneller was samen met 8,4% meer conversies in retail en 10,1% in reizen. Dat is een samenhang over 37 merken, geen bewijs van oorzaak. De richting is wel steeds dezelfde.

Telt snelheid mee in Google?

Ja, maar minder dan veel mensen denken. Google schrijft dat de Core Web Vitals worden gebruikt door zijn rankingsystemen. Maar Google laat ook altijd de meest relevante inhoud zien, zelfs als de pagina-ervaring matig is. Snelheid helpt vooral als er veel goede pagina’s over hetzelfde onderwerp zijn. Een snelle pagina met zwakke inhoud wint het dus niet van een tragere pagina die de vraag beter beantwoordt.

Wat Google en AI-crawlers van je site lezen

Google verwerkt een pagina in drie stappen: ophalen, renderen en indexeren. Renderen betekent dat Google de JavaScript uitvoert, zoals een browser dat doet. Pagina’s gaan daarvoor in een wachtrij. Dat duurt volgens Google een paar seconden, maar het kan langer.

Hoeveel langer, onderzochten Vercel en MERJ in april 2024, met ruim 100.000 bezoeken van Googlebot, vooral aan nextjs.org. Bij de helft van de pagina’s was Google binnen 10 seconden klaar met renderen. Bij 10% duurde het ongeveer 3 uur of langer, en bij 1% ongeveer 18 uur of langer. Uiteindelijk renderde Google wel alle pagina’s.

Staat je inhoud al in de HTML, dan maakt die wachtrij minder uit: Google leest je tekst en links meteen. Google noemt renderen op de server of vooraf zelf nog altijd een goed idee, omdat het je site sneller maakt voor bezoekers en crawlers, en omdat niet alle bots JavaScript kunnen uitvoeren.

AI-crawlers lezen alleen je HTML

Bij AI-crawlers is het verschil groter. Vercel onderzocht eind 2024 het verkeer op zijn netwerk: de grote AI-crawlers voerden geen JavaScript uit. De crawlers van ChatGPT en Claude haalden JavaScript-bestanden wel op, maar draaiden ze niet. De uitzonderingen waren Gemini, dat de techniek van Googlebot gebruikt, en AppleBot.

En die crawlers komen vaak langs. GPTBot van OpenAI deed in één maand 569 miljoen verzoeken op het netwerk van Vercel, en de crawler van Claude 370 miljoen. Samen is dat ongeveer 20% van de 4,5 miljard verzoeken van Googlebot in dezelfde periode.

Een pagina die pas in de browser wordt opgebouwd, is voor ChatGPT en Claude dus een lege pagina. Dat geldt ook voor sites die met AI gebouwd zijn. Het maakt niet uit of de code door een mens of door AI geschreven is, wel of je inhoud in de HTML staat. Meer over AI-zoeken lees je in gevonden worden in ChatGPT.

Wordt een site in code sneller geïndexeerd?

Niet vanzelf. Voor een site van tientallen of honderden pagina’s is crawlbudget geen punt. Google schrijft dat zijn advies daarover vooral geldt voor sites met meer dan 10.000 pagina’s die dagelijks veranderen, of meer dan een miljoen pagina’s. Een actuele sitemap en het rapport Pagina-indexering in Search Console zijn volgens Google genoeg.

Een snelle, stabiele server helpt wel een beetje. Antwoordt je site snel en zonder fouten, dan haalt Google meer pagina’s tegelijk op. Snel in Google kom je vooral met een sitemap, goede interne links en een aanvraag in Search Console.

Wat een headless website je geeft, naast snelheid

Als websitebouwers net zo snel kunnen zijn, waarom dan code? Omdat snelheid maar een van de dingen is die een site goed houden. De rest zit in wie hem bezit en hoe makkelijk hij verandert.

01

Hij is van jou

Je code staat in je eigen GitHub-repository en draait op elke host. Je zit niet vast aan het abonnement of de keuzes van een platform.

Bij bouwers ligt dat anders: zie Framer, Wix en Webflow.

02

Elke wijziging eerst gezien

Elke wijziging krijgt automatisch een eigen previewlink. Je bekijkt hem op je telefoon voordat hij live gaat. Google ziet die previews niet, want Vercel zet er standaard noindex op.

Bron: Vercel Docs, Vercel.

03

Direct terug

Gaat er toch iets mis, dan zet je de vorige versie meteen terug. Vercel noemt dat Instant Rollback. En omdat Git elke wijziging bewaart, zie je altijd wat er veranderd is en door wie.

Bron: Vercel Docs.

04

Geen plug-ins om bij te werken

Er draait geen database en geen plug-in die lek kan raken. Bij WordPress werden in 2025 11.334 nieuwe lekken gevonden, en 91% daarvan zat in plug-ins.

Bron: Patchstack.

05

Vervellen in plaats van herbouwen

Kleuren, letters, knoppen en blokken staan op één plek, in een designsysteem. Een nieuwe look of een nieuwe dienst pas je één keer aan, en elke pagina gaat mee. Zo blijft je site actueel zonder herbouw.

Onze aanpak, uit de Molt-thesis.

06

Gemaakt voor AI-hulp

AI-assistenten schrijven steeds vaker code, en websites zijn daarbij het grootste onderwerp. Bedrijven als Vellum en Yuma AI zetten nu pagina’s live in uren in plaats van dagen of weken.

Van 500.000 codegesprekken met Claude ging 31% over JavaScript en TypeScript, en 28% over HTML en CSS (Anthropic).

Wat je inlevert: de opmaak pas je niet zelf aan in een visuele editor, zoals in Webflow. Teksten en beelden kun je wel zelf beheren als er een CMS aan gekoppeld is. Wanneer een bouwer beter past, lees je hieronder.

Wat merken zagen na de overstap

Dit zijn bekende overstappen naar een site in code, met de cijfers die het merk of zijn platform zelf publiceerde. Geen van deze merken is klant van ons. Niemand heeft de cijfers onafhankelijk gecontroleerd, en bij elke overstap veranderde meer dan alleen de techniek. Lees ze als voorbeelden, niet als bewijs.

Adobe Commerce → Next.js2025

Helly Hansen

Noors outdoormerk, sinds 1877

De webshop ging van een laadtijd van meer dan 4 seconden naar 1,8 à 2 seconden. Binnen vijf maanden stonden alle Core Web Vitals op groen.

Gepubliceerd door Vercel, dat ook een verdubbelde conversie noemt. Het marketingbudget ging in dezelfde periode omhoog.

WordPress → Next.js2024

Personio

Europese HR-software voor het mkb

De mobiele LCP werd 29% beter, de Core Web Vitals verbeterden steeds meer dan 90%, vooral door minder verspringen. De site haalde 99,99% uptime.

Gepubliceerd door Vercel. Met Contentful als CMS.

WordPress → Hugo2017

Smashing Magazine

Vakblad voor webdesign en webontwikkeling

Het blad ging over op een statische site, met de winkel en de ledenlogin als losse diensten ernaast. De eerste laadtijd ging van 800 naar 80 milliseconden.

Gepubliceerd door Netlify en geschreven door een medeoprichter van Netlify.

WordPress → statisch2020

Celonis

Software voor procesverbetering bij grote bedrijven

De server reageerde in 270 milliseconden in plaats van 7 seconden. Een pagina laadde in 1,32 seconde, 82,3% sneller. Het team publiceert nu 100 pagina’s per maand.

Gepubliceerd door Netlify.

Angular → Next.js2024

Elkjøp

Noordse elektronicaketen

“Wat eerst 7 weken kostte, kost nu een dag.” Verspringen werd 93% minder, de reactietijd (INP) 60% en de LCP 50% beter.

Gepubliceerd door Vercel. Geen absolute cijfers.

Blogger → Astro2023

Firebase

Ontwikkelplatform van Google

Voor het blog ging een artikel publiceren van uren naar minuten, en de bouwtijd daalde 75%, naar gemiddeld anderhalve minuut.

Gepubliceerd door Astro.

Webflow → Next.js2026

Vellum

Start-up die tools voor AI-agents maakt

Vellum verhuisde zijn hele site in één week, met een AI-codeerassistent. De Google-posities bleven, en het bespaart $ 30.000 per jaar aan Webflow.

Door Vellum zelf gepubliceerd. Met Sanity als CMS en Claude Code als assistent.

Webflow → code2026

Yuma AI

Klantenservicesoftware voor webshops

Live na anderhalve week. In de eerste 30 dagen kwamen er 13% meer gebruikers en 27% meer paginaweergaven, en daalde de bounce rate met 21%.

Geschreven door de groeimanager van Yuma AI, in The GTM Engineer. Zonder controlegroep. Met Claude Code als assistent.

Wat de cases gemeen hebben: het grootste winstpunt is zelden alleen snelheid. Het is hoe snel een team daarna verandert: 7 weken die een dag worden, publiceren in minuten, pagina’s in uren. Dat is precies wat vervellen nodig heeft.

Onze strategie in zes stappen

Zo pakken we een nieuwe site aan voor onze klanten: snel, vindbaar en klaar om mee te groeien. Bouw je liever zelf, of met je eigen bouwer? Dan werken dezelfde stappen ook.

  1. We beginnen bij de vragen van je klanten

    Eén pagina per dienst of vraag, in de woorden die je klanten zoeken. Het antwoord staat bovenaan, als tekst in de HTML. Daar lezen Google en AI het als eerste.

  2. We ontwerpen een systeem, geen losse pagina’s

    Kleuren, letters, knoppen en blokken leggen we vast in een designsysteem. Nieuwe pagina’s bouwen we uit bestaande onderdelen, en de look verander je op één plek.

  3. We bouwen vooraf en sturen alleen wat nodig is

    Je krijgt kant-en-klare HTML. JavaScript gebruiken we alleen waar het iets toevoegt, zoals een formulier of een chat. Afbeeldingen slaan we op als WebP of AVIF, met een vaste maat, zodat er niets verspringt.

  4. We publiceren via Git en een CDN

    De code staat in een repository, gekoppeld aan een platform als Vercel, Netlify of Cloudflare. Elke wijziging krijgt een preview, elke versie blijft bewaard en je site staat dicht bij elke bezoeker.

  5. We meten bij echte bezoekers

    In Search Console volgen we het rapport Core Web Vitals en Pagina-indexering. Een labtest als Lighthouse helpt om problemen te vinden, maar de cijfers van echte bezoekers tellen. We dienen je sitemap in en vragen indexering aan voor nieuwe pagina’s.

  6. We vervellen klein en vaak

    Na de livegang verbeteren we je site in kleine stappen: een betere pagina, een nieuwe dienst, een frissere look. Met previews en een designsysteem is elke stap klein en veilig. Zo hoeft je site nooit meer helemaal opnieuw.

Stap je over van een ander platform? Dan houden we je URL’s waar het kan en verwijzen we elke URL die verandert door naar het nieuwe adres. Je titels, beschrijvingen en inhoud gaan mee. Lees hoe een website migratie zonder SEO-verlies werkt.

Wanneer een websitebouwer beter past

Een headless website is niet voor iedereen de beste keuze. Een eerlijke vergelijking:

Kies een websitebouwer als

  • jij of je team vaak zelf nieuwe pagina’s en layouts bouwt, zonder ontwikkelaar. Daar zijn Webflow en Framer voor gemaakt;
  • je een eenvoudige site wilt voor een klein budget. Wix en Squarespace zijn snel en regelen alles;
  • je vooral online verkoopt. Dan is Shopify vaak de kortste weg;
  • je WordPress-site goed werkt en draait op plug-ins die je nodig hebt, zoals boekingen of een ledenomgeving. Maak hem dan sneller in plaats van te verhuizen.

Kies een headless website als

  • je site snel moet zijn en gevonden moet worden, ook in AI-assistenten;
  • je eigenaar wilt zijn van je site, zonder vast te zitten aan een platform;
  • je site mee moet groeien met je bedrijf, met een eigen design dat je regelmatig vernieuwt;
  • je wijzigingen laat doen, door ons of je eigen ontwikkelaar, of teksten beheert in een gekoppeld CMS.

Twijfel je tussen WordPress en Webflow? Lees onze eerlijke vergelijking. Wil je de site zelf maken? Lees dan zelf een website maken of laten maken.

Zo bouwen we een headless website voor klanten

Nieuwe sites bouwen we het liefst zo: vooraf gebouwd, in code, met een eigen designsysteem. Werkt je huidige platform goed, dan houden we het en maken we het sneller. In de thesis noemen we dat: transformeren, niet opnieuw beginnen.

Wat je van ons krijgt

Code
Je site staat als code in een eigen repository op GitHub. Na de laatste betaling zijn ontwerpen, code, content en accounts van jou.
Design
Eén designsysteem voor al je pagina’s. Een nieuwe look of een nieuwe dienst pas je één keer aan, en elke pagina gaat mee.
Publiceren
Elke wijziging bekijk je eerst op een eigen previewlink. Daarna staat hij live op een CDN, dicht bij elke bezoeker.
Snelheid
Kant-en-klare HTML, met JavaScript alleen waar het iets toevoegt, zoals een formulier of een chat.
Teksten
Zelf teksten en beelden aanpassen kan met een gekoppeld CMS. Zonder CMS stuur je wijzigingen naar ons.
Overstappen
We houden je URL’s waar het kan en verwijzen de rest door, zodat je Google-posities meegaan.
  • Eerst zien. We ontwerpen eerst je nieuwe homepage. Binnen een week staat je gratis preview klaar, en jij beslist of we verdergaan. Bekijk de nieuwe homepage.
  • Weken, geen maanden. De meeste sites gaan binnen één tot vier weken live, met je URL’s en Google-posities behouden. Bekijk de volledige website.
  • Vervellen. Met Site Care houden we je site actueel: updates, kleine aanpassingen en monitoring, per maand.

Methode en bronnen

Geschreven op 13 oktober 2026, op basis van openbaar onderzoek. Alle bronnen geraadpleegd op die dag.

  • Snelheid per techniek komt uit de API van het HTTP Archive Tech Report: dataset augustus 2026, wereldwijd, alle sites. De percentages rekenden we zelf uit: sites met een goede score gedeeld door het aantal geteste sites. Het gaat om origins (domeinen), niet om bezoekers. Sites kiezen hun eigen techniek, dus de cijfers laten samenhang zien, geen oorzaak.
  • De cases zijn gepubliceerd door het platform (Vercel, Netlify, Astro) of door het bedrijf zelf. Niemand heeft ze onafhankelijk gecontroleerd.
  • De AI-crawlers zijn gemeten op het netwerk van Vercel, eind 2024. Hun gedrag kan sindsdien veranderd zijn.
  • De logo’s van Helly Hansen, Personio en Smashing Magazine zijn van de merken zelf en staan er alleen ter herkenning. Geen van de merken in deze strategie is klant van Molt.
  1. HTTP Archive: Tech Report, dataset augustus 2026.
  2. HTTP Archive: Tech Report API: Core Web Vitals en TTFB per techniek, opgehaald op 13 oktober 2026.
  3. HTTP Archive: Tech Report API: Vercel, Hugo en andere, opgehaald op 13 oktober 2026.
  4. Web Almanac 2024: Jamstack, 11 november 2024.
  5. Web Almanac 2025: Performance, 15 januari 2026.
  6. web.dev: Time to First Byte (TTFB), bijgewerkt op 28 november 2025.
  7. web.dev: Vodafone: A 31% improvement in LCP increased sales by 8%, 17 maart 2021.
  8. web.dev: How Rakuten 24’s investment in Core Web Vitals increased revenue per visitor, bijgewerkt op 24 augustus 2022.
  9. Deloitte: Milliseconds Make Millions, 24 maart 2020, in opdracht van Google.
  10. Google Search Central: Understanding page experience in Google Search results, bijgewerkt op 22 september 2026.
  11. Google Search Central: Understand JavaScript SEO basics, bijgewerkt op 4 maart 2026.
  12. Google Search Central: Crawl budget management for large sites, bijgewerkt op 22 juli 2026.
  13. Vercel en MERJ: How Google handles JavaScript throughout the indexing process, 31 juli 2024.
  14. Vercel: The rise of the AI crawler, 17 december 2024.
  15. Vercel Docs: CDN overview, bijgewerkt op 14 september 2026.
  16. Vercel Docs: Environments, bijgewerkt op 17 september 2026.
  17. Vercel: Are Vercel Preview Deployments indexed by search engines?, bijgewerkt op 2 oktober 2026.
  18. Vercel Docs: Performing an Instant Rollback on a Deployment, bijgewerkt op 7 juli 2026.
  19. Vercel: Pricing, geraadpleegd op 13 oktober 2026.
  20. Framer Help: Can I export my website to HTML and self-host it?, bijgewerkt op 15 september 2026.
  21. Wix Help Center: Exporting or Embedding Your Wix Site Elsewhere, geraadpleegd op 13 oktober 2026.
  22. Webflow Help Center: How do I export my Webflow site code?, bijgewerkt op 31 oktober 2025.
  23. Patchstack: State of WordPress Security in 2026, bijgewerkt op 25 februari 2026.
  24. Vercel: WordPress monolith to Vercel: How Personio elevated site performance and efficiency, 18 maart 2024.
  25. Netlify: How Celonis Supercharged their Content Production with Netlify Enterprise Solutions, 23 september 2020.
  26. Netlify: Smashing Magazine just got 10x faster, 16 maart 2017.
  27. Vercel: Helly Hansen migrated to Vercel and drove 80% Black Friday growth, 15 september 2025.
  28. Vercel: Elkjøp’s Digital Transformation: Powering Retail Innovation with Next.js and Vercel, 24 juli 2024.
  29. Astro: Release Content Faster: How Firebase Cut Blog Publishing From Hours to Minutes with Astro, augustus 2023.
  30. Vellum: How I migrated off of Webflow in one week with coding agents, 12 mei 2026.
  31. The GTM Engineer: How one person ships marketing pages 12x faster after ditching Webflow, 2 juni 2026.
  32. Very Good Ventures: Migrating VGV from Webflow to Astro: Building an AI-Native Website, 26 maart 2026.
  33. Astro: The Astro Technology Company joins Cloudflare, 16 januari 2026.
  34. State of JavaScript 2025: Libraries, Devographics.
  35. Stack Overflow: 2025 Developer Survey: AI, 2025.
  36. GitHub: Octoverse: A new developer joins GitHub every second as AI leads TypeScript to #1, 28 oktober 2025.
  37. Anthropic: Anthropic Economic Index: AI’s impact on software development, 28 april 2025.
  38. Orbit Media: What is the Average Website Lifespan? 10 Factors In Website Longevity, bijgewerkt op 30 juni 2026.
  39. Databox: How Does Website Age Impact Performance? Insights from 145+ Companies, 8 augustus 2024.
  40. Goree e.a., via The Next Web: Researchers analyzed 10,000 websites and yes, they all look the same, 16 mei 2020.
  41. Shin e.a.: Interrogating Design Homogenization in Web Vibe Coding, maart 2026, preprint.

Citeer deze strategie

Molt Studio (2026). Hoe topmerken snelle, vindbare headless websites lanceren. https://molt-studio.com/strategie/headless-website

Veelgestelde vragen

Goed om te weten.

Wat is een headless website?

Een site waarbij de inhoud los staat van de vormgeving. Teksten en beelden staan in een CMS of in bestanden, en de site haalt ze daar op bij het bouwen. Er is geen vast thema of platform dat bepaalt hoe je site eruitziet. Personio werkt zo, met Contentful als CMS en Next.js voor de site.

Wat is het verschil tussen een statische en een dynamische website?

Een dynamische site bouwt elke pagina op bij elk bezoek, zoals WordPress. Een statische site is vooraf gebouwd: de server stuurt vaste bestanden. Statisch zegt niets over hoe de site eruitziet. Formulieren, animaties en een chat werken gewoon.

Is een headless website sneller dan Webflow of Framer?

Niet vanzelf. Volgens het HTTP Archive heeft 71,2% van de Webflow-sites en 70,6% van de Framer-sites goede Core Web Vitals op mobiel, net zoveel als sites in Astro (71,0%). Sites in Next.js scoren met 35,1% zelfs slechter. Het verschil zit in hoeveel je meestuurt. Code geeft je daar wel meer controle over, en de site is van jou.

Wordt een site in code sneller geïndexeerd door Google?

Niet vanzelf. Vergeleken met een site die pas in de browser wordt opgebouwd, heb je een klein voordeel: Google hoeft niet eerst te renderen, en AI-crawlers lezen je tekst wel. Crawlbudget speelt voor een site van tientallen of honderden pagina’s geen rol. Snel in Google kom je met een sitemap, interne links en een aanvraag in Search Console.

Kan ik zelf teksten aanpassen als mijn site in code staat?

Ja, als er een CMS aan gekoppeld is. Dan pas je teksten en beelden aan in een editor, en blijft de site zelf in code. Zonder CMS laat je wijzigingen doen: met Site Care stuur je ze naar ons door, en wij regelen het. Zelf layouts in elkaar slepen, zoals in Webflow, is er meestal niet bij.

Wat kost hosting voor een site in code?

Bij Vercel is het gratis Hobby-plan alleen voor persoonlijk, niet-commercieel gebruik. Pro, bedoeld voor professionals en bedrijven, begint bij $ 20 per maand (vercel.com, oktober 2026). Netlify en Cloudflare bieden vergelijkbare hosting. Wat een hele site kost, lees je in wat kost een website?

Verlies ik mijn Google-posities als ik overstap?

Niet als je het goed voorbereidt. Houd je URL’s waar het kan, verwijs elke URL die verandert door naar het nieuwe adres, en neem je titels, beschrijvingen en inhoud mee. Vellum verhuisde in een week van Webflow naar code en hield zijn posities. Lees hoe een website migratie zonder SEO-verlies werkt.

Kan Molt een headless website voor mij bouwen?

Ja. Nieuwe sites bouwen we het liefst zo: vooraf gebouwd, in code, met een eigen designsysteem. We beginnen met een ontwerp van je nieuwe homepage, gratis, en binnen een week staat je preview klaar. Werkt je huidige platform goed, dan houden we het en maken we het sneller. Lees hoe een nieuwe homepage bij ons werkt.

Verder lezen

Lees ook dit.

Eerst zien

Zie je nieuwe site voordat je kiest.

We ontwerpen eerst je nieuwe homepage, gratis. Binnen een week staat je preview klaar, met de vaste prijs erbij.

Gratis en zonder verplichtingen.