Auditing an Inherited WordPress Theme: The 90-Minute Method

#The job

A site arrives with a theme nobody understands. The previous developer is gone, the client wants changes, and you need to know within a couple of hours whether this theme is a foundation or a liability. Ninety minutes is enough if you look at the right things in the right order.

Work on a staging copy with a fresh backup. Never on live.

#Minutes 0 to 10: identify what it is

Read style.css in the theme folder. The header block names the theme, version, author and, if it is a child theme, the parent. Then:

• Marketplace theme, child theme, or bespoke? A ThemeForest-style multipurpose theme with a child is common and has known characteristics: heavy, bundled plugins, a page builder. A bespoke theme has no parent and its quality depends entirely on who wrote it.
• Is it up to date? For a marketplace theme, compare the version to the current release. Years behind means a large upgrade or a replacement.
• Classic or block? A theme.json and templates/ folder means block theme. header.php and functions.php doing everything means classic.
• Is there a page builder? Elementor, Divi, WPBakery. If so, the content is in the builder's format and the theme is secondary.

Write a one-line summary. Everything after depends on it.

#Minutes 10 to 30: read functions.php and includes

Open functions.php and whatever it requires. Look for:

• What it enqueues. Every script and style loaded on every page. Count them. Note anything loaded from a CDN, anything loaded unconditionally that only one page uses, and jQuery plugins for effects nobody uses.
• What it registers. Post types, taxonomies, menus, sidebars, image sizes. Post types in the theme are a red flag: switch themes and the content disappears from admin.
• What it hooks. Filters on the_content, wp_head output, anything modifying queries globally. pre_get_posts hooks that alter every query are a classic performance trap.
• External calls. wp_remote_get, file_get_contents on URLs, API calls at render time. A theme that phones home on every page load is slow and fragile.
• Bundled plugins or libraries. A /inc/plugins/ folder full of zip files means the theme installs its own plugins, often outdated.

#Minutes 30 to 50: the templates

Open the main templates: header.php, footer.php, index.php, single.php, page.php, and any custom templates. You are looking for:

• Queries in templates. new WP_Query or get_posts inside a template, especially inside loops. Count them per page; more than a handful is a performance problem waiting.
• Unescaped output. echo $variable without esc_html, esc_attr or esc_url. Each is a potential XSS. Grep for echo $ and check.
• Hardcoded content. Phone numbers, addresses, copy typed into templates. The client cannot change these, and it explains why "just update the number" became a developer ticket.
• Inline styles and scripts. <style> and <script> blocks in templates. They bypass caching and enqueue ordering.
• Missing template parts. A single-service.php that duplicates single.php with one change, six times over.

#Minutes 50 to 65: performance, measured

Load the home page and an inner page on a throttled connection with the browser's performance tools, or through a lab tool. Note:

• Total requests and total weight.
• The number of script and style files and where they come from.
• The largest contentful paint element and whether it is a properly sized image.
• Long tasks on the main thread and which script owns them.
• Whether a caching layer is active and whether the page is served from it.

Query Monitor, installed on staging, shows the database queries per page and which component made them. A theme causing eighty queries on the home page is a theme with a problem.

#Minutes 65 to 80: security and hygiene

• Escaping, from the template pass.
• Nonces on any forms the theme handles itself.
• File permissions and anything writable the theme expects.
• Abandoned bundled plugins and their known vulnerabilities.
• Direct file access guards (defined('ABSPATH') || exit) on PHP files.
• Anything reading $_GET or $_POST without sanitisation.

#Minutes 80 to 90: the write-up

One page. Four sections.

What it is. The one-line summary from minute ten.

What is wrong. The findings, each with severity and location. Performance, security, maintainability.

What it would take to keep it. The fixes, roughly costed. Removing the unused enqueues, moving post types to a plugin, escaping output, fixing the query hooks.

What it would take to replace it. A new theme with the same content, roughly costed, and the ranking risk if URLs change.

The recommendation, in one sentence. Keep if the theme is sound and the issues are cosmetic. Replace if it is a years-old multipurpose theme with a page builder and a dozen bundled plugins, because the fixes would cost more than the replacement and leave you with the same foundation.

#What we usually find

Marketplace themes several versions behind with a page builder: replace, as part of a planned redesign. Bespoke themes by a competent developer with a few unescaped outputs and too many enqueues: keep and fix in a day. Bespoke themes by someone learning: it depends on how much of the site's logic lives in them. The ninety minutes is what lets us give a client a fixed quote rather than a shrug.