What is technical debt in a WordPress site?

Technical debt is the extra cost of work that was skipped or rushed in the past. In WordPress it shows up as outdated plugins, old PHP versions, custom code with no tests, slow pages, accessibility errors and security gaps.

Can you really put a number on technical debt?

Yes, if you keep it simple. Score each of six areas from 0 (healthy) to 3 (severe) using the same rules every time. The total is not a precise science, but it shows where the risk is and whether it is going up or down.

How often should I measure technical debt?

Run a full measurement once or twice a year and a light check every quarter. Also measure before and after any big change, such as a redesign, a host move or a PHP upgrade.

Is technical debt always bad?

No. Sometimes taking a shortcut is the right business call. The problem is debt nobody tracks. Once it has a number, you can decide when to pay it down instead of being surprised by it.

How to Measure WordPress Technical Debt: Six Metrics and a Simple Score

You measure WordPress technical debt by checking six areas: outdated or abandoned plugins and themes, unsupported server software, untested custom code, speed, accessibility and security exposure. Give each area a score from 0 to 3 using fixed rules, add them up, and repeat the check on a schedule. The total tells you how much risk your site is carrying, and the trend tells you whether things are getting better or worse.

This guide explains each metric, shows a scoring table you can use today, and covers how to track the number over time.

What technical debt means for a WordPress site

Technical debt is the future cost of past shortcuts. A plugin installed “just for now” in 2019. A theme edited directly instead of through a child theme. A server left on an old version of PHP because the upgrade felt risky.

None of these break your site today. But each one makes the next change slower, riskier and more expensive. That extra cost is the “interest” on the debt.

Most owners only notice the debt when something fails, and by then the work is urgent and costs more. Measuring it ahead of time lets you plan instead.

Why measuring beats guessing

“The site feels old” is not something you can budget for. A number is. When we put a score on technical debt, three useful things happen:

You can compare. A score of 12 last year and 7 this year means the work paid off.
You can prioritize. If security scores 3 and speed scores 1, you know where to start.
You can explain it. A marketing manager can take a simple score to leadership. A list of 40 plugin names is much harder to sell.

The goal is not a perfect number, but one measured the same way every time.

The six metrics

1. Outdated and abandoned plugins and themes

This is usually the biggest source of debt. Check three things for every plugin and theme:

Is it up to date? Count how many versions behind each one is.
Is it still maintained? On WordPress.org, plugins that have not been tested with recent releases show this notice: “This plugin hasn’t been tested with the latest 3 major releases of WordPress.” Plugins can also be closed and removed from the directory. Either is a strong signal of abandonment.
Is it needed? Inactive plugins still sit on the server and can still be attacked. Plugins that do the same job as another plugin add weight for no benefit.

For premium plugins, check that the license is active and the vendor still ships updates.

2. PHP, database and server versions past support

Every PHP version gets two years of active support and then two years of security fixes only. After that it is end of life, with no more security patches. The official PHP supported versions page lists the dates. As of October 2026, PHP 8.2 receives security fixes only until December 31, 2026, and anything older is already unsupported.

WordPress publishes its own recommendations too. The WordPress hosting handbook currently recommends PHP 8.4 or later for production, along with supported long-term releases of MySQL or MariaDB.

Record the versions of PHP, MySQL or MariaDB, the web server and the operating system. Then compare each one to its end-of-life date. Our guide on how to upgrade the PHP version on WordPress covers the upgrade itself.

3. Untested custom code

Custom code is any code written just for your site: a custom theme, a custom plugin, or snippets in functions.php. It is often the most valuable code you own, and also the riskiest, because nobody else is maintaining it.

Measure two things:

How much custom code there is, roughly, in files and lines.
How much of it has automated tests. For most sites the honest answer is “none.” That is normal, but it is still debt. Every update becomes a manual test, and manual tests get skipped.

Also note obvious warning signs: edits made directly inside a parent theme or a third-party plugin, code that uses deprecated WordPress functions, and PHP warnings in the error log. Our article on automated testing with Playwright and PHPUnit explains how to start adding tests.

4. Speed

Speed debt builds up slowly. Each new plugin, tracking script or oversized image adds a little. Measure:

Core Web Vitals. These are Google’s three user experience metrics. LCP measures loading, INP measures how fast the page responds to input, and CLS measures how much the layout jumps around. Google’s Web Vitals guide on web.dev sets “good” at an LCP of 2.5 seconds or less, an INP of 200 milliseconds or less, and a CLS of 0.1 or less, measured at the 75th percentile of real visits.
Page weight. The total size of the page, including images, scripts and fonts.
Slow database queries. A tool like the Query Monitor plugin on a staging copy shows which queries are slow and which plugin runs them.

Use real user data where you have it, such as the Chrome User Experience Report shown in PageSpeed Insights. Lab tests are useful for finding causes, but real data shows what visitors actually feel. For more detail, see our Core Web Vitals guide for WordPress.

5. Accessibility errors against WCAG 2.2

The WCAG are the international standard for accessible websites. Version 2.2 became an official W3C Recommendation in October 2023. Most US legal and procurement standards point to level AA, often of the older 2.0 or 2.1 versions, and 2.2 AA builds on both.

Measure in two layers:

Automated scans on your key templates (home, a blog post, a product or service page, forms, checkout). These catch the problems a machine can check, such as missing alt text and low contrast.
A manual check with a keyboard and a screen reader on the same templates. Many WCAG failures can only be found by a person.

Count the issues by severity. A missing form label on your contact page matters more than a decorative image with a redundant alt attribute. Our guide on how to audit WordPress accessibility walks through the full process.

6. Security exposure

Security debt is anything that makes an attack easier. Check for:

Stale admin accounts. Former staff, old agencies and test users that still have administrator access.
Leaked keys. API keys or passwords in theme files, public Git repositories or old backup files left in the web root.
Open endpoints. XML-RPC enabled when nothing uses it, user lists exposed through the REST API, or debug logs that anyone can download.
Missing hardening. No two-factor authentication for admins, file editing enabled in the dashboard, weak file permissions, or no web application firewall.

Our WordPress security hardening checklist covers each item in detail.

A simple scoring approach

Here is the scoring method we recommend. It is deliberately simple. Each metric gets a score from 0 to 3, where 0 means healthy and 3 means severe. The six scores add up to a total from 0 to 18.

Metric	0: Healthy	1: Minor	2: Significant	3: Severe
Plugins and themes	All current, all maintained, nothing unused	A few updates pending, no abandoned items	One abandoned item, or many updates pending	Several abandoned or closed items, or major versions behind
Server versions	PHP and database in active support	Security-only support for one component	Support ends within 6 months	Any component past end of life
Custom code	Tested, or no custom code	Small amount, untested, no warnings	Large amount untested, or edited third-party code	Deprecated functions, frequent errors, nobody understands it
Speed	All three Core Web Vitals “good”	One vital “needs improvement”	One vital “poor” or two need improvement	Two or more vitals “poor”
Accessibility	No known WCAG 2.2 AA failures on key templates	A few minor failures	Failures that block some tasks	Key tasks (forms, checkout, navigation) blocked for keyboard or screen reader users
Security	Hardened, accounts reviewed, no exposures found	Small gaps, such as no two-factor login	Stale admin accounts or open endpoints	Leaked keys, known vulnerable code, or signs of compromise

How to read the total:

0 to 4: Low debt. Keep up regular maintenance.
5 to 9: Moderate debt. Plan fixes over the next few months.
10 to 18: High debt. Some of it is likely urgent. Start with any metric that scored 3.

Why we do not weight the metrics

Weighted scores are harder to explain and easy to argue about. Instead, we use one simple rule: any 3 is urgent, no matter what the total says. A site scoring 3 on security and 0 everywhere else has a total of only 3, but it still needs attention this week.

Keep the evidence with the score

A score without evidence is just an opinion. For each metric, write down what you found: the plugin names, the PHP version, the Core Web Vitals numbers, the list of accessibility failures. That way, anyone can check the score, and next year’s audit can compare like with like.

Tracking technical debt over time

Set a schedule

We suggest a full measurement once or twice a year, plus a lighter quarterly check of the metrics that change fastest: plugin updates, admin accounts and Core Web Vitals. Also measure before and after big changes, such as a redesign, a host change or a major plugin swap.

Automate what you can

Several metrics can be collected automatically:

WP-CLI, the WordPress command-line tool, can list plugins with available updates (wp plugin list --update=available) and list administrators (wp user list --role=administrator).
PageSpeed Insights and the Chrome User Experience Report provide Core Web Vitals data over time.
Automated accessibility scanners can run on a schedule against your key pages.

Manual checks still matter, but automation makes the quarterly check quick and consistent.

Watch the trend, not just the number

A score of 8 that was 12 last year is good news. A score of 6 that was 2 last year means debt is building faster than it is being paid down. Plot the six metric scores on a simple chart and you can see which area is slipping.

Turning the score into a plan

The score is only useful if it leads to action. A practical order:

Fix anything scored 3. These are the items most likely to cause an outage, a breach or a legal complaint.
Fix cheap wins next. Removing unused plugins and stale admin accounts often drops the score by a point or two in an afternoon.
Schedule the bigger work. PHP upgrades, replacing abandoned plugins and adding tests to custom code take planning. Put them on a calendar.
Decide on the big question. If most metrics score 2 or 3, it may be time to ask whether to refactor or rebuild the site.

For a full list of what to check in each area, use our WordPress technical debt audit checklist.

Get your site measured

If you want an outside view, our technical debt audit measures all six metrics, gives each one a score with evidence, and hands you a prioritized plan. We work on complex sites every day and are comfortable with the messy ones. If that sounds useful, contact us and tell us a little about your site.

Frequently asked questions

What is technical debt in a WordPress site?: Technical debt is the extra cost of work that was skipped or rushed in the past. In WordPress it shows up as outdated plugins, old PHP versions, custom code with no tests, slow pages, accessibility errors and security gaps.
Can you really put a number on technical debt?: Yes, if you keep it simple. Score each of six areas from 0 (healthy) to 3 (severe) using the same rules every time. The total is not a precise science, but it shows where the risk is and whether it is going up or down.
How often should I measure technical debt?: Run a full measurement once or twice a year and a light check every quarter. Also measure before and after any big change, such as a redesign, a host move or a PHP upgrade.
Is technical debt always bad?: No. Sometimes taking a shortcut is the right business call. The problem is debt nobody tracks. Once it has a number, you can decide when to pay it down instead of being surprised by it.