Repareer uw trage WordPress Membership Site: Een Headless Rebuild Gids
Los je trage WordPress-lidmaatschapssite op: een gids voor headless rebuild
Ik ben de telling kwijtgeraakt van het aantal site-eigenaren van lidmaatschapssites die met hetzelfde verhaal bij ons aankwamen: "We lanceerden op WordPress, het ging een tijdje goed, en nu is het pijnlijk traag." Ze hebben alles geprobeerd -- caching-plugins, CDN, hosting upgraden, plugins één voor één uitschakelen. Sommige dingen hebben geholpen. Meeste niet. En de echte klap? Hun leden vertrekken. Niet omdat de inhoud slecht is, maar omdat wachten op 6 seconden tot een lessinapagina laadt, mensen doet twijfelen of die €49/maand het waard is.
Als dat bekend klinkt, is dit artikel voor jou. Ik loop je precies langs waarom WordPress-lidmaatschapssites een performance-grens bereiken, wat je realistisch kunt repareren zonder een rebuild, en wanneer (en hoe) je headless gaat -- WordPress als je content-backend gebruiken met een modern frontend die echt snijdt.
Inhoudsopgave
- Waarom WordPress-lidmaatschapssites traag worden
- De echte performance-cijfers
- Kunt u dit zonder een rebuild repareren?
- Wanneer een headless rebuild zinvol is
- Architectuur van een headless lidmaatschapssite
- Je frontend-framework kiezen
- Authenticatie en toegangscontrole
- Het migratieproces stap voor stap
- Performance-resultaten: voor en na
- Kosten- en tijdlijnverwachtingen
- Veelgestelde vragen
Waarom WordPress-lidmaatschapssites traag worden
Laten we eerlijk zijn over wat er eigenlijk onder de motorkap gebeurt. Een typische WordPress-lidmaatschapssite is niet zomaar WordPress. Het is WordPress + MemberPress (of Restrict Content Pro, of WooCommerce Memberships) + een paginabouwer + een LMS-plugin + een community-plugin + een forms-plugin + analytics + waarschijnlijk nog 15-25 andere plugins. Elk voegt databasequery's toe. Elk laadt CSS- en JavaScript-bestanden. En ze stapelen op.
Hier is wat een typische aanvraag op een lidmaatschapssite eruitziet:
- Gebruiker raakt de pagina
- PHP verwerkt het verzoek (WordPress core)
- Lidmaatschapsplugin controleert of de gebruiker toegang heeft (databasequery)
- Als toegang wordt verleend, wordt de inhoud opgehaald (meer databasequery's)
- De paginabouwer stelt de lay-out samen (nog meer query's)
- LMS-plugin controleert voortgang, markeert voltooiingen (nog meer query's)
- Alle plugin CSS/JS-bestanden laden -- zelfs de niet nodig op deze pagina
- De gerenderde HTML arriveert eindelijk in de browser
Een enkele lessinapagina op een lidmaatschapssite die ik vorig jaar controleerde, maakte 147 databasequery's en laadde 43 afzonderlijke CSS/JS-bestanden. De pagina woog 4,2 MB. Op shared hosting duurde die pagina 7,8 seconden om te laden.
De plugin-belasting
Elke WordPress-plugin is in feite een haak in de uitvoeringspijplijn. Zelfs goed geschreven plugins voegen overhead toe. Maar lidmaatschapsplugins zijn bijzonder duur omdat ze bij elke paginalaad draaien om machtigingen te controleren. MemberPress bijvoorbeeld haalt zich in template_redirect, the_content, en verschillende andere filters. Vermenigvuldig dit over een site met 500+ beschermde pagina's en duizenden actieve leden, en je server doet serieus werk bij elk verzoek.
Het databaseprobleem
WordPress slaat alles op in één database. Gebruikersmetagegevens, post-metagegevens, lidmaatschapsniveaus, cursusvoortgang, transactiegeschiedenis -- alles leeft in wp_options, wp_usermeta, en wp_postmeta. Deze tabellen zijn nooit ontworpen voor het volume van gegevens dat een lidmaatschapssite genereert. Zodra je meer dan 10.000 leden hebt met cursusvoortgangsgegevens, zwellen deze tabellen op en worden query's traag.
Ik heb wp_usermeta-tabellen gezien met meer dan 2 miljoen rijen op lidmaatschapssites. Zonder correcte indexering (en WordPress's standaardschema indexeert meta_value niet), worden zelfs eenvoudige lookups pijnlijk traag.
De echte performance-cijfers
Laten we hier data achter zetten. Hier is een vergelijking van Core Web Vitals van WordPress-lidmaatschapssites die we hebben gecontroleerd versus wat we zien na headless rebuilds:
| Metrische waarde | WordPress + lidmaatschapsplugins | Headless rebuild (Next.js) | Google-doel |
|---|---|---|---|
| Largest Contentful Paint (LCP) | 4,2 - 8,1 s | 0,8 - 1,4 s | < 2,5 s |
| Interaction to Next Paint (INP) | 280 - 450 ms | 40 - 90 ms | < 200 ms |
| Cumulative Layout Shift (CLS) | 0,15 - 0,38 | 0,01 - 0,04 | < 0,1 |
| Time to First Byte (TTFB) | 1,2 - 3,8 s | 50 - 200 ms | < 0,8 s |
| Totaal paginagewicht | 2,8 - 5,2 MB | 180 - 400 KB | < 2 MB |
| HTTP-verzoeken | 45 - 90+ | 8 - 15 | < 60 |
Dit zijn geen theoretische nummers. Ze zijn van echte projecten. Het verschil is verbijsterend, en het heeft direct invloed op je onderste regel.
Elementor's onderzoek toont aan dat slechts 40,5% van WordPress-sites alle drie Core Web Vitals haalt. Voor lidmaatschapssites met hun extra plugin-belasting? Dat getal daalt aanzienlijk. Ondertussen halen Next.js-sites ongeveer 55% uit de doos -- en met de juiste optimalisatie, kun je veel hoger gaan.
En hier is het bedrijfsargument dat het meest uitmaakt: een verbeteringvan 0,1 seconde op mobiel verhoogt retail-conversietariefen met 8,4% volgens onderzoek van Deloitte. Voor een lidmaatschapssite die €49/maand aanrekent, betaalt zelfs een kleine afname in uitval van snellere paginalaadingen de rebuild binnen enkele maanden terug.
Kunt u dit zonder een rebuild repareren?
Eerlijke vraag. En het eerlijke antwoord is: soms ja. Voordat je je aan een volledige headless rebuild vastlegt, probeer dit:
Snelle winsten die echt helpen
Voer PHP 8.3+ uit. Dit alleen kan de performance al met 20-30% verbeteren. Controleer je versie op Dashboard → Gereedschappen → Site Health → Info → Server. Als je nog steeds op PHP 7.4 zit, laat je gratis performance liggen.
Schakel over naar kwaliteitshosting. Als je op shared hosting zit, ga naar managed WordPress-hosting (Cloudways, Kinsta, WP Engine). Budget €45-135/maand in plaats van €9. Dit is de enige grootste verbetering die de meeste mensen kunnen maken.
Installeer een object cache. Redis of Memcached. Dit cached databasequery-resultaten in het geheugen, wat enorm helpt voor lidmaatschapssites die de database bij elk verzoek belasten.
// wp-config.php - Schakel Redis object cache in
define('WP_REDIS_HOST', '127.0.0.1');
define('WP_REDIS_PORT', 6379);
define('WP_REDIS_DATABASE', 0);
Verwijder ongebruikte plugins en schakel scripts per pagina uit. Gebruik Asset CleanUp of Perfmatters om plugin CSS/JS op pagina's waar het niet nodig is uit te schakelen. Dit alleen kan 10-20 HTTP-verzoeken per pagina verwijderen.
Optimaliseer je database. Verwijder verlopen transients, maak post-revisies schoon, optimaliseer autoloaded opties:
-- Controleer autoloaded data grootte (moet onder 1 MB liggen)
SELECT SUM(LENGTH(option_value)) as autoload_size
FROM wp_options
WHERE autoload = 'yes';
-- Vind de grootste overtreders
SELECT option_name, LENGTH(option_value) as size
FROM wp_options
WHERE autoload = 'yes'
ORDER BY size DESC
LIMIT 20;
Wanneer deze fixes niet genoeg zijn
Het ding is: al deze optimalisaties zijn pleister op een fundamenteel architectuurprobleem. Je draait nog steeds PHP bij elk verzoek. Je vraagt nog steeds een MySQL-database op om machtigingen te controleren. Je laadt nog steeds WordPress core -- alle 70.000+ regels ervan -- voordat ook maar één byte van je werkelijke inhoud wordt geserveerd.
Als je lidmaatschapssite minder dan 1.000 leden heeft en minder dan 200 inhoudsdelen, kunnen de bovenstaande optimalisaties je naar aanvaardbare performance brengen. Maar als je groeit -- en groei is vermoedelijk het doel -- zul je dezelfde muur opnieuw raken.
Wanneer een headless rebuild zinvol is
Een headless rebuild is niet voor iedereen het juiste. Hier is wanneer het zinvol is:
- Je hebt 1.000+ actieve leden en de performance verslechtert terwijl je groeit
- Je contentteam is blij met WordPress voor contentbeheer (ze haten alleen hoe traag de site is)
- Je hebt de site op meerdere platforms nodig -- web, mobiele app, misschien een API voor partners
- Je Core Web Vitals fail en het beïnvloedt SEO en conversies
- Je hebt al geprobeerd de bovenstaande optimalisatiestappen en bereikt dalende rendementen
- Je besteedt meer tijd aan het bestrijden van WordPress dan aan het bouwen van je bedrijf
En hier is wanneer het niet zinvol is:
- Je bent een solo-maker met een kleine site en beperkt budget
- Je contentteam kan niet zonder een visuele paginabouwer voor elke pagina werken
- Je hebt geen ontwikkelaar (of bureau) die een ontkoppelde architectuur kan onderhouden
- Je performanceproblemen zijn eigenlijk gewoon slechte hosting
Architectuur van een headless lidmaatschapssite
Laten we in de werkelijke architectuur duiken. Dit is wat een headless lidmaatschapssite eruitziet:
┌─────────────────┐ ┌──────────────────┐ ┌─────────────────┐
│ WordPress │ │ Next.js │ │ CDN │
│ (Backend) │────▶│ (Frontend) │────▶│ (Vercel/CF) │
│ │ API │ │ │ │
│ - Inhoud │ │ - SSR/SSG-pagina's│ │ - Edge caching │
│ - Gebruikersdata│ │ - Auth-verwerking │ │ - Wereldwijde │
│ - Lidmaatschappen│ │ - Toegangscontrole│ │ distributie │
│ - WP REST API │ │ - Cursusvoortgang │ │ │
│ of WPGraphQL │ │ │ │ │
└─────────────────┘ └──────────────────┘ └─────────────────┘
De inhoudlaag
WordPress blijft je CMS. Je contentteam blijft de editor gebruiken die ze kennen. Je geeft inhoud bloot via de WP REST API (ingebouwd) of WPGraphQL (veel beter voor dit geval). Ik raad WPGraphQL sterk aan -- het laat je exact de gegevens ophalen die je nodig hebt in één verzoek in plaats van meerdere REST-oproepen.
# Haal een les op met zijn cursus en toegangsvereisten
query GetLesson($slug: String!) {
lessonBy(slug: $slug) {
title
content
lessonFields {
duration
videoUrl
requiredMembershipLevel
}
course {
node {
title
slug
lessons {
nodes {
title
slug
}
}
}
}
}
}
De verificatielaag
Dit is waar het interessant wordt. Op een traditionele WordPress-lidmaatschapssite wordt verificatie verwerkt door cookies en wp_get_current_user(). In een headless-setup heb je een correct token-gebaseerd auth-systeem nodig.
We gebruiken meestal één van twee benaderingen:
- JWT-verificatie -- WordPress geeft een JWT uit bij inloggen, de frontend slaat het op en stuurt het mee met API-verzoeken
- NextAuth.js met WordPress als provider -- flexibeler, ondersteunt social login, beter sessiebeheer
Voor de meeste lidmaatschapssites is optie 2 beter:
// app/api/auth/[...nextauth]/route.ts
import NextAuth from 'next-auth'
import CredentialsProvider from 'next-auth/providers/credentials'
export const authOptions = {
providers: [
CredentialsProvider({
name: 'WordPress',
credentials: {
username: { label: 'E-mail', type: 'email' },
password: { label: 'Wachtwoord', type: 'password' },
},
async authorize(credentials) {
const res = await fetch(
`${process.env.WP_URL}/wp-json/jwt-auth/v1/token`,
{
method: 'POST',
headers: { 'Content-Type': 'application/json' },
body: JSON.stringify({
username: credentials?.username,
password: credentials?.password,
}),
}
)
const user = await res.json()
if (res.ok && user) {
return {
id: user.user_id,
name: user.user_display_name,
email: user.user_email,
token: user.token,
}
}
return null
},
}),
],
}
De toegangscontrolelaag
Toegangscontrole in een headless-setup gebeurt op de frontend-laag. De frontend controleert het lidmaatschapsniveau van de gebruiker voordat beschermde inhoud wordt weergegeven. Dit is eigenlijk veiliger dan traditioneel WordPress omdat zelfs als iemand de paginabron bekijkt, de beschermde inhoud nooit naar de browser werd verzonden -- deze wordt bij SSR op serverniveau gated.
// middleware.ts - Bescherm lidmaatschapsroutes op de edge
import { withAuth } from 'next-auth/middleware'
export default withAuth({
callbacks: {
authorized: ({ token, req }) => {
const path = req.nextUrl.pathname
if (path.startsWith('/courses/')) {
return token?.membershipLevel === 'premium' ||
token?.membershipLevel === 'lifetime'
}
if (path.startsWith('/community/')) {
return !!token
}
return true
},
},
})
export const config = {
matcher: ['/courses/:path*', '/community/:path*', '/dashboard/:path*'],
}
Je frontend-framework kiezen
Voor lidmaatschapssites specifiek, hier is hoe de belangrijkste opties zich stapelen:
| Framework | Best voor | SSR-ondersteuning | Auth-verhaal | Leercurve |
|---|---|---|---|---|
| Next.js (App Router) | Dynamische lidmaatschapssites met frequent content updates | Uitstekend | NextAuth.js is volwassen | Gemiddeld |
| Astro | Content-zware sites met minimale interactiviteit | Goed (hybrid) | Vereist meer DIY | Lager |
| Remix | Complexe gebruikersinteracties, forms-zware sites | Uitstekend | Ingebouwde patronen | Gemiddeld |
| SvelteKit | Teams die kleinere bundelmaten willen | Uitstekend | Groeiend ecosysteem | Gemiddeld |
Voor de meeste lidmaatschapssites is Next.js de juiste keuze. Het handelt het mengsel van statische inhoud (marketingpagina's, blogposts) en dynamische inhoud (dashboards, cursusvoortgang, community-functies) beter af dan alles anders momenteel. De App Router met React Server Components laat je gegevens op de server ophalen zonder de gegevenspullcode naar de browser te sturen.
We doen veel Next.js-ontwikkeling specifiek voor dit soort project. Als je site meer content-zwaar is met minder dynamische interactie -- denk een content-bibliotheeklidmaatschap zonder community-functies -- kan Astro zelfs sneller zijn omdat het standaard nul JavaScript verzendt.
Authenticatie en toegangscontrole
Lidmaatschapslagen hanteren
De meeste lidmaatschapssites hebben meerdere lagen. Gratis, basis, premium, misschien een lifetime-laag. In een headless-architectuur sla je lidmaatschapsgegevens op in WordPress en synchroniseer je ze met de sessie van je frontend.
De flow ziet er als volgt uit:
- Gebruiker logt in → frontend verifieert tegen WordPress → JWT wordt uitgegeven
- JWT bevat lidmaatschapsniveauclaims
- Frontend-middleware controleert deze claims op elke beschermde route
- Inhoud wordt opgehaald uit WordPress API alleen als de gebruiker het juiste toegangsniveau heeft
- Sessie wordt periodiek vernieuwd om lidmaatschapswijzigingen op te vangen (upgrades, vervaldatums, annuleringen)
Betalingsintegratie
Stripe is de standaard hier. Je hebt twee opties:
- Houd Stripe-integratie in WordPress met MemberPress of WooCommerce Subscriptions, en synchroniseer status naar de frontend
- Verplaats Stripe naar de frontend met Stripe Checkout en webhooks, met WordPress als gegevensopslagplaats
Optie 2 is op lange termijn schoner. Stripe Checkout handelt PCI-naleving af, en je kunt webhooks in Next.js API-routes verwerken:
// app/api/webhooks/stripe/route.ts
import Stripe from 'stripe'
const stripe = new Stripe(process.env.STRIPE_SECRET_KEY!)
export async function POST(req: Request) {
const body = await req.text()
const sig = req.headers.get('stripe-signature')!
const event = stripe.webhooks.constructEvent(
body,
sig,
process.env.STRIPE_WEBHOOK_SECRET!
)
switch (event.type) {
case 'customer.subscription.created':
case 'customer.subscription.updated':
// Werk lidmaatschapsniveau in WordPress bij via REST API
await updateWordPressMembership(event.data.object)
break
case 'customer.subscription.deleted':
// Downgrade naar gratis laag
await revokeMembership(event.data.object)
break
}
return new Response('OK', { status: 200 })
}
Het migratieproces stap voor stap
Dit is het werkelijke migratieproces dat we volgen. Dit is niet theoretisch -- het is het playbook dat we gebruiken voor headless CMS rebuilds.
Fase 1: Audit en architectuur (Week 1-2)
- Controleer huidige site-performance (Lighthouse, WebPageTest, metrieken van echte gebruikers)
- Wijzig alle inhoudstypen, lidmaatschapslagen en gebruikersflows
- Documenteer elke integratie (betalingsprocessor, e-mailservice, analytics, enz.)
- Ontwerp de headless-architectuur
- Stel WPGraphQL en aangepaste typen in
Fase 2: Backend-voorbereiding (Week 2-3)
- Installeer en configureer WPGraphQL
- Maak aangepaste GraphQL-velden voor lidmaatschapsgegevens
- Bouw aangepaste REST-endpoints voor authenticatie
- Stel JWT-authenticatie in
- Test alle API-endpoints grondig
Fase 3: Frontend-build (Week 3-6)
- Steiger Next.js-project met App Router
- Implementeer authenticatiestroom
- Maak paginasjablonen (marketingpagina's, cursuspagina's, lessinapagina's, dashboard)
- Implementeer toegangscontrole-middleware
- Verbind Stripe-integratie
- Bouw het liddashboard
Fase 4: Testen en migratie (Week 6-8)
- Performance-testen en optimalisatie
- Cross-browser en apparaattesten
- User acceptance testing met echte leden
- DNS-migratie en lancering
- Monitor de performance voor de eerste 2 weken na lancering
Performance-resultaten: voor en na
Hier is een echt voorbeeld van een lidmaatschapssite die we in begin 2026 hebben herbouwd. De site had ongeveer 8.000 actieve leden, 400+ lessen verspreid over 12 cursussen en een communityforum.
| Metrische waarde | Voor (WordPress + MemberPress + LearnDash) | Na (Next.js + WordPress Headless) |
|---|---|---|
| LCP (mobiel) | 6,2 s | 1,1 s |
| INP | 380 ms | 65 ms |
| CLS | 0,24 | 0,02 |
| TTFB | 2,8 s | 85 ms |
| Lighthouse Performance | 28 | 96 |
| Paginagewicht (lessinapagina) | 3,8 MB | 290 KB |
| Maandelijks uitvalpercentage | 8,2% | 5,1% (3 maanden na rebuild) |
Die uitvalreductie alleen -- van 8,2% naar 5,1% -- vertegenwoordigde ongeveer €12.500/maand aan behouden inkomsten voor deze specifieke site. De rebuild betaalde voor zichzelf in minder dan 3 maanden.
Kosten- en tijdlijnverwachtingen
Laten we eerlijk zijn over kosten. Een headless rebuild is niet goedkoop, maar het is ook niet zo duur als de meeste mensen aannemen wanneer je het ROI factoreert.
| Projectomvang | Tijdlijn | Budgetbereik |
|---|---|---|
| Eenvoudig lidmaatschap (1-2 lagen, alleen contentbibliotheek) | 6-8 weken | €13.500 - €27.000 |
| Gemiddeld lidmaatschap (meerdere lagen, cursussen, voortgangstracking) | 8-12 weken | €27.000 - €54.000 |
| Complex lidmaatschap (cursussen, community, gamificatie, mobiel) | 12-20 weken | €54.000 - €108.000+ |
Ter vergelijking: de traditionele WordPress-benadering met premium plugins kost €2.700-€9.000 vooraf, maar stapelt zich op in voortdurende kosten in hostingupgrades, plugin-licenties (€450-€1.350/jaar), en de constante strijd tegen performanceverslecht
ering.
Als je wilt bespreken wat een headless rebuild voor je specifieke site zou zijn, bieden we gratis architectuurconsultaties aan. Geen pitchdeck, gewoon een eerlijk gesprek over of het voor je situatie zinvol is.
Je kunt ook onze prijspagina controleren voor algemene engagementstructuren.
Veelgestelde vragen
Moet mijn contentteam een nieuw CMS leren? Nee, en dit is één van de grootste voordelen van de headless WordPress-benadering. Je contentteam blijft WordPress gebruiken precies zoals ze vandaag doen. Ze loggen in op hetzelfde admin-paneel, gebruiken dezelfde editor, en beheren inhoud op dezelfde manier. Het enige verschil is dat de frontend -- wat bezoekers zien -- is gebouwd met een modern framework. Je team zal geen verandering in hun workflow opmerken.
Hoe werkt SEO op een headless lidmaatschapssite? Met Next.js en server-side rendering ontvangen zoekmachines volledig gerenderde HTML, net als ze van een traditionele WordPress-site zouden ontvangen. Eigenlijk is het beter -- omdat pagina's sneller laden, verbeteren je Core Web Vitals, en Google gebruikt die als rankingsignalen. Je hoeft je sitemap-generatie en meta-tags in de Next.js-laag te hanteren, maar frameworks zoals next-seo maken dit eenvoudig. We zien sites doorgaans in zoekrangschikking verbeteren binnen 4-6 weken na een headless-migratie.
Kan ik MemberPress of WooCommerce blijven gebruiken voor betalingen? Je kunt, maar we raden over het algemeen aan om betalingsverwerking rechtstreeks naar Stripe op de frontend te verplaatsen. Het is schoner, beter onderhoudbaar, en geeft je beter controle over de checkout-ervaring. Als je diep geïntegreerd bent met MemberPress en je factureringssetup niet wilt veranderen, kun je het aan de WordPress-kant houden en de lidmaatschapsstatus naar de frontend via API synchroniseren. Het werkt, het is gewoon een extra laag om te onderhouden.
Wat gebeurt er als de WordPress-backend uitvalt? Dit is eigenlijk één van de voordelen van headless gaan. Als je statische generatie voor publieke pagina's gebruikt, worden die pagina's in een CDN gecached en blijven ze serveren zelfs als WordPress volledig offline is. Dynamische pagina's (dashboard, cursusvoortgang) zullen worden beïnvloed, maar je kunt elegant foutbeheer implementeren dat gecacheerde inhoud toont of een onderhoudsbericht. In een traditionele WordPress-setup, als WordPress uitvalt, valt alles uit.
Hoe ga ik om met alleen-lid-inhoud zodat deze niet in de API wordt blootgesteld? Dit is een kritiek beveiligingsprobleem. Je stelt nooit beschermde inhoud bloot in openbare API-endpoints. Beschermde inhoud mag alleen toegankelijk zijn via geverifieerde API-verzoeken. In WPGraphQL kun je toegangscontrolegels gebruiken die het lidmaatschapsniveau van de verzoeker controleren voordat inhoud wordt geretourneerd. De frontend gebruikt vervolgens de JWT van de geverifieerde gebruiker om deze verzoeken server-kant te doen, dus de inhoud raakt de browser nooit tenzij de gebruiker is geautoriseerd.
Is headless WordPress duurder om te hosten? De WordPress-backend wordt eigenlijk goedkoper om te hosten omdat het minder werk doet -- slechts API-reacties serveert in plaats van volledige pagina's te renderen. Je voegt een hostingkost toe voor de frontend (Vercel's Pro-plan is €18/maand per teamlid, of je kunt zelf-host op een VPS). Totale hostingkosten zijn meestal hetzelfde of iets hoger, maar de performanceverbeteringis dramatisch. Veel teams stellen vast dat ze hun WordPress-hosting kunnen downgraden omdat het niet langer rechtstreeks verkeer afhandelt.
Kan ik geleidelijk migreren in plaats van een volledige rebuild? Ja, en we raden deze benadering soms aan. Je kunt beginnen met het bouwen van slechts de publiek gerichte pagina's (marketing, blog) als een headless frontend terwijl je de ledenzone op traditioneel WordPress houdt. Migreer dan het liddashboard, dan cursussen, dan community. Dit reduceert risico en laat je de benadering valideren voordat je helemaal erin gaat. Next.js middleware maakt het gemakkelijk om bepaalde paden tijdens de overgang terug naar je WordPress-installatie in te voegen.
Hoe lang duurt de migratie zonder downtime? Downtime-vrije migratie is standaardpraktijk. Je bouwt de volledige nieuwe frontend terwijl de bestaande site blijft draaien. Als alles is getest en klaar, werk je DNS-records bij om naar de nieuwe frontend te wijzen. De omschakeling duurt minuten, en als er iets misgaat, kun je DNS onmiddellijk terugdraaien. We houden de oude WordPress-frontend normaal 2-4 weken als veiligheidsmaatregel parallel.