Technical Debt in Small Websites: How to Spot and Price It

Technical debt is a borrowed idea from software engineering: a shortcut that saves time now and costs more later. On a big product team it might mean skipping tests. On a small business website it is more mundane. A plugin that nobody has updated for years. A theme edited directly instead of through a child theme. A contact form that works because of a snippet pasted into a functions file in 2019. A hosting plan stuck on an old PHP version because upgrading "might break something".

None of these is a disaster on the day it is made. The cost arrives in instalments: a slower site, an unexpected outage, a security incident, and a quote for a redesign that is really a rescue. The useful question for an owner is not "do we have technical debt?", because every site does, but "how much, where, and what would it cost to pay it down?"

This guide gives you a simple scorecard to answer that for a small website, based on what the platform vendors and security bodies publish about maintenance. It does not need code access: most of the checks can be done from the admin screens, the hosting panel and a conversation with whoever built the site. If you want a professional pass, our website maintenance service includes one.

Be strict about the definition, or the scorecard will fill up with preferences. Technical debt is anything that makes the next change slower, riskier or more expensive than it needs to be. On a small site, six families cover almost everything:

• Outdated components. The core platform, plugins, themes, libraries and server software.
• Unmaintained components. Extensions whose developer has stopped, or which were closed or removed from the vendor's directory.
• Custom hacks. Edits to core or third-party files, and snippets with no documentation.
• Fragile infrastructure. Old PHP, no staging site, no tested backups, one person with the only password.
• Content and structure debt. Duplicate pages, orphaned landing pages, tangled redirects.
• Knowledge debt. No one knows why something was done.

A site that looks dated is not necessarily in debt: a plain, well-maintained site can be cheap to change. A beautiful site on a stack nobody understands can be very expensive. Keep appearance out of the scorecard.

The OWASP Top 10, the best-known awareness list for web application security, has a category called Vulnerable and Outdated Components. OWASP says you are likely vulnerable if you do not know the versions of all the components you use, including nested dependencies; if the software is vulnerable, unsupported or out of date, including the operating system, web server, database, applications and libraries; if you do not scan regularly and subscribe to security bulletins; if you do not fix or upgrade in a risk-based, timely way, which it says commonly happens when patching is a monthly or quarterly task under change control; and if developers do not test the compatibility of updated libraries. Read the entry: OWASP A06:2021.

Its prevention list is a maintenance plan in disguise: remove unused dependencies, features and files; keep a continuous inventory of component versions; monitor sources of vulnerability data; and subscribe to alerts for the components you use.

For a small business, the translation is simple. You need to know what is installed, which version, who maintains it, and whether it is still supported. That inventory is the first row of the scorecard.

Because many small sites run on WordPress, its published positions are a convenient baseline. WordPress says on its security page that only the latest version of WordPress is officially supported, although the Security Team backports fixes to older versions as a courtesy. For plugins and themes, vulnerabilities are reported to the developer and the plugins or theme review team; the page does not say who ships the patch. Source: WordPress security.

The plugin developer FAQ explains what happens when a plugin is closed: it stops generating zips and no one can download it through the website; plugins are closed for guideline violations, security issues or author requests. It also states that existing plugins that are no longer developed can be adopted, with no guarantee of a handover, and that not having a new owner for a plugin can have a lot of security implications. See the plugin developer FAQ.

Two practical checks follow. First, in the admin plugin list, look for plugins whose page on the directory says they have been closed or that show the "not tested with your version" notice. The FAQ explains that the "tested up to" value is set by the developer and that a missing or improper value produces a "not been tested" message. Second, check the server: WordPress recommends PHP 8.3 or greater and MariaDB 10.11 or greater or MySQL 8.0 or greater. It says it still works with PHP 7.4 and MySQL 5.5.5 in legacy environments but that these versions have reached end of life and may expose your site to security vulnerabilities (WordPress requirements).

The PHP project publishes the support status of each branch. At the time of writing (22 October 2026), the supported-versions page shows:

The page defines active support as a release receiving fixes for reported bugs and security issues, and "security fixes only" as meaning that only critical security issues are fixed. A site on PHP 8.2 therefore has until the end of 2026 for security fixes; any older branch is not listed as supported. Source: PHP supported versions.

Put the date of your PHP version's end in the calendar, and treat a version that is not on the page as a red-score item in the scorecard.

Score each line: 0 means fine, 1 means minor, 2 means a real problem, 3 means urgent. The lines are our own working method for small sites; they combine the OWASP and vendor guidance above with common agency practice.

Totals: 0 to 7 is healthy; 8 to 15 needs a maintenance plan; 16 to 22 needs a funded clean-up project; 23 to 30 means the site is a candidate for a rebuild. The bands are a rule of thumb, not an industry standard.

Debt is easiest to discuss when you can put a price on it. Ask a developer to estimate hours per scored line, then multiply by their rate. Our own simple websites start from EUR 300 excl. VAT (see pricing), but remediation work is hourly and depends on what you find. As a guide to the shape of the estimate, group the lines into three bundles.

1. Hygiene (lines 1, 2, 4, 10). Updates, removing unused items, moving PHP. Mostly routine, often within a monthly maintenance plan, with a staging test.
2. Replacement (lines 3, 5). Swapping abandoned plugins and undoing hacks. Each item is a small project: find an alternative, migrate settings and data, test.
3. Foundations (lines 6 to 9). Version control, staging, backups, access. A one-off setup, then it pays for itself in every later change.

Ask for each bundle to be quoted separately, with the highest-risk items first. If the replacement bundle exceeds the price of a clean rebuild, compare the options in our website redesign guide. A rebuild is not always cleaner: it carries its own debt if documentation and ownership are not part of the brief.

You can learn a lot without reading code.

• Admin screens. Count pending updates. Note any plugin without an update for a long time.
• Hosting panel. Read the PHP version and the database version, and check the age of the last backup.
• Ask the builder three questions. What was edited outside the normal settings? Where is the code stored? How would a new developer learn the site?
• Time a change. A trivial change, such as altering a phone number site-wide, shows how brittle the site is. If it takes a day, there is debt.
• Check the access list. Former staff and agencies with live admin accounts are a risk in their own right.

Write the findings in one page with the score beside each line, so the next person can pick up where you left off.

Be wary of two common false comforts. The first is "it has been fine for years": a site that has not been attacked is not the same as a site that cannot be. The second is a green tick from a plugin that claims to scan for everything. Such tools can help, but OWASP's advice is to keep an inventory and monitor vulnerability sources for the components you actually use, which no single tick replaces. Treat tool output as one input to the scorecard, never as the score.

You rarely need a single large clean-up. A calm approach is to schedule a small, regular slice of work.

1. Start with a backup you have actually restored on a copy.
2. Create a staging copy and apply updates there first.
3. Remove what is unused: plugins, themes, old media, test pages.
4. Replace the most dangerous abandoned component first.
5. Document custom code in a short readme and keep it in version control.
6. Move PHP to a supported branch when the staging test passes.
7. Set a monthly maintenance slot and a quarterly re-score.

OWASP's point about patching as a monthly or quarterly task under change control leaving "days or months of unnecessary exposure" is worth taking seriously: agree a fast lane for security updates, and a slow lane for everything else.

Rebuilding is justified when the platform itself is the problem: the core cannot be upgraded, the theme depends on abandoned frameworks, or the cost of the replacement bundle approaches the price of new work. It is not justified when the real issues are missing documentation and missing maintenance, because a new site without those will drift into the same state in two years.

Before any decision, run the scorecard, ask for the three bundle prices, and set a date to re-score after the work. To have us run the scorecard on your site, get in touch or request a quote, and see the WordPress development page for platform work.

• OWASP Top 10:2021 A06 Vulnerable and Outdated Components
• WordPress.org: security
• WordPress Plugin Handbook: plugin developer FAQ
• WordPress.org: requirements
• PHP: supported versions