Ik heb mijn geduld verloren met het aantal klanten dat met dezelfde verhaalvariatie naar ons toe komt: "Onze WordPress-site is gehackt. We hebben het opgeruimd. Het werd weer gehackt. We geven het op." De laatste was een middelgroot e-commerce bedrijf waarvan de WooCommerce-winkel was geïnjecteerd met een credit card skimmer verstopt in een legale pluginupdate. Ze hadden klantbetalingsgegevens drie weken lang gelekt voordat iemand het opmerkte. Dat is geen randgeval. Dat is een dinsdag in het WordPress-ecosysteem.

Dit artikel gaat niet over het afkeuren van WordPress. Het bevoegde een groot deel van het web met goede reden. Maar de architectuur die het in 2005 toegankelijk maakte, is dezelfde architectuur die het in 2025 een magneet voor geautomatiseerde aanvallen maakt. Als u bent gehackt -- of als u moe bent van het uitgeven van geld aan beveiligingsplugins die zelf aanvalsvectoren zijn -- dit is uw speelboek voor overstap naar iets fundamenteel veiliger.

Inhoudsopgave

WordPress Gehackt? Waarom Migratie naar Next.js + Supabase Uw Beste Oplossing Is

Het WordPress-beveiligingsprobleem is architecturaal

Laat me duidelijk zijn over iets: het WordPress-kernteam doet solide beveiligingswerk. WordPress-kern, up-to-date gehouden, is redelijk veilig. Maar niemand voert alleen WordPress-kern uit. De gemiddelde WordPress-site heeft 20-30 plugins geïnstalleerd. Elk is een afhankelijkheid die u niet heeft geschreven, beheerd door iemand die u niet kent, met toegang tot uw database, uw bestandssysteem en uw gebruikersgegevens.

Hier is wat steeds over het hoofd wordt gezien in "WordPress-beveiligingsaanbevelingen"-artikelen: het probleem is niet dat eigenaren van WordPress-sites nalatig zijn. Het probleem is dat de architectuur van WordPress vereist dat u uitvoerbare PHP-code van derden rechtstreeks op uw server installeert om basisfunctionaliteit te krijgen. Dat is gelijk aan elke aannemer die aan uw huis werkt permanent een sleutel van uw huis geven.

De vulnerabiliteitsdatabase van WPScan volgde meer dan 7.900 nieuwe WordPress-kwetsbaarheden in 2024, waarbij plugins ongeveer 96% ervan veroorzaakten. Het 2024-dreigingsrapport van Sucuri vond dat WordPress ongeveer 95% van alle CMS-infecties vertegenwoordigde die zij opschoonden. En Patchstack meldde dat 33% van kritieke WordPress-kwetsbaarheden in 2024 op het moment van openbaarmaking geen patch beschikbaar had.

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

Veelvoorkomende WordPress-aanvalsvectoren in 2025

Voordat we over de oplossing spreken, gaan we de aanvallen catalogiseren waar u tegen verdedigt. Ik heb persoonlijk tientallen gecompromitteerde WordPress-sites onderzocht, en de aanvallen volgen voorspelbare patronen.

SQL-injectie via plugins

WordPress gebruikt een MySQL-database met een goed gedocumenteerd schema. Elke plugin die gebruikersinvoer accepteert en de database aanraakt, is een potentiële SQL-injectiepunt. De $wpdb->prepare()-functie bestaat, maar is opt-in. Plugin-ontwikkelaars vergeten het, gebruiken het verkeerd, of slaan het volledig over voor "eenvoudige" queries.

Ik heb eens een injectie getraceerd naar een contactformplugin die 18 maanden lang niet was bijgewerkt, maar nog steeds op meer dan 200.000 sites was geïnstalleerd. De aanvaller gebruikte een UNION-gebaseerde injectie om de tabel wp_users te dumpen, admin-wachtwoordhashes op te halen en de zwakke offline te kraken.

-- Hoe een typische WordPress SQL-injectie er in logs uitziet
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 codeuitvoering

WordPress's intensief gebruik van serialize() en unserialize() creëert kansen voor PHP-objectinjectie. Wanneer een plugin door de gebruiker beheerde gegevens deserialiseert (wat veel doen), kan een aanvaller payloads construeren die willekeurige code uitvoeren tijdens het deserializatieproces.

In 2024 was er een kritieke RCE-kwetsbaarheid in een populaire backupplugin (geïnstalleerd op meer dan 5 miljoen sites) waarmee niet-geverifieerde aanvallers willekeurige PHP-code konden uitvoeren. De fix duurde 11 dagen om uit te gaan. Elf dagen waarin elke site met die plugin een gemakkelijk doelwit was.

Aanvallen op de supply chain van plugins

Dit is degene die me het meest bezorgd maakt. Aanvallers kopen verlaten plugins met grote installatiebasissen, duwen een "veiligheidsupdate" met een achterdeur erin, en WordPress-automatische-bijwerkmechanismen verspreiden malware naar elke site met die plugin. Het gebeurde met Display Widgets (300.000 installaties) en Social Warfare (70.000 installaties), en dit zijn slechts degenen die werden gevangen.

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 dat zij in 2024 gemiddeld 3 miljard kwaadaardige verzoeken per maand blokkeerden in hun netwerk. Zelfs met snelheidsbeperking en twee-factorauthenticatie verbruikt u servermiddelen voor het verwerken van deze aanvallen.

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

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

Waarom Headless-architectuur hele aanvalscategorieen elimineert

Hier wordt het interessant. Een headless-architectuur verlaagt niet alleen uw aanvalsoppervlakte -- het elimineert hele categorieën aanvallen door de voorwaarden te verwijderen die ze mogelijk maken.

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

  • PHP-code van meer dan 20 plugins van derden uitvoeren
  • Gebruikersauthenticatie beheren
  • Verbinding maken met de database
  • De admin-interface bedienen
  • Bestandsuploads verwerken
  • Formulierinzendingen verwerken

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

  • Frontend (Next.js op Vercel/Netlify): Statische HTML/JS geserveerd vanaf 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: Serverloze functies met expliciete, minimale eindpunten.
  • CMS (indien nodig): Headless CMS op zijn eigen geïsoleerde infrastructuur.

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

U hebt geen WAF nodig om een aanvalsoppervlakte te beschermen die niet bestaat.

WordPress Gehackt? Waarom Migratie naar Next.js + Supabase Uw Beste Oplossing Is - architectuur

Next.js + Supabase: Een veiligheidsgericht stapel

Laten we specifiek worden over waarom deze combinatie zo goed werkt vanuit beveiligingsstandpunt.

Next.js: De frontend die geen code uitvoert

Wanneer u een Next.js-site maakt met statische generatie (SSG) of incrementele statische regeneratie (ISR), wat wordt geïmplementeerd zijn HTML-, CSS- en JavaScript-bestanden op een CDN. Er is geen toepassingsserver die realtime verzoeken verwerkt. U kunt geen SQL-injectie in een CDN.

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

  • Geïsoleerd in zijn eigen uitvoeringscontext
  • Staatloos (geen gedeeld geheugen tussen verzoeken)
  • Kortdurend (koude start, uitvoering, beëindiging)
  • Expliciet gedefinieerd (geen auto-detectie van eindpunten)
// Next.js Route Handler -- expliciet, getypeerd, 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: 'Invalid input' }, { status: 400 })
  }
  
  const supabase = await createClient()
  const { error } = await supabase
    .from('contact_submissions')
    .insert(parsed.data)
  
  if (error) {
    return NextResponse.json({ error: 'Submission failed' }, { status: 500 })
  }
  
  return NextResponse.json({ success: true })
}

Vergelijk dat met een WordPress-contactformplugin die zich aan WordPress's actiesysteem moet aansluiten, zijn eigen AJAX-handler moet opnemen, nonce-verificatie moet beheren en zijn eigen SQL-queries moet bouwen. De Next.js-versie heeft minder bewegende onderdelen, gevalideerde invoer via Zod en geparametriseerde queries via de Supabase-client.

Supabase: Postgres met Row Level Security

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

-- Alleen geverifieerde gebruikers kunnen hun eigen gegevens zien
CREATE POLICY "Users can view own profile"
  ON profiles
  FOR SELECT
  USING (auth.uid() = user_id);

-- Openbaar kan formulieren indienen, maar niet lezen
CREATE POLICY "Anyone can submit contact form"
  ON contact_submissions
  FOR INSERT
  WITH CHECK (true);

CREATE POLICY "Only admins can read submissions"
  ON contact_submissions
  FOR SELECT
  USING (auth.jwt() ->> 'role' = 'admin');

Zelfs als een aanvaller een manier vindt om willekeurige Supabase-queries uit te voeren (wat al veel moeilijker is zonder een PHP-uitvoeringscontext), RLS-beleid voorkomt dat ze gegevens benaderen die ze niet mogen zien. Dit is verdediging in diepte die WordPress fundamenteel niet kan bieden omdat het permissiesysteem is geïmplementeerd in PHP-code, niet op databaseniveau.

Supabase handelt ook authenticatie af met ingebouwde ondersteuning voor e-mail/wachtwoord, magische koppelingen, OAuth-providers en multi-factor-authenticatie. Geen plugin nodig. Geen code van derden die op uw server wordt uitgevoerd.

Aanvalsoppervlakte vergelijking: WordPress vs Headless

Laten we dit naast elkaar zetten.

Aanvalsvector WordPress Next.js + Supabase
SQL-injectie Hoog risico -- plugins bouwen onbewerkte queries Bijna nul -- geparametriseerde queries via Supabase-client, RLS als back-up
PHP/externe codeuitvoering Hoog risico -- plugins voeren server-side PHP uit Niet van toepassing -- geen PHP-runtime
Supply chain van plugins Kritiek risico -- auto-updates verspreiden malware Niet van toepassing -- geen plugin-ecosysteem
Brute Force (login) Altijd blootgesteld (wp-login.php, xmlrpc.php) Admin-toegang via Supabase Auth of afzonderlijk dashboard, geen openbaar login-eindpunt vereist
XSS (opgeslagen) Hoog risico -- gedeelde admin/openbare context Laag risico -- React escaped uitvoer standaard, admin en openbaar zijn aparte apps
Exploitatie van bestandsuploads Hoog risico -- geüploade PHP-bestanden kunnen uitvoeren Laag risico -- uploads gaan naar objectopslag (Supabase Storage/S3), nooit als code uitgevoerd
Databaseblootstelling Directe MySQL-toegang als server is gecompromitteerd Database achter Supabase-infrastructuur, RLS-beleid als laatste verdediging
DDoS op oorsprong Server moet elk verzoek verwerken Statische assets op CDN, oorsprong zelden bereikt
Bekende padopsomming wp-admin, wp-content, wp-includes allemaal scanbaar Geen voorspelbare paden, geen blootgestelde admin-routes

Het migratieplan: WordPress naar Next.js + Supabase

Prima, u bent overtuigd (of uw gehackte site heeft u overtuigd). Hier volgt hoe u dit daadwerkelijk doet. We hebben deze migratie genoeg keer uitgevoerd om een herhaalbaar proces te hebben.

Fase 1: Triage en inhoudsaudit (Week 1)

Voordat u code aanraakt, moet u begrijpen wat u daadwerkelijk heeft.

  1. Exporteer alle WordPress-inhoud met behulp van WP-CLI of de REST API. Vertrouw niet op XML-exports -- ze missen meta-velden en aangepaste posttypen.
  2. Catalogiseer alle functionaliteit geleverd door plugins. Maak een spreadsheet: plugin-naam, wat het doet, of u het daadwerkelijk nodig hebt, en wat het vervangt.
  3. Wijs URL-structuren toe voor SEO-behoud. Elke bestaande URL heeft een omleiding nodig of een overeenkomende route in Next.js.
  4. Identificeer dynamische functies -- formulieren, zoeken, gebruikersaccounts, e-commerce -- 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 uw Supabase-databaseschema op basis van de inhoudsaudit. Repliceer niet zomaar het WordPress-schema -- het is opgeblazen met metatabel en geserialiseerde gegevensblobs.

-- 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 "Published posts are public"
  ON posts FOR SELECT
  USING (status = 'published');

CREATE POLICY "Authors can manage own posts"
  ON posts FOR ALL
  USING (auth.uid() = author_id);

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

Fase 3: Next.js-bouw (Weken 3-5)

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

Sleutelarchitectuurbesluiten:

  • Statische generatie voor inhoudspagina's -- blogposts, bestemmingspagina's, about-pagina's. Deze worden HTML-bestanden op een CDN.
  • Servercomponenten voor dynamische gegevens -- fetch van Supabase op aanvraagstijd met caching.
  • Route-handlers voor formulierinzendingen -- contactformulieren, nieuwsbriefsignups, enz.
  • Middleware voor omleidingen -- alle uw oude WordPress-URL's verwerken.
// next.config.ts -- handle WordPress URL redirects
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 -- send bots to a 410
      {
        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 wordt opgelost ofwel wordt omgeleid.
  • Valideer dat gestructureerde gegevens (JSON-LD) op alle pagina's aanwezig zijn.
  • Test alle formulieren en dynamische functies.
  • Voer Lighthouse en Core Web Vitals-controles uit -- u ziet vrijwel zeker verbeteringen omdat u nu vanaf een CDN bedient.
  • Stel monitoring in met Vercel Analytics of uw voorkeurstool.

Fase 5: Start en DNS-cutover (Week 6-7)

Implementeer op Vercel of Netlify, update DNS en stel monitoring in. Houd de oude WordPress-instantie 30 dagen offline maar toegankelijk, voor het geval u iets moet raadplegen.

Als uw site significant verkeer of e-commerce-functionaliteit heeft, overweeg een headless CMS-integratie voor inhoudsbeheer en spreek met ons over Astro als alternatief frontend voor inhoudszware sites waarbij bouwprestaties ertoe doen.

Na-migratiebeveiligingsverharding

Zodra u op de nieuwe stack bent, volgt uw beveiligingschecklist:

  1. Schakel Supabase RLS in op elke tabel. Geen uitzonderingen. Als een tabel geen beleid heeft, is het ofwel ontoegankelijk (goed standaardbeleid) ofwel volledig open (slecht).
  2. Gebruik omgevingsvariabelen voor alle geheimen. Vercel en Netlify behandelen dit beiden goed. Leg API-sleutels nooit vast.
  3. Stel Supabase-databaseback-ups in. Point-in-time recovery is beschikbaar op Pro-plannen ($25/maand).
  4. Configureer Content Security Policy-headers in uw Next.js-middleware.
  5. Schakel Vercel's DDoS-beveiliging in (inbegrepen op alle plannen).
  6. Stel uptime-monitoring in -- we gebruiken Better Uptime, maar Checkly en Vercel's ingebouwde monitoring werken ook.
  7. Audit uw 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

Laten we over geld spreken, want dat bepaalt werkelijk besluiten.

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

En dat is nog voordat u rekening houdt met uitvaltijd, verloren vertrouwen van klanten en mogelijke regelgeving boetes als klantgegevens zijn gecompromitteerd. Een enkele GDPR-rapporteerbare inbreuk kan tienduizenden kosten in juridische en nalevingskosten.

De migratie zelf kost normaal gesproken tussen $10.000-40.000, afhankelijk van de complexiteit van de site. Voor de meeste bedrijven betaalt dat zich zelf terug in 1-2 jaar alleen al in gereduceerde beveiligingsuitgaven -- en u krijgt een snellere, beter onderhoudbare site als bonus. Controleer onze prijspagina voor specifieke informatie over migrratieprojecten.

Veelgestelde vragen

Is WordPress werkelijk zo onveilig, of is dit overdreven? WordPress-kern wordt goed onderhouden. Het probleem is dat praktisch niemand alleen kern uitvoert. Het plugin-ecosysteem is waar 96% van kwetsbaarheden leven, en u kunt geen bruikbare WordPress-site zonder plugins uitvoeren. Het is niet overdreven -- Sucuri verwijderde malware van meer dan 60.000 WordPress-sites in 2024 alleen. De architectuur vereist dat u code van derde partijen PHP op uw server vertrouwt, en dat vertrouwen wordt constant misbruikt.

Kan ik in plaats van migratie niet gewoon betere beveiligingsplugins gebruiken? Beveiligingsplugins zijn zelf PHP-code die op uw server wordt uitgevoerd met diepe systeemtoegang. Wordfence en Sucuri worden goed onderhouden, maar het zijn pleister op een architectuurprobleem. Ze voegen ook serverbelasting toe, kunnen conflicteren met andere plugins en hebben zelf kwetsbaarheden in de loop der jaren gehad. U voegt complexiteit toe om een complexiteitsprobleem op te lossen.

Hoe lang duurt een WordPress naar Next.js-migratie normaal gesproken? Voor een standaard bedrijfssite (10-50 pagina's, blog, contactformulieren) voltooien we migraties normaal gesproken in 5-7 weken. E-commerce-sites met WooCommerce zijn ingewikkelder en kunnen 8-14 weken duren, afhankelijk van de grootte van de productcatalogus en aangepaste functionaliteit. Als u een eenvoudiger site heeft, neem dan contact met ons op en we kunnen u een specifiekere tijdlijn geven.

Zal ik mijn SEO-rankings verliezen bij migratie van WordPress? Niet als u het goed doet. De kritieke stappen zijn: alle URL-structuren behouden of juiste 301-omleidingen instellen, uw gestructureerde gegevensmarkering behouden, uw inhoud intact houden en bijgewerkte sitemaps naar Google Search Console indienen. De meeste van onze migratiklanten zien rankingverbeteringen binnen 2-3 maanden omdat Core Web Vitals-scores dramatisch verbeteren wanneer u overgaat naar een CDN-geserveerde statische site.

Wat betreft inhoudsbewerking? WordPress is eenvoudig voor niet-technische gebruikers. Dit is een legitiem probleem. U hebt opties: Supabase met een aangepast admin-dashboard, of een headless CMS zoals Sanity, Contentful of Payload CMS die content-editors een visuele bewerkingservaring geeft die op WordPress lijkt. We behandelen headless CMS-integraties regelmatig en kunnen aanbevelen wat het beste voor uw team's behoeften is.

Is Supabase veilig genoeg voor productiegebruik? Supabase draait op AWS-infrastructuur met SOC 2 Type II-compliance. De onderliggende database is PostgreSQL, die een sterke beveiligingstrack record heeft. Row Level Security-beleid dwingt toegangscontrole op databaseniveau af, wat eigenlijk veiliger is dan het PHP-gebaseerde permissiesysteem van WordPress. 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? Maak eerst onmiddellijk de site offline om verdere schade en gegevenslekken tegen te gaan. Ten tweede, behoud forensisch bewijs (databasedumps, toegangslogboeken, bestandssysteemafbeeldingen). Ten derde, schoon het niet zomaar op en zet het terug -- u zult waarschijnlijk binnen weken opnieuw worden besmet. Gebruik het incident als katalysator om te migreren. Neem contact op met ons team en we kunnen helpen met zowel onmiddellijke triage als migratieplan.

Moet ik alles tegelijk migreren, of kan ik het stap voor stap doen? Incrementele migratie is mogelijk maar voegt complexiteit toe. U kunt Next.js als frontend uitvoeren terwijl u WordPress tijdelijk als headless CMS-backend houdt, en WordPress vervolgens volledig faseren. 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's eerder.