WordPress Technical Debt Audit Checklist: What to Check and Why

A WordPress technical debt audit checks six areas: plugins and themes, server versions, custom code, speed, accessibility and security. This checklist lists what to look at in each area and what to write down, so you end up with evidence you can score and act on. Use it on your own site, or use it to check that an agency audit covers everything.

If you want the background on scoring and tracking, start with our guide on how to measure WordPress technical debt. This article is the hands-on companion.

Before you start

Set up the audit so it cannot hurt the live site:

• Take a fresh, tested backup of files and database.
• Create a staging copy for anything that needs testing.
• Get read access to hosting, the WordPress dashboard, the code repository (if there is one), Google Search Console and analytics.
• Write down the site’s key tasks: for example, “submit the quote form,” “buy a product,” “log in to the member area.” You will test these again and again.
• Note the date. An audit is a snapshot, and you will want to compare it later.

1. Plugins and themes

Plugins and themes are where most WordPress debt lives.

• Export a full list of plugins and themes with versions. With WP-CLI, the WordPress command-line tool, run wp plugin list and wp theme list.
• Mark each plugin with an update available, and how far behind it is.
• Check each free plugin’s page on WordPress.org. Note any that show the warning “This plugin hasn’t been tested with the latest 3 major releases of WordPress,” and any that have been closed.
• For premium plugins, confirm the license is active and the vendor still releases updates.
• List inactive plugins and themes. Unless there is a clear reason to keep them, they should go.
• Look for overlap: two SEO plugins, three slider plugins, several form builders.
• Check whether the active theme is a child theme or if the parent theme has been edited directly. Direct edits are lost on the next theme update.
• Note any plugins that were modified by hand. These cannot be updated safely.

What to record: total plugins, number outdated, number abandoned or closed, number inactive, and any edited third-party code.

2. Server and software versions

• Record the WordPress core version.
• Record the PHP version and compare it with the official PHP supported versions page.
• Record the MySQL or MariaDB version and compare it with the WordPress hosting handbook’s server recommendations.
• Record the web server (Nginx, Apache, LiteSpeed) and operating system versions if you have server access.
• Check the SSL certificate setup: renewal is automatic and the site redirects to HTTPS.
• Check the Site Health screen under Tools in the dashboard and note its critical issues.
• Run a PHP compatibility scan on staging before planning a PHP upgrade.

What to record: each version, its end-of-life date, and which components are already unsupported or will be within six months. Our guide to upgrading PHP on WordPress covers what to do next.

3. Custom code

• Find all custom code: the custom theme or child theme, custom plugins, must-use plugins in wp-content/mu-plugins, and snippets in functions.php or snippet plugins.
• Check whether the code is in version control (Git). If not, that is a finding on its own.
• Check for automated tests. Note whether any exist and whether they still run.
• Turn on debug logging on staging and click through the key tasks. Record PHP warnings, notices and deprecation messages.
• Look for calls to deprecated WordPress functions.
• Look for risky patterns: database queries built from user input without $wpdb->prepare(), output that is not escaped, and form handlers without nonce checks.
• Note hard-coded values that should be settings, such as email addresses, API keys or URLs.
• Check if anyone currently on the team understands the code. Code nobody can explain is expensive to change.

What to record: where custom code lives, its rough size, test coverage, error log findings and the riskiest files. If the list gets long, our article on automated testing with Playwright and PHPUnit shows how to put a safety net under it.

4. Speed

• Pull Core Web Vitals field data from PageSpeed Insights or Search Console for the home page and key templates. Google’s Web Vitals guide defines the “good” thresholds.
• Run lab tests on the same pages and note the largest issues, such as render-blocking scripts or oversized images.
• Measure page weight and the number of requests on key pages.
• Measure TTFB, the time the server takes to start responding, with and without page cache.
• On staging, use a tool like Query Monitor to find slow database queries and the plugins behind them.
• Check the size of autoloaded options and the database in general. Our guide to cleaning up a bloated WordPress database explains how.
• Check that page caching, object caching and a CDN are set up where they make sense.

What to record: Core Web Vitals per template, page weight, TTFB, the slowest queries and any caching gaps.

5. Accessibility

Audit against WCAG 2.2 level AA, the current W3C standard.

• Run an automated scanner on each key template.
• Navigate each key task using only the keyboard. Check that focus is always visible and never trapped.
• Test the same tasks with a screen reader.
• Check forms: every field has a label, errors are announced and explained, and required fields are marked in text, not just color.
• Check color contrast for text and controls.
• Check images for useful alt text, and videos for captions.
• Check headings for a logical order.
• Check new 2.2 criteria, such as focus not being hidden by sticky headers and minimum target sizes for buttons and links.

What to record: each failure, the WCAG criterion it fails, where it happens and how badly it blocks users. See our guide on how to audit WordPress accessibility for the full method.

6. Security

• List all administrator accounts. Flag former staff, old agencies, shared logins and test users.
• Check that two-factor authentication is required for admins.
• Search theme files, plugin files, the database and any public repositories for API keys and passwords.
• Look for backup files, database dumps and log files in the web root that anyone could download.
• Check whether XML-RPC is enabled and whether anything still uses it.
• Check whether the user list is exposed through the REST API or author archives.
• Confirm that file editing in the dashboard is disabled (DISALLOW_FILE_EDIT).
• Check file permissions and that wp-config.php is not readable from the web.
• Run a malware scan and check plugin versions against a vulnerability database.
• Confirm backups run, are stored off-site, and have been restored at least once as a test.

What to record: every exposure, how serious it is and how hard it is to fix. Our WordPress security hardening checklist goes deeper on fixes.

After the checklist: score and prioritize

A list of findings is not yet a plan. To turn it into one:

1. Score each area from 0 (healthy) to 3 (severe) using the same rules every time.
2. Flag anything urgent. Leaked keys, signs of compromise, unsupported PHP and blocked checkout flows go to the top.
3. Group quick wins. Deleting unused plugins and stale accounts often takes an afternoon.
4. Estimate the bigger work. Plugin replacements, PHP upgrades, test coverage and accessibility fixes each need a rough size.
5. Set a date for the next audit so you can measure progress.

If many areas score high, the next question is whether to fix the current site or start over. Our guide on whether to refactor or rebuild a legacy WordPress site helps with that decision.

Want a second pair of eyes?

Our technical debt audit follows this checklist, adds our experience with complex plugins and custom code, and gives you a scored report with a prioritized plan. If you would like us to look at your site, get in touch.

Frequently asked questions

What does a WordPress technical debt audit include?

It reviews six areas: plugins and themes, server software versions, custom code, speed, accessibility and security. Each area gets a score and a list of findings, and the result is a prioritized plan.

How long does a technical debt audit take?

For a typical business site, a few days of focused work. Large sites with lots of custom code, multisite networks or WooCommerce take longer because there is more to review and test.

Can I run a technical debt audit myself?

You can cover a lot of it with this checklist and free tools like WP-CLI, PageSpeed Insights and an accessibility scanner. The custom code review and manual accessibility testing are the parts where outside experience helps most.

Will an audit change anything on my live site?

It should not. A good audit is read-only on production. Anything that needs testing, like a PHP upgrade check, is done on a staging copy.