White-label inherited WordPress audit

Inherited WordPress sites are where agency margin disappears. The site is already live, the client assumes the agency now owns it, and nobody has fully mapped the stack. The risk is rarely just WordPress. It is access, hosting, plugins, PHP, custom theme code, backups, deploy process, and the expectations created by the previous supplier.

This is the white-label version of the audit: the agency owns the client relationship, the audit happens behind the agency brand, and the output becomes a quoteable plan for what should happen next.

For the service page, see white-label WordPress audit. For the access inventory format, pair this with the legacy handover checklist for agencies.

1. Start read-only

The first rule of an inherited site is simple: do not make changes before the system is mapped.

Collect:

• WordPress admin access
• hosting panel access
• DNS and registrar details
• repository access if one exists
• database access or export path
• backup provider access
• payment and email-provider ownership
• premium plugin license ownership
• notes from the previous supplier

Do not rotate credentials on day one unless there is an active security incident. Rotating first and mapping later is how agencies break webhook integrations, plugin updates, and hosting automations they did not know existed.

2. Map the site as a system

An inherited WordPress audit should produce a one-page system map.

Include:

• WordPress version
• PHP version
• MySQL or MariaDB version
• Ubuntu or hosting OS where visible
• theme and child theme
• active plugin list
• must-keep business flows
• custom plugins or snippets
• payment, CRM, email, analytics, and fulfillment integrations
• cron and scheduled tasks
• backup destinations
• deployment process

The goal is not to judge code quality yet. The goal is to know what the agency has accepted responsibility for.

3. Classify plugins by operational risk

Plugin count alone is not the problem. Plugin role is the problem.

Group plugins into:

• revenue-critical: checkout, payment, subscriptions, booking, membership
• data-critical: forms, CRM sync, analytics, import/export
• presentation-critical: builder, theme extensions, sliders, custom blocks
• operational: backups, security, caching, SMTP, redirects
• unknown or abandoned

This turns “43 plugins” into a plan. A stale slider plugin is not the same risk as a stale payment gateway. The audit should make that difference visible to the account lead and the client.

4. Check PHP and WordPress compatibility

Official WordPress requirements now recommend PHP 8.3 or greater, while older PHP versions may still run WordPress but are EOL and can expose sites to vulnerabilities.

Source facts last checked May 3, 2026: WordPress requirements and WordPress PHP compatibility notes.

For inherited sites, the useful question is not “what PHP version is recommended?” It is:

• what PHP version is the site actually using?
• does cron use the same version?
• do plugins and theme code support the target?
• can staging run the target version?
• can the old version be restored quickly?

If the site sells through WooCommerce, use the WooCommerce PHP upgrade audit as the more specific checklist.

5. Test backups before quoting fixes

Backups are often assumed until they are needed.

The audit should confirm:

• where backups are stored
• what is included: database, uploads, config, code
• retention period
• who owns the account
• whether a restore has been tested
• how long restore takes
• whether the restored site actually boots

A restore test changes the commercial conversation. It tells the agency whether they can safely quote updates, or whether the first paid task must be operational stabilization.

6. Produce a quoteable risk register

The output should be useful inside an agency proposal.

Each finding should include:

• what was found
• why it matters commercially
• severity
• suggested next step
• whether it blocks updates
• rough effort band

Examples:

• “Payment gateway plugin license is owned by previous supplier.”
• “PHP 8.3 staging test fails in custom checkout template.”
• “Backups exist but restore has not been verified.”
• “No repository found; theme edits appear to have been made in production.”

That is the difference between fear and scope.

7. Keep the client-facing message calm

The agency does not need to scare the client. The useful message is:

We have mapped the inherited site, found the operational risks, and separated immediate safety work from optional improvements.

That framing protects the relationship. It also prevents the agency from accidentally promising a fixed-price modernization before the stack is understood.

When to use a white-label audit

Use a white-label WordPress audit when the agency wants the risk register, plugin review, PHP check, backup assessment, and 30 / 60 / 90-day plan delivered behind its own brand.

Use a broader StackRefit audit when the inherited system includes custom PHP, Laravel, a separate database server, or VPS-level migration risk beyond WordPress itself.