Taking Over an Inherited WordPress Site: A Step by Step Playbook

You have inherited a WordPress site. Perhaps you are a new designer picking up a client whose previous developer vanished, a new marketing manager handed “the website”, or an owner whose agency closed. The site mostly works, nobody knows exactly how, and you have a mixed bag of logins in an email thread. You are nervous to press Update in case it all falls over.

That instinct is correct. The biggest risk in a takeover is not the old code; it is making changes before you know what you have and before you have a way back. This playbook puts the work in a safe order. Each step depends on the one before it, so resist the urge to jump ahead to updates or a redesign. Print the site takeover access inventory to check off as you go, and if you need to ask the owner or previous developer for access, use the client access request email.

What is happening

An inherited site usually has some combination of these problems, and you will not know which until you look:

• Accounts in the wrong name. The domain, hosting, analytics or licenses belong to the previous developer, not the business.
• Unknown dependencies. A transactional email service, a payment gateway, an API key in wp-config.php, a cron job on the server, a Cloudflare account, a CDN.
• Stale software. Plugins and themes years behind, an old PHP version, abandoned or closed plugins, page builders with bundled add-ons that never updated.
• License problems. Expired licenses, licenses tied to the developer’s account, or nulled (pirated) copies that may contain malware.
• Leftover access. Old admin accounts, application passwords, SFTP users, SSH keys and plugin “support” logins nobody remembers granting.
• No working backup. A backup plugin that stopped running long ago, or backups stored on the same server as the site.

None of these are emergencies on their own. They become emergencies when an update fails and there is no backup, or a renewal lapses in an account nobody can reach.

Before you start

You will need a browser, a password manager to store what you collect, and ideally SFTP or SSH access to the hosting. Commands below use WP-CLI, the WordPress command line tool. Run them over SSH in the site folder, the one containing wp-config.php; your host may call the command wp or wp-cli. DNS checks run on your own computer. If you have no SSH access, every step has a dashboard equivalent, noted where it matters. The WP-CLI cheat sheet and the hosting control panel cheat sheet help you find your way around.

Agree in writing with the site owner what you are allowed to change, and when. A takeover often finds things the owner did not know about, and you want permission before you remove them.

Step 1: Inventory every account, without changing anything

Start by mapping what exists from the outside, where you cannot break anything.

dig +short NS example.com
dig +short A example.com
dig +short MX example.com
dig +short TXT example.com

Run these on your own computer. +short prints only the answers. NS tells you who hosts DNS (often the registrar, the web host or Cloudflare), A tells you the web server, MX tells you where email lives, and TXT shows SPF and verification records that reveal services such as Google Workspace, Microsoft 365, a mailing tool or a transactional email provider. The who hosts this site tool and the DNS lookup tool do the same in a browser, and the domain lookup tool shows the registrar and expiry date through RDAP.

Then build a list with one row per account: what it is, the company, the login URL, the account owner, who has access, the renewal date, and where the credentials are stored. At minimum:

Account	Why it matters	How to find it if nobody knows
Domain registrar	Losing it loses website and email together.	RDAP lookup; renewal emails in the owner’s inbox.
DNS host	Every record lives here.	The NS records.
Web hosting	Files, database, backups, PHP version.	The A record and who hosts tool; bank statements.
CDN or proxy (for example Cloudflare)	Caching, SSL mode and firewall rules sit between visitors and the server.	NS or A records pointing at the proxy; response headers.
Email provider	Business mail and the reset address for other accounts.	MX and SPF records.
Transactional email or SMTP service	Form notifications, password resets and order emails.	An SMTP plugin’s settings; SPF includes; DKIM records.
WordPress administrators	Full control of the site.	Users screen; WP-CLI (Step 4).
Payment gateway, shipping, tax and accounting connections	Revenue and orders.	WooCommerce settings; plugin list.
Analytics, Tag Manager, Search Console, Business Profile	Reporting and search visibility.	Tracking code in the page source; verification TXT records.
Premium theme and plugin licenses	Updates and security fixes.	Plugin license screens; the plugin list.
Backups and monitoring	Your way back, and your early warning.	Backup plugin settings; host panel; uptime emails.

The aim is that every account belongs to the business, with you added as a user. Where an account belongs to the previous developer, mark it for recovery or replacement in Step 2.

Step 2: Secure the domain and the email behind everything

The domain is the one asset you cannot rebuild, and the owner’s email is the reset address for most other accounts. Fix these first.

• Confirm the registrar account belongs to the business. If it does not, start moving the domain into an account the business owns. If the previous developer holds it, follow getting your domain and logins back from a former web designer.
• In the registrar account: turn on two-factor authentication, confirm auto-renew and a valid payment method, check the registrar lock is on, and make sure the registrant email is a working address that is not only on this domain.
• Check the expiry date. If it is within a few weeks, renew now.
• Secure the email account that receives registrar, hosting and WordPress notices: strong password, two-factor, no unknown forwarding rules.
• Export a copy of the DNS zone, or screenshot every record, and store it with your notes. If DNS ever breaks, this is how you rebuild it.

If you find the nameservers or registrar changed without anyone’s knowledge, stop and follow domain hijacked: how to recover.

Step 3: Take a backup you can actually restore

Do this before you update, delete or switch anything. A backup that lives only on the same server is not enough: if the server or account fails, it goes with it.

wp db export ~/takeover-$(date +%F).sql
tar -czf ~/takeover-files-$(date +%F).tar.gz -C ~/public_html .

Run these over SSH. The first exports the database to a file in your home folder named with today’s date; $(date +%F) inserts the date as YYYY-MM-DD. The second creates a compressed archive of the site folder: -c creates, -z compresses, -f names the file, and -C ~/public_html . archives the contents of that folder. Replace ~/public_html with the real site folder (it is the folder containing wp-config.php). Good output is silence followed by two files of sensible size; check with ls -lh ~/takeover-*. Then download both files to your computer or to separate storage with SFTP.

No SSH? Use the host’s backup tool to create and download a full backup, or a reputable backup plugin that stores copies off the server. If backups fail, see backup and migration plugin failures.

Ideally, restore that backup to a staging copy to prove it works. A staging site is also where you will test updates in Step 7. The restore guide walks through it, and the backup plan checklist sets up an ongoing schedule.

Step 4: Audit who can get in

WordPress users

wp user list --role=administrator --fields=ID,user_login,user_email,user_registered

--role=administrator limits the list to admins and --fields chooses the columns. Good output is a short list of people you can name. Bad output is an account nobody recognizes, a generic “admin” or “support” login, a free webmail address you cannot attribute, or an account created recently with no explanation. In the dashboard, Users, filtered by Administrator, shows the same.

For each unknown administrator, ask the owner before deleting. When you delete a user, WordPress asks who should own their content; attribute it to a real user rather than deleting the content. If an account looks malicious (created at an odd time, an email address you cannot trace), treat the site as possibly compromised and read WordPress admin account compromised.

Application passwords and other back doors

wp user application-password list 1

Replace 1 with each administrator’s user ID from the list above. Application passwords let apps and scripts log in through the REST API without the main password or two-factor. Remove any you cannot explain. Also check:

• hosting panel users, SFTP and FTP accounts, and SSH keys (cat ~/.ssh/authorized_keys over SSH lists the keys allowed to log in);
• database users in the hosting panel;
• Cloudflare, analytics and Search Console users;
• “support access” or temporary login plugins left active.

Then change the passwords of the accounts you keep, starting with hosting and WordPress admins, and turn on two-factor. If you change the database password, update DB_PASSWORD in wp-config.php at the same time. Generating new authentication salts (the AUTH_KEY and related lines in wp-config.php) logs everyone out; wp config shuffle-salts does it in one command.

Step 5: Check the code is genuine and clean

WordPress core and free plugins

wp core verify-checksums
wp plugin verify-checksums --all

The first compares every core file with the official checksums for your WordPress version. Good output ends with Success: WordPress installation verifies against checksums. Bad output lists files that do not match or should not exist, and ends with an error. The second does the same for plugins from the WordPress.org directory; premium plugins have no public checksums, so they are reported as unverifiable, which is expected and not a sign of infection. Modified or extra files in core or free plugins should be investigated: see malware scanner flagged a file and hack keeps coming back.

Look for obvious trouble

find wp-content/uploads -name "*.php"
find . -name "*.php" -mtime -30 -not -path "./wp-content/cache/*"

The first lists PHP files in the uploads folder, where there should normally be none (a few plugins create harmless index files; investigate anything else). The second lists PHP files changed in the last 30 days (-mtime -30), skipping cache folders. Recent changes are not proof of a hack, since updates change files, but a change nobody can explain deserves a look.

Must-use plugins and drop-ins

wp plugin list --status=must-use
wp plugin list --status=dropin

Must-use plugins run automatically from wp-content/mu-plugins and do not appear in the normal plugin list unless you look. Drop-ins such as object-cache.php and advanced-cache.php replace parts of WordPress. Hosts and caching plugins add some legitimately; anything unexplained is worth opening.

Step 6: Sort out licenses, nulled and bundled plugins

wp plugin list --fields=name,status,version,update_version,auto_update
wp theme list

This shows each plugin’s version, whether an update is available and whether auto-updates are on. Write down every premium theme and plugin, then check each one.

Situation	What it means	What to do
License active, in the owner’s name	Updates and support work.	Record the renewal date and account.
License in the previous developer’s account	The code keeps running, but updates may stop when they remove the site or their license lapses.	Buy a license in the owner’s name and enter the new key.
License expired	Most premium plugins keep working but stop receiving updates, including security fixes, until renewed.	Renew, replace with an alternative, or remove. Do not run unpatched security sensitive plugins indefinitely.
Bundled with a theme (common with marketplace themes and page builder add-ons)	Updates usually arrive only through theme updates, and the bundled copy often cannot be registered on its own.	Keep the theme updated, or buy a standalone license if you need direct updates. See WPBakery and Avada problems on inherited sites.
Nulled (pirated, license check removed)	Distributed through unofficial sites and often modified to include backdoors, spam links or hidden admin users.	Replace with a genuine copy from the vendor, then rescan. Treat the site as possibly compromised until you have.
Abandoned or closed on WordPress.org	No more fixes, and closures are sometimes for security reasons.	Plan a replacement. See plugin vulnerability alerts.

Signs a premium plugin may be nulled: no license screen or a license field that is already filled with an odd value, “activated” with no account, files that phone home to unfamiliar domains, a version number that never existed on the vendor’s changelog, or the plugin was “free” when the vendor only sells it. To check a suspicious copy, download a genuine copy of the same version from the vendor and compare the two folders on your computer with a diff tool. Do not try to keep a nulled copy by “cleaning” it; replace it.

Step 7: Bring the software up to date safely

Now that you have a tested backup and know what is installed, you can update. Do it on staging first if you possibly can.

1. Check PHP. wp --info shows the PHP version WP-CLI uses, and Tools, Site Health, Info, Server shows the version the website uses. If PHP is old, update plugins first, then follow upgrading PHP safely.
2. Update in small batches. Plugins a few at a time, then the theme, then WordPress core. Test the key pages, forms and checkout after each batch.
3. Watch the page builder. Builders and their add-ons are the most common thing to break on old sites. See page builder broke after an update.
4. Keep notes. Record each version change so that if something breaks later, you know what changed.

The safe update routine covers staging, rollback and auto-update policy in detail. If an update leaves the site in maintenance mode or shows a critical error, see stuck in maintenance mode and there has been a critical error.

Step 8: Check the hidden integrations

• wp-config.php. Read it (over SFTP or SSH, never paste it anywhere public). Note custom constants: API keys, SMTP credentials, disabled cron, debug settings, memory limits. The wp-config constants reference explains them.
• Server cron jobs. crontab -l over SSH, or Cron Jobs in the hosting panel. Note what runs and how often, especially if DISABLE_WP_CRON is set.
• WordPress scheduled events. wp cron event list shows what WordPress runs on a schedule. Events from deleted plugins can be removed later.
• Site email. Submit every form and trigger a password reset. If mail does not arrive, see WordPress not sending email, and check SPF, DKIM and DMARC with the email authentication checker.
• Payment and API keys. For stores, confirm the payment gateway is in live mode with the owner’s account and that webhooks point at this site.
• Redirects and server rules. Look at .htaccess or the Nginx rules and any redirect plugin. Unknown redirects can be leftovers or a sign of a hack; see finding redirects you did not create.
• SSL and the CDN. Check certificate expiry and auto-renewal with the SSL checker, and note the SSL mode if Cloudflare is in front.

Step 9: Set up monitoring and write it all down

• Uptime monitoring that alerts a real person, plus SSL and domain expiry alerts.
• Scheduled, off-server backups with a restore tested at least once.
• Search Console verified in the owner’s account, with you as a user.
• A renewals register: domain, hosting, licenses and certificates, with dates and owners.
• A handoff document that the next person can pick up. The website handoff document template is a good structure, and the monthly maintenance checklist keeps it current.

When the takeover is done, hand the client a written record of their website. The free website owner’s manual generator fills in the host, domain, DNS, email and SSL details for you, then adds renewals, who does what and a maintenance routine.

If none of that worked

If you cannot get access to a critical account, work through the recovery paths in the former designer guide and the locked out or lost access triage page. If you find malware, unexplained admin users or nulled software you cannot replace quickly, follow WordPress site hacked: the first hour before doing anything else.

When you contact the host for help, send the domain, the hosting account name, what you are trying to do (for example “transfer the account to the business owner” or “restore the backup from date X”), the output of wp core verify-checksums if you suspect a compromise, and the PHP version shown in Site Health. Hosts can usually confirm account ownership, create panel users, restore backups and tell you which PHP versions are available.