Every agency client has received one: the audit. Forty pages, a score on the cover, a table of issues sorted by severity, exported from a crawler on a Tuesday and emailed with a line like "let's walk through this on the call". Three weeks later somebody asks whether the duplicate title tags were fixed, and the honest answer is that nobody opened the PDF again after the call.
I run SharpHaw, a small agency in Lisbon, and I built SharpOS, the workspace our client engagements run in. Audits is the row on our replacement ledger that sits opposite Semrush and Lighthouse. This post is about what that row does, what it deliberately doesn't do, and why the audit surface in our own product has no "Run audit" button.
TL;DR: the crawler was never the bottleneck. The PDF was. Audits in SharpOS is where findings live, get rechecked against the live site, and get closed. It does not crawl.
What Semrush and Lighthouse are for, and where they strain
A crawler-backed SEO suite does one thing well: it walks a site and produces findings. Missing descriptions, thin pages, broken canonicals, duplicated titles, a health score you can track over time. Lighthouse does the other half: a lab run against one URL that tells you where the performance, accessibility and SEO basics stand, with the specific audit that failed. Both are good tools — I still run PageSpeed against pages I'm about to ship.
The strain shows the moment the findings have to reach a client. The crawler lives in the agency's account, so the output has to be exported, and an export is a snapshot. Then the snapshot has to be explained, so it becomes a call. Then the call ends and the findings have nowhere to sit except inbox history. The threads on r/SEO say it plainly: one owner pushing back on an 18-hour audit because "the report is repetitive", another warning that autogenerated audits "frequently miss" what matters. Both are complaints about the document rather than the crawl. Our own playbook has the same line about the agency model in general: audits and strategy documents become PDFs that vanish after the first week.
What Audits does instead
Audits is the workspace where a site's findings live. Each site a client cares about is an audit target inside their organisation. A run against that target holds the crawled pages, the findings (scored across eleven categories), the artefacts, and a short structured verdict, and the org's members open it the way they open a board. If you want to see what that looks like without an account, the fixture-only showcase runs the real components in your browser: open a target here.
The part that changes the client's experience is what happens to a finding after it exists. A finding has a status, so it can be set to done. A finding can become a page or a board card in one action, which is how "fix the duplicate titles on the service pages" turns into a card on the same weekly board the client already watches. And a finding can be rechecked against the live site: a recheck that passes deletes the finding, a recheck that fails keeps it and says so. The audit stops being a document you re-read and becomes a queue you drain. The feature page puts it in five words: the audit that doesn't disappear.
Visibility and roles apply the way they do everywhere else in the workspace. A target is client or internal; internal ones are platform-admin only and don't appear in listings at all. The Audits feature flag gates the routes, the navigation and every backend access path, so an org without the feature never reaches a handler.
How it works
SharpOS doesn't crawl. That is the decision the surface is built around, and it's why there is no "Run audit" button. Crawling and analysis happen in an agent outside the product (ours runs from a repo-local skill with a set of deep-dive lanes: conversion path, message quality, answer-engine readiness, performance, accessibility, trust), and the agent pushes results in through the integration API: create the target, open a run marked as agent-sourced, push the pages, push the findings, push the insights, finalise. Scoring is computed on the server at finalise, from the evidence that was ingested. Every write requires the platform admin key; an organisation's own API token can read client-visible findings and cannot create a single one.
That split keeps two things honest. A long crawl never has to fit inside a backend function's runtime. And the workspace is the source of truth for what a site looked like, rather than a mirror of whatever the crawler's account remembers.
Ingest reports what was persisted, not what was sent. A page-level finding whose URL matches no ingested page is dropped, and the dropped URLs are listed back to the agent, so a push that only partly landed is visible immediately. Ingested pages must belong to the target's host. And a new run replaces the previous run's evidence: pages, findings, artefacts and blobs go, and only the older run's score and finding count stay as history. Storage doesn't grow without bound, and the workspace always shows the current state of the site rather than a stack of stale ones.
Lighthouse stayed, in one specific place. Rechecking a Largest Contentful Paint, Cumulative Layout Shift or Interaction to Next Paint finding triggers a fresh PageSpeed probe and evaluates the result against the Core Web Vitals thresholds. Pass, and the finding is deleted. Fail, and it stays, marked as rechecked and failed. If the probe can't be captured at all, the finding is kept — a recheck may only delete evidence when it has evidence. Only finding types SharpOS can genuinely re-evaluate on the live site can be rechecked; anything else is refused up front instead of being silently resolved.
What it doesn't do
Audits does not out-crawl a dedicated SEO suite, and it isn't trying to. There is no keyword research, no backlink index, no rank tracking, no competitor visibility graph. If your work depends on those, keep the suite. Lighthouse itself isn't replaced either; it's called during rechecks, and PageSpeed remains the lab measurement we trust for that.
There is also no crawl cockpit. You can't start a run, watch a progress bar, or stop one from the hub, because the run isn't happening there. An hourly sweep marks runs that stopped reporting progress as failed, and the workspace's History tab is where a failed run gets reviewed. For a team that wants a button and a spinner, this is the wrong shape.
Where it sits in the SharpHaw service
Audits is the first thing that happens on a conversion-first website engagement and the thing that keeps happening after: the run finds the problems, the board carries them to done, the next run confirms the fix. It ships inside SharpOS with every subscription.
The question
The audit-as-PDF shape has survived a long time, and I suspect it's because a document feels like something you handed over, while a queue feels like an admission that the work isn't finished. If you've moved audit findings into a tracked system (tickets, cards, anything with a status), what happened to the findings nobody would have fixed from the PDF? And what did you lose by dropping the document?
This is part of SharpOS, surface by surface. Part 1, with the full replacement ledger: We replaced a 12-tool client stack with one workspace we built.
Top comments (0)