You can tell good WordPress development from bad without reading a single line of code. Good builds have a short plugin list, current versions, a backup someone has actually restored, a staging environment, and written documentation. Bad builds hide behind a nice-looking homepage: 43 plugins, edits pasted into the theme editor, and no record of who changed what.
What separates good WordPress development from bad?
Good WordPress development is judged by what happens six months after launch, not on launch day. Anyone can make a homepage look sharp in Elementor. The difference shows up when a plugin update breaks checkout, when Google flags the site for malware, or when you need to hire someone new and nobody can explain how the site works.
Bad development isn't usually incompetence. It's shortcuts that were invisible at the time and expensive later: a plugin installed to solve a five-minute problem and never removed, custom CSS dumped into the Customizer instead of a child theme, a "quick fix" edited live on production at 11pm.
Here's the uncomfortable part for site owners: you are the one who pays for those shortcuts, and you usually pay a different developer to fix them. So learning to spot the pattern is worth real money.
How to tell a good WordPress developer from a bad one: 7 checks anyone can do
You don't need technical skills for any of these. You need admin access and about 30 minutes. Run them on a site you already own, or ask a prospective developer to walk you through them on their own past work.
1. Count the plugins — then count the ones nobody can explain
Go to Plugins → Installed Plugins. Note the number of active plugins. Then ask your developer what each one does and why it's there.
There's no magic maximum, but there's a strong correlation: the more plugins nobody can justify, the worse the build. Three red flags in particular:
- Two plugins doing the same job (two SEO plugins, two caching plugins, two form builders). This is the single most common sign of unmanaged accretion.
- Deactivated-but-installed plugins. Inactive plugin files still sit on the server and can still be exploitable.
- Plugins with "last updated: 2 years ago" in the repository.
Our full WordPress plugin audit process walks through how to evaluate each one for security, performance, and redundancy. The short version: every plugin is a permanent subscription to someone else's code quality.
2. Check the update lag
Dashboard → Updates. How many core, plugin, and theme updates are pending, and how old are they?
According to Patchstack's State of WordPress Security report, 7,966 new vulnerabilities were disclosed across the WordPress ecosystem in 2024, with roughly 96% originating in plugins (2025). Nearly all of those had patches available. A site sitting six months behind on updates isn't "stable" — it's a published list of ways in.
A good developer has an update strategy with staged testing. A bad one has update anxiety, because they know something will break and they don't know what.
3. Ask for a restore, not a backup
This is the question that separates the two groups faster than anything else.
Don't ask "do we have backups?" Everyone says yes. Ask: "When did you last restore this site from a backup, and how long did it take?"
A good developer answers with a specific date and a number of minutes, because they've tested it. A bad one says "there's a plugin for that." Untested backups fail regularly — wrong database prefix, files excluded, storage quota hit three months ago and silently stopped. Our WordPress backup strategy guide covers what a real recovery plan includes.
4. Look for a staging environment
Ask: "Where do you test changes before they go live?"
If the answer is "on the site" or "I do it at night when traffic is low," you're paying for risk. A proper WordPress staging environment is table stakes in 2026 and comes standard with most managed hosting. Its absence tells you the developer either doesn't know or doesn't care — and both cost you the same.
5. Open Appearance → Theme File Editor
If the active theme is a popular commercial theme (Astra, Divi, Kadence, GeneratePress) and there's no child theme, that's a red flag. It means either nothing was customized in code, or customizations were made directly to the parent theme — and will be wiped on the next theme update.
Similarly, check Customizer → Additional CSS. Hundreds of lines of CSS in that box is a symptom, not a solution. So is a single "Code Snippets" plugin holding 30 snippets that constitute the site's actual business logic. There's a reasonable line between plugins and custom code — we wrote a framework for deciding when to replace plugins with code — but "everything lives in a text box" isn't it.
6. Ask where the code lives
"Can you send me the Git repository?"
If custom development happened, there should be a repo. If the honest answer is "the code is only on the server," you have no version history, no way to see what changed when, and no way to onboard a second developer without archaeology.
7. Check who owns the accounts
Look at Users → All Users. How many administrators are there? Are any of them named "admin"? Are there old contractor accounts still active? Then ask who the registrant is on the domain, who owns the hosting account, and whose credit card is on the plugin licenses.
A good developer builds in your name and hands you the keys. A bad one keeps the keys as a retention strategy. This one isn't about skill — it's about whether you're a client or a hostage.
Red flags vs green flags: the quick reference
| What you check | Green flag | Red flag | Why it costs you |
|---|---|---|---|
| Plugin count | Every plugin has a stated purpose | 30+, duplicates, inactive-but-installed | Each unjustified plugin is added attack surface and load time |
| Updates | Zero to a handful pending, monthly cadence | Months behind, "we don't update, it breaks" | ~96% of ecosystem vulnerabilities come from plugins (Patchstack, 2025) |
| Backups | Tested restore with a date and duration | "There's a plugin" | Untested backups fail exactly when you need them |
| Staging | Separate staging URL, documented workflow | Changes made live | Every edit is a potential outage |
| Theme | Child theme or block theme, versioned | Edits in parent theme / 400 lines in Additional CSS | Customizations vanish on update |
| Code | Git repo handed over | Server-only, no history | Vendor lock-in and expensive discovery for the next dev |
| Accounts | You own domain, host, and licenses | Developer owns everything | Leaving costs you weeks and legal friction |
| Performance | Core Web Vitals passing, measured | "It seems fast on my machine" | Deloitte found a 0.1s mobile speed improvement lifted retail conversions 8.4% (2020) |
| Security | Server-side scanning, MFA, hardened logins | A free scanner plugin and hope | Cleanup plus reputation recovery dwarfs prevention costs |
What does bad WordPress development actually cost?
Here's the math most site owners never see, because the costs arrive as separate invoices spread over two years.
| Consequence of a bad build | Typical cost | Frequency |
|---|---|---|
| Emergency malware cleanup | $300–$1,500 per incident | Recurring until root cause fixed |
| Rebuild of an unmaintainable site | $8,000–$25,000 | Once, painfully |
| Developer discovery time on an undocumented site | 8–20 billable hours before any work starts | Every new vendor |
| Downtime during peak sales | Direct revenue loss + support load | Unpredictable |
| Lost conversions from a slow site | Ongoing, invisible on any invoice | Continuous |
| Re-doing customizations wiped by a theme update | 4–12 hours | Every major theme release |
We covered the fuller accounting in what a WordPress security breach really costs, and the pattern is consistent: the prevention line item is always smaller than the remediation line item, and it's never close.
The part that stings for agency owners: when you inherit a bad build from a client's previous vendor and don't audit it first, you own the problem the moment you touch it. The client won't remember who installed the 43 plugins. They'll remember that the site broke while you were managing it.
How to audit a site you inherited without becoming technical
If you've just taken over a site — as an owner, a marketing director, or an agency onboarding a client — do these three things before you commit to a scope of work or a monthly retainer.
1. Get an objective third-party assessment in writing. Not from the developer you're evaluating. This is exactly why we built our AI site audit tool with Claude: it reads the actual site — plugin inventory, versions, performance signals, security posture, config issues — and produces a plain-English report you can hand to a non-technical stakeholder. Documentation you didn't write yourself is leverage in every subsequent conversation.
2. Establish a baseline you can point to later. Screenshot the plugin list, the pending update count, the Core Web Vitals scores, and the user list on day one. Six months from now this is how you prove things improved — or how you catch a vendor who let them slide.
3. Separate "broken" from "risky." Broken things get fixed this week. Risky things (no backups, no staging, shared admin accounts, unsupported PHP) get fixed before anything cosmetic. Owners frequently insist on the visual fix first; your job is to explain that a homepage redesign on an unbacked-up site is a nicer-looking liability.
What to ask before you hire a WordPress developer
Copy this into your next call. The answers are more revealing than any portfolio.
- "Walk me through your update process. What happens when a plugin update breaks something?"
- "When did you last restore a client site from backup?"
- "Where will I be able to see the code, and will I own it?"
- "How many plugins do you expect this build to need, and why?"
- "What happens if I want to move to a different developer in two years?"
- "Who will own the domain, hosting account, and plugin licenses?"
- "What's your monitoring setup, and how will I find out about downtime?"
Question five is the honesty test. Good developers answer it comfortably, because their work is portable by design. Watch what happens to the ones who don't.
Where hosting fits into all of this
A lot of what looks like bad development is actually bad infrastructure forcing bad decisions. When the host has no staging, no real backups, and no server-side security, developers compensate with plugins — caching plugins, security plugins, backup plugins — and each one adds another thing to break. That's how a clean build turns into a 40-plugin build in eighteen months. It's also a big part of why smart agencies outsource WordPress hosting entirely instead of absorbing that maintenance drag into their margins.
Move the plumbing to the platform and the plugin list shrinks on its own. On TopSyde, staging, backups, CDN, caching, and 24/7 monitoring are handled at the server level, and TopSyde Sentinel does server-side malware detection rather than relying on a scanner running inside WordPress. That's fewer plugins, fewer failure points, and fewer "why did the site go down?" conversations. If you want the specifics before you commit, the full platform spec sheet lists what's included at each tier, and pricing starts at $89/mo per site.
For agencies and freelancers, there's a second benefit: hosting gives you an objective standard to hold inherited sites against. When you can say "here's the audit, here's the plugin inventory, here's what we're removing and why," the client stops hearing opinion and starts hearing diagnosis. We break down that positioning in more detail in managed WordPress hosting for marketing agencies, and there's an honest ROI breakdown in is managed WordPress hosting worth the extra cost? — including the cases where it isn't.
The one-sentence version
Good WordPress development is boring six months later. If your site requires heroics — late-night fixes, plugin roulette, a developer who's the only person who understands it — that's not a complex site. That's a badly built one, and it's charging you interest.
If you're not sure which one you have, get the audit. Bring us a site you inherited and we'll tell you what's actually in it, in writing. Migration is handled for you, support responds in under 2 hours during business hours, and there's a 30-day money-back guarantee if the platform isn't a fit. Start with our pricing or look at what other agencies moved off before you sign another retainer on a build nobody has inspected.
Frequently Asked Questions
How many plugins is too many for a WordPress site?
There's no fixed number — a well-built WooCommerce store might legitimately run 25 plugins while a brochure site needs six. The real test is whether someone can explain the business purpose of each one. If more than a handful are unexplained, duplicated, or abandoned by their authors, the plugin list is the problem regardless of the count.
Can I tell if a WordPress developer is good without technical knowledge?
Yes. Ask about process rather than code: their update cadence, the last time they restored a backup, where they test changes, and who will own the code and accounts. Vague or defensive answers to those four questions are more predictive than any portfolio, because they reveal how the site will be maintained after launch.
Should I rebuild a badly developed WordPress site or fix it?
Audit first, then decide. Many "bad" sites are fundamentally sound builds buried under plugin bloat, missing updates, and bad hosting — those are cleanup jobs, not rebuilds. Rebuild when core business logic lives in untracked snippets, the theme has been directly modified, or nobody can document how key features work.
What are the biggest red flags in an inherited WordPress site?
In order of urgency: no tested backups, months of pending security updates, the developer owning your domain and hosting accounts, changes made directly on production with no staging, and customizations sitting in the parent theme or a code-snippet plugin. Any one of those turns a routine update into a potential outage.
How does a hosting change help with bad WordPress development?
Managed hosting absorbs the jobs that developers usually solve with plugins — caching, backups, staging, CDN, security scanning — which shrinks the plugin list and removes failure points. It also gives you a consistent baseline to measure inherited sites against, so quality conversations with developers are based on documented findings rather than opinion.
Founder & Lead Developer
20+ years full-stack development, WordPress, AI tools & agents
Colton is the founder of TopSyde with 20+ years of full-stack development experience spanning WordPress, cloud infrastructure, and AI-powered tooling. He specializes in performance optimization, server architecture, and building AI agents for automated site management.
