Taking over a site somebody else built means inheriting decisions nobody documented. The instinct is to start improving it; the better first move is to find out what you have, because some of what looks improvable is load-bearing.
An hour of auditing before touching anything is the cheapest hour in the project.
Establish access before anything else
Not just the WordPress login. The hosting account, the domain registrar, the mailboxes, and any third-party service the site depends on.
Find out specifically whose name the domain is registered in. A domain in the previous developer's name is the single largest risk you have inherited, and it is resolved by negotiation rather than by support. There is more in How to Work with a Web Developer on Your Hosting.
Then check the account's contact address. If it is the previous owner's, password resets and security warnings are still going to them.
Take a backup before you learn anything
Files and database, downloaded and verified, before the first change.
You do not yet know what is fragile. A backup taken now is the only version of the site as it was handed to you, and it is what makes the rest of the audit safe to perform. How to Restore a WordPress Site from Backup walks through using it.
Check whether it is already compromised
Before assuming the site is merely neglected.
Look at the administrator list for accounts nobody recognises. Check for .php files in the uploads directory, which are never legitimate. Look at file modification dates for a cluster of changes nobody can explain.
An unmaintained site is compromised often enough that this is worth ten minutes instead of an assumption. How to Clean Up a Hacked WordPress Site explains what to do if you find something.
Inventory the plugins, and their state
For each one: what it does, whether it is active, when it was last updated, and whether it is still maintained.
Three categories emerge. Ones doing something visible and important. Ones nobody can account for. And abandoned ones, not updated in years, which are the security problem, because a disclosed vulnerability in them will never be fixed.
Do not delete anything yet. Deactivate the unaccounted-for ones one at a time and see what breaks; the ones that break something were load-bearing and undocumented. How to Choose and Vet WordPress Plugins explains judging replacements.
Find the custom code
The part that decides how risky updates are.
Is the theme a child theme, or was the parent edited directly? If it was edited directly, the next theme update erases that work, and the site may be on an old version specifically because someone discovered that.
Look for code in functions.php, in a site-specific plugin, and in template overrides. WooCommerce's status page lists outdated template overrides explicitly, which is the fastest way to find them on a shop.
Check the environment
PHP version and whether it still receives security updates. The database version. Whether the site is on the plan it needs.
An old PHP version is common on an inherited site, and it is usually old because nobody dared change it. Test on a staging copy rather than switching live. There is more on the extension trap that breaks the upgrade in MultiPHP Manager and Choosing a PHP Version.
Find out what is scheduled
Cron jobs in the hosting account, scheduled tasks inside the application, and anything a plugin runs.
Inherited sites frequently have a job nobody knows about. A nightly export to a system that no longer exists, a sync to a supplier who is no longer a supplier. Some are harmless; some are sending data somewhere. There is more on finding them in How to Set Up Cron Jobs in cPanel.
Check the things that expire
Domain expiry and whether auto-renewal is on. Certificate expiry and whether it renews automatically. Any third-party subscription the site depends on, and when it renews.
Each of those is a site that stops working on a date, and the date is often close on a site that has been neglected. There is more on the one that is hardest to undo in What Happens When a Domain Expires.
Then fix in this order
Security first: credentials, two-factor, and updates for anything with a known vulnerability.
Then continuity: backups running and restored once, monitoring alerting to you rather than to the previous owner.
Then the environment: PHP version, and removing what is genuinely unused.
Improvements last. A faster site that nobody can restore is worse than a slow one that somebody can.
Write it down as you go
The document you wished you had inherited: what each plugin is for, where the custom code lives, what is scheduled, what expires when, and who holds which account.
You will need it yourself within a year, and it is what makes the next handover an hour in place of a week.
Work out what the site is actually built on
Before judging anything, establish which parts are standard and which are somebody's decision, because only the second kind can be wrong.
wp core version; wp theme list; wp plugin list --fields=name,version,status,update wp option get template; wp option get stylesheet diff <(wp theme get "$(wp option get template)" --field=version) /dev/null 2>/dev/null
A child theme means customisation lives in a place that survives updates. Its absence, on a site that has clearly been customised, means the changes are in a theme that an update will overwrite, which is the most important thing to find on the first day.
Check whether core files have been modified as well. A site with edited core files cannot be updated safely and that constraint shapes everything you plan afterwards.
Measure it before you change it
Inherited sites come with a reputation, and the reputation is frequently wrong in both directions.
curl -s -o /dev/null -w 'ttfb %{time_starttransfer} total %{time_total}\n' https://example.com/
wp db size --human-readable
wp db query "SELECT COUNT(*) FROM wp_options WHERE autoload='yes';"
du -sh wp-content/uploads
Record these on the first day. They are the baseline against which everything you do afterwards is judged, and they cannot be reconstructed later.
The autoloaded options count is the single most useful number on a neglected site. Several thousand means every page load reads a large block of data before doing anything else, and it is a common consequence of plugins installed and removed over years. Cleaning up the database deals with it.
Find out who else has access
An inherited site comes with inherited accounts, and some of them belong to people who are no longer involved.
wp user list --fields=ID,user_login,user_email,roles,user_registered wp user list --role=administrator --fields=user_login,user_email ls -la ~/.ssh/authorized_keys 2>/dev/null && wc -l < ~/.ssh/authorized_keys
Read the administrator list first. Accounts with an address at a domain you do not recognise, or with a registration date that does not match anything, are the ones to ask about.
Do not delete them immediately. Reassign their content first, since deleting an account can remove or orphan the posts attributed to it. Demote to a role with no privileges, confirm nothing broke, and remove later.