Website Audit: 6 Rules to Verify Before You Fix Anything

A website audit doc looks like a to-do list. It is not. It is a list of claims, and some of them will be wrong by the time you read them. I recently worked through a 16-item website audit for a professional services site, and several items did not hold up once I checked the live pages. These six rules kept the work honest.

1. Check every claim against the live site

An audit doc is a snapshot. Between the day it was written and the day you open it, someone may have fixed the issue, or the author may have blamed the wrong page.

In my audit, one item said old URLs were broken, but they already redirected correctly. Another said two menu labels were inconsistent, but the site was already consistent. A third had been fixed by a teammate and even came with a bonus improvement.

Open the page. Run curl -I to see real redirect headers. View the source. If the doc is wrong, say so plainly and write "no change needed". If you want a deeper walkthrough of reading each hop, my post on a WordPress redirect chain that ends on the wrong page shows the method.

2. Work one item at a time

Bulk fixes feel fast, but they hide cause and effect. When you change ten things at once and something breaks, you do not know which change did it.

One item at a time gives you a clean loop: read the claim, verify it live, make one change, verify again, close it. A duplicate URL in my audit turned out to have a redirect pointing at the wrong target. Fixing only that, then testing it, proved the cause.

3. Fix the real cause, not the doc's wording

The doc describes a symptom in the author's words. Your job is to find what is actually wrong.

Two examples from the audit:

• A members-only training page was sitting in the public sitemap. The fix was three small things together: set it to noindex, remove its canonical tag, and take it out of the sitemap.
• The doc called some category archives "thin or duplicate". That framing did not hold up. The real gap was a missing robots meta tag, so I set five archives to noindex.

Schema was the same story. The Organization, Person and page entities were not connected to each other. I fixed it with a small PHP filter on the SEO plugin's schema graph, then read the JSON-LD on the live pages to confirm each link. The schema.org vocabulary is the reference for which properties belong where.

4. Keep a website audit log

You will not remember what you checked on item 3 by the time you reach item 12. Keep one log file and update it after every item.

Mine had four sections: finished, unfinished, no longer applicable, and found but not in the doc. Each finished item closed the same way: the item title, a finished mark, and a list of page slugs I changed, slugs only, never full URLs.

When a client needs to apply text changes, I give them a three-column table: slug, text to replace, text to replace with. Nothing else. It is easy to scan and easy to hand to someone who is not technical.

I also built a content register: a spreadsheet of about 170 URLs pulled straight from the XML sitemaps, with columns for audience and topic. It turns a vague "clean up the content" request into a list you can sort and review each quarter.

5. Park blocked items with a clear owner

Some items cannot be finished by you, and that is fine. What matters is that "blocked" never means "forgotten".

Four items in my audit were blocked:

1. Core Web Vitals. My environment could not reach speed-testing tools, and I had no Search Console access. The owner of the property can run PageSpeed Insights and paste the numbers.
2. A conflicting business address. The header showed a PO box, while the footer map showed a street address. Only the business owner can say which is correct.
3. Testimonials. They need real client names and permission before anything gets built.
4. A conversion funnel. It needs a CRM that is not in place yet.

For each one, write what is blocking it, who can unblock it, and what you will do the moment they answer. Do not guess the address. A wrong guess is worse than a gap.

6. Keep unrelated finds in a separate list

While checking one thing you will spot another. Resist the urge to fix it on the spot. Scope creep is how a clean audit turns into a messy rebuild.

Put it on a separate "found but not in the doc" list, tell the client, and let them decide. The same goes for items that stop mattering. Two team-bio items became irrelevant when those people left, so I marked them "no longer applicable" instead of quietly dropping them.

What this gets you

An audit done this way ends with something you can trust: every claim checked, every change verified, every blocker named. The client sees exactly what changed and exactly what is waiting on them.

If you want a website audit like this on your own site, take a look at my SEO-ready websites and WordPress maintenance services, or get in touch and tell me what your audit doc says.