The website audit checklist, in the order that actually pays

Audit in the order that pays, not the order that reads well

Most audit checklists are organised by topic, which is convenient to write and useless to work through. A site with a broken checkout and a missing meta description does not have two problems of equal standing, and an audit that presents them in a list of 200 items has made the reader do the triage that was the job.

The order below is by consequence. Each stage answers a question whose answer changes what is worth doing in the next one - there is no point tuning Largest Contentful Paint on pages a crawler cannot reach, and no point improving copy on a page that returns a 500 twice a day.

Do the whole first stage before starting the second. The most common way an audit fails is not missing an item - it is spending the budget on stage four while a stage one problem is still live.

Stage 1 - Is it up, is it reachable, is it yours

The questions that make every other question moot. All of them are answerable in minutes and each has been the entire finding of a real audit at least once.

• Every page returns the status it should - 200 for real pages, a genuine 404 for missing ones, and no page that says 'not found' while returning 200
• HTTP redirects to HTTPS, the certificate is valid and trusted, and it is not weeks from expiry
• No mixed content: an HTTPS page loading an HTTP script is an insecure page with a padlock
• The site is not blocking itself - no leftover site-wide noindex, no Disallow: / from a staging config
• The domain resolves with and without www, and one of them is a redirect to the other rather than a second copy of the site

Stage 2 - Can it hurt anyone

Security next, because it is the only category where the cost of being wrong is not measured in conversion rate. The externally visible part is a short list, it is cheap, and it is very often untouched.

• Security headers: HSTS, a Content-Security-Policy, clickjacking protection, nosniff, Referrer-Policy
• Session cookies with Secure, HttpOnly and an explicit SameSite
• No version numbers leaking in Server, X-Powered-By or a meta generator - free reconnaissance for anyone matching your stack against a CVE list
• No stack traces on error pages, no directory listings, no admin interface linked from a public page
• Password fields only ever on HTTPS pages, and forms that do not post credentials across origins

This is also the stage where an audit has to be honest about its own reach. Everything above is visible from outside, which is why it is checkable - and it is a fraction of what security means. See the last section.

Stage 3 - Can it be found

Indexability before content, because a page that cannot be indexed cannot be improved into a ranking one. Work through the mechanical causes first: robots directives, canonicals, status codes, redirect chains, and whether the content exists in the served HTML at all.

• Every page has a title and a meta description, both within display length, and no two pages share either
• One H1 per page that matches what the title promises
• Canonicals present and pointing at a reachable page on the same site
• An XML sitemap that lists only URLs that return 200 and are not noindexed
• Internal links with descriptive text, and none of them broken
• Structured data that parses, and that describes what is actually on the page

Stage 4 - Is it usable, and by whom

Performance and accessibility together, because they fail the same people first: the ones on the slow connection, the old device, the small screen, the assistive technology. Both are also the stages where a lab measurement and a real user diverge most, so measure mobile separately and treat the automated accessibility pass as one half of the job.

• Largest Contentful Paint and Cumulative Layout Shift within threshold, measured at a mobile viewport as well as desktop
• Text responses compressed, static assets cached, images in a modern format at the size actually rendered
• Alt text on images, labels on inputs, contrast within ratio, headings that do not skip levels, zoom not disabled
• Tap targets large enough, and a viewport that uses device-width
• The keyboard pass: reach everything with Tab, activate it with Enter, and always be able to see where focus is

Stage 5 - Does it do its job

The stage almost every technical audit omits, and the one the person paying for it cares about. A site can pass every check above and still fail commercially, and the failures are usually embarrassingly mechanical.

• The buy, sign-up and contact links resolve - a checkout button pointing at a 404 is a technical defect with a revenue number attached
• Forms submit, and say something useful when they do not
• The 404 page offers a route back rather than a dead end
• Privacy policy, terms and cookie policy exist, are linked, and are reachable
• Contact details a real person can use, and a consent mechanism if you set cookies that need one

How to weight it when you have to produce one number

Sooner or later somebody wants a score. Any single number is a compression of judgement, so the only defensible version is one whose weights are written down before the audit rather than after. These are ours, across 199 checks in nine categories - published so a reader can disagree with them specifically:

• Security - Headers, TLS, cookies, exposure surface, weighted 22%
• Performance - Core Web Vitals readiness, payload, caching, weighted 16%
• SEO - Indexability, metadata, structure, links, weighted 14%
• Accessibility - WCAG signals, semantics, contrast, weighted 12%
• UX quality - Clarity, states, navigation, trust, weighted 10%
• Technical - Status codes, rendering, assets, canonicals, weighted 10%
• Compliance - GDPR, policies, consent, transparency, weighted 8%
• Mobile readiness - Viewport, tap targets, responsive integrity, weighted 5%
• Browser compat - Engine coverage, fallbacks, legacy risk, weighted 3%

Two properties matter more than the exact figures. The weights must be fixed before you look at the site, or you are choosing the number you wanted. And a finding present on every page must cost more than the same finding on one page - otherwise a template-wide defect scores the same as an isolated one.

Publish the weights alongside the score, always. A score whose arithmetic is not reconstructable is not a measurement, it is an opinion with a number attached - and the first client who challenges one in a meeting will find that out for you.

What no external audit can tell you

Every checklist above stops where visibility stops. These are the questions that decide whether a site is actually safe and actually maintainable, and not one of them can be answered by any scanner, including a good one:

• How passwords are stored, and with which algorithm and parameters
• Whether the API authorises each request or merely authenticates the caller
• Whether rate limiting exists where it matters, and what it does when it triggers
• Whether access control is enforced in the database or assumed in application code
• Whether backups exist, and whether anyone has ever restored one
• Who has production access, and what happens when they leave
• Whether dependencies are patched, and how quickly

The right way to handle them is not to leave them out and not to guess at them. Put them on the record as a separate, explicitly manual layer: someone attests to each one, the answer is dated and attributable, and it never silently moves an automated score in either direction.

An audit that reports only what it could measure, and names what it could not, is worth more than one that produces a confident 94/100 out of half the picture. If you take one thing from this page, take that.