WordPress naar Astro: zo scoren we de herbouw-beslissing

Het is 23:00 en een Nederlandse agency-eigenaar stuurt ons een mail door van haar grootste klant. Die klant las een thread over Astro en wil nu weten waarom hun WordPress-site, die nog steeds werkt, nog steeds rankt en nog steeds converteert, nog niet is gemigreerd. Ze moet vrijdag in het strategieoverleg een antwoord hebben. Ze heeft dertien van dit soort sites in beheer.

Deze mail krijgen we ongeveer vier keer per kwartaal. Het eerlijke antwoord is bijna nooit 'herbouwen op Astro' en bijna nooit 'laten staan'. Het eerlijke antwoord is een scorekaart met drie assen, en zodra je de site scoort, vertelt de beslissing zichzelf.

De twee echte opties, plus een tussenweg

Sla de marketingblog met zes opties over. In productie zijn er twee, met een derde tussenweg die de meeste agencies onderschatten.

Optie A: een geharde WordPress 6.7-stack. Auto-updates aan, minder dan vijftien plugins, de admin achter Cloudflare Zero Trust of een basic-auth gate, dagelijkse beheerde back-ups, en een staging-kopie die wekelijks de productie spiegelt. Het redactieteam werkt in Gutenberg. Content gaat binnen minuten live. WordPress 6.7 is een geloofwaardige verdedigingspositie, als je 'm ook daadwerkelijk patcht.

Optie B: een statische herbouw op Astro met content in markdown of MDX, gedeployed op Vercel of Cloudflare Pages, met afbeeldingen via een CDN. De site is snel, secure by default, en kost ongeveer tien euro per maand aan hosting. De redacteurs werken nu in een git-workflow of een headless CMS zoals Sanity, Storyblok of Payload.

Optie C, de tussenweg, is headless. WordPress blijft de redactieomgeving en de database, maar de front-end is Astro die data ophaalt uit de WP REST API of WPGraphQL, vaak met Advanced Custom Fields als schema-laag. De redacteur houdt haar Gutenberg-spiergeheugen. De bezoeker krijgt een statische pagina. De agency neemt de meeste operationele complexiteit voor haar rekening.

As 1: vaardigheid van de redacteur

Geef dit een score van één tot vijf.

Een één is een communicatiedirecteur van vijftig die uit Word plakt, de visuele editor gebruikt, en de agency belt als de afbeeldingengalerij stuk is. Een vijf is een contentteam dat publiceert via pull requests, weet wat een frontmatter-blok is, en markdown verkiest boven TinyMCE.

De eerlijke realiteit bij Nederlandse mkb'ers tussen de 500k en 50M omzet: de meeste redacteurs scoren een 2 of 3. Ze kunnen een YouTube-embedcode kopiëren. Ze kunnen geen merge conflict oplossen. Scoort jouw klant onder de 3, dan creëert een Astro-herbouw met een pure git-workflow een permanente afhankelijkheid van jou, de agency, voor elke typefout die hersteld moet worden. Dat is tegelijk een omzetkans en een relatierisico.

Een score van 4 of hoger en Astro met markdown is voor de redacteur écht sneller dan Gutenberg ooit was. We hebben contentteams hun publicatietempo zien verdriedubbelen, juist omdat pull request reviews ze dwingen om even stil te staan voordat ze publiceren.

As 2: contentvolume

Hoeveel contentupdates landen er gemiddeld per week, over de afgelopen zes maanden? Trek de WP audit log eruit of kijk naar wp_posts.post_modified en tel.

• Minder dan vijf updates per week: build time doet er niet toe. Astro wint op elke andere as.
• Vijf tot twintig: nog steeds prima voor Astro met incremental builds, maar dan moet je die ook echt configureren.
• Twintig tot honderd: een volledige rebuild bij elke save wordt een UX-probleem. De redacteur slaat op, ververst de preview, ziet niets veranderd, slaat opnieuw op. Nu heb je spook-edits.
• Meer dan honderd: blijf bij WordPress, tenzij je volledig headless gaat met on-demand revalidation, en zelfs dan: test een maand voordat je commit.

Een kleine SQL-query die je kunt draaien in phpMyAdmin of wp-cli:

SELECT
  DATE_FORMAT(post_modified, '%Y-%m') AS month,
  COUNT(*) AS edits
FROM wp_posts
WHERE post_status = 'publish'
  AND post_modified > DATE_SUB(NOW(), INTERVAL 6 MONTH)
GROUP BY month
ORDER BY month;

Ligt het maandelijkse gemiddelde onder de twintig, dan ligt Astro op tafel. Ligt het boven de honderd en zijn de redacteurs niet-technisch, dan kijk je vrijwel zeker naar de tussenweg, of blijf je waar je bent.

As 3: wie neemt om 23:00 de telefoon op

Dit is de as die niemand eerlijk scoort, en daarom zetten we 'm als laatste en wegen we 'm het zwaarst.

WordPress gaat op bekende manieren stuk. Plugin-update sloopt de winkelwagen. Themaconflict eet het menu op. Een managed host als Kinsta, WP Engine of Savvii heeft on-call engineers die de failure mode al kennen. De agency-eigenaar kan om 23:14 op zondag haar host bellen en binnen twintig minuten een rollback krijgen.

Astro gaat op nieuwere manieren stuk. Een build faalt omdat iemand een content collection-schema heeft aangepast. De CDN serveert een stale pagina omdat revalidation verkeerd staat. Sanity ligt eruit en de build kan geen content ophalen. Vercel deprecate op dinsdag een edge runtime API, en woensdag werkt jouw contactformulier niet meer.

Scoor de agency, niet de site:

• Weet iemand in het team om 23:00 een Vercel build log te lezen?
• Is er een runbook voor 'de site bouwt lokaal wel, maar op CI niet'?
• Heeft de agency een contract dat buiten kantooruren wordt betaald, of staat de agency-eigenaar zelf stand-by?

Is het antwoord op alle drie nee, zet je klant dan niet op een stack die de agency niet operationeel kan houden. Een verwaarloosde WordPress is nog altijd veiliger dan een Astro-site waarvan de beheerder geen build error kan debuggen.

De scorekaart

Neem de drie assen. Tel ze op. Het totaal loopt van 3 tot 15.

• 3 tot 7: geharde WordPress 6.7. Audit de plugins, vergrendel de admin, regel dagelijkse off-site back-ups, en factureer een kwartaalretainer voor onderhoud.
• 8 tot 11: de tussenweg. Astro-front-end, WordPress als headless bron. De redacteur houdt Gutenberg. De bezoeker krijgt een snelle statische pagina. De agency neemt de build pipeline op zich.
• 12 tot 15: volledige Astro-herbouw met markdown of een developer-vriendelijke headless CMS. Het redactieteam werkt in een git- of PR-flow. De agency committeert zich aan het monitoren van builds.

Dat is de hele methode. Je hebt geen Notion-document met twintig criteria nodig. Drie cijfers, een eerlijk gesprek, een beslissing.

De tussenweg is onderschat

De meeste sites die bij ons over de tafel komen, scoren tussen de 8 en 11. Headless WordPress met Astro aan de voorkant is voor hen echt het juiste antwoord, en de meeste agencies praten zichzelf eruit omdat de build pipeline zwaar voelt.

Licht is hij niet. Je gaat ACF met WPGraphQL inrichten, Astro-contentloaders schrijven, preview tokens afhandelen, en webhooks voor on-demand revalidation uitvogelen. Maar de redacteur opent nog steeds wp-admin, gebruikt nog steeds de Gutenberg-blokken waarop ze getraind is, en de publieke site staat niet langer één zero-day verwijderd van een defacement.

Toen we vorig jaar de tussenweg-herbouw deden voor een Nederlandse uitgever, was waar we tegenaan liepen dat ACF flexible content-blokken niet schoon op Astro-componenten mapten. Uiteindelijk hebben we het opgelost met codegen: een Astro build-stap leest de ACF JSON-export en genereert een getypeerde component-map, zodat de redacteur een nieuw blok in WP toevoegt en de developer in de volgende deploy een getypeerde prop krijgt. Dat soort plumbing zetten we voor agencies op binnen onze legacy migratie.

Een audit van vijf minuten voor vrijdag

Open vanavond de site van één klant. Scoor 'm op de drie assen. Is het totaal onder de 8 en zat je aan een Astro-herbouw te denken, stop daar dan mee. Is het totaal boven de 11 en zit de klant nog op een stack met zeventien plugins zonder patch-beleid, dan heb je je antwoord voor het vrijdagoverleg.