Inherited WordPress Site Audit: What to Check Before You Take Over Someone Else’s Website

The first mistake: treating an inherited site like a new project

A new WordPress build starts with decisions you control.

An inherited site starts with decisions somebody else already made—often without documentation.

You may find:

• premium plugins activated under the previous agency’s license;
• custom PHP hidden in functions.php;
• must-use plugins installed by hosting or an old developer;
• hard-coded API credentials;
• DNS controlled by an unknown account;
• three backup systems, none tested for restore;
• two caching layers invalidating each other;
• cron disabled in wp-config.php with no server cron configured;
• Google Search Console still owned by a former vendor;
• unused admin accounts;
• custom database tables with no known owner;
• WooCommerce integrations firing from background jobs nobody monitors.

The takeover therefore has a different objective:

Before changing the system, discover what must not break.

Phase 1: get ownership before you get WordPress access

A WordPress administrator account is not ownership of the website.

Build an access matrix for every system the website depends on.

Google has specifically warned about old Search Console ownership tokens remaining after owners or agencies move on. Review users and unused verification tokens, not only visible Search Console accounts.

Phase 2: create a recovery point before changing anything

WordPress’s own update documentation recommends backing up the site before updates, and plugin-management documentation repeats the same warning for plugin updates.

For an inherited site, I would go further:

• backup the database;
• backup the entire WordPress filesystem;
• record current DNS and important host configuration;
• export critical plugin settings where supported;
• record current versions;
• store the snapshot somewhere independent of the live filesystem if practical;
• prove how restore works.

A backup you have never restored is a hope, not yet a recovery procedure.

If the site may be compromised, do not destroy the suspicious copy immediately. WordPress’s hacked-site guidance recommends preserving a snapshot before cleanup because even an infected copy can be useful for reference and forensics.

WooCommerce changes the meaning of rollback

A normal brochure site can often tolerate a full database restore to a recent snapshot.

A store may receive:

• orders;
• payments;
• refunds;
• new accounts;
• subscription changes;
• stock updates;
• coupon usage;
• fulfillment status

after the snapshot.

Restoring yesterday’s full database may repair a plugin update while deleting today’s legitimate commerce.

For WooCommerce, document separate rollback strategies for:

• code: plugin/theme/custom-code rollback;
• configuration: setting reversal;
• database schema: migration rollback/recovery;
• transaction data: preservation/reconciliation.

This is the same operational distinction in the WooCommerce Maintenance Cost framework.

Phase 3: take a WordPress inventory

Do not rely only on the wp-admin Plugins screen.

Inventory:

• WordPress core version and update state;
• active theme and parent theme;
• inactive themes;
• active plugins;
• inactive plugins;
• must-use plugins;
• drop-ins such as object-cache.php;
• custom plugins;
• custom code snippets;
• child-theme code;
• server/host-level plugins;
• custom database tables;
• cron/background tasks;
• third-party webhooks/API integrations.

WordPress documents must-use plugins separately because they are automatically enabled and cannot be disabled through the normal Plugins screen. They can therefore contain critical logic that a casual inventory misses.

WP-CLI can make the inventory more explicit. Its wp plugin list command reports installed plugins, activation status and update availability and can list drop-ins as well.

Phase 4: use Site Health as a baseline, not as the whole audit

Start with:

Tools → Site Health → Status / Info

WordPress Site Health provides a high-level view of the environment and flags critical/recommended configuration issues. Its Info view can expose useful runtime details without immediately opening server configuration files.

Capture the Site Health information before major changes so you have a baseline.

But Site Health does not tell you:

• why a custom plugin exists;
• whether the previous agency still owns your license;
• whether checkout actually works;
• whether an ERP mapping is correct;
• whether a cron task duplicates another job;
• whether your SEO plugin generated the intended canonical;
• whether an inactive plugin left 5 GB of tables behind.

It is a starting instrument, not a replacement for system understanding.

Phase 5: determine code provenance

Every non-core code component should answer three questions:

1. Where did this code come from?
2. Who owns/supports it?
3. Can it be updated safely?

For WordPress.org-distributed code, WP-CLI provides checksum tools. wp core verify-checksums compares core files with WordPress.org checksums, and wp plugin verify-checksums can verify supported plugin packages.

A checksum mismatch is not automatically malware—it can be a legitimate local edit—but it is evidence that deserves explanation.

Phase 6: review security ownership, not just security plugins

WordPress’s current hardening guidance treats security as ongoing work, not a one-time plugin installation.

For a takeover audit, review:

• all administrators;
• unexpected user roles/capabilities;
• old agency/developer accounts;
• 2FA/MFA where available;
• application passwords/API credentials;
• SSH/SFTP accounts;
• database credentials;
• SMTP/API keys;
• payment/webhook secrets;
• wp-config.php custom constants;
• debug exposure;
• filesystem ownership/permissions;
• HTTPS/redirect behavior;
• security/CDN/WAF rules.

WordPress’s security documentation recommends keeping core, plugins and themes current and favors actively maintained components. But do not update first and ask questions later. On inherited production, secure change means backup → staging → compatibility test → update → regression.

Do not leave debugging exposed

Inspect wp-config.php for:

WP_DEBUG
WP_DEBUG_LOG
WP_DEBUG_DISPLAY
DISABLE_WP_CRON
WP_CACHE
WP_MEMORY_LIMIT
custom environment constants
API / license constants

WordPress debugging documentation explains that WP_DEBUG and WP_DEBUG_LOG are useful in development. WordPress Site Health also warns that debug output or logs may expose sensitive information when accessible publicly.

Inherited sites often contain debug flags left from a previous incident.

Phase 7: audit cron, queues and background work

WordPress’s WP-Cron is traffic-triggered: it checks scheduled tasks when page loads occur. Some hosts replace or supplement it with a real system scheduler.

You need to know which model the inherited site uses.

Check:

• is DISABLE_WP_CRON enabled?
• if yes, is a real server cron configured?
• are there duplicate recurring events?
• are old plugin hooks still scheduled?
• do tasks run at unrealistic frequency?
• are long jobs competing with traffic?

WordPress explicitly warns developers that repeatedly scheduling the same event without checking can create thousands of duplicate scheduled tasks.

WP-CLI’s wp cron commands can list and test WordPress cron behavior.

For WooCommerce, inspect Scheduled Actions separately

Go to:

WooCommerce → Status → Scheduled Actions

WooCommerce documents pending, in-progress, complete and failed background actions there, with logs for failed tasks.

Look for:

• large pending backlogs;
• very old pending actions;
• repeated failures;
• subscription renewal errors;
• webhook/integration jobs;
• imports/exports;
• email tasks;
• migration jobs.

Phase 8: inspect database health before “optimizing” it

Do not open phpMyAdmin and start deleting rows because a table looks large.

First identify:

• database size;
• largest tables;
• tables not using the current WordPress prefix;
• plugin-specific custom tables;
• orphaned tables from removed plugins;
• large options/transients;
• large postmeta/usermeta tables;
• Action Scheduler tables on WooCommerce;
• revision/log/session tables;
• database errors/corruption.

WP-CLI provides wp db check to check database status and commands to enumerate tables.

Large does not mean bad. A large orders table on a busy store can be healthy; a 2 GB orphaned log table from a deleted plugin can be waste.

Determine ownership before deletion.

Audit autoloaded options carefully

Inherited sites often accumulate configuration from years of themes/plugins.

Inspect:

• autoloaded option volume;
• large serialized options;
• expired transient behavior;
• plugin settings belonging to removed plugins;
• cache/plugin options loaded on every request.

The WordPress Transients API is specifically intended for temporary cached data with expiration. Treat persistent leftovers as something to investigate, not automatically delete.

Phase 9: test the actual application, not just wp-admin

Before updates, establish a smoke-test baseline.

Generic WordPress

• homepage;
• main templates;
• search;
• forms;
• login/password reset;
• media uploads;
• transactional email;
• mobile navigation;
• critical admin workflows;
• scheduled publishing if used.

WooCommerce

• product → cart;
• cart → checkout;
• guest/logged-in order;
• shipping/tax;
• each material payment method;
• order email;
• stock;
• refund;
• My Account;
• CRM/ERP/fulfillment;
• Scheduled Actions.

If checkout is already slow, capture that before changing plugins. Use the slow WooCommerce checkout diagnostic to establish whether the bottleneck is frontend, Store API, PHP/database or a remote integration.

Phase 10: audit SEO and indexing before changing URLs or plugins

An inherited site’s search traffic can be damaged by a technically “successful” migration or cleanup.

Check:

• Search Console ownership;
• current sitemap URLs;
• robots.txt;
• page-level noindex;
• canonical tags;
• redirect rules;
• 404s;
• staging-domain leakage;
• www/non-www and HTTP/HTTPS normalization;
• SEO plugin ownership/configuration;
• schema output;
• hreflang if multilingual;
• analytics/tag manager.

Google’s current robots documentation is worth remembering: robots.txt controls crawling; it is not a reliable mechanism for keeping HTML pages out of Google. noindex is the indexing control when Google can crawl the page.

Google’s Search Console guidance recommends verifying ownership and using Search Console to review whether Google can find/read your pages and to inspect indexing issues.

Phase 11: classify every finding by business risk

A takeover audit can easily produce 80 findings.

Do not fix them in the order you discover them.

This prevents a common inherited-site failure:

Spend day one refactoring CSS while the domain is still owned by a former employee and the store has no tested backup.

Do not update 27 plugins in one batch

Once a snapshot, staging environment and smoke tests exist, plan updates in controlled groups.

A reasonable sequence may be:

1. security-critical isolated updates;
2. WordPress core / runtime prerequisites;
3. WooCommerce and its tightly coupled official extensions;
4. payment/shipping/tax dependencies;
5. theme/page builder;
6. content/SEO/analytics plugins;
7. low-risk utility plugins;
8. abandoned/replacement candidates separately.

After each meaningful group:

• run smoke tests;
• inspect logs;
• inspect Woo Scheduled Actions if applicable;
• compare performance;
• commit/document the state.

The detailed isolation process is in the WooCommerce Plugin Conflict Guide.

Do not remove inactive plugins before checking what they left behind

Inactive code increases maintenance/security inventory and is usually a cleanup candidate.

But before deleting it, determine:

• was it intentionally deactivated during an incident?
• does it own custom tables/data needed for migration?
• is another plugin reading its data?
• does the business still need exported settings/history?
• did it create scheduled jobs that remain?

Removal should include data ownership decisions, not only file deletion.

Look for duplicate ownership

Inherited WordPress stacks often contain two or more tools doing the same job:

• two SEO plugins;
• two cache plugins;
• multiple schema generators;
• two SMTP layers;
• several security plugins plus host/WAF overlap;
• multiple redirect managers;
• multiple optimization/minification systems;
• two pricing/discount engines in WooCommerce.

The risk is not plugin count alone. It is competing ownership of the same state.

That principle also drives the plugin vs custom architecture framework.

Performance baseline: measure before cleanup

Record at least:

• homepage/product/content TTFB;
• critical page Core Web Vitals where field data exists;
• admin responsiveness;
• slow requests/APM traces if host provides them;
• database size;
• PHP/runtime resource pressure;
• object/page-cache configuration;
• third-party script inventory;
• WooCommerce checkout timing if applicable.

Without a baseline, deleting ten plugins and changing hosting may make the site “feel faster” but you cannot reliably attribute the improvement—or detect a regression.

The first 30 days after taking over a WordPress site

What the final takeover report should contain

I would deliver a report with:

1. Ownership/access map — what is controlled, missing or still vendor-owned.
2. Recovery status — backups, retention, restore method, WooCommerce rollback caveats.
3. Environment inventory — host, PHP/DB, cache, CDN, cron, mail.
4. Dependency inventory — core, themes, plugins, MU plugins, drop-ins, custom code.
5. License/support map — renewal and ownership risk.
6. Security findings — accounts, credentials, updates, debug exposure and integrity anomalies.
7. Database/queue findings — large/orphaned tables, cron, Scheduled Actions.
8. Functional baseline — forms, checkout, integrations, email and other critical paths.
9. SEO/analytics baseline — Search Console, indexation, sitemap, canonical/robots, measurement.
10. Risk-ranked remediation plan — P0–P5 with effort and dependencies.
11. 30/60/90-day roadmap — stabilize, simplify, then improve.

When the audit should become a fixed project

A fixed remediation project makes sense when the audit identifies a bounded body of work:

• update and replace eight known dependencies;
• migrate hosting;
• replace abandoned theme;
• rewrite one custom plugin;
• repair checkout integration;
• move DNS/CDN/analytics into client ownership;
• clean a known database/log problem.

That is a defined finish line.

When the audit should become maintenance or a retainer

Ongoing support makes sense when the site has recurring operational or growth work after stabilization.

Maintenance if the main need is updates, backups, security, monitoring and incident ownership.

Development/growth retainer if the backlog continues to change—SEO, CRO, integrations, content, small features and performance work.

If the backlog will continue to change, the WordPress growth retainer explains how ongoing technical work is scoped and prioritised.

Inherited WordPress site audit: final checklist

• Domain ownership transferred?
• DNS/CDN/WAF access confirmed?
• Hosting/billing belongs to client?
• Independent WordPress admin created?
• SSH/SFTP/database access confirmed?
• Files + DB snapshot created?
• Restore procedure understood/tested?
• Core/theme/plugin/MU/drop-in inventory exported?
• Premium licenses identified?
• Custom code has repository/owner?
• Core/plugin checksums reviewed where applicable?
• Admin users and old vendor access reviewed?
• Debug/log exposure checked?
• WP-Cron/server cron mapped?
• Woo Scheduled Actions reviewed?
• Database/table growth understood?
• Forms/email tested?
• Woo checkout/payments/refunds tested?
• CRM/ERP/webhooks tested?
• Search Console ownership cleaned up?
• robots/noindex/canonical/sitemap baseline captured?
• Analytics/tag manager ownership confirmed?
• Performance baseline recorded?
• P0–P5 remediation backlog created?
• First 30-day stabilization plan agreed?

If you cannot answer those questions, you have not fully taken over the site yet—you only have access to it.