Disallowed WordPress plugins on managed hosting

This reference covers plugin restrictions across six major managed WordPress hosts: WP Engine, Kinsta, Pressable, GoDaddy Managed WordPress, Flywheel, and WordPress.com. The policies documented here reflect each host's public support pages as of the dates noted per source. Host policies change; check your host's current documentation when a specific plugin matters to you.

Table of contents

• Why managed hosts block plugins at all
• How enforcement works: mu-plugins, not folder names
• Caching plugins
• Backup plugins
• Security and firewall plugins
• Related posts and database-heavy plugins
• Server-manipulating plugins
• Statistics and analytics plugins
• Cross-host comparison table
• How to check if your host has restrictions
• Three misconceptions worth correcting
• Working with your host when you need a blocked plugin

Why managed hosts block plugins at all

Managed WordPress hosting sells a promise: the host handles caching, backups, security, and server configuration so you do not have to. To deliver on that promise, the host runs its own server-level infrastructure for each of those functions. A third-party plugin that tries to do the same thing does not just duplicate the work. It conflicts with it.

A caching plugin that writes its own advanced-cache.php drop-in collides with the server-level page cache the host already operates. The result is double-cached pages, stale content, or outright crashes. A backup plugin that runs a full database dump and file archive on a schedule consumes CPU and I/O that the host's own backup system already uses, sometimes saturating the server during peak hours. A security plugin that scans every file on disk can exhaust PHP workers on a platform designed to handle the scanning at the infrastructure layer.

The restriction is not a judgment on the plugin's code quality. WordPress.org's plugin review process evaluates GPL compliance, code conduct, and user-data handling. It does not evaluate whether a plugin works correctly on every hosting architecture. A plugin can pass WordPress.org review and still be incompatible with a specific managed environment.

How enforcement works: mu-plugins, not folder names

Managed hosts enforce plugin restrictions through must-use plugins (mu-plugins), which live in wp-content/mu-plugins/ and load automatically before any regular plugin. You cannot deactivate an mu-plugin from the WordPress dashboard; it requires direct filesystem access that most managed hosts do not expose.

The host's mu-plugin handles the infrastructure the blocked plugin would have provided. Kinsta's mu-plugin, for example, manages full-page caching, CDN integration, and automatic cache purging. Removing or modifying it would break the site. This is the mechanism that makes renaming a blocked plugin's folder ineffective: the enforcement layer operates independently of the plugin folder structure, and the functionality the blocked plugin provides is already being handled by code you cannot modify.

On some hosts, restrictions are also enforced at the filesystem level. Pressable blocks writes to advanced-cache.php entirely, which means any caching plugin that depends on that drop-in file simply cannot function, regardless of its folder name.

Caching plugins

This is the largest and most consistently enforced category. Every managed WordPress host in this reference blocks or discourages third-party page caching plugins because the host operates its own server-level page cache (typically nginx fastcgi_cache, Varnish, or a proprietary equivalent). Installing a plugin-level page cache on top of a server-level one produces double-caching, stale content, or a site that crashes when both layers try to purge simultaneously.

For a detailed explanation of how WordPress caching layers work and why server-level caching is faster than plugin-level caching, see how WordPress caching actually works.

Commonly blocked caching plugins:

The WP Rocket exception. WP Rocket is the only caching/optimization plugin WP Engine permits, and it is also the only caching plugin allowed on WordPress.com Business and Commerce plans. On hosts where WP Rocket is allowed, its page caching module is automatically disabled by the host's integration, but its other features (LazyLoad, file optimization, CDN integration) continue to work. This "partial allow" pattern is common: the host blocks the page caching function specifically, not the entire plugin.

What to use instead. On a managed host, you already have page caching. You do not need to install anything for it. If you want the optimization features WP Rocket provides (file minification, lazy loading, critical CSS), WP Rocket works on most managed hosts with its caching module auto-disabled. For image optimization specifically, consider a service-based approach like ShortPixel or Imagify that processes images externally rather than on the server.

Backup plugins

Managed hosts block or discourage backup plugins for two reasons: the host already provides automated backups as part of the plan, and a plugin-level backup running alongside the host's own backup consumes significant server resources (full database dumps, disk I/O for file archiving, temporary storage for compressed archives).

Commonly blocked backup plugins:

Source dates: WP Engine (July 2025), Kinsta (January 2026), Pressable (September 2024), GoDaddy.

One notable detail on Kinsta. UpdraftPlus is banned on existing Kinsta sites but allowed on new ones. If you read "UpdraftPlus is banned on Kinsta" without that context, you get the wrong picture. Kinsta also version-gates BackWPup: versions 5.5 and below are blocked, but 5.6.0 and newer are allowed.

What to use instead. Your managed host's built-in backup system is the primary layer. For a second, independent copy (which you should have), use a backup approach that stores data off the host's infrastructure. For a full breakdown of what a real backup strategy looks like, including why host backups alone are not enough, read the WordPress backup strategy guide.

Security and firewall plugins

This category is more nuanced than caching or backups. Most managed hosts do not blanket-block security plugins; instead, they block specific features or require configuration changes.

Wordfence was removed from WP Engine's disallowed list in September 2019 after WP Engine's engineers worked with Wordfence to store WAF rules in the database instead of the filesystem, resolving the compatibility conflict. On Kinsta, Wordfence is supported but Traffic Logging must be disabled because the logging feature generates excessive database writes.

WordPress.com blocks security plugins entirely on the grounds that they "interfere with your site's built-in security systems." This is the most restrictive stance of any major host.

What to use instead. Managed hosts typically provide WAF protection, DDoS mitigation, and malware scanning at the infrastructure level, before WordPress even loads. A security plugin that operates inside WordPress (after the server has already accepted the request and started PHP) adds value for specific features like two-factor authentication, login audit logging, and file integrity monitoring, but it cannot replace infrastructure-level protection. For a practical WordPress security hardening checklist that works on any host, including what matters most and what is security theatre, see the linked guide.

Related posts and database-heavy plugins

Plugins that generate "related posts" listings by scanning content similarity across all posts run expensive LIKE queries, full-text index operations, or JOINs against large post tables on every page load. On a site with thousands of posts, this produces measurable MySQL load.

Commonly blocked:

• WP Engine explicitly blocks Dynamic Related Posts, SEO Auto Links & Related Posts, Similar Posts, and Contextual Related Posts, calling them "extremely database intensive."
• GoDaddy blocks the same category for the same reason.
• Flywheel discourages them, citing a "barrage of MySQL queries."
• Pressable blocks Broken Link Checker specifically, which "overwhelms servers with a very high amount of HTTP requests."

What to use instead. If you need related posts, use a plugin that pre-computes relationships on save rather than querying on page load (FLAVOR is one example), or use a tag/category-based approach built into your theme. For broken link checking, use an external service like Ahrefs Site Audit or the free Dr. Link Check that crawls your site from outside rather than hammering the database from inside.

Server-manipulating plugins

Some plugins need to write to files that managed hosts control: .htaccess (which does not exist on nginx-based hosts), wp-config.php, or system-level PHP configuration. These fail silently or break the site.

• Flywheel blocks all plugins that modify .htaccess because Flywheel runs nginx, not Apache. There is no .htaccess to modify.
• Flywheel also blocks plugins that write to wp-config.php, stating they "cannot function on Flywheel."
• WP Engine blocks VersionPress (version-control-based revisions) because it requires server-level functions disabled for security.
• WordPress.com blocks WP File Manager and Advanced WP Reset because they "often result in a broken website".
• WP Engine blocks WP phpMyAdmin and Adminer, which expose database management through a web URL, creating a direct attack surface.

What to use instead. For database access, use the database management tool your host provides in its dashboard (phpMyAdmin through cPanel, Adminer through Kinsta's MyKinsta, or the equivalent). For .htaccess-based redirects on nginx hosts, configure redirects through the host's dashboard or ask support for an nginx redirect rule.

Statistics and analytics plugins

Plugins that log every page view to the WordPress database create a write operation on every single request. At scale, this saturates the database with insert queries and bloats wp_options or custom tables.

GoDaddy explicitly blocks several statistics plugins in this category: WP-PostViews, WP Power Stats, WP SlimStat, StatPress, and JR Referrer. Pressable blocks Melapress File Monitor for a similar reason: it "drastically increases the database size of the wp_options table."

What to use instead. Use a client-side analytics service that does not write to the WordPress database: Google Analytics, Plausible, Fathom, or Matomo Cloud. These process analytics data on their own infrastructure.

Cross-host comparison table

This table compares enforcement approach and scope across the six hosts covered in this reference.

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

What is not on this list. SiteGround and Cloudways do not publish formal disallowed-plugins lists. Cloudways explicitly markets itself as allowing plugins freely. If plugin freedom is a priority for you, those hosts take a notably more permissive approach.

How to check if your host has restrictions

1. Search your host's support documentation for "disallowed plugins," "banned plugins," "blocked plugins," or "incompatible plugins." Every major managed host publishes a list.
2. Check the plugin's own compatibility documentation. WP Rocket's hosting compatibility page is a good example: it documents host-by-host behavior, including which features are auto-disabled on which platforms.
3. Try installing the plugin on a staging environment first. If the host blocks it, you will see an error during activation, or the plugin will activate but its core feature will not function (this is common with caching plugins where the page caching module is silently disabled).
4. Contact your host's support and ask directly. Some restrictions are not documented publicly, and some hosts maintain separate lists for different plan tiers. GoDaddy's Managed WooCommerce plans have a stricter blocklist than their standard Managed WordPress plans.

Three misconceptions worth correcting

"If a plugin is on WordPress.org, it works on any host." WordPress.org's plugin review guidelines scope their review to code quality, GPL compliance, and user-data handling. They do not evaluate hosting-environment compatibility. A plugin can pass review and still be architecturally incompatible with a specific managed platform.

"A blocked plugin was removed because it is malicious." The vast majority of blocked plugins are restricted for performance or architectural-conflict reasons, not security. Caching plugins conflict with server-level caches. Backup plugins duplicate built-in services and consume excessive resources. Related-posts plugins run expensive database queries. A small subset on GoDaddy's list is blocked for known security vulnerabilities in specific outdated versions (not the current release), but this is the exception.

"Renaming the plugin folder bypasses the restriction." Renaming a plugin's folder is a legitimate technique for deactivating a plugin when you cannot access wp-admin, because WordPress matches the active_plugins database option against the filesystem. But on managed hosting, the enforcement layer (mu-plugins, filesystem-level write blocks) operates independently of the regular plugin folder structure. The host's mu-plugin loads before any regular plugin and provides the infrastructure the blocked plugin would have provided. Renaming the folder does not restore the blocked functionality; it just gives you an inactive plugin under a different name.

Working with your host when you need a blocked plugin

If a blocked plugin provides functionality you genuinely need and the host's built-in alternative does not cover your use case, the path forward is a support conversation, not a workaround.

Prepare for that conversation:

• Name the specific feature you need, not the plugin. "I need to schedule incremental database backups to an off-site S3 bucket every four hours" is actionable. "I need UpdraftPlus" is not, because the host will point you to their built-in backup system.
• Explain why the built-in alternative falls short. If the host's backup retention is 30 days but you need 90, say that. If the host's security scanner does not cover file integrity monitoring, say that.
• Ask whether the plugin can run with specific features disabled. The WP Rocket pattern (page caching disabled, other features active) is not unique to WP Rocket. Some hosts will allow a plugin if its conflicting module is disabled.
• Ask about the host's API or CLI tools. The feature you need from a plugin may be available through the host's API, WP-CLI integration, or dashboard tooling.

If the host cannot accommodate your workflow, that is a legitimate reason to evaluate whether the host is the right fit for your project. Plugin restrictions are a trade-off: you gain managed infrastructure, you lose some plugin flexibility. That trade-off is worth it for most sites. It is not worth it for every site.