Search for how to conduct a website audit and you will be handed a numbered framework. Six steps, seven core components, five C’s of auditing. Almost none of them says whose framework it is, and most of them quietly cover two different jobs at once, which is why people work through one and still cannot say whether their site is actually broken.
This procedure covers the delivery side. Whether pages come back at all, whether they come back fast enough for the people actually loading them, whether somebody navigating by keyboard can get through a form, and whether any of it holds up on the device most of your visitors are holding. The search side, whether a crawler can reach your pages and whether the right one answers each query, is a separate run book and it is linked in the first section.
We sell audits, so treat this as interested testimony and check it. Every threshold below comes from a named documentation page, quoted with its URL and the date it was read. Where the sequence is ours rather than anybody’s published standard, the section that sets it out says so in its first line.
How to conduct a website audit depends on which one you mean
Before any procedure, settle which of the two you are running, because the instruments, the findings and the person who fixes them are all different.
One audit treats the site as a search asset. It asks whether pages can be crawled, whether the right page answers each query, and whether search behavior changed after you acted on something. Our walkthrough of SEO performance step by step is that procedure, and if that is the question you came with, go there instead of reading on.
The other audit, this one, treats the site as a delivered product. It asks whether the thing works. Does the page return, does it return quickly, can it be operated by somebody who is not using a mouse and a large screen, and does it survive contact with a mid-range phone on a normal connection. None of those questions appear in a query export, and all of them cost money in ways that a ranking report will never show you.
The two overlap on exactly one finding, which is that a page nobody can load is also a page nobody can rank. Beyond that they are separate. Our website audit page covers what we run on the delivery side, and our note on why a website audit is worth running at all makes the case for doing either of them before you commission work.
Almost every wasted audit we see is this confusion. Somebody asks for a website audit, receives a keyword report, and still has a checkout that fails on one browser.
The five passes, and why this sequence is ours
Say the unglamorous thing first. The five passes below are our sequence, not an industry standard, and there is no body that publishes a canonical order for this work. If you see a six-step or seven-component framework presented as the way it is done, ask the same question of it that you should ask of ours, which is who decided and on what grounds.
Ours is ordered by dependency rather than by importance, and the grounds are that each pass makes the next one readable. You cannot judge how fast a page is until it reliably returns. You cannot judge whether it is operable until it renders. You cannot tell whether a fix worked until you know what the number was before. Ordering by severity instead, which is what most exported findings lists do, produces a plan that keeps sending you back to the top.
What is not ours is every threshold inside the passes. Those are quoted, with the page and the date, from Google’s Web Vitals documentation, from the PageSpeed Insights documentation, and from Mozilla’s accessibility testing material. The split is deliberate. A sequence is a judgment and should carry a name. A threshold is a fact and should carry a citation.
The five, in order. Does it work. Is it fast for real visitors. Can it be operated. Does it hold up on a phone. Will you be able to tell whether your fix helped. Run them in that order even when something further down looks worse, because a finding from pass four is not trustworthy while pass one is still failing. That ordering is most of our answer to how to conduct a website audit, and it is the part we would defend rather than the checklist sitting inside it.
Pass one, does the thing actually work
This pass needs no tool you have to pay for and it finds the most embarrassing faults, which is why it goes first rather than last.
Crawl the site and read the status codes rather than the summary. You are looking for pages that return an error, pages that redirect more than once before they land, and pages that return a success code while showing an error message in the body, which is the one a crawler will tell you is fine. Then check that every internal link resolves, because a broken link inside your own navigation is a fault you shipped rather than one that happened to you.
Then do the part no crawler does. Submit every form. Not look at every form, submit it, with a real address you can check, and confirm something arrives at the other end. Buy something if the site sells something. Reset a password. Contact forms that silently stopped delivering are the single most expensive fault on this list and they are invisible to every automated check, because the form returns a success page either way.
Finish by checking that the site is served over a secure connection everywhere, including the pages somebody built in a hurry, and that the error page actually helps rather than dumping a visitor at a dead end. Write down what you find here in plain sentences. A fault in this pass is almost never a judgment call, which makes it the easiest section of your report to get agreed.
Pass two, how fast it is for real visitors rather than for your laptop
This is where most audits go wrong, and the reason is that the easiest number to collect is the one that means least.
Google publishes three thresholds. Its Web Vitals documentation states that Largest Contentful Paint “should occur within 2.5 seconds of when the page first starts loading”, that pages “should have a INP of 200 milliseconds or less” for Interaction to Next Paint, and that Cumulative Layout Shift should be 0.1 or less, the three covering what it calls “loading, interactivity, and visual stability” (web.dev/articles/vitals, read 16 September 2026).
Now the part that changes how you audit. The same page says that “a good threshold to measure is the 75th percentile of page loads, segmented across mobile and desktop devices”. So the question is not whether your page was fast when you tested it. It is whether it was fast for three quarters of the people who loaded it, counted separately for phones and computers. One run from your own machine cannot answer that and never could.
The distinction has a name in Google’s own tooling documentation. PageSpeed Insights “provides both lab and field data about a page. Lab data is useful for debugging issues, as it is collected in a controlled environment. However, it may not capture real-world bottlenecks. Field data is useful for capturing true, real-world user experience” (developers.google.com/speed/docs/insights/v5/about, read 16 September 2026). Lab data is the simulation. Field data is what happened to real visitors, and the same page notes it is reported “over the previous 28-day collection period”.
So collect field data first and treat lab data as a debugging aid for whatever the field data says is wrong. If a page has too little traffic to report field data, say so in the finding rather than substituting a lab number and letting the reader assume it is the same thing. Our explanation of what these metrics are actually measuring covers the definitions behind the three thresholds.
Pass three, can somebody use it without a mouse
Accessibility is the pass most delivery audits skip, usually because the automated score came back green and everyone took that as an answer.
It is not an answer, and the clearest statement of why comes from Mozilla’s own testing material, which says that “You can’t rely on automated tools alone for determining accessibility problems on your site” and that every project needs a user testing strategy including screen reader users and keyboard-only users (developer.mozilla.org, Learn web development, Core, Accessibility, Tooling, read 16 September 2026). An automated checker finds missing alternative text and thin color contrast. It cannot tell you that your tab order jumps from the header to the footer and back.
Run three manual checks yourself before you commission anything larger. Put the mouse down and move through a key page using only the keyboard, confirming that you can see where you are at every step and that you can reach and operate every control including the menu and the cookie banner. Then check the same page with styling switched off, because as Mozilla’s page explains, assistive technology reads content in source order, and the fastest way to see that order is to disable the site’s CSS in your browser and read what is left.
Third, check the text against its background for contrast on the elements people actually have to read, which means body copy and form labels rather than a heading somebody chose the color for. Those three take under an hour on a small site and they find faults that no score reports, because a score is computed from what a machine can inspect and these are properties of a journey.
Pass four, the device most of your visitors are actually holding
By this point you know the site returns, roughly how fast it is and whether it can be operated. Now check that any of that survives a phone.
Google’s own guidance builds the device split into the measurement rather than treating it as an afterthought, which is why its percentile advice says to segment across mobile and desktop and why PageSpeed Insights reports the two separately. Read them separately too. A site whose combined figure looks acceptable is routinely a site that is comfortable on desktop and failing on phones, and the combined view is what hides it.
Then get off the emulator. Device emulation in a desktop browser resizes the viewport, it does not give you the processor, the memory pressure or the network of a real mid-range handset, and those are exactly what make an interaction slow. Pick up an ordinary phone, not the newest one in the office, and complete the task the site exists for. Buy the thing, book the appointment, send the message.
Watch for the faults that only appear at that size. Controls too close together to hit reliably, a fixed header that eats half the screen, a form that scrolls the field you are typing in behind the keyboard, a menu that cannot be closed. None of these produce a failing metric and all of them lose the sale.
Pass five, set the re-measure date before you fix anything
The last pass happens before any work starts, which is why people skip it and then cannot prove the work was worth doing.
Write down the numbers you just collected and the date you collected them, then set the date you will collect them again, and put both in the report before a single fix is scheduled. The timing is not arbitrary. Because field data is reported over a rolling 28-day window, a page you fix today will keep showing a blend of the old and the new experience for weeks, and a re-measure taken the following morning tells you nothing at all. Deciding that in advance stops the argument about whether the work helped from being settled by whoever is most confident in the room.
Record the conditions as well as the figures. Which pages, which device split, field or lab, and what else changed in the same window. A site that got faster during a month when traffic also halved has not necessarily got faster, and you will not be able to tell later unless you wrote down what else was going on.
The same discipline applies to comparing yourself against anybody else, which is a separate exercise with its own traps. Our guide to benchmarking side by side covers what makes two measurements comparable and what quietly makes them not.
What to do with the score a tool hands you
Somewhere in this process a tool will give you a number out of one hundred, and what you do with it decides whether the audit was worth running.
Use it as an index, never as a target. A composite score is a weighted bundle of individual checks, so two sites with the same score can have nothing in common, and moving the score is not the same as fixing anything a visitor would notice. The number is useful for one thing, which is telling you which page to open first.
Be especially careful when the score is computed in a simulation. A lab score is repeatable, which makes it feel authoritative, and it is repeatable precisely because it is not measuring your visitors. Chasing it produces the audit outcome we see most often, which is a site that scores better and feels the same. Our comparison of website checkers covers what the common ones actually inspect, and our look at what this software meters and charges for is worth reading before you buy a subscription on the strength of a free report.
Our own position is that we do not put a single grade on a delivery audit, because the passes above answer to different people and collapsing them into one figure destroys the only information a fixer needs, which is what to do on Monday.
How to write findings somebody will actually fix
An audit that nobody acts on is a cost, and the usual reason nothing happens is that the document was written for the person who wrote it.
Give every finding three things. Where it happens, stated as a URL and the steps to see it. What the reader should observe when they get there. And what it costs, in the plainest terms available, which is usually a sentence about who cannot complete what. A finding that says a contrast ratio is below threshold will sit in a backlog. A finding that says the labels on the checkout form cannot be read against that background, with the URL, gets scheduled.
Put the evidence in the document rather than in a folder somewhere. A screenshot of the failing state, the figure you read and the date you read it, and the browser and device you were using when you saw it. Six weeks later, when somebody cannot reproduce a finding, the question is always whether it got fixed or whether it was never quite true, and only the evidence you attached at the time can settle that.
Order the list by dependency, the same way you ran the passes, and say in the document that you have done so. If you sort by severity you will put a slow page above a broken form, and the team will work top down and rediscover the order you should have given them. Where one finding cannot be judged until another is fixed, say that in the finding rather than leaving it to be discovered.
Then name the receiver. Delivery findings go to whoever owns the build, the hosting and the front end. If half your list is really about content and search results it belongs to a different person and probably to a different audit, and posting it to the wrong queue is how a good finding dies quietly.
What we would check first, and what to ask us
Given an unfamiliar site and one day, we would not open a scoring tool at all until the afternoon.
We would submit the forms first, because that is where we find the fault that is costing real money more often than any other single check, and it takes twenty minutes. Then we would pull field data for the pages that carry the business, read it at the 75th percentile split by device, and only then open a lab tool to work out why whichever number is failing is failing. The keyboard pass would come before anything cosmetic.
Now point that at us, because we sell audits and this article is an argument for having one done. The test it sets is that thresholds are quoted to a named page with a date, the sequence is owned rather than presented as standard, and findings are ordered by dependency with a receiver named. Ask us which of the five passes we ran, which numbers are field data and which are lab, and why a finding sits where it does in the list. An audit that hands you a severity-sorted export and a grade out of one hundred has answered a different question, and that applies to ours as much as to anybody’s.
The first move costs nothing though. Go and submit your own contact form, then check whether it arrived. If you would rather have the five passes run for you and handed back as a findings list, our free website audit is where we would start.
