The confusion costs both sides. An owner pays for an audit and gets a printout about hosting and backups that never mentions the booking page. An agency delivers a careful review of twelve pages and, three weeks later, hears “but did you check the blog?” Nobody agreed the scope, so everyone remembers a different one.
The fix is to define the audit by its questions rather than its tools. The working definition we use: a website audit is a review of chosen pages that answers specific questions about whether they work for the business, backed by evidence a second person can check.
What should a website audit include? Five areas, five questions
Competent audits split the work into five areas. The labels vary by provider; the questions underneath shouldn’t.
Technical is where audits get padded. A technical finding should concern something that stops a page being fetched or read as intended: a redirect chain, a canonical tag pointing at the wrong address, a noindex left over from staging. Reviewing fetched pages also has a ceiling: it can count the bytes in an image, but it can’t tell you how fast the page felt to someone on a train.
UI/UX has to be judged at two widths. A page that looks fine on a desktop monitor can fall apart on a 390px phone, and for a local service business the phone is often where the enquiry starts. The specific failures are covered in mobile usability issues that stop phone visitors from booking.
SEO, inside a website audit, means on-page clarity: does each title, description and heading say what this particular page is about, as distinct from its neighbors? The usual offenders are in common on-page SEO issues.
Content is harder, because the answer often isn’t on the page at all. In Prooflin’s sample Website Audit for a fictional dental clinic, the implants page invites questions but never describes the first consultation: who assesses suitability, how a proposed plan is discussed, what the visits look like. The audit names the gap without filling it, because those details “must come from the clinic, not an assumed standard pathway.” An audit that invents clinical, legal or pricing facts to fill such a gap has overstepped.
Marketing is the commercial reading. Is the offer specific, and does each page hand the visitor on to a sensible next step? If the homepage is your main worry, what a homepage audit should tell you goes further. If people arrive and don’t act, first work out whether it’s the traffic or the page.
Which pages belong in the audit
An audit of every URL sounds thorough and usually isn’t. Seven careful page reviews beat fifty thin ones, provided the seven are the pages that carry the business goal.
Write the goal down in one sentence first. The sample dental audit frames it as helping a visitor begin an appropriate appointment or treatment conversation, then gives every page a job:
- Home: entry and orientation
- Services: service discovery
- Teeth whitening and dental implants: treatment consideration
- About: trust and familiarity
- Smile gallery: visual reassurance
- Contact: enquiry and appointment intent
Eight pages were inventoried and seven selected. The privacy policy was excluded as outside the content and conversion scope, and the scope page says so rather than leaving the reader to assume it was checked. One line closes the question before anyone asks it.
What should a website audit include when the site has 300 URLs?
Sample by template and by intent. Say a roofing contractor’s site has a homepage, eight service pages, 140 near-identical suburb pages and 150 blog posts. Review the homepage, every service page, the quote page, two or three suburb pages standing in for the rest, and the few posts that actually send people to a quote. A problem found on one suburb page then belongs to the template, and the report should say so once rather than log it 140 times.
The sample handles its navigation the same way: one sitewide finding covers all seven pages, with an explicit note not to duplicate it into seven separate issues. Inflated finding counts look diligent and make the plan harder to act on.
The evidence standard each finding should meet
A finding is a claim about a page. It should give someone who wasn’t there enough to check it. At minimum:
- A location: the page, plus a quote, source line or capture showing the problem.
- What was observed, kept apart from why it matters. The observation can be checked; the interpretation is opinion with reasons attached.
- Severity and priority as two separate ratings. In the sample’s words, severity describes the issue; priority describes the sequence.
- Confidence, with its basis. High confidence that something is on the page isn’t high confidence that fixing it will bring in more bookings.
- One recommended action and a completion check, so someone can tell when it’s actually done.
Here’s a technical finding from the sample, quoted as written:
Gallery assets are much larger than their displayed size
Observed
Six PNG photographs, each 1536 × 1024 pixels, are embedded directly without responsive image candidates. Their actual saved sizes range from 1.86 to 2.54 MB, totalling 13.59 MB (decimal). Each is displayed at 360 CSS pixels wide in the 1366px desktop view.
Why it matters · interpretation
The page references high-resolution source files for relatively small cards. Smaller, appropriately compressed derivatives could reduce transferred image bytes. These file measurements do not establish a load time, speed score or real-user experience.
Completion check
Inspect the browser-selected resource at desktop and mobile sizes. Compare encoded byte sizes with the originals and check fine detail visually. Record bytes actually delivered; run a separate performance evaluation before making speed claims.
Hard numbers, and still no speed claim. A report that careful with what you can verify earns trust on the judgment calls you can’t.
What a usable output looks like
Five sections of findings aren’t an output yet. What gets used is one ordered plan across the areas, because the work crosses them: a button label depends on where the button goes.
The sample dental audit ends with 18 findings and exactly one action per finding: 2 at P1 Immediate, 6 at P2 High, 7 at P3 Planned and 3 at P4 Nice-to-have. They’re sequenced into three windows (immediate, within 7 days, within 30 days), and each action names a suggested owner and a dependency. The whitening call-to-action change waits on the contact form’s labels; the service-card copy waits on a decision about where each card links. Every action is still marked proposed; nothing is claimed as done.
An owner knows what to brief this week. An agency has the document that survives the meeting, which is the piece usually missing when SEO recommendations stall.
Prooflin’s Website Audit covers the same five areas, one at a time or together as a Complete Website Audit with a single action plan. Pages come from one URL, a sitemap.xml or a pasted list of up to 200 https:// addresses, and you include or exclude each one on the Review Discovered Pages step. Findings cite their evidence and carry severity, priority and confidence, and every report opens as a draft that a person reviews and finalizes before it goes anywhere. The Nova Dental Studio sample, seven pages and 18 findings on a .example domain, shows a finished audit in this shape.
Website audit or SEO audit?
Pick by symptom, not label. A specialist SEO audit may also dig into rankings, backlinks and search data, but its on-page core asks one question: does each page describe itself clearly? A website audit asks that plus four more. That’s most of the website audit vs SEO audit decision.
When the problem really is on-page only, Prooflin offers that SEO area by itself as the SEO Audit Report Generator: page-level findings on titles, descriptions and headings, with suggested replacement copy and no ranking predictions.
What a credible audit says it did not check
Asking what should a website audit include is only half the scoping job. The other half is what it won’t look at. Stay quiet about the limits and the reader assumes everything was covered. That’s how “did you check X?” turns into a dispute.
A page-based audit can’t see these, and the report should say so:
- Logged-in areas: member portals, account pages, anything behind a sign-in
- Rankings and traffic, which live in your search and analytics data
- Backlinks, a separate off-site question
- Real-user speed: file sizes can be read from a page, but load times for real visitors can’t
- Accessibility conformance, which needs full keyboard and assistive-technology testing
- Form delivery and live booking: whether the enquiry actually arrives
Its data-gaps table names, for each missing input, the conclusion it withheld: no performance measurements, so no load-time claim; no live form service, so no claim that enquiries arrive. Prooflin’s own reports follow the same rule. They don’t report rankings, traffic, backlinks, speed scores or Core Web Vitals, and where data isn’t available they say so instead of estimating. None of that replaces sending a test enquiry through your own contact form.
Agree the scope before anyone opens the site
The answer to what should a website audit include will differ for every site. The way to agree it doesn’t:
- Write the business goal in one sentence: “more consultation requests from the implants page”, not “improve the website”.
- List the pages that carry that goal and give each one a job. Drop anything that hasn’t got one.
- Choose the areas from the symptom, using the table above. Take all five if you’re unsure or about to redesign.
- Ask to see one complete finding and the out-of-scope list before work starts. A provider who can’t show either is selling a printout.
- Name who supplies the facts an audit can’t (prices, clinical details, team credentials) and who owns each fix.
Agencies: put that out-of-scope list in the proposal word for word. It costs one paragraph and saves an awkward call later.
