Taking Over a WordPress Site: Audit Checklist for Agencies

The fastest way to lose money on a takeover engagement is to skip the audit and go straight to the work the client hired you for. The site looks fine, the homepage loads, you assume the previous developer kept things tidy, and you start building.

Three weeks later something breaks. A plugin update conflicts with a custom modification you didn't know existed. A backdoor that's been sitting in `wp-content/uploads/` for eight months reactivates the moment you change the admin password. Google flags the site for malware your scanner wasn't configured to detect. The client thinks you broke it. You can't prove you didn't.

This is what skipping the audit looks like in practice. The reason it happens is that audits feel unbillable — the client wants a homepage redesign, not a security report. But the audit is the one piece of work that protects everyone involved: it documents the state of the site at the moment you took over, it scopes the real work, and it removes ambiguity about what was already broken when you got there.

The 90-minute audit you do on day one is what makes every subsequent invoice defensible.

Most takeover engagements skip straight to "send me the WordPress login". That's the wrong order. Before you accept admin credentials, you want a full inventory of what "access" actually means for this site.

Hosting account login. Where does the site live, who pays the bill, and is the account in the client's name or the previous developer's? If it's in the previous developer's name, every minute that account remains active is a minute they could pull the plug, restore an old backup, or rotate the credentials on you. Get this transferred first.

Domain registrar and DNS. The domain might be in a separate Cloudflare, Hetzner, or registrar account from the hosting. If you don't control DNS, you don't control the site — somebody could repoint the domain at any time. List both nameservers and registrar.

SFTP and SSH credentials. The WordPress admin login is one access path; SFTP and SSH are another. Some hosts auto-generate these when you create an account; the previous developer may have additional keys you don't know about. Ask for the full list and rotate everything you can.

WordPress admin accounts and third-party API keys. Get the list of all admin-level users (not just yours) — every admin you don't recognise needs a story attached. Then check connected services: Mailchimp, Stripe, Google Analytics, Search Console, ad accounts, CDN. Anything connected via API key is access that doesn't go through the WordPress admin.

Email forwarders and aliases on the domain. Easily missed. Forwarders can quietly intercept password-reset emails — including reset emails for the WordPress admin you just inherited. Audit this even if the client says "we don't use email on this domain".

Before you log in to wp-admin, scan the site from the outside. The external scan tells you what an attacker can see without credentials — and that's also what you've inherited at the moment of takeover.

Run a free GuardingWP scan against the site URL. The report comes back in seconds and includes the full list of public-facing security indicators: vulnerable plugin versions, exposed files, user enumeration, XML-RPC status, login-page exposure, server-software fingerprinting, directory listing. No login required, no agent installation, no impact on the site.

The report has two uses on day one. First, it tells you the security baseline you're starting from. Whatever the scan flags, you now know existed before you touched anything. If the same issue appears on a scan three months from now, it wasn't introduced under your watch.

Second, it tells you about the previous developer. A site with five critical issues has not been actively maintained. A site with zero findings has been. This is data you can use to scope: a poorly-maintained site needs more work to bring up to standard and that needs to be priced into the engagement, ideally before you've signed a fixed-fee contract.

Save the scan report as a PDF. This is one of two pieces of evidence that protect you on day one — it timestamps what was true about the site at handover. The other piece is the forensic deep-dive in the next section.

The external scan covers what's exposed. The forensic deep-dive covers what's been planted. These are two different problems and need two different tools.

A forensic scan reads the filesystem and the database directly: every PHP file in `wp-content/uploads/` (none should exist), every modified core file (compared against WordPress checksums), every must-use plugin (most legitimate sites have none), every cron event (every entry should belong to a plugin you can name), every option row containing executable code, every administrator account. What you're hunting for: PHP files in uploads (always malicious), modified core files (almost always malicious), unfamiliar admin users, base64-encoded payloads in `wp_options`, scheduled cron jobs that re-download anything from an external URL.

Realistic time estimates for a manual forensic check on a site you're inheriting. Best case — 45 minutes. Small site, you know SSH and WP-CLI cold, the site is in good shape. You run the 12 checks, find nothing, document, move on.

Typical case — 3 to 5 hours. You walk through the file checks, find one suspicious file, decode it, document the finding, then walk through the database checks. Most takeovers of mid-sized sites land here.

Worst case — 10+ hours. You find multiple backdoors planted at different times by different attackers, each one needing its own analysis. Common when the site has been compromised for a while without anyone noticing — exactly the scenario where the previous developer left without cleaning up.

The Forensic Toolkit runs the same 12 checks in 2 to 3 minutes. It's a one-off purchase, you can run it on every takeover engagement you do for the next year, and it gives you a documented report you can hand the client. For a fixed-fee takeover audit, the math usually works out in the toolkit's favour after the first engagement.

By this point you have two reports — the external scan and the forensic deep-dive — and you know what's wrong. Now you triage: what gets fixed today, what gets fixed in the first month, and what's deferred.

The rule of thumb: anything actively malicious gets fixed today. PHP files in uploads, unknown admin accounts, modified core files — these don't wait. Anything in the external scan flagged as high or critical gets fixed in week one. Medium and low findings get a written note and a fix date.

How you fix depends on what's flagged. The simple stuff — XML-RPC enabled, directory listing, exposed sensitive files, login-page hardening — is `.htaccess` work and takes about an hour total. The fix guides on this site cover each of those step-by-step. The complex stuff — plugin updates with potential breakage, full backdoor cleanup, database malware removal — needs a staging environment and a backup plan first.

Document everything. For each finding: what was wrong, what you did, when, and what verification you ran. This document is what protects you when the client comes back six months from now asking why a particular plugin works the way it does. It's also the basis for any future security retainer — you have a documented baseline to maintain.

Re-scan after fixing. The same external scan that found the issues should come back clean for the items you fixed. If a finding still appears, the fix didn't fully apply. Common reasons: a cached version of the page, a server-level rewrite that overrides .htaccess, a plugin re-introducing the issue. Don't sign off until the re-scan matches the work.

The audit doesn't get done unless somebody pays for it. The mistake most freelancers make is bundling it into a vague "discovery" line item or doing it for free as part of winning the work. Both undervalue what the audit actually delivers.

Price it as a fixed fee. Common ranges for small business WordPress sites: €350 to €600, delivered in 5 to 10 working days. Larger or more complex sites scale up from there. The deliverable is a written report covering: external scan findings, forensic findings, what was fixed, what was deferred and why, recommended next steps, and a list of access credentials and where they live.

Frame it to the client as risk reduction, not security theatre. "Before I take responsibility for this site, I need to know what's currently in it. The audit gives both of us a documented starting point. It's also the only way I can tell you accurately what ongoing maintenance is going to cost — because right now, neither of us knows." This usually closes.

Bundle in a 30-day post-audit window where you handle anything that surfaces from the audit at the agreed fee. After that window, anything new is billable. This protects you from scope creep while giving the client predictability.

Use the audit as the on-ramp to a maintenance retainer. The audit produced a list of items — vulnerable plugins, missing backups, no monitoring. The retainer is the natural next step: weekly automated scans (GuardingWP Pro is €9 per site per month), monthly maintenance, alerting when something new comes up. The audit gives you the conversation; the retainer is what makes the work sustainable.