Taking over a client's website: what to check before you quote

A new client has parted ways with their previous developer and wants someone to take over the website. They ask what monthly maintenance will cost. It is tempting to reply with your standard rate. The trouble is, you do not yet know what you are signing up for.

A site that has changed hands can come with dozens of plugins, some of them untouched for a long time, a database dump sitting in a public folder, and an admin account belonging to someone nobody remembers. Price it like a well-kept site and your first weeks of maintenance are unpaid. And if the site is already compromised, from the day you take over it looks like your problem.

Below is a checklist in two parts: what you can check from the outside before the client hands over any passwords, and what to look at in the admin panel once they do. At the end, how to turn the findings into a quote.

Get the client's permission first

Looking at a site the way any visitor does needs nobody's permission. Running scanning tools against it is different: the hosting company or the previous developer may react badly to traffic they did not expect. A one-line email from the client, "I agree to you checking the site before you quote", covers you.

From the outside, no passwords needed

You can do all of this before the first meeting. It takes about half an hour, and it is often enough to tell whether this will be a standard quote.

Certificate and redirects. Does the site run only on HTTPS? Do http:// and the www and non-www versions all land on one secure address? When does the certificate expire, and does the server still accept the retired TLS 1.0 and 1.1? The SSL certificate checker answers all of that in seconds.

Email on the domain. The MX, SPF, DKIM and DMARC records. No DMARC, or DMARC at p=none, is a line item for your quote and a hint that nobody has looked at the DNS in a while. Note where the client's email is hosted too, because every DNS change you make later has to respect it. The SPF, DKIM and DMARC check shows the current state.

Platform and versions. What the site runs on, which version, which plugins show up in the page code and whether they give away their version numbers. The generator meta tag and the ?ver= parameters on script URLs tell you a lot. Match what you find against a vulnerability database such as WPScan or Patchstack.

Files that should not be public. backup.zip, .sql dumps, wp-config.php.bak, a .git folder, a .env file, phpinfo.php. Do not guess the addresses by hand; a tool will check them faster and more thoroughly. If you find something, do not download it. Note the address and tell the client straight away. The forgotten backup on your server explains why this one cannot wait.

Forms. Does every form submit over HTTPS, is there spam protection, and is there a privacy notice next to it? Send one test enquiry and ask the client whether it arrived, and in which inbox. It happens that a contact form has been sending leads to a former employee's address for months.

Headers and subdomains. Adding the missing security headers is usually a small job, but it belongs in the quote. Forgotten subdomains like test. or old. can be riskier than the main site, because nobody updates them.

Signs of a hack. Search Google for site:clientdomain.com and scroll through the results. Pages in Japanese, or about pharmacies or casinos, mean you start with a clean-up, not with maintenance.

In the admin panel, once you have access

Backups. Where they are, how often they run, how far back they go and who can reach them. Ask whether anyone has ever restored the site from one. Before you change anything, take your own full backup and store it off the server. It is your insurance in case something turns out to have been broken before you arrived.

Admin accounts. Go through every user with the Administrator role. Accounts belonging to the previous agency, former staff or people nobody recognises should go, once the client agrees. Treat an account nobody can explain as a possible sign of compromise, not as clutter.

Plugins and theme. Count the plugins and note which ones are waiting for updates, which are deactivated, and which have had no new release in a long time. Check the licences on paid plugins: whose name they are in and whether they have lapsed. A premium plugin without a licence gets no updates, and a copy "from an unofficial source" may carry extra code. See whether the theme was edited directly instead of through a child theme, because the next update will wipe those edits. Outdated WordPress plugins covers what to update first and what to delete.

PHP version and environment. The Site Health screen under Tools shows the PHP and database versions along with WordPress's own warnings. An old PHP version often blocks every other update, so it decides the order of the work.

Hosting, domain and DNS. This is the item that is easy to leave for later and then blocks everything. Find out whose name the domain is registered in and who can log in to the registrar, whose account the hosting is on and who pays for it, and who can change DNS. Ideally everything belongs to the client and you get your own login, not the previous developer's. If the domain is registered to the old agency, start the transfer before you plan any migration.

Forms from the inside. Where submissions go, whether they are stored in the database, and for how long. Years of old enquiries full of personal data are a GDPR question for the client, so put it in your report even if the decision is not yours.

Turning the findings into a quote

The client cannot see the difference between a well-kept site and a neglected one. In a browser they look the same. If your quote shows a single figure for "website takeover" and a competitor's figure is lower, the client picks the lower one. You need to show where the difference comes from.

Split the quote into three parts:

1. Current state. A short list of what you found, with the date of the check. Three sentences per item: what is wrong, what it could cost the business, what needs doing. No jargon. Instead of "no DMARC", write "anyone can send emails that look like they come from your company, fake invoices included".
2. Initial clean-up. One-off work that follows from the current state, each item with its own price or time estimate. The client sees exactly what they are paying for and can set priorities if the budget is tight. Mark urgent items, like a database dump in public view, as a condition of taking over.
3. Monthly maintenance. A fixed fee for keeping the site in the state you bring it to.

Add one sentence about responsibility: your maintenance covers the site from the handover date, and the problems listed under current state become yours only once they are fixed. Have a lawyer word it for your market, but the principle protects both sides. The client knows what they are paying for, and you are not answerable for someone else's neglect.

Keep the evidence from the day of the check: the report, screenshots, the list of accounts and plugins. If an infection from before your time surfaces three months later, you can show it.

A report the client can read on their own

A list in a quote works better when the client can forward it to a business partner or their accountant without calling you to translate. That is why a report from the check, under your own brand, is worth attaching to the quote.

ShieldWave handles the outside half of this checklist. It checks the site without a plugin or passwords, and on the Enterprise plan the report carries your agency's logo and details. The client gets each problem explained without jargon and a fix plan ordered by urgency; you get the findings with addresses, evidence and estimated working time to build the quote from. Enterprise costs $29 a month for unlimited sites, with a 7-day trial. It will not look inside the panel, the backups or the access list for you, so the second half of this checklist stays your job.