Verboden WordPress-plugins op managed hosting

Dit naslagartikel behandelt pluginbeperkingen bij zes grote managed WordPress-hosts: WP Engine, Kinsta, Pressable, GoDaddy Managed WordPress, Flywheel en WordPress.com. Het beleid dat hier beschreven staat, is gebaseerd op de openbare supportpagina's van elke host op de datums die per bron vermeld zijn. Hostbeleid verandert; controleer de actuele documentatie van je host als een specifieke plugin voor jou belangrijk is.

Inhoudsopgave

• Waarom managed hosts plugins blokkeren
• Hoe de handhaving werkt: mu-plugins, niet mapnamen
• Cachingplugins
• Backupplugins
• Beveiligings- en firewallplugins
• Gerelateerde-berichten- en database-intensieve plugins
• Server-manipulerende plugins
• Statistiek- en analytics-plugins
• Vergelijkingstabel per host
• Hoe je controleert of je host beperkingen heeft
• Drie misverstanden die het rechtzetten waard zijn
• Contact met je host als je een geblokkeerde plugin nodig hebt

Waarom managed hosts plugins blokkeren

Managed WordPress-hosting verkoopt een belofte: de host regelt caching, backups, beveiliging en serverconfiguratie zodat jij dat niet hoeft te doen. Om die belofte waar te maken draait de host eigen server-level infrastructuur voor elk van die functies. Een third-party plugin die hetzelfde probeert te doen, dupliceert het werk niet alleen. Het conflicteert ermee.

Een cachingplugin die zijn eigen advanced-cache.php drop-in schrijft, botst met de server-level pagecache die de host al draait. Het resultaat is dubbel gecachete pagina's, verouderde content, of regelrechte crashes. Een backupplugin die op schema een volledige databasedump en bestandsarchief maakt, verbruikt CPU en I/O die het eigen backupsysteem van de host ook al gebruikt, soms op piekuren. Een beveiligingsplugin die elk bestand op schijf scant, kan PHP-workers uitputten op een platform dat die scanning al op infrastructuurniveau afhandelt.

De beperking is geen oordeel over de codekwaliteit van de plugin. Het WordPress.org pluginreviewproces beoordeelt GPL-compatibiliteit, codekwaliteit en omgang met gebruikersdata. Het beoordeelt niet of een plugin correct werkt op elke hostingarchitectuur. Een plugin kan door de WordPress.org-review komen en toch incompatibel zijn met een specifieke managed omgeving.

Hoe de handhaving werkt: mu-plugins, niet mapnamen

Managed hosts handhaven pluginbeperkingen via must-use plugins (mu-plugins), die in wp-content/mu-plugins/ staan en automatisch laden voor alle reguliere plugins. Je kunt een mu-plugin niet deactiveren vanuit het WordPress-dashboard; daarvoor heb je directe bestandstoegang nodig, en die bieden de meeste managed hosts niet.

De mu-plugin van de host regelt de infrastructuur die de geblokkeerde plugin zou hebben geleverd. Kinsta's mu-plugin beheert bijvoorbeeld full-page caching, CDN-integratie en automatische cachepurging. Verwijderen of aanpassen zou de site breken. Dit is het mechanisme dat het hernoemen van een geblokkeerde pluginmap zinloos maakt: de handhavingslaag werkt onafhankelijk van de pluginmapstructuur, en de functionaliteit die de geblokkeerde plugin biedt wordt al afgehandeld door code die je niet kunt wijzigen.

Bij sommige hosts wordt de beperking ook op bestandssysteemniveau afgedwongen. Pressable blokkeert schrijfbewerkingen naar advanced-cache.php volledig, wat betekent dat elke cachingplugin die van dat drop-in bestand afhankelijk is gewoon niet kan functioneren, ongeacht de mapnaam.

Cachingplugins

Dit is de grootste en meest consistent gehandhaafde categorie. Elke managed WordPress-host in dit naslagartikel blokkeert of ontraadt third-party pagecaching-plugins omdat de host een eigen server-level pagecache draait (meestal nginx fastcgi_cache, Varnish of een eigen variant). Een plugin-level pagecache installeren bovenop een server-level cache levert dubbele caching, verouderde content, of een site die crasht als beide lagen tegelijk proberen te purgen.

Voor een gedetailleerde uitleg over hoe WordPress-cachinglagen werken en waarom server-level caching sneller is dan plugin-level caching, lees hoe WordPress-caching eigenlijk werkt.

Veelgeblokkeerde cachingplugins:

De WP Rocket-uitzondering. WP Rocket is de enige caching-/optimalisatieplugin die WP Engine toestaat, en het is ook de enige cachingplugin die op WordPress.com Business- en Commerce-abonnementen mag draaien. Op hosts waar WP Rocket is toegestaan, wordt de pagecaching-module automatisch uitgeschakeld door de integratie van de host, maar de andere functies (LazyLoad, bestandsoptimalisatie, CDN-integratie) blijven werken. Dit "gedeeltelijk toestaan"-patroon is gebruikelijk: de host blokkeert specifiek de pagecaching-functie, niet de hele plugin.

Wat je in plaats daarvan kunt gebruiken. Op een managed host heb je al pagecaching. Je hoeft er niets voor te installeren. Wil je de optimalisatiefuncties die WP Rocket biedt (bestandsminificatie, lazy loading, critical CSS), dan werkt WP Rocket op de meeste managed hosts met de cachingmodule automatisch uitgeschakeld. Voor beeldoptimalisatie is een service-gebaseerde aanpak zoals ShortPixel of Imagify een goede keuze, omdat die afbeeldingen extern verwerkt in plaats van op de server.

Backupplugins

Managed hosts blokkeren of ontraden backupplugins om twee redenen: de host biedt al automatische backups als onderdeel van het abonnement, en een plugin-level backup die naast de eigen backup van de host draait verbruikt aanzienlijke serverresources (volledige databasedumps, disk-I/O voor bestandsarchivering, tijdelijke opslag voor gecomprimeerde archieven).

Veelgeblokkeerde backupplugins:

Brondatums: WP Engine (juli 2025), Kinsta (januari 2026), Pressable (september 2024), GoDaddy.

Een belangrijk detail over Kinsta. UpdraftPlus is geblokkeerd op bestaande Kinsta-sites maar toegestaan op nieuwe. Als je "UpdraftPlus is geblokkeerd op Kinsta" leest zonder die context, krijg je een verkeerd beeld. Kinsta hanteert ook een versie-eis voor BackWPup: versie 5.5 en lager is geblokkeerd, maar 5.6.0 en nieuwer mag wel.

Wat je in plaats daarvan kunt gebruiken. Het ingebouwde backupsysteem van je managed host is de eerste laag. Voor een tweede, onafhankelijke kopie (die je toch wilt hebben), gebruik een backupaanpak die data buiten de infrastructuur van de host opslaat. Lees voor een compleet overzicht van wat een echte backupstrategie inhoudt, inclusief waarom alleen hostbackups niet genoeg zijn, de WordPress backupstrategie-gids.

Beveiligings- en firewallplugins

Deze categorie ligt genuanceerder dan caching of backups. De meeste managed hosts blokkeren beveiligingsplugins niet categorisch; ze blokkeren specifieke functies of vereisen configuratiewijzigingen.

Wordfence werd in september 2019 van de WP Engine-blokkeerlijst verwijderd nadat de engineers van WP Engine met Wordfence samenwerkten om WAF-regels in de database op te slaan in plaats van in het bestandssysteem, waarmee het compatibiliteitsconflict was opgelost. Op Kinsta wordt Wordfence ondersteund, maar Traffic Logging moet uitgeschakeld worden omdat die logfunctie te veel databaseschrijfbewerkingen genereert.

WordPress.com blokkeert beveiligingsplugins volledig met als reden dat ze "de ingebouwde beveiligingssystemen van je site verstoren." Dat is het strengste standpunt van alle grote hosts.

Wat je in plaats daarvan kunt gebruiken. Managed hosts bieden doorgaans WAF-bescherming, DDoS-mitigatie en malwarescanning op infrastructuurniveau, voordat WordPress ook maar geladen wordt. Een beveiligingsplugin die binnen WordPress draait (nadat de server het verzoek al heeft geaccepteerd en PHP gestart is) voegt waarde toe voor specifieke functies zoals tweefactorauthenticatie, login-auditlogging en bestandsintegriteitsmonitoring, maar kan geen infrastructuurbeveiliging vervangen. Voor een praktische WordPress security hardening-checklist die op elke host werkt, inclusief wat het meest uitmaakt en wat beveiligingstheater is, lees de gelinkte gids.

Gerelateerde-berichten- en database-intensieve plugins

Plugins die "gerelateerde berichten"-lijsten genereren door content te vergelijken over alle berichten heen, draaien dure LIKE-queries, full-text indexbewerkingen of JOINs op grote berichtentabellen bij elke paginaweergave. Op een site met duizenden berichten levert dat meetbare MySQL-belasting op.

Veelgeblokkeerd:

• WP Engine blokkeert expliciet Dynamic Related Posts, SEO Auto Links & Related Posts, Similar Posts en Contextual Related Posts, en noemt ze "extremely database intensive."
• GoDaddy blokkeert dezelfde categorie om dezelfde reden.
• Flywheel ontraadt ze, met als reden een "barrage of MySQL queries."
• Pressable blokkeert specifiek Broken Link Checker, die "servers overspoelt met een heel groot aantal HTTP-verzoeken."

Wat je in plaats daarvan kunt gebruiken. Als je gerelateerde berichten nodig hebt, gebruik dan een plugin die relaties vooraf berekent bij opslaan in plaats van te queryen bij elke paginaweergave (FLAVOR is een voorbeeld), of gebruik een tag-/categorie-gebaseerde aanpak die in je thema is ingebouwd. Voor broken link checking kun je een externe dienst gebruiken zoals Ahrefs Site Audit of het gratis Dr. Link Check, die je site van buitenaf crawlt in plaats van de database van binnenuit te belasten.

Server-manipulerende plugins

Sommige plugins moeten schrijven naar bestanden die managed hosts beheren: .htaccess (die niet bestaat op nginx-gebaseerde hosts), wp-config.php, of systeemniveau PHP-configuratie. Deze falen stil of breken de site.

• Flywheel blokkeert alle plugins die .htaccess aanpassen omdat Flywheel nginx draait, niet Apache. Er is geen .htaccess om aan te passen.
• Flywheel blokkeert ook plugins die naar wp-config.php schrijven: die "kunnen niet functioneren op Flywheel."
• WP Engine blokkeert VersionPress (versiebeheer-gebaseerde revisies) omdat het server-level functies nodig heeft die om veiligheidsredenen uitgeschakeld zijn.
• WordPress.com blokkeert WP File Manager en Advanced WP Reset omdat ze "vaak een kapotte website opleveren".
• WP Engine blokkeert WP phpMyAdmin en Adminer, die databasebeheer via een web-URL ontsluiten en zo een direct aanvalsoppervlak creeren.

Wat je in plaats daarvan kunt gebruiken. Gebruik voor databasetoegang de tool die je host in het dashboard biedt (phpMyAdmin via cPanel, Adminer via Kinsta's MyKinsta, of het equivalent). Voor .htaccess-gebaseerde redirects op nginx-hosts kun je redirects configureren via het dashboard van de host of support vragen om een nginx-redirectregel.

Statistiek- en analytics-plugins

Plugins die elke paginaweergave naar de WordPress-database loggen, produceren een schrijfbewerking bij elk verzoek. Op schaal verzadigt dit de database met insert-queries en laat wp_options of aangepaste tabellen onnodig groeien.

GoDaddy blokkeert expliciet meerdere statistiekplugins in deze categorie: WP-PostViews, WP Power Stats, WP SlimStat, StatPress en JR Referrer. Pressable blokkeert Melapress File Monitor om een vergelijkbare reden: het "vergroot de databaseomvang van de wp_options-tabel drastisch."

Wat je in plaats daarvan kunt gebruiken. Gebruik een client-side analyticsdienst die niet naar de WordPress-database schrijft: Google Analytics, Plausible, Fathom of Matomo Cloud. Die verwerken analyticsdata op hun eigen infrastructuur.

Vergelijkingstabel per host

Deze tabel vergelijkt de handhavingsaanpak en reikwijdte bij de zes hosts die in dit naslagartikel behandeld worden.

Bronnen: WP Engine, Kinsta, Pressable, GoDaddy, Flywheel, WordPress.com.

Wat niet op deze lijst staat. SiteGround en Cloudways publiceren geen formele blokkeerlijsten. Cloudways profileert zich expliciet als host die plugins vrij toestaat. Als pluginvrijheid voor jou een prioriteit is, zijn die hosts een stuk soepeler.

Hoe je controleert of je host beperkingen heeft

1. Zoek in de supportdocumentatie van je host naar "disallowed plugins," "banned plugins," "blocked plugins" of "incompatible plugins." Elke grote managed host publiceert een lijst.
2. Controleer de compatibiliteitsdocumentatie van de plugin zelf. De hosting-compatibiliteitspagina van WP Rocket is een goed voorbeeld: die documenteert het gedrag per host, inclusief welke functies automatisch uitgeschakeld worden op welk platform.
3. Probeer de plugin eerst op een staging-omgeving te installeren. Als de host het blokkeert, zie je een foutmelding bij activatie, of de plugin activeert maar de kernfunctie werkt niet (dit is gebruikelijk bij cachingplugins waarbij de pagecaching-module stilletjes wordt uitgeschakeld).
4. Neem contact op met de support van je host en vraag het rechtstreeks. Sommige beperkingen zijn niet openbaar gedocumenteerd, en sommige hosts hanteren aparte lijsten voor verschillende abonnementsniveaus. GoDaddy's Managed WooCommerce-abonnementen hebben een strengere blokkeerlijst dan hun standaard Managed WordPress-abonnementen.

Drie misverstanden die het rechtzetten waard zijn

"Als een plugin op WordPress.org staat, werkt die op elke host." De pluginreviewrichtlijnen van WordPress.org beperken de review tot codekwaliteit, GPL-compatibiliteit en omgang met gebruikersdata. Ze beoordelen geen hostingomgevingscompatibiliteit. Een plugin kan door de review komen en toch architecturaal incompatibel zijn met een specifiek managed platform.

"Een geblokkeerde plugin is verwijderd omdat die kwaadaardig is." Het overgrote deel van geblokkeerde plugins is beperkt vanwege prestatie- of architectuurconflicten, niet vanwege beveiliging. Cachingplugins conflicteren met server-level caches. Backupplugins dupliceren ingebouwde diensten en verbruiken te veel resources. Gerelateerde-berichtenplugins draaien dure databasequeries. Een klein deel op de lijst van GoDaddy is geblokkeerd vanwege bekende beveiligingslekken in specifieke verouderde versies (niet de huidige release), maar dat is de uitzondering.

"De pluginmap hernoemen omzeilt de beperking." Een pluginmap hernoemen is een legitieme techniek om een plugin te deactiveren als je niet bij wp-admin kunt, omdat WordPress de active_plugins-databaseoptie vergelijkt met het bestandssysteem. Maar op managed hosting werkt de handhavingslaag (mu-plugins, bestandssysteem-level schrijfblokkeringen) onafhankelijk van de reguliere pluginmapstructuur. De mu-plugin van de host laadt voor elke reguliere plugin en levert de infrastructuur die de geblokkeerde plugin zou hebben geleverd. De map hernoemen herstelt de geblokkeerde functionaliteit niet; het geeft je alleen een inactieve plugin onder een andere naam.

Contact met je host als je een geblokkeerde plugin nodig hebt

Als een geblokkeerde plugin functionaliteit biedt die je echt nodig hebt en het ingebouwde alternatief van de host je use case niet dekt, is de juiste route een supportgesprek, geen workaround.

Bereid je zo voor op dat gesprek:

• Noem de specifieke functie die je nodig hebt, niet de plugin. "Ik moet elke vier uur incrementele databasebackups naar een off-site S3-bucket plannen" is concreet. "Ik heb UpdraftPlus nodig" is dat niet, want de host wijst je dan naar hun eigen backupsysteem.
• Leg uit waarom het ingebouwde alternatief tekortschiet. Als de backupretentie van de host 30 dagen is maar jij 90 nodig hebt, zeg dat. Als de beveiligingsscanner van de host geen bestandsintegriteitsmonitoring dekt, zeg dat.
• Vraag of de plugin met specifieke functies uitgeschakeld mag draaien. Het WP Rocket-patroon (pagecaching uit, andere functies aan) is niet uniek voor WP Rocket. Sommige hosts staan een plugin toe als de conflicterende module uitgeschakeld is.
• Vraag naar de API- of CLI-tools van de host. De functie die je nodig hebt van een plugin is misschien beschikbaar via de API van de host, WP-CLI-integratie of dashboardtooling.

Als de host je workflow niet kan accommoderen, is dat een legitieme reden om te evalueren of de host de juiste keuze is voor je project. Pluginbeperkingen zijn een afweging: je krijgt beheerde infrastructuur, je levert wat pluginflexibiliteit in. Die afweging is het voor de meeste sites waard. Niet voor elke site.