Taking over a client's WordPress site: a checklist to run before you change anything

Before you change anything on a WordPress site you have inherited, take a backup of your own, record the state the site is in, and tell the client in writing what you found. That record is your baseline: it shows what was already wrong on the day you arrived. A backup you took and restored yourself is the only one you know works.

This checklist is for an agency or a freelancer who has agreed to maintain a site someone else built, and who can already get into it. If access is the problem, start with how to take over a WordPress site when the developer has disappeared.

The commands use WP-CLI, run over SSH from the folder that holds wp-config.php. How to use WP-CLI to manage a WordPress site covers connecting. Where a dashboard screen shows the same thing, it is named. To keep any listing as a file, add --format=csv and send it to the baseline folder made in the backup step:

Access and ownership

The client should be the owner of record on every row. You should have a login of your own, never the client's password and never the previous developer's.

A shared login cannot show who did what, and it cannot be taken away from one person. In WordPress, an administrator adds you under Users, then "Add User". Where the owner of record is you or the previous developer, record it: moving an account into the client's name is the client's decision, and often a separate job.

Check one more address. "Administration Email Address", under Settings, then General, receives the recovery mode and critical error notices. WordPress's documentation says that on a site set up by a developer or an agency, it should point to an address the organization can read.

Write down: for each account, the owner of record, everyone else with a login, and the level of your own access.

Back up before you touch anything

A full backup is two things: the files and the database. Take both yourself. Whatever backups the site already has are unproven until someone restores one.

Without SSH, make a full copy with the host's backup tool or a backup plugin, and download it.

Write down: the date and time of your backup, the size of each file, where the copies are kept, the date of the test restore and what you checked on it.

The baseline audit

Each check ends with what to record. None of them fixes anything.

WordPress, PHP and the database

The first three print the WordPress version, any newer release (or Success: WordPress is at the latest version.), and the database server's version.

Read wp cli info with care. It describes WP-CLI's own environment: its "PHP version" line is the PHP on the command line, and its "MySQL binary" line is the client program, not the database server. For the PHP that serves visitors, open Tools, then Site Health, then the Info tab, and read "PHP version" under Server. The end-of-life checker shows whether each version still gets security fixes.

Write down: the three versions, whether a newer WordPress is waiting, and whether the PHP version is still supported.

Site Health

On the Status tab, WordPress sorts its own tests into critical issues, recommended improvements and passed tests. Copy every critical issue and every recommendation as worded.

On the Info tab, select "Copy site info to clipboard" and paste the result into your document. It holds the versions, the active and inactive plugins and themes, the server and database details, and whether WordPress can write to its folders: most of a baseline in one step, with no command line. The site health check adds what a page shows from outside.

Plugins and themes

Each row says whether the plugin is active, whether an update is waiting, and whether automatic updates are on. In the theme list, a status of parent means the active child theme depends on that theme. Never delete it.

wporg_status says whether WordPress.org still lists the plugin. An answer of active can be relied on. Check every other answer by hand. WP-CLI looks a plugin up by its folder name, and it reports closed whenever a second lookup, of WordPress.org's code repository, returns anything other than "not found". When that lookup is refused, a custom plugin that was never on WordPress.org is reported as closed too.

For each plugin that is not active, open https://wordpress.org/plugins/ followed by its folder name:

• Closed. The page says the plugin has been closed and is not available for download. The reasons WordPress.org gives include the author's request, a guideline violation and a security issue. No update will arrive for it.
• Left behind. The page carries a notice that begins "This plugin hasn't been tested with the latest 3 major releases of WordPress."
• No page at all. The plugin is paid or custom. Find out who sells it, whose account holds the license and whether that license still receives updates.

Write down: the full list, and separately: updates waiting, closed and untested plugins, and each paid plugin with its vendor, license holder and renewal date.

Must-use plugins and drop-ins

Must-use plugins live in wp-content/mu-plugins. They cannot be switched off from the dashboard, only removed as files, and they show no update notices. Drop-ins are single files in wp-content that replace a part of WordPress. Finding one is not a fault: advanced-cache.php and object-cache.php are how caching is wired in. But WordPress's documentation warns that a compromised must-use plugin may be harder to detect than a regular one.

On the Plugins screen, the links "Must-Use" and "Drop-ins" above the table show the same lists. The ls shows subfolders, which the lists leave out.

Write down: every file, what it does and who put it there. Open each one.

Custom code and the child theme

Look in four places: a child theme, a plugin with no page on WordPress.org, the must-use folder, and a snippets plugin that keeps code in the database.

A child theme keeps its changes apart from the parent, so the parent can be updated without losing them. If the active theme has no child and was edited directly, the next theme update overwrites the edits. WP-CLI has no checksum command for themes. To see whether a theme from WordPress.org was edited, download the same version and compare the two folders.

Write down: where each piece of custom code lives, who wrote it, and whether a copy exists outside the site, such as a repository. If none does, your backup is the only copy.

Users, roles and registration

The Users screen shows the same list. The client should be able to put a person's name to every administrator. Mark shared logins, accounts of people who have left, and any account nobody can identify. For that last kind, read what to do about an unknown admin user before going further.

The two options are "Anyone can register" and "New User Default Role" on the General settings screen. A 1 with a default role above subscriber means anyone can register and be given that role.

Write down: every administrator with a name beside it, the accounts to be reviewed, and both settings.

Application passwords

An application password lets a program sign in to the site's REST API or XML-RPC as a user. It cannot be used on the login screen, so nobody sees it in daily use, and one made for an old deployment script or a phone app is easy to forget.

WP-CLI prints created and last_used as Unix timestamps, such as 1791420391. On Linux, date -d @1791420391 turns one into a date. On a site with thousands of customer accounts, add --role=administrator to the inner wp user list first.

In the dashboard, the list is on each user's profile under "Application Passwords", with the columns "Last Used" and "Last IP" and a "Revoke" link.

Write down: each one, its owner, when it was last used, and whether anyone knows what it is for.

Checksums

These compare WordPress and each plugin with the releases on WordPress.org. A clean run prints one line for each command and nothing else:

Anything else on the screen is a finding, even when the last line still says Success.

Do not repair anything yet. If a changed or added file cannot be explained, stop and work through how to check whether your site has been hacked.

Write down: both last lines, every warning, and the explanation for each or the words "not explained".

Scheduled events

The list shows every scheduled task with its next run. Look for hooks that belong to a plugin no longer installed, and for run times far in the past, which mean scheduled tasks are not running.

wp cron test asks the site to start its scheduler, as any visit does, and answers Success: WP-Cron spawning is working as expected. It reports an error when DISABLE_WP_CRON is set, which is not a fault if the server calls the scheduler itself.

Write down: the number of events, any hook you cannot place, and the answer to the test.

Autoloaded options

Autoloaded options are the settings WordPress loads on every page. Site Health tests their total size. A pass reads "Autoloaded options are acceptable". Above 800,000 bytes it raises "Autoloaded options could affect performance" as a critical issue.

The first query gives the total and the second the ten largest. Both count the four values WordPress has autoloaded since version 6.6. WP-CLI's own shortcut, wp option list --autoload=on --format=total_bytes, counts only on and yes, so it reads low on a current site.

Write down: the total, and the largest options with the plugin each belongs to. Change none of them now.

The error log

WordPress keeps a log of its own only when WP_DEBUG_LOG is set. The first command prints 1 when it is on, a path when the log goes to a file elsewhere, and an error that the constant is not defined when it is off. Switched on, the log is wp-content/debug.log, and Site Health raises "Your site is set to log errors to a potentially public file". WordPress's documentation does not recommend its debugging tools on a live site, so a log left on is itself a finding. Otherwise PHP's errors go to a log the host keeps.

Write down: the errors that repeat, the file each one names, and the date of the oldest.

Forms and email

Send a real message through every form, from an address outside the client's domain, and confirm it arrives. A form can show its thank-you message while the email goes nowhere.

Write down: each form, where it sends, and whether the message arrived.

A store

WooCommerce's documentation says to test payments on a staging site only, and that many payment gateways have a sandbox or test mode. So place the test order on your staging copy, with the gateway in test mode, and delete the order afterward. WooCommerce gives a test order no special status.

On the live store, read. Open WooCommerce, then Orders, and look at the last few weeks. "Failed" means a payment failed or was declined. "Pending payment" means an order arrived and no payment was made. A run of either is a fault you inherited.

Write down: the payment methods switched on, the date of the last paid order, and how many recent orders failed.

Security posture

The baseline already holds most of this. Four questions remain.

• Does every administrator have a second step at login? WordPress's hardening guide calls two-step authentication a good idea. Record who has it. How to set up two-factor authentication covers adding it.
• Which accounts should go? Take the list of old and shared accounts to the client. Removing a person is their decision.
• Are file permissions loose? The hardening guide gives 755 for folders, 644 for files, and 400 or 440 for wp-config.php. The two commands below list the files and the folders that any account on the server can write to. The file permissions guide explains what to set.
• Does anything look like a past break-in? An administrator nobody knows, a checksum warning nobody can explain, a must-use plugin nobody installed. If a sign holds up, stop the takeover and tell the client the same day.

For a full review, with each plugin looked up for known vulnerabilities, follow how to audit a WordPress site for security weaknesses.

Performance and search baseline

Record how fast the site is and how it stands in search today, so that later changes can be compared.

• Run PageSpeed Insights on named pages. Use the home page and one page of each kind that matters: a product, a post, the contact page. It reports mobile and desktop. Its field data comes from real Chrome users over the previous 28 days, and falls back to figures for the whole site when a page has too little. Its lab data comes from a simulated load and varies between runs.
• Record the three Core Web Vitals from the field data. Google's good range is 2.5 seconds or less for Largest Contentful Paint, 200 milliseconds or less for Interaction to Next Paint, and 0.1 or less for Cumulative Layout Shift.
• Export the Page indexing report from Search Console. It counts the pages that are indexed and not indexed, with a table of reasons. Google says not to expect every address to be indexed, only the canonical pages, so the count is a baseline and not a score.
• Export the Performance report. By default it shows clicks and impressions for the past three months.
• Check that the site is not hiding from search engines. The command below prints 0 when "Discourage search engines from indexing this site" is ticked under Settings, then Reading. On a live site that goes to the top of the list.

Write down: the date, each address tested, the device, the figures, and the two exports.

Write down what is already wrong

Turn the baseline into a list of findings. For each one, give what you saw, where, on what date, and what it risks, in a sentence the client can follow. Then put it in one of three groups.

Send the list before you begin, and ask the client to reply that they have read it. What you owe the client is set by your agreement with them, and this page is not legal advice. The care plan proposal template has wording for what a plan includes and what it does not.

The handover note

The handover note is the baseline in a form the client can read and keep. It should contain:

• the site's address, the date of the baseline and who made it;
• each account, its owner of record and your level of access;
• your backup: when it was taken, where it is held, when it was restored and what was checked;
• the backups that existed before you, or that there were none;
• the WordPress, PHP and database versions, and whether each is still supported;
• the plugin and theme list as an attachment, with updates waiting, closed and untested plugins, and paid licenses with holder and renewal date;
• must-use plugins, drop-ins and custom code, with where each lives;
• the administrators by name, the accounts nobody could identify, and the application passwords;
• the result of both checksum runs, with every warning;
• Site Health's critical issues and recommendations, as worded;
• what was sent through each form and whether it arrived, and on a store, what the orders show;
• the speed and search figures, with their dates;
• the findings, each in its group, with what the plan covers and what is quoted separately;
• what you did not check, such as the code inside a paid plugin;
• what you changed during the audit, which should be nothing beyond your own login.

The first month

If you would rather not carry that routine yourself: White label is our Essential care plan, delivered under your agency's brand. It is for agencies with three or more client sites.

When to say no, or quote a clean-up first

A care plan assumes a site that is sound on the day it starts. Do not put a site on a plan as it is when:

• there are signs of a break-in. That is a clean-up, then a plan. The hacked site runbook covers the first hour;
• no backup restores, and your own would not restore on staging either;
• WordPress or PHP no longer gets security fixes, and the staging copy breaks when either is updated;
• the site depends on a closed plugin, or on a paid one whose license the client will not renew;
• files of WordPress itself or a parent theme were edited, and nobody knows what was changed or why;
• the checkout on a store is failing now;
• the client will not become the owner of record for the domain and the hosting, or will give you only a shared login;
• the client will not acknowledge the findings in writing.

For most of these the answer is a clean-up quoted as its own job, with its own scope and an end, and a plan that starts when it is done. For the last two, it is no.