How to run a technical SEO audit
An audit is only useful if it ends in changes that shipped. The order below is built around that: it front-loads the findings that unblock everything else, and it groups fixes so one edit clears many pages.
Establish what is actually indexable before anything else
Begin with a single page you know well, checking robots rules, meta robots, the canonical target, and the status code. This takes a minute and calibrates everything that follows: if the basics are broken on a page you chose deliberately, they are likely broken more widely, and the audit becomes an indexability investigation rather than a general sweep.
Then crawl the whole site and separate the indexable pages from the rest. That split is the foundation of every later number. A site with 10,000 URLs of which 3,000 are indexable has a very different set of problems from one where all 10,000 are, and reporting issue counts without that denominator produces figures that sound alarming and mean nothing.
Group findings by cause, not by page
A raw audit export is a list of pages with problems, and reading it that way is how audits die: four thousand rows is not a task list, it is a reason to close the tab. Almost every large count collapses when you group by cause instead. A missing meta description on 800 pages is usually one template that does not emit one. A duplicate title on 300 pages is one generator using the same pattern. A broken link on 200 pages is one dead URL in a shared footer.
Grouped that way, a four-thousand-issue report routinely becomes fifteen or twenty actual fixes, most of them template edits. That is the difference between an audit that gets actioned and one that gets filed.
Sequence the fixes by what unblocks what
Indexability fixes go first because they gate everything: there is no point improving the content of a page while it carries a noindex. Template-level fixes come next, because their multiplier is highest and their risk is lowest, being a single edit you can verify on one page before it applies everywhere. Structural fixes such as internal linking and orphan resolution follow, since they need the indexable set to be stable first. Page-level content work comes last, on the pages that are now reachable, indexable and understood.
Verify by re-crawling, not by assuming
The step most audits skip is the one that proves anything happened. Re-crawl after the fixes ship and compare run to run. This catches two things nothing else will: fixes that did not deploy, which is more common than anyone expects, and fixes that solved the reported symptom while creating a different problem, such as a canonical correction that silently deindexed a set of pages that were ranking.
Comparing runs is also the only honest way to report progress. A single health score is a snapshot with no context. Two scores with the list of what changed between them is evidence.