Inherited a WordPress Site? A Takeover Checklist

If you've inherited a WordPress site, whether your developer disappeared, an agency closed or a colleague left, do things in this order. First, get control of the accounts that matter (domain, DNS, hosting, WordPress admin). Second, take a full backup you store yourself. Third, audit what's actually installed, including licences. Only then start updating or changing things. Rushing straight to "update all" on an unknown site is the quickest way to break it.

The checklist below is how I approach a site I didn't build. It works whether you're doing it yourself or handing it to a new maintainer.

Day one: get control of the accounts

Everything else depends on this. A beautifully maintained site is still at risk if someone else controls the domain.

Domain

Find out where the domain is registered and whose name it's in. A WHOIS lookup will often show the registrar even when owner details are hidden. If the registrant is the old developer or their company rather than your business, fix that now. In practice that means getting the developer to move it to your account or transfer it to a registrar where you hold the login. Check the expiry date while you're there.

DNS

DNS might be managed at the registrar, at the host, or at a service such as Cloudflare. You need to know which, and you need a login. Before you change anything, take a screenshot or export of every DNS record. MX records control your email. Get those wrong and the business stops receiving email, which is usually a bigger problem than the website.

Hosting

Get the hosting account in your name, or at least get your own login with full access. If the site sits on the old developer's reseller account alongside dozens of other clients, plan a move. You don't control the renewal, the backups or the server.

WordPress admin

Log in and look at Users. Create your own administrator account with a strong unique password. Note every other admin. Don't delete the old developer's account yet if you might still need to ask them something, but change its password or downgrade it once you're sure you have everything.

Everything else connected to the site

This is the part people forget: Google Analytics, Google Search Console, Google Tag Manager, Google Business Profile, payment gateways (Stripe, PayPal, local providers), email sending services (SMTP or transactional email), CDN accounts, and any third-party forms or booking tools. For each one, make sure someone at your business has owner-level access.

Day one: take your own backup

Before you update, delete or "tidy" anything, take a full backup of files and database and store it somewhere the old developer can't touch, such as your own Google Drive or Dropbox. If the host has a backup tool, use it and download the result. If not, a backup plugin like UpdraftPlus works.

This is your baseline. Whatever happens next, you can return to the site as you received it.

Week one: find out what you actually have

Versions and environment

Write down the WordPress version, PHP version, theme (and whether there's a child theme), and the hosting plan. Site Health under Tools in the WordPress admin shows most of this. WordPress.org currently recommends PHP 8.3 or greater. An inherited site on a much older PHP version is a warning sign that updates have been skipped for a long time.

Plugin inventory

List every plugin, its version, whether it's active, and when it was last updated by its developer. Delete inactive plugins after the backup. Flag anything not updated by its developer in over a year, and anything doing the same job as another plugin.

This matters more than it sounds. Patchstack's State of WordPress Security in 2026 found that 91% of new WordPress vulnerabilities in 2025 were in plugins, and that 46% weren't fixed by the developer before they were publicly disclosed. An inherited site with 40 plugins and no recent updates is carrying a lot of that risk.

Licences

Premium plugins and themes need licences to receive updates: Elementor Pro, Crocoblock, premium form, backup and SEO plugins, theme frameworks. For each one, find out whose account it's registered to and whether it's still active. If the licence sits in the old developer's account, it may stop updating when they stop paying, and you can't renew something you don't have the login for. Budget for buying your own licences if needed. On Elementor sites this is especially important, and I explain why in maintaining an Elementor + Crocoblock website.

While you're here, look out for "nulled" plugins: paid plugins installed from unofficial sources without a licence. You can't verify what's been changed inside them, and they never receive legitimate updates. If a premium plugin has no licence field, no account behind it and no clear source, treat it as suspect and replace it with a properly licensed copy.

Custom code

Look for a child theme with a large functions.php, custom plugins with names you don't recognise, and code snippet plugins. This is where the previous developer's undocumented work lives. You don't need to understand all of it on day one, but you need to know it exists before you update the parent theme or remove "unknown" plugins.

Week one: check security

Run a malware scan with a reputable security plugin or your host's scanner. Check the admin user list for accounts nobody recognises. Check for files modified recently in places they shouldn't be (the uploads folder shouldn't contain PHP files).

Then change the passwords that matter: WordPress admins, hosting, SFTP, database (updating wp-config.php to match), and the domain registrar. Generating new security keys and salts in wp-config.php logs everyone out, which is exactly what you want after a handover. Turn on two-factor login for admin accounts.

If the scan finds an infection, deal with it before any normal maintenance. Cleaning comes first, updates second.

Weeks two to four: stabilise

Set up staging

Create a staging copy. On an unfamiliar site, every update should be tested there first. You don't yet know which plugins are fragile.

Update in small batches

Update WordPress core, then the page builder and its add-ons, then other plugins, then the theme, testing between each batch. Expect some breakage on a site that hasn't been updated in a long time. That's why you're on staging. My step-by-step recovery guide is useful if something goes wrong.

Fix backups properly

Set up scheduled backups that go off the server to an account you own, keep several weeks of history, and test a restore on staging. Then write down where they live.

Write it all down

Make a single document with every login location (not the passwords themselves, keep those in a password manager), the plugin list and licences, renewal dates, the custom code you found and how DNS is set up. The reason you're doing a takeover at all is that the last person kept this in their head.

Start a routine

Once the site is stable, move to a regular schedule. My WordPress maintenance checklist covers weekly, monthly and quarterly tasks.

What if the old developer won't hand anything over?

Start with what you can prove you own. If the domain is registered in your business's name, the registrar can help you regain access. If you pay the host directly, the host can verify you as the account holder. Where the developer holds the accounts in their own name, things get harder, and depending on your contract it may become a legal question rather than a technical one.

Sometimes rebuilding is the practical answer. If you can get a copy of the content but not the accounts, a fresh install on hosting you control can be quicker than a long dispute. Get advice before going that way if the site carries real revenue.

What a professional takeover usually costs

Some maintainers price a takeover or audit as a fixed first step before a monthly plan, and others fold it into the first month. Either way, expect some first-month clean-up cost on a neglected site, whoever you hire, because getting access sorted, taking a backup you own, checking every plugin and licence and running the first round of tested updates all take real time. For ongoing plan prices, see website maintenance cost in Malaysia.

Taking over your site with Frame The Pixel

Inherited sites come up a lot in maintenance work, because people often look for a new maintainer only once the old one has gone. When I take on a site I didn't build, I follow the steps above: access and ownership first, a backup you own, a full inventory of plugins and licences, then updates on staging. After that the site moves onto a regular website maintenance plan with monthly updates, weekly fixes and changes, backups and security monitoring.

I don't publish fixed prices yet, because a neglected site can need anything from an hour of tidying to a proper clean-up. Tell me about your site here, including what access you currently have, and I'll tell you what the takeover would involve.

FAQ

What should I do first when I inherit a WordPress website?

Secure the domain, DNS, hosting and WordPress admin accounts, then take a full backup and store it in an account you control. Don't update or delete anything until you have both access and a backup.

My web developer disappeared. How do I get my website back?

Check who the domain and hosting are registered to. If they're in your business's name, the registrar and host can verify you and restore access. If they're in the developer's name, you'll need their cooperation or legal advice. If you can access WordPress but nothing else, export your content and back up the site straight away.

How do I know if an inherited WordPress site is safe?

Run a malware scan, review the admin user list for unknown accounts, check for outdated or nulled plugins, and look for PHP files in the uploads folder. Then change all passwords and security keys. If anything looks wrong, clean the site before you start normal updates.

Do I need to buy new plugin licences after a takeover?

Often, yes. If premium licences for things like Elementor Pro or Crocoblock sit in the previous developer's account, you can't renew them or rely on updates. Buying licences in your own business's name avoids the same problem next time.