An SEO audit is a structured review of everything that affects a site’s ability to rank: technical health (crawlability, speed, indexing), on-page factors (titles, headings, content quality), off-site signals (backlinks, mentions), and, for local businesses, listing consistency. The output should be a prioritized list of specific fixes, not a 40-page PDF of every issue a tool can flag. The categories are well documented; what most explanations skip is how to decide which of the 200 flagged issues to fix first, and that most performance and uptime findings are hosting problems, not content problems.
Every top result defines an SEO audit the same way and lists the same four categories. None of them tell you what to do with the output: a crawl tool routinely returns hundreds of “issues,” most of them trivial, a handful of them the actual reason rankings are flat. This post gives the categories briefly, then the part that is missing, a way to prioritize the list an audit produces, and where the findings that mention speed or downtime actually get fixed.
Table of contents
- The four categories an audit actually covers
- What the tools actually show you
- How to prioritize 200 flagged issues
- Technical findings that are actually hosting problems
- Running a basic audit yourself
- What a good audit deliverable looks like
- How this fits the rest of the stack
- FAQ
The four categories an audit actually covers
A comprehensive SEO audit checks four layers, and skipping any one of them leaves a blind spot.
- Technical. Crawlability, indexing status, site speed, mobile usability, HTTPS, structured data, and duplicate content caused by URL parameters or missing canonicals.
- On-page. Title tags, headings, content quality and depth relative to competing pages, internal linking, and image optimization.
- Off-site. Backlink profile: quantity, quality, anchor text distribution, and any toxic links worth disavowing.
- Local (if applicable). Google Business Profile completeness, NAP (name, address, phone) consistency across directories, and review volume and response rate.
A tool-driven crawl covers technical and on-page thoroughly. Off-site and local usually need a separate backlink tool and manual directory checks, which is why a single automated report rarely tells the whole story.
What the tools actually show you
A crawler like Screaming Frog, Ahrefs’ Site Audit, or Search Console’s own reports will return a list of URLs against each check: missing title, thin content, broken link, slow load, no canonical, blocked by robots.txt. This is a symptom list, not a diagnosis.
The tool has no idea which of these pages drive revenue, which ones are already ranking fine despite the flagged issue, or which fix will move a needle anyone cares about. That judgment is the part of an audit a tool cannot do, and it is also the part most audit guides skip in favor of listing more categories a tool can check.
Read the raw output as a starting inventory, not a to-do list in the order the tool printed it.
How to prioritize 200 flagged issues
Sort by two axes: how many pages or how much traffic the issue touches, and how cheap the fix is. Four buckets fall out of that:
- High impact, cheap fix. A sitewide canonical bug, a broken sitemap, a redirect chain on the homepage. Fix these first; they move every page at once.
- High impact, expensive fix. Thin content on pages that should rank for valuable terms. Plan these as a content project, not a quick pass.
- Low impact, cheap fix. Missing alt text on a handful of images. Batch these, do not let them block the report.
- Low impact, expensive fix. A full information architecture rebuild for marginal gain. Usually not worth doing on its own.
This ordering turns a 200-item spreadsheet into a week of real work instead of a permanent backlog nobody starts.
Technical findings that are actually hosting problems
A meaningful share of what a technical audit flags is not a content or markup issue at all. Slow Time to First Byte, inconsistent uptime, and a server that cannot handle a traffic spike without timing out all show up as “technical SEO issues,” and none of them get fixed by editing a page.
Time to First Byte over 600ms, a common audit flag, usually traces back to the server: no caching layer, an underpowered plan, or a database query running on every request instead of being cached. Downtime during a crawl or an audit re-run shows up as intermittent 5xx errors, which search engines read as an unreliable site and crawl less aggressively as a result.
If the audit’s technical section keeps surfacing the same speed or reliability flag after the obvious content fixes are done, the next fix is a hosting decision, not another content pass.
Running a basic audit yourself
A useful first pass does not require a paid tool. Google Search Console is free and covers indexing status, mobile usability, and Core Web Vitals directly from Google’s own data, which is more authoritative than a third-party crawler’s estimate.
PageSpeed Insights gives a per-URL breakdown of what is slowing a page down, down to which specific script or image is the bottleneck. A manual pass through the top twenty pages by traffic, checking title uniqueness, one H1, and working internal links, catches most of the on-page issues a paid crawler would also flag.
Save the paid tools for backlink analysis and full-site crawls once the free, high-signal checks are handled. That order gets the free wins fixed before spending on a report that will mostly confirm them.
What a good audit deliverable looks like
The output should be short enough to act on: a prioritized list, grouped by the four buckets above, with an owner and an estimated effort for each item, not a raw export of every flag a crawler produced.
A good audit also states what is already working, so nobody “fixes” a page that is ranking fine and accidentally breaks it. And it separates one-time fixes (a broken canonical) from ongoing practices (checking new pages before publishing), because an audit is a snapshot and the site keeps changing after it is delivered.
How this fits the rest of the stack
An audit is only useful if the technical findings actually get fixed, and the ones that trace back to server response time or uptime need a hosting change, not another content edit. Model what a faster plan or a managed database would cost against the traffic the audit says those pages get, using the RunxBuild hosting calculator. Static sites on RunxBuild covers the caching and build path that keeps Time to First Byte low without a manual tuning project, and the dashboard shows the metrics that confirm whether the fix worked.
Useful related references:
- Onsite SEO: The Full Checklist, and Where It Actually Differs From On-Page
- Offsite SEO: The Off-Page Levers, and the On-Server Ones People Forget
- Real Estate SEO: The Checklist That Actually Moves Local Rankings
- Static sites on RunxBuild
FAQ
What does an SEO audit check?
A full audit checks technical health (crawlability, indexing, speed, mobile usability), on-page factors (titles, headings, content quality, internal links), off-site signals (backlink quality and quantity), and for local businesses, listing consistency across directories and Google Business Profile.
How often should you do an SEO audit?
A full audit once or twice a year is enough for most sites, with lighter monthly checks on Search Console for indexing errors and Core Web Vitals regressions in between. Sites publishing content weekly benefit from a quarterly on-page pass to catch duplicate titles and thin pages early.
Can I do an SEO audit myself for free?
Yes, for the majority of it. Google Search Console covers indexing, mobile usability, and Core Web Vitals at no cost, and PageSpeed Insights diagnoses speed issues per URL. Paid crawlers add convenience and backlink data, but the highest-impact technical checks are free.
What is the difference between a technical SEO audit and a full SEO audit?
A technical audit covers crawlability, indexing, site speed, and markup issues only. A full audit adds on-page content quality and off-site backlink analysis on top, giving a complete picture instead of just the infrastructure layer.
Why does my SEO audit keep flagging slow page speed?
Because the underlying cause has not been fixed. Recurring speed flags usually trace to server response time, uncompressed images, or render-blocking scripts. If content-side fixes have not moved the number, the next step is a hosting or caching change rather than another content pass.