Te veel plug-ins in WordPress.

Wat doen 30 plug-ins eigenlijk?

Anatomie van een typische MKB-WP-site met 28 plug-ins (echte audit-data, januari 2026):

• 3 page-builder plug-ins (Elementor + Elementor Pro + Essentials Add-ons)
• 2 form-plug-ins (Contact Form 7 + ConvertKit)
• 3 SEO-plug-ins (Yoast + Rank Math + redirect-plugin)
• 4 security-plug-ins (Wordfence + Login Lockdown + 2FA + spam-filter)
• 3 cache-plug-ins (W3 Total Cache + image-cache + autoptimize)
• 2 backup-plug-ins (UpdraftPlus + Duplicator)
• 2 cookie-banner-plug-ins (CookieYes + custom)
• 2 social-share-plug-ins
• 2 analytics-plug-ins (MonsterInsights + GA-tracker)
• 5 overige (gallery, slider, sitemap, breadcrumbs, custom-CSS)

Probleem zichtbaar: 5 categorieën met 2-4 plug-ins die overlappende functionaliteit hebben. Klassiek WP-creep.

Wat kost elke plug-in?

1. Performance (5-30ms LCP per plug-in)

Elke plug-in laadt:

• 1-3 CSS-bestanden (gemiddeld 15-50kb totaal)
• 1-2 JavaScript-bestanden (20-100kb)
• 1-5 extra HTTP-requests
• 2-15 extra database-queries per pageview

Bij 28 plug-ins: ~500kb extra bundle + ~120 extra DB-queries per pageview. Op een €2/mnd shared hosting: site-snelheid hapert structureel.

2. Security-risico (per plug-in ~1.2% breach-kans/jaar)

Wordfence-data: gemiddelde plug-in heeft 1.2% kans op critical CVE per jaar. Bij 28 plug-ins:

• Kans dat je elk jaar minstens één vulnerable-plug-in hebt: ~28%
• Kans op meerdere tegelijk: ~4%

Met <10 plug-ins: kans daalt naar <10%. Lees WordPress security 2026.

3. Onderhoudstijd (~4 min/maand per plug-in)

Updates checken, staging-test, productie-push, post-update visual check — gemiddeld 4 min per plug-in per maand. Bij 28 plug-ins: 1.9 uur/maand alleen voor plug-in-onderhoud. Zie onderhoud eindeloos.

4. Conflict-kans (1.5% per plug-in-paar)

Bij 28 plug-ins zijn er 378 plug-in-paren. Conflict-kans cumuleert: dagelijks 1-2 mini-conflicten (typografie wisselt, formulier breekt, CSS overschrijft).

De plug-in-audit (3 uur werk)

Stap 1 — Lijst alles

WP Admin → Plugins → Installed Plugins. Kopieer alle plug-in-namen + versies naar spreadsheet. Voeg kolommen toe: `Functie`, `Vervangbaar door`, `Verwijderen?`.

Stap 2 — Categoriseer per functie

Groepeer per use-case: forms, SEO, security, cache, social, etc. Per categorie: zijn er meerdere plug-ins? Kies één.

Stap 3 — Check WP-core alternatief

Veel oudere plug-ins zijn nu vervangen door WP-core features:

• Lazy-loading: WP-core sinds 5.5
• WebP-support: WP-core sinds 5.8
• Auto-update voor minor versions: WP-core sinds 5.6
• Page Builder: Gutenberg-blocks vervangen vaak Elementor (depending on complexity)

Stap 4 — Check Cloudflare-alternatief

Cloudflare gratis tier vervangt:

• Image-optimization plug-ins (Polish)
• CDN-plug-ins (built-in)
• Basic security-plug-ins (Cloudflare WAF gratis tier)
• Cache-plug-ins (Cloudflare Cache, +Auto-minify)

Stap 5 — Plug-in-bundeling overwegen

Multifunctionele plug-ins kunnen 3-5 enkel-functie plug-ins vervangen:

• Rank Math: SEO + redirects + schema.org + sitemap = 3-4 plug-ins in één
• WP Rocket: cache + critical CSS + image-lazy + minify = 2-3 plug-ins in één
• Wordfence Premium: firewall + scan + 2FA + login-protection = 3-4 plug-ins in één

Stap 6 — Test deactivering op staging

Voor elke kandidaat-verwijdering: deactiveer op staging. Test 5 belangrijkste pagina's. Werkt alles? OK om weg.

Stap 7 — Cleanup database-tabellen

Bij verwijderde plug-ins blijven soms tabellen achter (`wp_plugin_xyz_data`). Plug-in als WP-Optimize of CodeShack's "Cleanup" kan ze vinden + verwijderen.

Realistische sanerings-resultaten

Van een DC-klant met 28 plug-ins eind 2025:

• Na audit: 11 plug-ins. Functioneel identiek.
• Lighthouse mobile: 48 → 76 (+28 punten)
• LCP: 4.2s → 2.1s
• Maandelijks onderhoud: 2.4 uur → 0.9 uur

Sanering kostte 3 uur. Maandelijkse winst: 1.5 uur × €75 = €112.5 = €1.350/jaar.

Wanneer sanering niet meer genoeg is

Als je site bij start >40 plug-ins heeft, sanering vaak niet voldoende:

• Veel functionaliteit zit verweven in plug-ins (page-builders, custom post types, custom forms)
• Saneren breekt vaak meer dan het oplost
• Onderliggende thema-keuze (Avada/Divi) blijft een performance-vloer

In dat geval: rebuild overwegen. Zie WP → Webflow migratie of WP → Astro.

De 5 plug-ins waar je écht niet om heen kunt

Voor een typische MKB-WP-site:

• SEO: Rank Math of Yoast Premium
• Cache: WP Rocket of LiteSpeed Cache (afh. van hosting)
• Security: Wordfence Premium
• Backup: UpdraftPlus Premium of beheerde hosting-backup
• Form: Gravity Forms of WPForms

5 plug-ins. Combined-kosten: €450-€600/jaar. Functioneel uitgebreid maar onderhoudsmatig schoon.

Gerelateerde artikelen

FAQ — te veel plug-ins

WordPress versus moderne stacks: waarom plug-in-overload zelden voorkomt buiten WP

Plug-in-overload is een typisch WordPress-probleem, en daar zit een structurele reden achter. WordPress is een monolithische applicatie die runtime functionaliteit injecteert via hooks en filters. Elke plug-in haakt zich in op core-events, breidt de admin uit, voegt database-tabellen toe en laadt extra assets. Bij een moderne stack als Astro, Next.js, Eleventy of een headless CMS (Sanity, Storyblok, Payload) wordt functionaliteit op build-time bepaald. Wat je niet gebruikt zit niet in je bundel. Wat je wel gebruikt is geïmporteerd als pakket, niet geïnjecteerd op runtime. Het verschil is groot: een Astro-site met tien geïmporteerde libraries blijft kleiner dan een WP-site met tien plug-ins, omdat tree-shaking en static rendering ongebruikte code eruit halen.

Webflow zit ergens in het midden. De editor is closed-source maar de output is statische HTML/CSS plus een afgemeten runtime. Apps en integraties zijn opt-in en draaien meestal extern (via Zapier, Make of native koppelingen) in plaats van als binnenlandende plug-ins. Het gevolg: een Webflow-site die vijf integraties gebruikt heeft niet zes keer een eigen jQuery, geen overlappende formulier-libraries en geen vijf trackingsnippets die elkaar tegenwerken. Voor de meeste MKB-sites is dat een net schonere afslag dan WordPress met evenveel functionaliteit.

Sanity en Storyblok zijn een nog scherpere keuze als je content centraal staat. Je redacteur werkt in een gestructureerde editor, je front-end is wat je zelf bouwt (Next.js, Nuxt, Astro). Er is geen plug-in-architectuur die andere ontwikkelaars kunnen vervuilen. Wat je toevoegt is altijd code die jij of je bureau beheert. De prijs is dat je minder kant-en-klare modules krijgt; de winst is dat je nooit meer een "shop-plug-in voegt 14 scripts toe aan elke pagina"-situatie hebt.

Hoe stack-keuze plug-in-overload structureel uitsluit

Mensen zoeken vaak naar een betere plug-in-combinatie binnen WordPress, maar de echte oplossing zit een laag dieper: bouw op een fundament dat geen plug-in-cultuur kent. Vergelijk de drie veelgebruikte alternatieven naast elkaar.

Astro. Static-first met optionele "islands" voor interactiviteit. Geen runtime CMS, geen plug-in-marktplaats. Je voegt features toe via npm-packages die alleen worden gebundeld als je ze importeert. Een Astro-site die tien jaar oud is gebruikt nog steeds dezelfde build-output: HTML. Geen versie-conflicten, geen "deze plug-in werkt niet meer op PHP 8.4".

Webflow. Visuele editor, gehoste runtime. Functionaliteit is ingebakken (CMS, forms, e-commerce, animaties via Webflow Interactions). Er is geen plug-in-laag waar derden code kunnen injecteren. Integraties draaien extern. Resultaat: voorspelbare performance en geen plug-in-bloat.

Next.js + headless CMS. Voor wie écht complexe site nodig heeft (klantenportaal, configurator, marketplace). Functionaliteit zit in geverifieerde npm-packages, niet in een marktplaats van duizenden onderhouden-door-vrijwilligers extensies. Je bundle bevat alleen wat je écht gebruikt.

Voor Keurmeesters (energielabel-bureau) hebben we bewust gekozen voor een vanilla-stack zonder plug-in-architectuur. Resultaat na vier maanden: nul security-incidenten, geen onderhoudsuren aan core-updates en een Lighthouse-score die nooit onder 95 zakt. Dat is geen toeval — dat is een direct gevolg van de stack-keuze.

Wanneer plug-in-sanering binnen WP genoeg is en wanneer migratie verstandiger is

Plug-in-sanering is zinvol als je site qua content en functionaliteit stabiel is, je team WordPress beheert, en het probleem hoofdzakelijk een opgepoetste plug-in-lijst betreft. Verwacht 20-40% snelheidswinst en 30-50% minder onderhoud, mits je écht durft te snoeien. Migratie naar een moderne stack is verstandiger als je site herontwerp toe is, je conversie laag is, je meerdere malen per jaar gehackt bent geweest, of je redactie er gewoon klaar mee is. Onder de streep: sanering verlengt de levensduur van wat je hebt, migratie geeft je een nieuw fundament.

Veel sites die wij wereldwijd tegenkomen zitten ergens in het midden — net niet kapot, maar ook niet meer een fundament waar je drie jaar op door kunt. Onze gratis audit kijkt naar dat omslagpunt en geeft een eerlijk advies: sanering, refresh, of complete rebuild.

• Plug-in-aantal <15: gezonde basis, focus op kwaliteit per plug-in
• 15-25 plug-ins: oplettendheid, maandelijkse audit aan te raden
• 25-40 plug-ins: sanering verplicht, anders performance-degradatie binnen 6 maanden
• 40+ plug-ins: rebuild of platform-switch overwegen, sanering kost vaak meer dan opnieuw bouwen
• Elke EoL-plug-in: vandaag verwijderen of vervangen, security-risico stijgt elke dag
• Page-builder-plug-ins (Elementor, Divi, WPBakery): vervang waar mogelijk door Gutenberg-blocks
• SEO-plug-in: één tegelijk (Yoast OF Rank Math), nooit twee parallel
• Caching-plug-in: kies één strategie (WP Rocket, W3 Total Cache of LiteSpeed Cache)
• Image-optimization: vervang door Cloudflare Polish of een build-step in moderne stack
• Backup-plug-in: native server-backup (cPanel, Plesk) of managed-host backup is beter
• Form-plug-ins: één voldoet, geen drie verschillende voor verschillende formulieren
• Analytics: server-side (Plausible, Fathom) is sneller dan client-side plug-ins
• Multi-language: WPML en Polylang zijn zwaar — overweeg static-site met aparte subfolders
• Comment-plug-ins (Disqus, Akismet-vervangers): native WP-comments + Akismet is genoeg
• Plug-ins die niet zijn bijgewerkt in 12+ maanden: weg, geen uitzondering

Plug-in-audit als nulmeting voor stack-keuze

Een goede plug-in-audit doet meer dan tellen. Het brengt drie dingen in kaart: welke plug-ins doen wat, hoeveel resources kost elke plug-in, en welke functies kunnen native of via een schonere stack. Dat laatste is waar de migratie-beslissing geboren wordt. Als 80% van je plug-ins vervangbaar is door build-time features (Astro, Next.js) of native platform-features (Webflow), is plug-in-sanering eigenlijk de eerste stap naar migratie. Je saneert nu, je verzamelt data, en bij de volgende grote redesign-cyclus heb je een gefundeerd argument voor stack-switch.

Wij beginnen elke audit met Query Monitor (WP-plug-in, paradoxaal genoeg) om resource-gebruik per plug-in te meten. Een plug-in die 200ms per page-load toevoegt is een rode vlag — vooral als de functionaliteit triviaal is. Drie zulke plug-ins en je TTFB is verdubbeld zonder dat je weet waar het zit. Na de meting volgt de prioritering: welke plug-ins schrappen we, welke vervangen we, en welke houden we omdat ze écht onmisbaar zijn.

FAQ — diep op plug-ins en alternatieven

Wat doe je vandaag?

Open je WP-admin en tel je plug-ins. Zit je onder de 15 en draait alles goed, dan is dit artikel een waarschuwing voor over een jaar. Zit je tussen 15 en 30, plan dan een sanering-sessie van een halve dag. Zit je boven de 30, vraag dan een gratis audit aan — wij maken de lijst voor je en zeggen eerlijk of sanering of stack-switch beter werkt. Geen verkooppraatje, gewoon een concrete lijst en een prijsindicatie.

Door Twan van Hulst — DesignCheck. Laatst bijgewerkt 17 mei 2026.