SEO site audit reporting
Site health, explained without the jargon
Lighthouse scores, Core Web Vitals, ranked opportunities, accessibility findings and technical SEO checks — mobile and desktop, scoped to one client. Sign in to open the report workspace, or preview what’s inside.
SEO site audit reporting
A site audit is the easiest technical work to do and the hardest to show. This dashboard organizes it the way a client review actually runs: the four Lighthouse scores up top for mobile and desktop, Core Web Vitals beside the pages responsible for them, and the fix list ranked by how much time or weight each item actually saves.
Lighthouse produces four scores out of a hundred, and every one of them means something different to the person paying for the work. The report puts all four on the same row for the device you are reviewing, colors them by Google's own bands, and adds a single weighted site-health figure so a monthly update can open with one number instead of four. Switching between mobile and desktop re-scopes the whole report, because the two rarely tell the same story and a blended score hides which one is hurting.
Scores are levels rather than volumes, so they are reported as levels. Each card carries the change in points across the window you selected instead of a percentage that reads strangely on a hundred-point scale, and the trend beneath it plots the same category day by day. A regression then shows up as a shape you can point at in a meeting — the week the new hero image landed, the week the tag manager grew — rather than a difference between two isolated snapshots.
Every vitals conversation ends on the same question: which page? This report answers it by keeping two measurements beside each other. The field percentile is what visitors actually experienced — Largest Contentful Paint, Interaction to Next Paint and Cumulative Layout Shift at the 75th percentile, against Google's own good and poor lines. The lab audit is what the crawler measured on each URL under controlled conditions, on demand, the day a fix ships. One says whether the site is passing; the other says which template is responsible.
The audited-pages table is where that pairing shows up. Every crawled URL carries its own four scores beside its own lab LCP and CLS, and the assessment donut counts how many pages pass outright, need improvement or fail — so “the site feels slow” becomes a work order naming the template, the traffic behind it and the metric at fault. Property-level trends and the device split Google publishes belong in the Search Console report; this page is the bench test underneath them.
The opportunities tab lists what the audit found and what fixing it is worth — milliseconds for render-blocking resources, preconnect hints and server response time; kibibytes for oversized images, next-generation formats, offscreen media, unused JavaScript, unminified CSS and cache lifetimes. Each row carries the area it belongs to and a severity derived from the size of the saving, so a developer estimate and an agency priority can be argued from the same list rather than from two different exports.
Diagnostics sit alongside as the explanation rather than the to-do list: DOM size, main-thread work, JavaScript execution time, request count, transfer weight, critical request chains, the element that defines Largest Contentful Paint and the elements moving after paint. Each is reported with the target it should be under and a plain sentence about why it matters, which is usually the difference between a report a client forwards to their developer and one that comes back with questions.
Automated accessibility checks are grouped the way remediation is actually scoped — by impact. Critical findings such as unlabelled form fields and images with no alternative text sit apart from serious ones like contrast failures and unnamed links, which sit apart again from moderate issues such as tap-target size, heading order and focus order. Each row carries the number of elements involved, so a quote is built from counts rather than from a vague promise to improve accessibility.
The report is deliberately honest about what an automated pass covers. These checks catch a fraction of the barriers a manual review finds, and the surface says so, which protects an agency from a client reading a clean run as a compliance certificate. Used properly it is the cheapest first sweep available: it clears the mechanical failures, leaves a documented record of what was fixed and when, and gives a manual audit a much smaller surface to work through.
Ten crawl-and-markup checks run as a pass or fail list with a sentence explaining what the crawl found: title elements, meta descriptions, crawlable links, canonical declarations, hreflang annotations, a valid robots file, image alt attributes, legible font sizes, tap-target spacing and structured-data validity. A headline count sits above the table, so the first thing anyone sees is how many of the ten are clean and how many are open work.
This is the on-page audit, not the indexing report — what a crawler can parse on the page rather than what Google chose to keep. The two answer different questions and belong in different places, which is why coverage, queries and impressions live in the Search Console report and this page stays on the markup. Reviewing them together is the usual pattern: fix what the audit flags here, then watch coverage and position respond over the following weeks.
Every audit is scoped to a single client through the workspace switcher and presented with your agency branding, so the same structure carries the January review and the June one. Scores, vitals, opportunities, diagnostics, accessibility and technical checks keep their places across engagements, which makes month-on-month comparison a matter of reading the same section twice rather than reconciling two differently shaped documents. The workspace provides the review surface; data-source setup remains a separate step.
That repetition is what turns technical work into something a client will renew. A developer sees a ranked fix list with estimated savings; an account manager sees four scores, a health figure and the pages behind them; and both are looking at the same report. Teams spend the time on deciding what to fix next instead of rebuilding a presentation layout, and the audit stops being the deliverable nobody looks forward to writing.
Lighthouse is Google's open-source auditing tool. It loads a page in a controlled environment, runs a fixed set of audits and scores it from 0 to 100 on Performance, Accessibility, Best Practices and SEO. This report runs those four categories per audited page and per device, so a mobile score is never quoted as though it were the desktop one.
Lab data comes from a controlled test of one page: repeatable, ideal for diagnosis, and not what real visitors experienced. Field data comes from real sessions and is summarised at the 75th percentile. The report carries both — field Core Web Vitals as the headline, with the lab audit of every crawled URL underneath explaining what to fix.
They are part of Google's page-experience signals, so they can separate otherwise comparable results — but they do not outrank relevance, and nothing ranks on speed alone. The useful framing for a client is that LCP, INP and CLS describe how the site feels to use, and the opportunities view prices that work by showing what each fix saves.
Contrast, alt text, form labels, ARIA use, tap-target size, heading order and focus order, each carrying an impact level — critical, serious, moderate or minor — and the number of pages affected. The impact level is what makes an audit quotable: it turns a list of failures into work an agency can scope, price and schedule.
Often enough to catch a regression before the client does, which for most retainers means monthly, plus an extra pass after a redesign or a template change. The history view keeps previous runs, so the audit reads as a trend rather than a one-off screenshot and a fix can be shown as the exact moment a score moved.
