Je cliënt belt: hun WooCommerce-winkel is opnieuw gehackt. Je hebt het vorige maand schoongemaakt—de backdoor verwijderd, drieëntwintig plugins gepatched, inloggegevens gereset. Maar vanmorgen heeft hun betalingsverwerker verdachte kaartactiviteit gemarkeerd. Je SSH-t in en vindt het: een credit card skimmer verstopt in een legitiem ogende analytics-plugin die dinsdagnacht automatisch bijgewerkt is. Hetzelfde verhaal, ander plugin. Het aanvalsoppervlak is geen bug in WordPress core—het zijn de zevenendertig third-party plugins waarvan hun site afhankelijk is om te functioneren. Elk ervan is een deur. De meeste worden traag gepatched. Sommige worden nooit gepatcht. Migratie naar Next.js + Supabase schoon niet alleen de infectie—het verwijdert de hele plugin-laag waar 90% van WordPress-inbreuken vandaan komen.

Dit artikel gaat niet over het afkraken van WordPress. Het zette een groot deel van het web aan voor goede redenen. Maar de architectuur die het toegankelijk maakte in 2005 is dezelfde architectuur die het in 2026 een magneet voor geautomatiseerde aanvallen maakt. Als je bent gehackt—of je bent het zat geld uit te geven aan beveiligingsplugins die zelf aanvalsvectoren zijn—dit is je speelboek voor het verplaatsen naar iets fundamenteel veiliger.

Inhoudsopgave

WordPress Gehackt? Waarom migratie naar Next.js + Supabase je beste oplossing is

Het WordPress-beveiligingsprobleem is architecturaal

Laat me duidelijk zijn over iets: het WordPress core-team doet solide beveiligingswerk. WordPress core, up-to-date gehouden, is redelijk veilig. Maar niemand draait alleen WordPress core. De gemiddelde WordPress-site heeft 20-30 plugins geïnstalleerd. Elk ervan is een afhankelijkheid die je niet hebt geschreven, onderhouden door iemand die je niet kent, met toegang tot je database, je bestandssysteem en de gegevens van je gebruikers.

Hier is het ding dat voortdurend gemist wordt in "WordPress-beveiligingsbest practices"-artikelen: het probleem is niet dat WordPress-siteeigenaren nalatig zijn. Het probleem is dat de WordPress-architectuur vereist dat je uitvoerbare PHP-code van derden rechtstreeks op je server installeert om basisfunctionaliteit te krijgen. Dat is gelijk aan het geven van elke aannemer die aan je huis werkt een kopie van je huissleutel—permanent.

WPScan's kwetsbaarhedendatabase volgde meer dan 7.900 nieuwe WordPress-kwetsbaarheden in 2024, waarbij plugins ongeveer 96% ervan waren. Het 2024 dreigingsrapport van Sucuri vond dat WordPress ongeveer 95% van alle CMS-infecties vertegenwoordigde die ze schoonmaakten. En Patchstack rapporteerde dat 33% van kritieke WordPress-kwetsbaarheden in 2024 geen patch beschikbaar had op het moment van openbaarmaken.

Dit zijn geen bugs die kunnen worden opgelost met betere codeerpraktijken. Het zijn opkomende eigenschappen van de architectuur zelf.

Veelvoorkomende WordPress-aanvalsvectoren in 2026

Voordat we het over de oplossing hebben, moeten we catalogi maken wat je eigenlijk verdedigt. Ik heb persoonlijk tientallen gecompromitteerde WordPress-sites getrieerd, en de aanvallen vallen in voorspelbare patronen.

SQL-injectie via plugins

WordPress gebruikt een MySQL-database met een goed gedocumenteerd schema. Elk plugin dat gebruikersinvoer accepteert en de database aanraakt, is een potentieel SQL-injectiepunt. De $wpdb->prepare()-functie bestaat, maar deze is opt-in. Plugin-ontwikkelaars vergeten het, gebruiken het verkeerd, of slaan het volledig over voor "eenvoudige" query's.

Ik heb eens een injectie teruggebracht naar een contactformulier-plugin die 18 maanden was verlaten, maar nog steeds geïnstalleerd was op 200.000+ sites. De aanvaller gebruikte een UNION-gebaseerde injectie om de wp_users-tabel te dumpen, admin-wachtwoordhashes te grabben en de zwakke op te kraken offline.

-- Wat een typische WordPress SQL-injectie in logs eruit ziet
GET /wp-content/plugins/vulnerable-plugin/ajax.php?id=1%20UNION%20SELECT%201,user_login,user_pass,4,5%20FROM%20wp_users--

PHP-objectinjectie en externe code-uitvoering

WordPress's intensief gebruik van serialize() en unserialize() creëert mogelijkheden voor PHP-objectinjectie. Wanneer een plugin door gebruiker gecontroleerde gegevens unserialisiert (en veel doen), kan een aanvaller payloads maken die willekeurige code uitvoeren tijdens het unserializatieproces.

In 2024 stelde een kritieke RCE-kwetsbaarheid in een populaire backup-plugin (geïnstalleerd op 5 miljoen+ sites) aanvallers in staat willekeurige PHP-code uit te voeren. Het duurde 11 dagen voordat de fix werd verzonden. Elf dagen waarin elke site met die plugin een makkie was.

Plugin-toeleveringsketen-aanvallen

Dit is degene die me het meest bang maakt. Aanvallers kopen verlaten plugins met grote installatiegebieden, duwen een "beveiligingsupdate" met een achterdeur, en WordPress auto-update-mechanismen distribueren de malware naar elke site met die plugin. Het gebeurde met Display Widgets (300.000 installaties) en Social Warfare (70.000 installaties), en dat zijn alleen de degenen die betrapt werden.

Brute Force-aanvallen op wp-login.php

Elke WordPress-site stelt /wp-login.php en /xmlrpc.php standaard bloot. Geautomatiseerde botnets slaan constant op deze eindpunten. Wordfence rapporteerde het blokkeren van gemiddeld 3 miljard schadelijke verzoeken per maand in hun netwerk in 2024. Zelfs met snelheidsbeperking en twee-factorverificatie, besteed je serverresources aan het verwerken van deze aanvallen.

Cross-Site Scripting (XSS) via thema's en plugins

Opgeslagen XSS in WordPress is bijzonder gevaarlijk omdat het adminsdashboard en de openbare site dezelfde sessiecontext delen. Een XSS-payload die via een opmerking, een formulierverzending of een kwetsbare plugin-instelling wordt geïnjecteerd, kan escaleren naar volledige admin-toegang.

Waarom Headless-architectuur hele aanvalscategorieën elimineert

Hier wordt het interessant. Een headless-architectuur vermindert niet alleen je aanvalsoppervlak—het elimineert hele categorieën aanvallen door de omstandigheden te verwijderen die ze mogelijk maken.

In een traditionele WordPress-setup doet dezelfde server die je HTML rendert ook:

  • PHP-code uit 20+ third-party plugins uitvoeren
  • Gebruikersverificatie beheren
  • Verbinding met de database maken
  • Het admin-interface serveren
  • Bestandsuploads afhandelen
  • Formulierverzoeken verwerken

Dat is veel verantwoordelijkheden voor een enkele applicatie. In een headless-setup met Next.js en Supabase worden deze verantwoordelijkheden verdeeld over geïsoleerde services:

  • Frontend (Next.js op Vercel/Netlify): Statische HTML/JS bediend vanuit een CDN. Geen server-side runtime blootgesteld aan het openbare internet in de meeste gevallen.
  • Database + Auth (Supabase): Beheerde Postgres met Row Level Security, nooit rechtstreeks blootgesteld aan eindgebruikers.
  • API-laag: Serverless-functies met expliciete, minimale eindpunten.
  • CMS (indien nodig): Headless CMS draaiend op zijn eigen geïsoleerde infrastructuur.

Er is geen PHP om in in te injecteren. Er is geen plugin-directory met schrijftoegang. Er is geen gedeelde sessie tussen de admin en de openbare site. Er is geen wp-login.php voor bots om op in te slaan.

Je hebt geen WAF nodig om een aanvalsoppervlak te beschermen dat niet bestaat.

WordPress Gehackt? Waarom migratie naar Next.js + Supabase je beste oplossing is - architectuur

Next.js + Supabase: een beveiligings-eerste stack

Wees specifiek over waarom deze specifieke combinatie vanuit beveiligingsoogpunt zo goed werkt.

Next.js: de frontend die geen code draait

Wanneer je een Next.js-site bouwt met statische generatie (SSG) of incrementele statische regeneratie (ISR), wat wordt gedeployed zijn HTML-, CSS- en JavaScript-bestanden op een CDN. Er is geen applicatieserver die in realtime verzoeken verwerkt. Je kunt geen CDN SQL-injecteren.

Voor dynamische functionaliteit worden Next.js Server Actions en Route Handlers als serverless-functies uitgevoerd. Elke functie is:

  • Geïsoleerd in zijn eigen uitvoeringscontext
  • Stateless (geen gedeeld geheugen tussen verzoeken)
  • Kortdurend (koude start, uitvoering, beëindiging)
  • Expliciet gedefinieerd (geen auto-detectie van eindpunten)
// Next.js Route Handler -- expliciet, getypt, minimaal
import { createClient } from '@/lib/supabase/server'
import { NextRequest, NextResponse } from 'next/server'
import { z } from 'zod'

const ContactSchema = z.object({
  name: z.string().min(1).max(100),
  email: z.string().email(),
  message: z.string().min(10).max(5000),
})

export async function POST(request: NextRequest) {
  const body = await request.json()
  const parsed = ContactSchema.safeParse(body)
  
  if (!parsed.success) {
    return NextResponse.json({ error: 'Ongeldige invoer' }, { status: 400 })
  }
  
  const supabase = await createClient()
  const { error } = await supabase
    .from('contact_submissions')
    .insert(parsed.data)
  
  if (error) {
    return NextResponse.json({ error: 'Inzending mislukt' }, { status: 500 })
  }
  
  return NextResponse.json({ success: true })
}

Vergelijk dat met een WordPress-contactformulier-plugin die in WordPress's actiesysteem moet inwerken, zijn eigen AJAX-handler moet opnemen, zijn eigen nonce-verificatie moet beheren, en zijn eigen SQL-query's moet bouwen. De Next.js-versie heeft minder bewegende delen, gevalideerde invoer via Zod, en geparametriseerde query's via de Supabase-client.

Supabase: Postgres met Row Level Security

Supabase geeft je een beheerde PostgreSQL-database met één killer-beveiligingsfunctie: Row Level Security (RLS). In plaats van erop te vertrouwen dat je toepassingscode toegangscontrole afdwingt (het WordPress-model), definieer je beveiligingsbeleid op databaseniveau.

-- Alleen geverifieerde gebruikers kunnen hun eigen gegevens lezen
CREATE POLICY "Gebruikers kunnen eigen profiel bekijken"
  ON profiles
  FOR SELECT
  USING (auth.uid() = user_id);

-- Openbaar kan contactformulier invoegen maar niet lezen
CREATE POLICY "Iedereen kan contactformulier indienen"
  ON contact_submissions
  FOR INSERT
  WITH CHECK (true);

CREATE POLICY "Alleen admins kunnen inzendingen lezen"
  ON contact_submissions
  FOR SELECT
  USING (auth.jwt() ->> 'role' = 'admin');

Zelfs als een aanvaller een manier vindt om willekeurige Supabase-query's uit te voeren (wat al veel moeilijker is zonder een PHP-uitvoeringscontext), voorkomen RLS-beleid dat ze gegevens openen die ze niet zouden moeten zien. Dit is verdediging in diepte die WordPress fundamenteel niet kan bieden omdat zijn toestemmingssysteem in PHP-code is geïmplementeerd, niet op databaseniveau.

Supabase handelt ook verificatie af met ingebouwde ondersteuning voor email/wachtwoord, magische koppelingen, OAuth-providers en multi-factor-verificatie. Geen plugin vereist. Geen third-party-code draaiend op je server.

Aanvalsoppervlak-vergelijking: WordPress vs Headless

Laat dit naast elkaar zetten.

Aanvalsvector WordPress Next.js + Supabase
SQL-injectie Hoog risico -- plugins bouwen raw query's Bijna nul -- geparametriseerde query's via Supabase-client, RLS als back-up
PHP/externe code-uitvoering Hoog risico -- plugins voeren server-side PHP uit Niet van toepassing -- geen PHP-runtime
Plugin-toeleveringsketen Kritiek risico -- auto-updates distribueren malware Niet van toepassing -- geen plugin-ecosysteem
Brute Force (inloggen) Altijd blootgesteld (wp-login.php, xmlrpc.php) Admin-toegang via Supabase Auth of apart dashboard, geen openbaar inlogpunt vereist
XSS (opgeslagen) Hoog risico -- gedeelde admin/openbare context Laag risico -- React escapeert uitvoer standaard, admin en openbaar zijn afzonderlijke apps
Bestandsuploading-exploitatie Hoog risico -- geüploade PHP-bestanden kunnen uitvoeren Laag risico -- uploads gaan naar objectopslag (Supabase Storage/S3), nooit uitgevoerd als code
Database-blootstelling Directe MySQL-toegang als server is gecompromitteerd Database achter Supabase-infrastructuur, RLS-beleid als uiteindelijke bewaker
DDoS op Oorsprong Server moet elk verzoek verwerken Statische assets op CDN, oorsprong zelden geraakt
Padopsomming bekend wp-admin, wp-content, wp-includes allemaal scanbaar Geen voorspelbare paden, geen blootgestelde admin-routes

Het migratie-speelboek: WordPress naar Next.js + Supabase

Oké, je bent overtuigd (of je gehackte site heeft je overtuigd). Hier is hoe je dit eigenlijk doet. We hebben deze migratie genoeg keer uitgevoerd om een herhaalbaar proces te hebben.

Fase 1: Triage en inhoudaudit (week 1)

Voordat je een code aanraakt, moet je begrijpen wat je eigenlijk hebt.

  1. Exporteer alle WordPress-inhoud met WP-CLI of de REST API. Vertrouw niet op XML-exports -- ze missen metavelden en aangepaste posttypen.
  2. Catalogi alle functionaliteit geleverd door plugins. Maak een spreadsheet: plugin-naam, wat het doet, of je het echt nodig hebt, en wat het vervangt.
  3. Toewijzings-URL-structuren voor SEO-behoud. Elke bestaande URL heeft een omleiding nodig of een overeenkomende route in Next.js.
  4. Identificeer dynamische functies -- formulieren, zoekopdracht, gebruikersaccounts, ecommerce -- die API-eindpunten nodig hebben.
# Exporteer WordPress-inhoud via REST API
curl -s "https://yoursite.com/wp-json/wp/v2/posts?per_page=100&page=1" | jq '.' > posts_page1.json
curl -s "https://yoursite.com/wp-json/wp/v2/pages?per_page=100" | jq '.' > pages.json
curl -s "https://yoursite.com/wp-json/wp/v2/media?per_page=100" | jq '.' > media.json

Fase 2: Supabase-schema en gegevensmigratie (week 2)

Ontwerp je Supabase-databaseschema op basis van de inhoudaudit. Repliceer niet zomaar het WordPress-schema -- het is opgeblazen met metadatatafels en geserialiseerde gegevenblobs.

-- Schoon, doelgericht schema
CREATE TABLE posts (
  id UUID DEFAULT gen_random_uuid() PRIMARY KEY,
  title TEXT NOT NULL,
  slug TEXT UNIQUE NOT NULL,
  content TEXT,
  excerpt TEXT,
  featured_image TEXT,
  status TEXT DEFAULT 'draft' CHECK (status IN ('draft', 'published', 'archived')),
  published_at TIMESTAMPTZ,
  created_at TIMESTAMPTZ DEFAULT NOW(),
  updated_at TIMESTAMPTZ DEFAULT NOW(),
  author_id UUID REFERENCES auth.users(id)
);

-- Schakel RLS onmiddellijk in
ALTER TABLE posts ENABLE ROW LEVEL SECURITY;

CREATE POLICY "Gepubliceerde posts zijn openbaar"
  ON posts FOR SELECT
  USING (status = 'published');

CREATE POLICY "Auteurs kunnen eigen posts beheren"
  ON posts FOR ALL
  USING (auth.uid() = author_id);

Schrijf een migratiescript (Node.js of Python) dat WordPress JSON-exports in je nieuw schema omzet en in Supabase invoegt.

Fase 3: Next.js Build (weken 3-5)

Bouw je Next.js-frontend. Als je werkt met een team dat de stack kent, gaat dit snel. Als je hulp nodig hebt, heeft ons Next.js-ontwikkelingsteam deze migratie genoeg keer gedaan om sterke meningen te hebben over de juiste patronen.

Sleutelarchitectuurbesluiten:

  • Statische generatie voor inhoudspagina's -- blogposts, landingspagina's, over pagina's. Deze worden HTML-bestanden op een CDN.
  • Servercomponenten voor dynamische gegevens -- ophalen van Supabase op aanvraagstijd met caching.
  • Route-handlers voor formulierinzendingen -- contactformulieren, nieuwsbriefaanmeldingen, enz.
  • Middleware voor omleidingen -- al je oude WordPress-URL's afhandelen.
// next.config.ts -- WordPress URL-omleidingen afhandelen
const nextConfig = {
  async redirects() {
    return [
      {
        source: '/category/:slug',
        destination: '/blog/category/:slug',
        permanent: true,
      },
      {
        source: '/:year(\\d{4})/:month(\\d{2})/:slug',
        destination: '/blog/:slug',
        permanent: true,
      },
      // wp-login.php -- bots naar een 410 sturen
      {
        source: '/wp-login.php',
        destination: '/gone',
        permanent: true,
      },
      {
        source: '/wp-admin/:path*',
        destination: '/gone',
        permanent: true,
      },
    ]
  },
}

Fase 4: Testen en SEO-validatie (week 6)

  • Voer Screaming Frog uit tegen de nieuwe site om te verifiëren dat elke oude URL ofwel oplost ofwel omleidt.
  • Valideer gestructureerde gegevens (JSON-LD) aanwezig op alle pagina's.
  • Test alle formulieren en dynamische functies.
  • Voer Lighthouse en Core Web Vitals controles uit -- je zult bijna zeker verbeteringen zien omdat je nu van een CDN bediend wordt.
  • Stel monitoring in met Vercel Analytics of je voorkeursinstrument.

Fase 5: Lancering en DNS-omschakeling (weken 6-7)

Deploy naar Vercel of Netlify, werk DNS bij en stel monitoring in. Houd de oude WordPress-instantie offline maar toegankelijk gedurende 30 dagen voor het geval je iets moet raadplegen.

Als je site aanzienlijk verkeer of ecommerce-functionaliteit heeft, overweeg dan een headless CMS-integratie voor inhoudsbeheer en spreek met ons over Astro als een alternatief frontend voor inhoudszware sites waarbij compilatieprestaties van belang zijn.

Beveiliging na migratie verscherpen

Zodra je op de nieuwe stack bent, hier is je beveiligingschecklist:

  1. Schakel Supabase RLS in op elke tabel. Geen uitzonderingen. Als een tabel geen beleid heeft, is het ontoegankelijk (goed standaard) of wijd open (slecht).
  2. Gebruik omgevingsvariabelen voor alle geheimen. Vercel en Netlify hanteren dit allebei goed. Verbind nooit API-sleutels.
  3. Stel Supabase-databaseback-ups in. Point-in-time recovery is beschikbaar op Pro-plannen ($25/maand).
  4. Configureer Content Security Policy-headers in je Next.js-middleware.
  5. Schakel Vercel's DDoS-bescherming in (inbegrepen in alle plannen).
  6. Stel uptime-monitoring in -- we gebruiken Better Uptime, maar Checkly en Vercel's ingebouwde monitoring werken ook.
  7. Audit je Supabase RLS-beleid driemaandelijks. Gebruik Supabase's SQL-editor om beleid met verschillende gebruikerscontexten te testen.
// middleware.ts -- beveiligingsheaders
import { NextResponse } from 'next/server'
import type { NextRequest } from 'next/server'

export function middleware(request: NextRequest) {
  const response = NextResponse.next()
  
  response.headers.set('X-Frame-Options', 'DENY')
  response.headers.set('X-Content-Type-Options', 'nosniff')
  response.headers.set('Referrer-Policy', 'strict-origin-when-cross-origin')
  response.headers.set(
    'Content-Security-Policy',
    "default-src 'self'; script-src 'self' 'unsafe-inline' 'unsafe-eval'; style-src 'self' 'unsafe-inline';"
  )
  response.headers.set(
    'Permissions-Policy',
    'camera=(), microphone=(), geolocation=()'
  )
  
  return response
}

Werkelijke kosten van WordPress-beveiliging versus migratie

Laat het over geld hebben, want dat drijft daadwerkelijke besluiten.

Kostencategorie WordPress (jaarlijks) Next.js + Supabase (jaarlijks)
Hosting $300-1.200 (beheerde WP) $0-240 (Vercel Pro)
Beveiligingsplugins (Wordfence/Sucuri) $200-500 $0 (niet nodig)
SSL/CDN $0-200 $0 (inbegrepen)
Malware-cleanup (bij hack) $500-2.500 per incident N.v.t.
Ontwikkelaarstijd op beveiligingspatches $2.000-5.000 $500-1.000
Database (Supabase) Inbegrepen in hosting $0-300 (Gratis tot Pro)
Totaal $3.000-9.400 $500-1.540

En dat is voordat je rekening houdt met de kosten van downtime, verloren klantvertrouwen en mogelijke regelgevingsstraffen als klantgegevens worden aangetast. Een enkele GDPR-rapporteerbare inbreuk kan tienduizenden kosten in juridische en complianceoverhead.

De migratie zelf kost meestal tussen $10.000-40.000 afhankelijk van sitecomplex. Voor de meeste bedrijven betaalt dat zichzelf terug binnen 1-2 jaar in gereduceerde beveiligingsuitgaven alleen—en je krijgt een snellere, beter onderhoudbare site in het proces.

Veelgestelde vragen

Is WordPress echt zo onveilig, of is dit overdreven? WordPress core wordt goed onderhouden. Het probleem is dat praktisch niemand alleen core draait. Het plugin-ecosysteem is waar 96% van kwetsbaarheden leven, en je kunt geen nuttige WordPress-site zonder plugins uitvoeren. Het is niet overdreven -- Sucuri reinigde malware van meer dan 60.000 WordPress-sites in 2024 alleen al. De architectuur vereist dat je vertrouwt op derde PHP-code op je server, en dat vertrouwen wordt voortdurend misbruikt.

Kan ik niet gewoon beter beveiligingsplugins gebruiken in plaats van migreren? Beveiligingsplugins zijn zelf PHP-code die op je server met diepe systeemtoegang draait. Wordfence en Sucuri worden goed onderhouden, maar ze zijn pleister op een architectuurprobleem. Ze voegen ook serverbelasting toe, kunnen met andere plugins conflicteren, en hebben in het verleden hun eigen kwetsbaarheden gehad. Je voegt complexiteit toe om een complexiteitsprobleem op te lossen.

Hoe lang duurt een WordPress naar Next.js migratie meestal? Voor een standaard bedrijfssite (10-50 pagina's, blog, contactformulieren) voltooien we migraties meestal in 5-7 weken. Ecommerce-sites met WooCommerce zijn complexer en kunnen 8-14 weken duren afhankelijk van de grootte van de productcatalogus en aangepaste functionaliteit. Als je een eenvoudigere site hebt, stuur ons een bericht en we kunnen je een specifiekere tijdslijn geven.

Verlies ik mijn SEO-rangschikkingen bij migratie van WordPress? Niet als je het goed doet. De kritieke stappen zijn: alle URL-structuren behouden of correct 301-omleidingen instellen, je gestructureerde gegevensmarkup behouden, je inhoud intact houden, en bijgewerkte sitemaps indienen bij Google Search Console. De meeste van onze migratiecliënten zien rangschikkingsverbeteringen binnen 2-3 maanden omdat Core Web Vitals-scores dramatisch verbeteren wanneer je naar een CDN-bediende statische site verhuist.

Wat doen we met inhoudbewerking? WordPress is gemakkelijk voor niet-technische gebruikers. Dit is een legitiem bezwaar. Je hebt opties: Supabase met een aangepast admin-dashboard, of een headless CMS zoals Sanity, Contentful, of Payload CMS dat content-editors een visuele bewerkingservaring geeft die vergelijkbaar is met WordPress. We hanteren headless CMS-integraties regelmatig en kunnen aanraden wat het beste voor je team past.

Is Supabase veilig genoeg voor productiegebruik? Supabase draait op AWS-infrastructuur met SOC 2 Type II-compliance. De onderliggende database is PostgreSQL, die een sterk veiligheidsrapport heeft. Row Level Security-beleid dwingt toegangscontrole af op databaseniveau, wat eigenlijk veiliger is dan WordPress's PHP-gebaseerd toestemmingssysteem. Supabase biedt ook point-in-time recovery, versleutelde verbindingen, en netwerkbeperkingen op betaalde plannen.

Wat als mijn WordPress-site is gehackt en ik heb onmiddellijke hulp nodig? Breng eerst de site offline om verdere schade en gegevenslekken te voorkomen. Ten tweede bewaart u forensisch bewijs (databasedumps, toegangslogs, bestandssysteemmomentopnamen). Ten derde, reinig het niet zomaar en zet het terug—je wordt waarschijnlijk binnen enkele weken opnieuw geïnfecteerd. Gebruik het incident als katalysator voor migratie. Neem contact met ons op en we kunnen helpen met zowel onmiddellijke triage als migratieplanning.

Moet ik alles tegelijk migreren, of kan ik het incrementeel doen? Incrémentele migratie is mogelijk maar voegt complexiteit toe. Je kunt Next.js als de frontend gebruiken terwijl je WordPress als een headless CMS-backend tijdelijk draait, vervolgens WordPress geleidelijk volledig elimineren. Dit betekent echter dat WordPress nog steeds draait en nog steeds beveiligingsonderhoud nodig heeft tijdens de overgang. Voor de meeste sites is een schone cutover sneller, goedkoper, en elimineert beveiligingsrisico sneller.