Every quarter we tend to do the same thing. Someone runs an audit on a client site, exports 600 issues to a spreadsheet, fixes a handful, and files the rest. Three months later the next audit produces another 600-row export. Nobody can say which issues are new, which ones were fixed, or whether the site is better than it was.
The audit isn't the problem. The problem is that an audit is a snapshot, and technical SEO is ongoing work. A snapshot can't tell you what changed, who's working on what, or whether you're winning.
What actually moves a site forward is a living list of known issues: checked continuously, remembered between runs, and organized so the fixes that matter most sit at the top.
Why one-off audits stall
Point-in-time audits fail in predictable ways:
- No memory. Each audit starts from zero. An issue fixed in March and broken again in May looks exactly the same as one that was never touched.
- No sense of scale. Six hundred rows is a wall, not a plan. The spreadsheet doesn't show that 400 of them come from one template.
- No owner. The export lands in someone's downloads folder, and the work never makes it into a backlog.
- No progress to show. The client sees a score, not the twelve things you fixed this month.
The fix is to stop treating SEO as an event and start treating it as a backlog. Triage every issue by impact and effort. Trace it back to the template that causes it. Fix the cause, not the 200 symptoms.
Two views of the same list
A working list needs two ways in, because there are two different questions you're trying to answer.
By issue type: "What's the one fix that clears the most?"
Most technical SEO problems aren't page problems. They're template problems. A missing meta description on 200 blog posts is one fix in one template. An oversized hero image on every product page is one fix in one component.
Google thinks about it the same way. Search Console's Core Web Vitals report groups pages "that have a similar user experience," on the assumption that their problems share "the same underlying reasons." Group your issues by type and the biggest wins become obvious.
By page: "Is the page that makes money healthy?"
The pricing page, the top landing page and the contact form matter more than an old blog archive. Viewing the list page by page lets you check the money pages first, whatever the totals say.
Run the list like an operations dashboard
A list only becomes a working list when there's a rhythm around it. Use the same one you'd use for any part of a client's website operations: know what's healthy, what's at risk, what changed, who's been told, and what the client should hear.
- What's healthy. Pages and issue types with nothing open are done. Leave them alone until something changes.
- What's at risk. Critical issues on important pages go to the top: a noindex on a key page, broken internal links, a big performance drop on a revenue template.
- What changed. Every run should tell you three things: what's new, what's still open, and what's been resolved since last time. That's how you tell a regression from an old issue, and how you prove a fix actually worked.
- Who's been told. Urgent problems should reach someone straight away. Lower-priority advisories belong in a daily digest that gets read, not a flood of alerts that gets muted.
- What the client hears. "We fixed 140 issues this month, the product template now passes, and two new issues appeared after the plugin update" is a far better conversation than "your score is 78."
Then work down the list. Export it, work through it manually or pass it off to your agents. Fix the issues, let the next run confirm it, and watch the list get shorter.
Progress you can show
This is where a living list pays for itself on a care plan. Because every issue is tracked from the run it first appeared to the run it was resolved, the list doubles as a record of work done.
Over a few months you can see the open count fall, issue types disappear completely, and new problems get caught within a run of appearing. That's the story clients are paying for, and a one-off audit can't tell it.
How DownCTL handles it
DownCTL runs Lighthouse across a rotating set of each site's pages, not just the homepage, alongside its crawl and sitemap checks. Everything it finds goes into one list of known issues:
- Remembered between runs. Each issue is deduplicated and tracked from first seen to resolved, so you always know what's new, what's still open and what's been fixed.
- Grouped by issue type and by page. Find the template fix that clears hundreds of pages, or focus on the pages that matter most.
- Alerts for the urgent, a digest for the rest. Critical findings notify you straight away. Advisories are batched into a daily digest.
- Acknowledge what you've seen. Mark issues as known so the list only shows what still needs a decision.
- Fix guidance attached. Each Lighthouse finding includes the measured value, the passing target and recommended fixes.
Stop starting from zero every quarter. Start working down the list and show your clients it getting shorter.