Inherited a Website Mess? Start With This Website Audit Checklist

Why the free audit tools won't tell you what you need to know #

Your first instinct is probably to run the URL through one of the free scanners. Do it if you like, but know what it gives you. Those tools grade meta descriptions, flag a slow image, and tell you your heading structure is off. What they can't tell you is who owns the domain, whether the contact form still lands in anyone's inbox, or which parts of the site the business quietly depends on to make money. That's the information that actually matters in your first few weeks, and the only way to get it is to look for it yourself.

So treat this less as an audit and more as triage. A proper website audit checklist for an inherited site isn't about chasing a perfect SEO score. You're working out what you've got, what it's responsible for, and what will break if you touch the wrong thing.

Start by working out what you've actually got #

Begin with the boring questions, because the answers tend to be revealing. What CMS is the site built on, and what version is it running? Is there a staging site as well as a live one? Who hosts it, who owns the domain, and where are the logins actually kept?

If those answers come back vague, missing, or tied to someone who left two years ago, flag that straight away. A surprising number of inherited-site problems come down to access rather than code. Hosting, the domain, CMS accounts, analytics, tag manager, forms, CRM connections: make a list of who controls each one. The day something stops working, you'll want to know who to call before you want to know why it broke.

Find out what the site is quietly responsible for #

Before you can judge how risky anything is, you need to know what the site is doing for the business. Some sites are little more than a brochure. Others are running lead capture, feeding a CRM, gating resources, pushing submissions into marketing automation, powering campaign landing pages, or handling customer logins. Plenty are doing several of those at once, and no one has written it down.

The more jobs the site is doing, the more careful you need to be, because each job is a place where a small change can quietly cost the business money. Map them before you go near anything.

Test the things that fail silently #

Forms are the classic example. A contact form can stop delivering and look completely fine on the surface, and no one notices until someone asks why the leads dried up. Go through the main inquiry forms yourself. Do they still send? Where do the submissions go? Who gets notified, and has anyone tested them recently?

Tracking and analytics fail the same quiet way. Check whether analytics is installed and configured, whether conversions are being tracked, and whether the numbers line up with what the team believes is happening. If the reporting feels off at this stage, make a note. You don't have to solve it now, but you'll want it on the record.

Check what your team actually lives with day to day #

Here's a test worth running early. Make the kind of update marketing needs all the time. Change a heading, swap an image, add a sentence to a key page. You're not really testing the change. You're testing how the site feels to work in. If a small edit turns into a struggle, that tells you more about the state of the site than any performance score.

While you're in there, look hard at the pages the business relies on most. The main service pages, the pricing page, the campaign landing pages, and the resources sales sends to prospects. Out-of-date messaging, broken layouts, stale calls to action, and pages that are clearly painful to edit are all signs of a site that's been left to rot.

Know what not to touch #

This is the part most audit checklists skip, and it's the part that matters most when you didn't build the site. There are areas where a well-meant quick fix creates far bigger problems than the one you were trying to solve.

Be very careful around DNS settings, CRM connections, analytics setup, redirect rules, core CMS updates, and any plugin or template that affects more than one page type. Those parts of a site are almost always wired to more than they appear to be. A rushed change in one of them can knock out form submissions, break tracking, hurt search visibility, or take down a page the sales team relies on, and you often won't see the damage until leads stop arriving.

We see the results of this regularly. At least once a quarter, a business comes to us to fix a site that another team broke while trying to help. The pattern is almost always the same: a reasonable-looking change to something that turned out to be revenue-generating. When you're new and under pressure to show progress, the discipline to leave certain things alone until you understand them is one of the most valuable things you can bring.

Keep a running list of the questions no one can answer #

As you go, track two lists. One is what you've found. The other is everything no one can explain yet. Why was this built this way? What depends on this section? Who receives these leads? Can we remove this safely? Is this page even still in use?

That second list is worth more than it looks. If you do end up bringing in outside help, handing over a clear set of unknowns saves everyone weeks and tells a good partner exactly where the risk is hiding.

When to bring in a professional, and why that doesn't mean a rebuild #

Work through all of that, and you'll usually reach a fairly honest verdict. Sometimes the site is in better shape than the warnings suggested, and you can settle in. Or you'll see a CMS several versions behind, reporting that doesn't line up, a structure that's clearly been patched over for years, and small changes that keep causing new problems.

When that's the picture, the reflex is often to call for a full redesign. Resist it. A rebuild is expensive, slow, and frequently solves the wrong problem, because the real issue usually sits underneath the surface rather than in how the site looks. We wrote about that here: Why Redesign a Website If the Real Problem Is Something Else?

Before anyone spends a rebuild budget, you want a clear read on what's actually wrong.

That's what our Tech Plan is for. It's a paid diagnostic that runs before any implementation work, which makes it a good fit for exactly this situation: a site you inherited, didn't build, and don't fully trust yet. We look at the code health, the stability, and the technical debt that's built up over time, and you come away knowing what's safe, what's risky, and what needs fixing first.

It's worth being straight about why this is paid rather than a free review. A genuine read on the condition of a complex site takes real work, and a rushed free version tends to confirm what you already suspected without telling you what to do about it. Around 65% of the sites we've worked on over the past decade have been genuinely complex, with problems no one had seen before. Those aren't sites you diagnose in a ten-minute scan.

You inherited the site. You don't have to inherit the problems. #

The first few weeks are about protecting the business, supporting your team, and making smart calls early rather than fast ones. Work through the checklist, resist the urge to fix things you don't yet understand, and get a professional read before you commit to anything major.

None of this is unusual, by the way. More than half of the clients who've been with us for years first came to us in exactly this kind of moment, with an urgent problem on a site they'd inherited. The panic passes. What's left is a site you can actually trust.

If you're now responsible for a site you didn't build and you want an honest assessment of where it stands, reach out and we'll talk it through. It's a lot easier to steady a site than to start over, and it's almost always the right first move.