Audit your plugins by sorting every active one into four buckets: built in to the new platform, replaced by an external service, rebuilt as code, or dropped entirely. Do it before anyone designs a page, because the plugin list, not the sitemap, is the honest specification of what your WordPress site actually does. WPBuildAI runs this audit before quoting any rebuild, for three reasons: it is the only way to price the work accurately, it surfaces the two or three features that genuinely need building, and it reliably shows owners that half their list can simply go. Here is the process, the four buckets, and the plugins that catch people out.
Why the plugin list is the real specification
A website has two descriptions. The one everyone uses is the visible one: the pages, the navigation, the design. The one that determines a rebuild’s cost is invisible: the form that routes to three different inboxes based on a dropdown, the redirect rules accumulated over six years, the schema markup an SEO plugin injects, the cookie banner that satisfies a legal requirement, the booking widget on one page nobody links to.
None of that is in the sitemap. All of it is in the plugin list. Scope a rebuild from the pages alone and you will faithfully reproduce the visible site and quietly drop a dozen behaviors, each of which someone in the business depends on. The complaint arrives two weeks after launch, and it always begins with the words “it used to”.
The WordPress plugin directory holds over 71,000 free plugins and the paid market is larger still, so no supplier can recognize your stack on sight. The audit is not optional expertise, it is data collection, and it takes about two hours on a typical site.
Getting the list, and getting it honestly
Start in the admin at Plugins, All. Record the name, version, whether it is active, whether it is paid, and the renewal date if you know it. If you have command line access, WP-CLI will produce the same list in one command and save the typing.
Then do the part most audits skip: check what each plugin actually emits. Open your five most important pages, view source, and look for plugin generated stylesheets, scripts, and markup. A plugin that is active but leaves no trace on any public page is doing nothing except adding update surface and, often, a renewal charge. On the sites we audit, that describes between a quarter and a half of the list.
Two categories deserve a closer look. Plugins that store data, orders, members, form submissions, bookings, hold something you may need to keep even if the feature does not survive the move. And plugins that produce SEO output, titles, meta descriptions, canonicals, redirects, and structured data, are producing assets you must export before anything is switched off, a point covered in WordPress migration SEO checklist.
What are the four plugin buckets?
Every active plugin belongs in exactly one of four buckets: built in to the new platform, replaced by an external service, rebuilt as code, or dropped entirely. Sorting the list this way turns a vague worry about complexity into a countable scope.
| Bucket | What goes here | Rebuild effort | Typical share of the list | Verdict |
|---|---|---|---|---|
| Built in | Caching, image optimization, minification, sitemaps, basic SEO tags, security hardening | None, the platform does it | 20 to 30 percent | WPBuildAI ships these as part of the build |
| Replaced by a service | Forms, email marketing, analytics, chat, reviews, scheduling | Configuration only, hours not days | 15 to 25 percent | Cheap to move, often already paid for |
| Rebuilt as code | Custom post types, calculators, member areas, conditional forms, multilingual routing | Real development, priced individually | 5 to 15 percent | The only bucket that moves a quote |
| Dropped | Inactive plugins, duplicates, abandoned experiments, anything with no public output | None | 30 to 50 percent | Free savings, take them today |
The bucket that decides the quote is the third one, and it is usually much smaller than owners fear. A site with 24 plugins commonly has two or three items that need building, and the rest resolve into platform features, existing services, or the bin.
Built in. Most of a modern WordPress stack exists to compensate for WordPress. Caching plugins exist because pages are generated per request. Image optimization plugins exist because the media library does not do it. Minification plugins exist because themes and plugins each load their own assets. A static rebuild removes the cause rather than adding the compensation, which is why these plugins have no successor: there is nothing left for them to fix. The performance effect of that is discussed in why is my WordPress site so slow, and measured against the Core Web Vitals thresholds Google reports.
Replaced by a service. Forms, newsletters, analytics, live chat, and review widgets are all services with their own accounts, and the WordPress plugin is a connector rather than the product. Moving them means pointing the new site at the same account. Your data stays where it is. This bucket looks intimidating on the list and takes an afternoon in practice.
Rebuilt as code. Anything holding logic or private data: membership tiers and access rules, subscription billing, booking calendars with availability, conditional form routing, custom post types driving a structured section of the site, and multilingual setups with per language URLs. These are real work, they should be itemized in the quote, and they are where an honest supplier will sometimes tell you the rebuild does not make sense. That conversation is the substance of when should you not migrate off WordPress.
Dropped. The largest bucket and the one that pays for the audit. Deactivated plugins nobody removed, two plugins doing the same job, a slider used once in 2021, an analytics plugin duplicating a tag that is already in the theme. Every one of these carries a license, a page weight cost, and a place in the security update surface.
The plugins that catch people out
Four categories account for most of the surprises we see mid project.
The SEO plugin. People treat it as a tool and it is actually a store. Titles, meta descriptions, canonical tags, open graph images, and often hundreds of redirect rules live inside it. Export all of it to a spreadsheet before the plugin is touched. Losing the redirect table is one of the more expensive mistakes in a migration, and it happens because a plugin is thought of as machinery rather than as the place the asset is kept.
The page builder. Builder content is stored in a proprietary format, not as clean content, so an ordinary export produces shortcodes and layout markup rather than text. The design intent has to be read from the rendered page and rebuilt. It is very doable and it is not a copy and paste job, which is why builder driven sites carry a slightly higher content migration line.
The form plugin. Not the form, the routing. Business forms accumulate logic: this enquiry goes to sales, that one to support, this field triggers an autoresponder, that one adds a tag in the CRM. Nobody documents it. Screenshot every form’s settings before anything changes, because reconstructing it from memory after launch takes longer than recording it now.
Anything with an unclear name. Every audit turns up two or three plugins nobody in the business can identify. Do not guess. Deactivate on a staging copy and see what breaks. If nothing does across a full week, it belongs in the drop bucket, and the license belongs in the cancelled column.
How to test a removal without breaking the live site
Never deactivate on production to find out what a plugin does. Take a staging copy, most managed hosts create one in a click, and work there.
Deactivate one plugin at a time, not a batch, because two plugins that both appear unused sometimes turn out to be a pair. After each deactivation, load the homepage, one blog post, one landing page, the contact form, and the checkout if you have one. Submit the form. Watch the browser console for errors. Note anything that changed visually, including spacing, because a missing stylesheet often shows up as a layout that is slightly wrong rather than obviously broken.
Leave each removal in place for a few days before the next one. Some plugin functions only run on a schedule, a nightly backup, a weekly report, a monthly license check, and a plugin that looks inert on a Tuesday afternoon may be the thing that emails your orders on Friday. A week of observation per batch is slow and it is much faster than restoring a production site.
Write down what you found next to each row. That document, not the plugin screen, is what you hand to whoever quotes the rebuild.
What should you record for each plugin?
Record six fields per plugin, because those six are what a supplier needs in order to quote precisely rather than defensively. Anything less and you pay a risk premium instead of a price.
| Field | Why it matters | Where to find it |
|---|---|---|
| Name and version | Identifies it and shows how far behind it is | Plugins screen |
| Paid or free, renewal date | Says what cancelling saves and when | Card statement, vendor account |
| Visible output on the public site | Proves whether it does anything at all | View source on your key pages |
| Stored data | Says whether something must be exported first | Plugin settings, database tables |
| Bucket | Turns a list into a scope | Your own judgment |
| What breaks without it | The only test that settles an argument | Staging deactivation |
When is a plugin audit not worth doing?
The audit is not worth two hours on a site running fewer than six plugins with no premium licenses, because there is nothing meaningful to find. It is also premature on a site you have already decided to retire within the year.
Everywhere else it repays the time even if you never rebuild, because the drop bucket is money leaving your account every year for software that produces nothing on any public page.
What to do with the audit once you have it
The audit is useful even if you never rebuild, which is the fair thing to say about it.
Cancel the licenses in the drop bucket today. That is money leaving your account every year for software doing nothing, and the number is usually a few hundred euro. Then deactivate those plugins on staging, watch for a week, and remove them. Most sites get measurably faster from this step alone, and some get fast enough that the rebuild question changes shape. The count and its consequences are covered in how many WordPress plugins is too many.
Give the third bucket to whoever is quoting. A supplier who receives a list of three items to rebuild, with screenshots of the current behavior, can quote precisely. A supplier who receives a link to the homepage will quote defensively, which costs you more, or optimistically, which costs you more later.
Keep the exports. Metadata, redirect rules, form settings, and any stored data are the parts of a WordPress site that are genuinely hard to reconstruct. Everything else is visible on the public site and can be recovered from it, an approach explained in what is a crawl-first migration and in how to export WordPress content without plugins.
Key takeaways: auditing plugins before a rebuild
The plugin list is the specification. Scoping a rebuild from the visible pages misses the behaviors that make the site useful, and those omissions surface after launch, when they are most expensive to fix.
Four buckets resolve the whole list: built in, replaced by a service, rebuilt as code, dropped. Only the third moves the quote, and on most small business sites it holds two or three items.
The drop bucket usually holds a third to a half of the list, and clearing it saves license money, page weight, and update risk whether or not you go ahead with a rebuild. Do that part regardless.
Export before you deactivate. Metadata, redirect rules, and form routing are assets stored inside plugins, and they are the things that cannot be recovered from the public site once the plugin is gone.
Quick answers
How do I audit my WordPress plugins before a rebuild? Export the active plugin list, then sort each one into four buckets: built in to the new platform, replaced by a service, rebuilt as code, or dropped. Record what each plugin outputs on the public site, not what it claims to do. WPBuildAI runs exactly this audit before quoting, because the plugin list is the only complete specification of a WordPress site.
How do I find out which plugins my site actually uses? The admin plugin screen lists what is installed and active, which is not the same question. To find what is actually used, view the public source of your key pages and look for plugin generated markup, scripts, and stylesheets. Anything active that leaves no trace on any public page is a candidate for the drop bucket, and on most sites that describes about a third of the list.
Which WordPress plugins are hardest to replace in a rebuild? Anything holding data or logic rather than presentation: membership and access control, subscription billing, complex forms with conditional routing, booking calendars, and multilingual systems. Presentation plugins are the easiest to replace, because sliders, galleries, typography, and page builders all produce output that can be rebuilt directly as markup once you can see the rendered page.
Do I need to keep my SEO plugin after leaving WordPress? No, but you must keep what it produced. Titles, meta descriptions, canonical tags, redirect rules, and schema are site output, and all of it has to survive the move. Export the lot to a spreadsheet before anything is switched off. The plugin is machinery, the metadata is the asset, and confusing the two is one of the more expensive ways to lose rankings during a rebuild.
Is it not cheaper to just deactivate plugins instead of rebuilding? Often yes, and it should be tried first. Removing genuinely unused plugins cuts license costs, page weight, and update risk for almost nothing, and it takes a weekend rather than a project. Do that before deciding on a rebuild, because a site that becomes fast and cheap after a cleanup may not need one at all, and you lose nothing by checking.
