Plugin sprawl: when an AI build leaves you 40 plugins deep

#When the plugin list is longer than the sitemap

If the build also shipped custom PHP from an AI assistant, pair this audit with auditing AI-generated WordPress plugin code. When sprawl, custom code, and traffic loss compound, the work sits inside AI-built website rescue.

#The anonymised case: 38 plugins, 1.47s TTFB

A B2B professional services site (training and consulting for regulated industries) came to us after an internal stakeholder ran Lighthouse and asked why “WordPress felt slow.” The site had been assembled over roughly three weeks with Cursor and ChatGPT: page structure, copy drafts, form flows, and “just install something for that” plugin picks. Nobody owned the plugin list.

Hosting did not change: a 2 vCPU VPS with PHP 8.2 and no object cache at intake. We added Redis after the plugin pass, which shaved another ~120ms off TTFB, but the majority of the win came from removing and merging plugins, not from infrastructure upgrades.

The owner’s first reaction was predictable: “We only added what we needed.” That is exactly how sprawl presents. Each individual install had a plausible reason. The cost was cumulative.

#How AI builds reach 40 plugins faster than manual ones

Manual sprawl usually grows over months: a freelancer adds a slider, marketing adds a popup tool, someone installs a second SEO plugin “just to try it.” AI-assisted sprawl compresses the same behaviour into days because the model optimises for plausible completion, not stack coherence.

Recurring patterns we see on rescue intakes:

1. One prompt, one plugin. The assistant does not say “extend your existing form plugin.” It returns a slug.
2. No inventory memory. Session two does not know session one installed Rank Math; session four recommends Yoast for “better schema.”
3. Tutorial stacking. Blog posts and YouTube transcripts the model was trained on recommend “best plugins for X” lists. The build inherits the whole list.
4. Custom code plus commercial sprawl. The same assistant that suggested twelve plugins also generated three small custom plugins for “quick fixes,” adding unmaintained PHP on top of unmaintained dependencies.
5. Optimizer plugins as band-aids. When TTFB rises, the next prompt is “install a cache plugin,” sometimes without deactivating the first cache plugin.

None of this requires malice or incompetence. It requires a process gap: nobody with WordPress architecture responsibility reviewed the stack before launch.

#Eight categories that over-index on AI builds

On the anonymised site, these eight buckets accounted for 31 of the 38 plugins. Your list will differ, but the categories repeat across rescues.

#1. Duplicate SEO and schema tools

Two SEO plugins were active. Both output schema. Both hooked wp_head. One was left from a migration, one from the AI build week. Keep one. Merge settings manually; do not trust automatic importers blind.

#2. Multiple form builders

Contact Form 7, a drag-and-drop builder from a prompt, and a lightweight modal form plugin all captured leads into different inboxes. Consolidation moved three forms into one builder and deleted the rest.

#3. Competing cache and optimization plugins

A host-level cache plugin and a second “speed booster” both minified scripts. They produced intermittent broken JavaScript on the pricing page. Never run two HTML cache layers. Pick one system and configure it.

#4. Analytics and pixel sprawl

GA connector, a Facebook pixel plugin, a LinkedIn insight tag plugin, a heatmap trial, and GTM inserted twice (once via plugin, once via header snippet). Measurement did not improve. Request weight did.

#5. Page builder and addon packs

Elementor plus a commercial addon pack plus a legacy slider plugin left on “just in case.” The homepage used the builder; inner pages did not. We exported static sections where possible and removed the slider entirely.

#6. Security and housekeeping duplicates

Two login limiters, a file manager plugin (removed immediately), and a “database cleaner” that ran on every admin load. Security belongs in a deliberate stack, not three overlapping plugins.

#7. AI content and image tools

An AI writer plugin and an auto-alt-text tool added admin cron jobs and outbound API calls. Content workflows moved to editorial process; the plugins left.

#8. Custom AI mu-plugins

Three files in mu-plugins/ from pasted PHP: a custom redirect handler, a “fix” for REST permissions, and an admin column tweak. One redirect plugin duplicated .htaccess rules. One REST tweak disabled a legitimate integration. After security review, we kept the admin column tweak as vetted code in a single maintained file and deleted the other two.

#Self-diagnostic: signs you are plugin-deep

Run this before you install another optimizer.

Install Query Monitor on staging (not production if policy forbids), load the homepage logged out, and screenshot the query stack. That single view often embarrasses the stack into action.

#Triage: keep, merge, replace, remove

We use a four-column ledger on every sprawl rescue. Each active plugin gets exactly one label.

Keep - single owner of a function, maintained, no overlap. Example: the one SEO plugin after settings merge.

Merge - two plugins doing adjacent jobs that one maintained tool can cover. Example: three form plugins to one.

Replace - plugin job is valid but the implementation is heavy; replace with a few lines in a child theme or a block pattern. Example: a related-posts plugin that runs WP_Query on every view replaced with a curated block.

Remove - abandoned, duplicate, dangerous, or unused. File manager plugins, hello-world SEO trials, and “temporary” debug tools land here.

Work in batches of five to eight plugins maximum. Deactivate, test checkout and forms, measure TTFB, then delete. Bulk deletes are how production breaks on a Friday.

On the anonymised site the split looked like this:

• Keep: 21 plugins after consolidation (including Woo-less core stack, one SEO, one forms, one cache, one security suite)
• Merge: 9 plugins folded into kept tools
• Replace: 4 plugin jobs moved to theme code or blocks
• Remove: 8 plugins deleted outright (including 2 abandoned, 1 file manager, 1 duplicate cache)

#Custom AI plugins are still plugins

Teams often count only directory plugins and forget mu-plugins or “code snippets” plugins that inject PHP. AI assistants love generating those because it feels faster than teaching proper plugin structure.

Treat every custom file like third-party code:

• Read for ABSPATH guards, nonces, and $wpdb->prepare()
• Check whether the feature duplicates an existing plugin
• Move surviving code into version control, not a paste bin in wp-admin

If you find missing nonces and concatenated SQL, stop uninstalling commercial plugins until custom code is scoped. Bad custom PHP plus a shrinking commercial stack can expose endpoints nobody remembered.

#Consolidation workflow you can run on staging

1. Freeze new installs. No plugin answers until the ledger exists.
2. Export the active list to a spreadsheet: slug, version, last updated date, stated job, actual job.
3. Flag overlaps in SEO, cache, forms, analytics, and security first.
4. Deactivate duplicates on staging, clear all caches, test primary conversion paths.
5. Measure TTFB and query count on homepage, heaviest landing page, and checkout/contact thank-you page.
6. Delete in small batches, measure again after each batch.
7. Document the final stack in the project README or client handover so the next AI session has an inventory to read.

Pricing for rescue work is always individual because plugin count is only one variable. Database bloat, custom AI code, and traffic level matter as much as the number in wp-admin.

#What not to do

• Do not install a “plugin manager” plugin to fix plugin sprawl. You added another plugin.
• Do not enable two full-page caches “to be safe.”
• Do not let an AI assistant auto-generate a cleanup script that bulk-deletes rows in wp_options without a backup and diff review.
• Do not assume deactivated plugins are harmless. Some still load code on init if left in odd states; delete after verification.
• Do not skip forms and checkout tests because “it’s just a blog.” The anonymised site was lead-gen; the broken JavaScript was on the pricing page, not the blog index.

#When to escalate to rescue

Incremental cleanup works when overlaps are obvious, custom code is minimal, and someone technical owns staging. Escalate to a formal AI-built website rescue when:

• Active plugins stay above the mid-thirties after a first pass
• Multiple custom AI plugins touch authentication, uploads, or SQL
• TTFB remains above ~1s uncached after removing duplicate cache and SEO tools
• The business cannot afford a broken form or payment flow during unguided deletes
• Security scans show known CVEs across abandoned plugins nobody will update

Rescue is not a euphemism for rebuild. On the case above, 17 plugins left the stack and the site stayed on the same theme and hosting tier. The deliverable is a measured ledger, not a sales pitch for a new platform.

#Measuring success beyond the plugin count

Plugin count is a proxy. Track metrics that reflect user experience:

After consolidation, set a plugin budget: for this site class, no new plugin without retiring or merging an existing one. Give AI assistants that rule in the project instructions file so the next prompt does not undo the rescue in an afternoon.

#Glossary

• Plugin sprawl - accumulation of active plugins with overlapping jobs until performance, security, and maintainability degrade.
• TTFB (Time to First Byte) - server response time before the browser renders content; sensitive to PHP hook count and database queries.
• mu-plugin - must-use plugin loaded on every request from wp-content/mu-plugins/; often used for AI-generated “quick fixes.”
• Autoloaded options - WordPress options loaded on every request; bloated by plugins that store large arrays with autoload=yes.
• Query sprawl - excessive database queries per page view, common when many plugins each fetch metadata independently.

#The takeaway

Forty plugins deep is not a moral failure. It is what happens when fast AI-assisted assembly outruns architecture review. The anonymised site in this guide went from 38 to 21 active plugins, median uncached TTFB from 1.47s to 0.68s, and homepage queries from 187 to 94 without changing hosts or rebuilding the theme. The work was tedious, measurable, and mostly uninstalls.

Start with the ledger, kill duplicate SEO and cache layers, audit custom AI files before you celebrate deleting commercial plugins, and measure after every batch. If the stack still fights you, that is what AI-built website rescue is for: a keep, rewrite, and remove split with numbers attached, not another plugin recommendation.