Skip to content
WordPress

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.

Stian BrendlienCEO at PXL
Published
Updated
Reading time
6 min
WordPress dashboard with 18 outdated plugins, PHP 7.4, a failed backup and critical site health
Illustration: what technical debt often looks like in wp-admin. Outdated PHP, 18 plugins waiting for an update and a backup that's more than a year old.

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.

Frequently asked questions

What is technical debt in WordPress?

Technical debt is the sum of shortcuts taken during development that create future costs. In WordPress, that typically means too many plugins, no version control, outdated PHP, heavy page builders and missing security practices.

How do I know if my website has technical debt?

The clearest signs are load time over 3 seconds, more than 15 plugins, no staging environment, last update several months ago, FTP as the only deployment method, and Elementor or WPBakery as your page builder.

Can technical debt be fixed without rebuilding everything?

Often yes. We modernise existing WordPress sites with WPFluent MVC architecture, FrankenPHP and CI/CD. Sometimes migrating to Sanity + Next.js is more cost-effective. We recommend whichever costs you less to get where you need to be.

What does a cleanup cost?

A technical review starts from NOK 10,000, and modernising an existing WordPress site from NOK 50,000. The price of migrating to Sanity depends on how much content and functionality needs to move.

Is it better to start over than to repair?

It depends on how much debt has accumulated. If the codebase is clean and the issues are infrastructure, we modernise. If everything is built in Elementor with 30 plugins, starting fresh with Sanity is often cheaper.

How do we avoid technical debt in the future?

Use version control (Git), a CI/CD pipeline, a staging environment, automated tests, custom plugins instead of off-the-shelf ones, and a maintenance agreement with an SLA. Or: choose Sanity + Next.js for new projects and avoid the plugin problem entirely.

Written by

Stian Brendlien

CEO at PXL

Stian has built and run web platforms for more than 18 years, including 13 years as CTO at Anbudstorget and five as contracted tech lead at GlobalConnect. He is a full-stack developer and the one you talk to about CI/CD, Kubernetes and architecture.

Wondering if your website has technical debt?

We'll do a no-obligation review and tell you what needs fixing and what can wait.

All articles