Technical SEO audits that get implemented: fixes ranked by revenue

7 min read

Technical SEO audits that get implemented: fixes ranked by revenue

7 min read

A technical SEO audit usually fails after delivery, not during it. The crawl is thorough, the spreadsheet runs to 200 rows, and every row carries a severity label from a tool that has no idea which pages earn money. Six months later, a handful of easy fixes have shipped and the issues holding back revenue pages are still live.

The answer is not a better crawler. It is a different way of ranking the findings: by the revenue each issue puts at risk and the effort it takes to fix, with every fix written as a ticket a developer can pick up, and a re-crawl after release to prove it landed.

This article explains how we run that process, what it changes for your development budget, and how to tell whether the audit you are paying for will get implemented.

Why it matters to the business

Developer time, not ideas, is the scarce resource in most SEO programmes. When an audit arrives as a flat list, engineering teams sensibly pick the quick wins, and the quick wins are rarely the issues that cost money.

The issues that cost money are the ones that stop revenue pages being crawled, indexed or chosen as the canonical version: a noindex left on a template after a release, canonicals pointing at the wrong URL, product links that only exist after JavaScript runs. A missing alt attribute on a footer icon is a real finding, but it does not belong in the same queue.

Getting this right means the first sprint goes on the issues with the most revenue behind them, and leadership sees a short list framed in revenue at risk rather than a count of warnings. It also stops a common waste: large performance projects aimed at a perfect score. Google says it always seeks to show the most relevant content, even if the page experience is sub-par, and that good results in its Core Web Vitals report do not guarantee top rankings. Speed work is worth doing, but it has to win its place in the queue on evidence like everything else.

How we run a technical SEO audit

Every audit we run follows the same nine steps. The first and last are the ones we see skipped most often.

Build the revenue map before opening a crawler. We export twelve months of organic landing page data from GA4 (sessions, key events and revenue), join it to Search Console clicks and impressions, and group URLs by template: category, product, article, location, tool. That shows which templates carry the money, which decides where an issue matters.
Crawl the whole site twice, with and without JavaScript rendering. Google processes JavaScript sites in three phases, crawling, rendering and indexing, so we compare the raw HTML with the rendered page to find links, content or tags that only exist after scripts run. This is the core of a technical SEO review, and the part a generic technical SEO checklist covers least well.
Check what Google actually sees. We read the Page indexing report in Search Console for pages Google crawled but chose not to index, duplicates where Google picked its own canonical, and soft 404s, then use the URL Inspection tool on sample URLs from each template to compare the Google-selected canonical with the one the page declares. The Crawl Stats report adds response codes and host status for the last 90 days.
Group findings by template and root cause. Forty thousand product URLs with the same missing canonical are one bug in one template, so they become one row. This usually collapses a 200-row export into a few dozen issues a developer can reason about.
Score each issue on revenue at risk. We take the organic revenue of the affected URLs and apply a band for how directly the issue blocks it: full for pages kept out of the index, high for wrong canonicals or broken internal links to revenue pages, partial for slow templates, none for cosmetic findings. Bands rather than false precision keep the debate on the decisions that matter.
Treat page speed on evidence. We check field data in Search Console's Core Web Vitals report, which uses real-user data, against the thresholds Google publishes: Largest Contentful Paint within 2.5 seconds, Interaction to Next Paint of 200 milliseconds or less and Cumulative Layout Shift of 0.1 or less, at the 75th percentile of page loads. Interaction to Next Paint replaced First Input Delay in March 2024, so older audits may be measuring the wrong thing, and a lab score below 100 on its own is not a finding.
Score effort with the people who will do the work. The engineering lead sizes each issue as small, medium or large and flags dependencies, such as a platform release or a third-party script owner. Revenue at risk against effort gives the order: high revenue and low effort first, high revenue and high effort planned into the roadmap, low revenue parked.
Write every fix as a developer ticket. Each ticket names the template and example URLs, the current behaviour, the expected behaviour and acceptance criteria a tester can check, such as "page 2 of every category is linked with a plain HTML link and returns a 200 status". We write in the team's own tracker format and join sprint planning, rather than sending a PDF.
Re-crawl after release and confirm the fix landed. We test in staging first, kept out of Google with authentication because Google says robots.txt is not a mechanism for keeping a web page out of Google, then re-crawl the affected template on production and click Validate fix in Search Console. Page indexing validation typically takes up to about two weeks, and Core Web Vitals fixes are tracked over a 28-day monitoring period because they rely on field data, so a ticket closes when the fix is verified, not when it is merged.

How to measure it

We report the audit as a programme, not a document. For leadership, one line usually does the job: how much organic revenue sat behind the issues we found, and how much of it now sits behind issues that are fixed and verified.

What good looks like is the high-revenue bands closing first. If the easy, low-value tickets are shipping and the top of the list is not, the process is not working, whatever the issue count says. The measures underneath:

Revenue at risk resolved: the share of scored revenue at risk attached to issues that are fixed and verified in production.
Implementation rate: tickets verified against tickets raised, split by priority band, so you can see whether the top of the list ships first.
Time to verified fix: from ticket raised to confirmed in a re-crawl, which shows where the process stalls.
Index coverage of revenue templates: indexed URLs per template in the Page indexing report, against the number you expect to be indexed.
Commercial check: organic revenue on fixed templates against untouched ones, year on year.

When it does not fit, and the mistakes we see most

Revenue scoring needs revenue data. A new site, or one with almost no organic traffic, has nothing to score, so we prioritise on search demand for the pages that should rank instead. For lead generation sites, we use pipeline value per lead in place of revenue.

Site migrations need their own process. Scoring an audit is no substitute for a full redirect map and pre-launch testing, and on enterprise sites we run the two separately. The mistakes we see most:

Using a crawler's severity labels as the priority order.
Reporting the number of issues found instead of the revenue behind them.
Chasing a perfect lab speed score when the field data in Search Console already passes.
Using robots.txt to remove pages from the index, when a blocked URL can still be indexed if other sites link to it.
Delivering the audit as a PDF with no owner for each fix.
Closing tickets on merge without a re-crawl, so regressions in later releases go unnoticed.

Questions to ask your team or agency

Ask these before you fund the next audit. Our organic search team works this way alongside in-house developers, to their sprint cycle.

Which of these issues sit on the templates that earn most of our organic revenue, and how much revenue is behind each one?
Who sized the effort, and do our developers agree with it?
Can a developer pick up each fix without a meeting to explain it?
How will we know a fix has landed in production, and who checks?
Which issues are we choosing not to fix, and why?

Frequently asked questions

What is included in a technical SEO audit?

A technical SEO audit checks whether search engines can crawl, render and index a site's important pages and choose the right version of each. It covers crawlability, JavaScript rendering, indexing status, canonical tags, redirects, status codes, internal links, structured data, page speed and Core Web Vitals. A useful audit also ranks every issue by the revenue it puts at risk and the effort needed to fix it.

How often should you run a technical SEO audit?

Run a full technical SEO audit once a year, before any replatform or redesign, and after a sudden drop in organic traffic. Between full audits, a lighter monthly crawl of the main page templates catches regressions from new releases, which is a common way fixed issues come back. Review Search Console's Page indexing report every month as well, since it shows what Google has and has not indexed.

Do Core Web Vitals affect Google rankings?

Google says good Core Web Vitals align with what its core ranking systems seek to reward, and recommends site owners achieve them. It also says it always seeks to show the most relevant content even when page experience is sub-par, and that good scores do not guarantee top rankings. Treat them as one factor among many, worth fixing where real-user data shows a template failing.