A prospective client has a WordPress site built by someone else. They want you to look after it, or add a feature, or “just tidy it up”. They would like a quote by Friday. You have seen the homepage, it looks fine, and the temptation is to send a number and a start date.
Resist it. An inherited site is a box you have not opened yet. It might be clean and well built. It might also be running a theme that stopped receiving updates years ago, with the client’s custom changes edited straight into its files, backups that have never worked, and a plugin list nobody can explain. If you promise a price and a timeline before you know which, you are pricing a guess, and the client will hold you to it.
This checklist is for the first look: what to collect, what to check, and how to report it back before you commit to anything.
Agree a paid audit, or a defined first step
The cleanest way to onboard an existing site is to separate the audit from the ongoing work. Offer a short, fixed piece of work up front: you review the site, write up what you find, and then propose the ongoing arrangement. The client gets something useful whether or not they continue, and you are no longer quoting blind.
Some agencies fold this into the first month of a care plan. Others charge for it separately. Either works, as long as the client understands that the first step is looking, and that your proposal for ongoing work comes after.
The wording can be simple:
“Before we commit to a monthly plan or a quote for the new feature, we’d like to do a short review of the site. We’ll check how it’s built, what state the updates and backups are in, and whether there’s anything that needs attention first. You’ll get a written summary, and from there we can give you a proposal we can actually stand behind.”
What to collect before you start
Ask for these at the beginning. Missing items are themselves a finding.
- A WordPress administrator account in your name.
- Hosting access, ideally through a team or delegate feature if the host has one.
- Where the domain is registered and who controls it.
- Where DNS is managed.
- The name of the previous developer or agency, and whether they are still reachable.
- Any documentation the previous developer left.
- Licence details for premium plugins and themes.
- A short list from the client: what matters most on the site, what has gone wrong recently, and what they want changed.
That last item is easy to skip and very useful. The client’s answer to “what has been annoying you about the site?” often points straight to the real problem. For a secure way of receiving all those logins, see how to collect and store client credentials.
The technical audit
Hosting and server
- PHP version, and whether it is still supported. Older versions no longer receive security fixes.
- Hosting type: shared, managed WordPress, VPS. This shapes what you can change.
- Available disk space and any resource limits.
- Whether the host provides staging.
- Whether SSL is installed and set to renew.
WordPress core, plugins and theme
- Is WordPress core up to date?
- How many plugins are installed, how many are active, and how many have updates waiting?
- Are any plugins no longer maintained by their authors, or removed from the WordPress.org directory?
- Are there inactive plugins and themes that can be removed?
- Is the active theme a parent theme, a child theme, or a custom theme? If it is a parent theme, have its files been edited directly? Updating it would overwrite those edits.
- Is a page builder in use, and is it the free or paid version?
- Are there any nulled (pirated) plugins or themes? These often carry malware and cannot be updated legitimately.
The Site Health screen under Tools in the dashboard is a reasonable first stop for some of this; our post on which Site Health warnings actually matter helps sort the noise from the real problems. For plugins that have gone quiet, our guide to abandoned plugins explains how to judge them.
Backups
- Is anything backing up the site at all?
- Where are backups stored? A backup on the same server as the site is not much use if the server fails.
- Has a restore ever been tested?
Before you change anything, take your own full backup and store it off the server. This is non-negotiable. If something you touch in the first week breaks, you need to be able to show what the site was like when you received it.
Security
- The list of users, especially administrators. Are there accounts nobody recognises?
- Is two-factor authentication in use for administrators?
- Any security plugin, and what its logs show.
- Signs of compromise: unknown files in the uploads folder, unexpected redirects, spam pages in search results, strange admin users.
- File permissions that look too open.
If you find signs of a hack, stop and tell the client before going further. Cleanup is a separate piece of work, and you should not quietly absorb it into a maintenance quote.
Function
- Submit every form and check the messages arrive where they should.
- Check whether the site sends email through the server’s default mail or a proper SMTP service.
- If it is a shop, place a test order where the payment gateway allows a test mode.
- Check the mobile layout on the pages that matter most.
- Look for broken links and missing images on key pages.
Performance baseline
- Run a speed test on a few key pages and save the results.
- Note any caching plugin and whether it is configured.
- Note obviously oversized images.
You are not fixing anything at this stage. You are recording a starting point, so that if the client later says “it was faster before you started”, you have a record.
Write it up in a way the client can read
An audit only helps if the client understands it. Sort your findings into three groups:
- Needs attention now: security risks, broken forms, no working backups, an outdated PHP version that the host is about to retire.
- Should be fixed soon: outdated plugins, an unmaintained theme, missing two-factor authentication.
- Worth knowing: performance observations, plugins that could be removed, things that are fine but unusual.
For each item, one line on what it is and one line on why it matters to the business. “The contact form sends from the server’s default mail, so some enquiries may land in spam” is more useful than “SMTP not configured”.
A summary email might read:
“We’ve finished reviewing your site. The good news: it’s well designed and the content is in good shape. There are three things we’d recommend fixing before anything else: [items]. After that, ongoing care would cover [plan]. The full write-up is attached. Happy to talk through any of it.”
What to promise, and what not to
Once the audit is done, you can promise things with confidence. You still should not promise everything.
Reasonable to commit to after an audit:
- A defined list of first fixes, with an estimate.
- An ongoing plan with clear inclusions.
- A backup and update routine from a specific date.
Not reasonable to commit to:
- That nothing will break when you update a site that has not been updated in a long time. Say plainly that bringing an old site up to date can uncover problems, and that you will work on a staging copy where possible.
- That you are responsible for problems that existed before you started. Your audit record is what protects you here.
- A fixed price for ongoing work on a site you have not been able to fully examine, such as one where you could not get hosting access.
Contact the previous developer, if you can
If the client is on good terms with whoever built the site, a short polite message can save hours: “We’re taking over care of [site] and would be grateful for any notes on custom code or known issues.” Many developers will happily answer. Some will not, and that is fine. Just do not assume the absence of notes means the absence of quirks.
Business owners going through this from the other side may find our article on taking a site over from another developer useful, and you can share it with clients who are nervous about the change.
Keep the audit as the first page of the site’s file
The audit is not a one-off document. It is the first entry in the site’s record. Keep it with the site’s notes, update it when you fix things, and refer back to it when you review the plan in a few months. It is the clearest way to show the client how far the site has come.
Onboarding inherited sites is one of the places where agencies most often bring in extra help; the guide to outsourcing WordPress work as an agency explains how that tends to work. If the audit turns up a list of fixes your team does not have room for, our one-off fixes for agency client sites page covers how we take them on while you keep the client conversation.
Next in this series: Managing Plugin Licenses Across Agency Clients
