What technical debt in WordPress really costs
Technical debt in WordPress can turn a NOK 15,000 website into a NOK 200,000 bill over three years. See what the debt costs and how to get rid of it.
- Published
- Updated
- Reading time
- 6 min

In short
- Technical debt in WordPress is shortcuts such as off-the-shelf themes, page builders, piles of plugins and FTP deployment that make every later change more expensive.
- In our experience, a WordPress site with high technical debt costs two to four times more to maintain than one built on clean architecture.
- The way out is either modernising WordPress with Git, CI/CD and fewer plugins, or moving pure content sites to Sanity and Next.js.
Technical debt is shortcuts taken during development that make every later change more expensive. In WordPress it typically means off-the-shelf themes, page builders, piles of plugins, outdated PHP and FTP deployment. In our experience, a site with high technical debt costs two to four times more to maintain than a site with clean architecture.
The website nobody dares to touch
The site cost NOK 15,000, the agency delivered in three weeks and everyone was happy.
Six months later the contact form works intermittently. The site takes four seconds to load. Marketing wants to change a headline, but the developer says it'll take two days because "Elementor makes it difficult." And nobody remembers the password to the hosting account.
Sound familiar? Then you're sitting on technical debt.
What is technical debt?
Technical debt is shortcuts taken during development that create future costs. In WordPress, that means:
- Off-the-shelf themes with code you'll never understand
- Plugins that do half of what you need while loading 200 KB of JavaScript you don't
- No version control: changes are made directly in production via FTP
- No staging environment: you test in prod and hope for the best
- No automated tests: you discover bugs when customers complain
At first you don't notice the debt, because the site works. But every shortcut makes later changes more expensive, and eventually nobody dares update anything because the risk of something breaking is too high.
The usual culprits
We see the same culprits again and again.
Elementor and WPBakery
Page builders like Elementor and WPBakery solve a real problem: they let people without coding skills build websites. The problem is what they do under the hood.
A typical Elementor page loads 300-500 KB of extra JavaScript and CSS, even on pages that don't use Elementor functionality. Every widget element generates nested HTML that's hard to style and maintain and can't be migrated, so you're locked into Elementor.
Gutenberg, WordPress's built-in editor, is a better choice. With custom blocks, editors get the same flexibility without the performance penalty.
20+ plugins
Every plugin is a dependency, a new attack surface, a potential conflict with the next WordPress update and one more thing that needs maintaining.
We regularly see sites with 25-40 plugins, where three do the same thing, five haven't been updated in over a year and two have known security vulnerabilities.
Our rule is simple: if 50 lines of clean code can solve it, we choose that over a plugin. Custom plugins built on WPFluent do exactly what you need and nothing more.
FTP and no version control
If the only way to deploy code is to FTP files to the server, you have a problem. There's no history of who changed what, no way to roll back, no code review and no automated tests.
Professional WordPress development uses Git, CI/CD pipelines and staging environments. Code is tested before it reaches production, and deployments run automatically when something is merged to main.
PHP 7.x on shared hosting
PHP 7.4 reached end of life on 28 November 2022 and receives no security fixes, yet many WordPress sites still run on PHP 7.x. The hosting provider offers it, and nobody has asked for anything else.
PHP 8.4 is significantly faster and more secure, and it handles errors better. FrankenPHP Worker Mode gives response times under 200 ms, while shared hosting with PHP 7.4 gives you 3-5 seconds.
What technical debt actually costs
The sums behind a cheap website rarely add up, because these costs are left out.
| Cost item | Typical cost |
|---|---|
| Building a cheap WordPress site | NOK 15,000 |
| Debugging, security cleanups and lost traffic over three years | NOK 200,000 |
| Cleanup after a security incident | NOK 20,000-50,000 |
| Proactive maintenance with an SLA | from NOK 2,500/month |
| Maintenance with high technical debt | 2-4x more than with clean architecture |
| Response time, shared hosting with PHP 7.4 vs FrankenPHP | 3-5 s vs under 200 ms |
Security incidents
Patchstack recorded 11,334 new vulnerabilities in the WordPress ecosystem in 2025, a 42% increase on 2024. 91% were in plugins and 9% in themes. Only 6 were reported in WordPress core, all low priority. That's why outdated plugins on shared hosting without a firewall are so exposed.
A security incident typically costs NOK 20,000-50,000 in cleanup. On top of that come lost revenue, a damaged reputation and the time it takes Google to trust your domain again after blacklisting it.
With a maintenance agreement with an SLA, proactive security costs from NOK 2,500 per month.
Lost SEO visibility
Google confirms that Core Web Vitals are used by its ranking systems, and rates an LCP of 2.5 seconds or less as good. A site that takes 4 seconds to load loses traffic to competitors that load in under a second. According to Google/SOASTA Research (2017), the probability of a mobile visitor bouncing increases 32% as load time goes from 1 to 3 seconds, and 90% from 1 to 5 seconds.
Technical debt makes your site slower as plugins, JavaScript and database queries pile up. Without active performance optimisation, it keeps getting slower every year.
Developer lock-in
The agency that built the site is the only one that understands it, because there isn't any code to understand. There's just an Elementor configuration with 40 plugins that only works on that exact server with that exact PHP version.
If you want to switch agencies, you'll almost have to rebuild. In practice you're held hostage by the old one.
Wasted developer hours
The developer spends two hours on a change that should take ten minutes. There's no documentation, the theme is a labyrinth of nested shortcodes, and updating plugin A breaks plugin B which depends on plugin C.
Over three years, those hours add up. A site with high technical debt typically costs 2-4x more to maintain than one with clean architecture.
How to spot technical debt
Some signs are obvious:
- The site takes over 3 seconds to load
- You have more than 15 active plugins
- There's no staging environment
- The last plugin update was more than three months ago
- The deployment method is FTP
- The page builder is Elementor, WPBakery or Divi
- The PHP version is older than 8.2, the oldest one still receiving security fixes
- Nobody uses version control (Git)
- Nobody knows exactly who has access to wp-admin
- You're afraid to update anything
If you recognise three or more of these, you probably have a problem.
Two ways out
1. Modernise your existing WordPress
If the site has valuable content, good SEO rankings and an editorial team that knows WordPress, modernisation is often the right call.
Our WordPress team replaces Elementor with Gutenberg and custom blocks, removes unnecessary plugins and builds lightweight alternatives with WPFluent MVC. Then we set up Git, CI/CD, staging and automated tests, and move the site to FrankenPHP with managed infrastructure.
You keep your content, URLs and SEO visibility. The site becomes faster, more secure and cheaper to maintain.
2. Migrate to Sanity + Next.js
If the site is a pure content site without an online store or heavy WordPress-specific integrations, it's often cheaper to start fresh with Sanity CMS and Next.js.
That leaves out plugins, PHP and security holes from third-party code. Response times land under 100 ms, and maintenance costs a fraction of what WordPress does.
For many businesses, a new Sanity site is cheaper than cleaning up a WordPress site with heavy debt.
How to avoid technical debt from the start
Three principles help most:
Choose the right platform. For new projects without specific WordPress requirements, we recommend Sanity + Next.js. Without plugin dependencies, you take on no technical debt from third-party code.
Demand version control and CI/CD, whatever the platform. If the agency doesn't use Git, doesn't have a staging environment, or deploys via FTP, find another agency.
Plan for maintenance. A website without a maintenance agreement is like a car without servicing: it runs fine for a while, until suddenly it doesn't.
Not sure whether your site has technical debt? Get in touch for a no-obligation review. We'll tell you honestly what needs fixing and what can wait.


