The Lighthouse and SEO site audit reporting dashboard for agencies

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 — and it appears wherever Google has real-visit data for the site. The lab audit is what Lighthouse measured on each listed URL under controlled conditions, on demand, the day a fix ships; where Google has no field data, it stands in for LCP and CLS and is labeled lab, because INP needs real visits. One says whether the site is passing; the other says which template is responsible.

The page scores table is where that pairing shows up. Every audited URL carries its own four scores beside its own lab LCP and CLS and a Core Web Vitals result marked as real visits or lab, worst pages first — so “the site feels slow” becomes a work order naming the template and the metric at fault. Clicks, impressions and position 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 and server response time; kibibytes for image delivery, 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 and the lab timings behind them, such as First Contentful Paint, Largest Contentful Paint, Speed Index and Total Blocking Time. Each is reported with its target 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.

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 and image alt attributes, among others. A headline count sits above the table, so the first thing anyone sees is how many checks 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 queries, impressions and position 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 impressions 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, and the pages to audit are added in the report itself.

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.