What a website audit actually finds
The first thing I do in a site audit isn’t clever. I look at what’s sitting in the open.
On one of them, I found a full copy of the site’s database. Not a hint of one. The whole file, in a folder on the live site, downloadable by anyone who knew where to look. Everything the site had ever collected about the people who used it.
Nobody put it there on purpose. Some time before, someone moving the site to a new host made a backup “just in case,” left it where the web server could reach it, and went home. It sat there through redesigns and a string of people who each said they’d look after the site.
A note on this story: it’s a composite. I’ve merged and changed details from more than one site so it doesn’t describe any single business. The pattern is real, and I’ve seen it more than once.
An automated scan would not have found that file. It’s also not the most important thing a good audit finds.
What a scan gives you, and what it can’t
Run a free scanner against your site and you get a score and a list: outdated plugins, a slow image, a missing header. Most of it you could have guessed. None of it tells you the things that actually decide whether the site hurts you.
Who can get into this site, and who can’t, though they should? Has anyone already been in? Would the backups save you, or are they sitting on the same server as the thing they protect? Where do the contact forms send people’s details? Those questions take a person, a private copy of the site, and a few days of patience. Here’s what I do on a deep audit that a scan doesn’t.
It starts with who’s in charge
Before I read a line of code I draw the ownership map. Whose account holds the domain? Whose inbox gets the hosting login codes, the admin email, the password resets? Whose personal account holds the license for the theme the whole site is built on?
I keep finding the same shape. Everything points at one person, usually someone who has since moved on or is about to. A former developer’s account still has full access. A shared login nobody remembers creating still works. None of that shows on a speed report, and every bit of it is the difference between a site you control and a site you’re allowed to borrow.
Has anyone already been in?
I restore a copy of the site on my own machine, cut off from the internet and from email, and compare every core WordPress file and every plugin file against the official release. Any file that differs is either a hack or somebody’s undocumented edit, and I want to know which.
This is how I look for signs of malware, the real kind and not a scanner’s guess. I search the uploads folder for code that has no business there, check for scheduled jobs no plugin owns, look for admin accounts nobody can explain, and compare the theme’s own files against a clean copy. That last one finds two things: injected code, and edits your next update will silently wipe. The second is the real reason “the update broke our site” happens, and almost nobody checks for it.
The server’s own logs
The site tells you what it intended. The server’s logs tell you what actually happened: every request, for weeks.
Reading them is where an audit turns from a list into a story. You can see who’s guessing passwords and how many tries it took, what’s probing for known holes, which automated visitor is hammering the server, and which oversized file is eating the bandwidth. And when I’ve found an exposed file, the logs answer the question the owner asks first: did anyone download it? Sometimes the answer is no. Sometimes it’s yes, and you want to know that now.
Speed, down to the piece that’s slow
A speed score tells you the page is slow. I want to know which plugin, which line of its code, and how many milliseconds. On the private copy I time each stage of building a page and each piece of code that runs in it, and I look at what the database loads on every single request whether the page needs it or not.
Your host, your caching, and what’s already been tried
Half the time the biggest lever isn’t code at all. It’s the hosting plan: an old contract that can’t do what a current one does, a code cache that’s switched off, no object cache, a PHP version at the end of its life. I find out what your plan actually includes and what a better one would add, and when I can, I test the fix on the copy and report what it does in numbers. “Pages build several times faster” is a lot more useful than “consider upgrading.”
I also audit what’s already been done. Most sites have had someone “optimize” them: a caching plugin, minification, an image tool, a pile of builder settings. Sometimes they work. Sometimes two of them fight each other, or one is doing nothing, or one is quietly breaking a form. You can’t tell from a score. You can from the settings.
Your plugins, one by one
I inventory every plugin and theme: what’s current, what’s abandoned, what has a published security hole (each one cited to a public source, so you can check me). The question I care about isn’t only “is it outdated.” It’s whether you need it at all, whether a lighter option exists, and whether you’re paying for two things that do the same job.
How the site actually gets run
An audit that stops at the code misses half the risk. I look at the workflow around the site: who edits it and how, who runs the updates and when, where the backups go and whether anyone has ever restored one. A site with perfect code and no process breaks the first time the person who knew how it worked is out sick.
I test things instead of assuming
- Backups. Are they on the server they’re meant to protect? Could you actually restore from one?
- Email. I send a real message from the business’s own mailbox and look at where it lands. When a domain’s mail isn’t signed, the message goes to junk, and so do the form notifications and the invoices.
- Contact forms. Where does each one go? I’ve found an old form still delivering customer details to an inbox nobody checks anymore.
- Customer data. What do the forms collect, and where does it sit? If people type sensitive details into a form, that’s worth knowing before it becomes somebody’s problem. I flag it plainly and I’m careful not to play lawyer.
How you compare to your neighbors
I measure a few local competitors exactly the way I measure you: speed on phones, search markup, security headers, whether customers can book online. “Your site is slow” is a fact. “Your closest competitors load faster on a phone and let customers book online” is a reason to act.
What to improve, and what’s about to go wrong
Two lists I always end up writing. The first is upgrades and opportunities: the updates worth doing and in what order, the heavy plugin with a light replacement, the quick wins versus the real projects, each with an hour estimate so you can compare them to what you’d pay.
The second is trouble spots, things that haven’t failed yet. An access token that expires next week. A certificate or a domain renewal on a card nobody owns. Software that stopped getting security patches. Anything that rests on one person or one login. These never show up in a scan because nothing is wrong yet. They’re the ones that cost you a weekend later.
How I handle your site while I look
Care is part of the product. The copy stays on my encrypted machine and gets deleted when we’re done. Every security issue I report cites a public source, so you can check me. I don’t exploit anything against your live site. If I change something on the live server, it’s with your permission, and I log what and when.
What you get at the end
A report a business owner can read without a translator. It opens with the short version and the few things that matter most, in order, with what needs attention this week separated from what can wait a quarter. Every finding says what it is, why it matters in plain terms, and what fixing it takes. A roadmap and an estimate of the hours close it out, so you can decide what to do and who should do it. You can hire me for the fixes or hand the report to anyone.
That’s the gap. A scan hands you a score. An audit hands you a decision.
My audits are published and fixed-price, from a basic look to the whole-business version: see website audits and speed fixes. If you run an agency and want this under your own brand for a client, I do that too: white-label work. If you’d rather check the basics yourself first, I wrote up a ten-minute self-check.
Or email [email protected] with the address of the site and I’ll take a free look and tell you what I see.