What We Check Before Taking Over a Website

When a business asks us to take over a website — from a previous agency, a freelancer who has moved on, or an in-house person who has left — the first thing we do is nothing. No updates, no changes, no “quick wins”. We spend the first session finding out what is actually true about the site, because the handover notes, where they exist, are almost never complete.

This is what that review looks like. It is the origin of our 27-Point Website & Infrastructure Health Checklist, which is the same review written so you can run it yourself.

1. Who owns what

Before touching the site, we establish control of the things that cannot be recovered if lost:

• The domain. Which registrar, whose account, is it locked, when does it expire, and does the renewal email go to someone who still works there. A surprising number of business domains are registered in a former developer’s personal account.
• DNS. Where it is hosted (often not the registrar), who has the login, and what every record is for. Stale records pointing at old servers are common and occasionally dangerous.
• Hosting. Which company, which plan, who pays, and whether the client has their own login or only ever went through the agency.
• Everything else with a login: Cloudflare, email provider, analytics, premium plugin licences, payment gateways, transactional email service.

The output is a document listing every account, its owner and who has access. If one didn’t exist, this is when it gets created. It is the single most valuable artefact of the whole process, and it usually takes the longest.

2. Whether there is a way back

Next: backups. Not “are there backups” but:

• Where are they stored? If the answer is “on the server”, they are not backups.
• How often, and how far back?
• Has anyone restored one? If not, we do, to a staging location, and time it.

We do this before anything else because every subsequent step — updates, cleanup, migration — is a change, and we will not make changes to a site we cannot restore.

3. What is actually installed

A full inventory of the WordPress installation:

• Core version and whether auto-updates are on.
• Every plugin: version, whether it is active, when it was last updated by its author, whether it is still maintained, and whether a premium licence is valid. Plugins that have not been updated in two years get flagged. Inactive plugins get deleted, not left “just in case” — inactive code is still exploitable.
• The theme, whether it is a child theme (so updates don’t destroy customisations), and how much custom code lives in functions.php.
• Any custom code, must-use plugins, or modifications to core files. These are where surprises live.
• Users: every account with administrator rights, and whether each one belongs to someone who should have it.

We are looking for two things: the attack surface, and the things that will break when we update.

4. How the server is doing

On a VPS or dedicated server, a quick health check: OS version and patch status, PHP version and whether it is still supported, PHP-FPM pool configuration versus available RAM, MySQL version and configuration, disk usage, and what is in the logs. dmesg for out-of-memory events. The cron table for jobs nobody remembers.

On shared or managed hosting, the equivalent from the host’s control panel: resource usage graphs, PHP version, and the support ticket history if the client can share it.

We are not fixing anything yet. We are finding out whether the server is a candidate to keep or a candidate to leave.

5. Whether anything is watching

• Is there external uptime monitoring, and does it alert a person who can act?
• Is there any security scanning, and is it a plugin inside the site (which malware can disable) or something outside it?
• Are logs retained long enough to investigate an incident?
• Is anyone told when a plugin in use has a published vulnerability?

Usually the answer to most of these is no, and setting them up is one of the first things we do once the review is done.

6. What the edge looks like

If Cloudflare or a similar service is in front of the site: whether records are proxied, SSL mode, whether the origin can be reached directly (bypassing everything), what WAF and rate-limiting rules exist. If nothing is in front of the site, that goes on the list.

7. Whether email works

The part everyone forgets. We send a test through every form on the site and check where it lands. We look at whether the site sends mail via the server’s mail() function (unreliable, increasingly rejected) or through an SMTP/API service, and whether SPF, DKIM and DMARC are published for the domain. “The contact form sometimes doesn’t work” is nearly always an email deliverability problem, not a form problem.

8. What the visitor experiences

Last, because it is the least urgent: performance on the key pages, on mobile, with real measurements rather than a single Lighthouse run. Whether caching is actually hitting. Whether the site is usable on a phone and with a keyboard. This tells us what to prioritise once the foundations are solid.

What comes out of it

A short written report: what we found, what is urgent (usually backups, access and anything end-of-life), what is important but not urgent, and what we recommend doing first. Then a plan the client can agree to before anything changes.

The whole review takes a few hours for a typical business site — longer if the ownership picture is messy, which it often is. It is the least glamorous part of website management and the part that prevents most of the emergencies later.

If you want to run it on your own site, the checklist is the same review in 27 yes/no questions. Most businesses find a few gaps. One of them is usually backups.