How to Do an SEO Audit (Step-by-Step, No Template Sold Separately)

Most people ask how to do an SEO audit expecting a checklist they can run through in an afternoon and call it done. It doesn’t work that way, and I’ve seen enough half-finished audits gathering dust in a Google Doc to know why. This post is the actual order I check things in, which reports I pull from Search Console, and how I decide what to fix first once I’ve found a pile of issues.

What an SEO Audit Actually Checks (And Skips)

An audit is a diagnosis, not a strategy document. The goal of an SEO audit is to find what’s actively costing you rankings or traffic right now, not to produce a 40-page report nobody reads. That means it covers crawlability, indexation, technical health, on-page quality, content, and backlinks, roughly in that order of how likely each one is to be silently sabotaging everything downstream of it.

It does not cover keyword strategy, content planning, or link building execution. Those are separate projects that an audit’s findings feed into, not part of the audit itself. Conflating the two is how audits balloon into six-week engagements that never ship a fix.

A real example: a SaaS site I audited had a founder convinced the problem was thin blog content, because that’s what a generic template pointed them to first. The actual cause turned out to be a broken canonical tag pushed in a template update months earlier, silently telling Google that every pricing-page variant was a duplicate of the homepage. No amount of content strategy would have fixed that; the audit’s whole value was finding the actual mechanism instead of the assumed one.

What You Need Open Before You Start

You need four things open before you touch a single page: Google Search Console, an analytics tool (GA4 or whatever the site actually uses), a crawler (Screaming Frog is what I reach for first, Sitebulb works too), and the site’s actual robots.txt and XML sitemap in separate tabs. Skipping the crawler and trying to eyeball technical issues page by page is the single biggest time sink I’ve watched people fall into.

Make sure you actually have owner or full-user access to Search Console, not just a shared export someone sent over. A read-only export can’t answer a follow-up question once you spot something odd, and I’ve had entire audits stall for days waiting on someone else to pull one more filtered view.

Configure the crawler to render JavaScript before you start crawling too, not just fetch raw HTML, since a site built on a JS framework can look completely different to a renderer than it does to a basic HTML fetch.

Step 1: Confirm Google Can Actually Crawl and Index the Site

Before anything else, check whether Google can even see the pages you care about. Pull up Search Console’s Page Indexing report and look at the ratio of indexed to non-indexed pages, then click into the non-indexed bucket and read the actual reasons Google gives, not just the count.

“Discovered, currently not indexed” and “Crawled, currently not indexed” are the two statuses that matter most, and they mean different things. The first means Google hasn’t gotten around to crawling the URL yet, usually a crawl-budget or internal-linking problem. The second means Google crawled it and chose not to index it, usually a content-quality or duplication problem. Treating both the same way is a common audit mistake I’ve corrected more than once.

Cross-check a handful of URLs individually with the URL Inspection tool, since the bulk report can lag behind the live crawl state by a few days. Also check the Crawl Stats report under Settings for a spike in 5xx errors or a sudden drop in crawl requests, both of which point to a server or hosting issue rather than a content one.

Open the robots.txt file directly in a browser too, not just Search Console’s robots.txt tester. I’ve audited sites where a staging-environment robots.txt got pushed to production during a deploy and quietly blocked the whole site from crawling for weeks before anyone noticed the traffic graph. Check the sitemap the same way: confirm it only lists canonical, indexable URLs, since a bloated sitemap full of redirected or noindexed pages actively wastes Google’s attention on the site.

The Crawl Data Search Console Doesn’t Actually Give You

Search Console’s Crawl Stats report is sampled and aggregated, not raw. Server log files are the only ground truth for what Googlebot actually requested, when, and how often, and most DIY audits skip them entirely because they require server or CDN access most people don’t think to ask for. I pull at least two to four weeks of raw access logs, filter to verified Googlebot user agents by reverse DNS, and group hits by URL pattern.

What this actually surfaces that Search Console won’t: which URL patterns are eating a disproportionate share of crawl budget relative to how much they matter (faceted filter combinations on an e-commerce site are the classic offender), how long it’s actually taking Googlebot to revisit pages after they change, and whether a specific template is getting crawled at all versus just appearing in the sitemap.

On one mid-sized site I worked on, log analysis showed Googlebot spending well over half its crawl budget on parameterized search-result URLs that were already noindexed, meaning that budget was doing nothing for the pages that actually needed it.

This step is genuinely optional for a small brochure site with a few dozen pages. It stops being optional the moment a site has thousands of URLs, faceted navigation, or a history of indexation issues that the standard Search Console reports haven’t explained.

Step 2: Technical Health, Speed, and Core Web Vitals

This is where the crawler earns its keep. Run a full site crawl and pull the redirect chains, broken internal links, duplicate title tags, and missing or duplicate canonical tags into one spreadsheet. Redirect chains longer than two hops are worth flattening on sight; they waste crawl budget and dilute a small amount of link equity at every extra hop.

I go into the mechanics of crawl budget, canonicals, and sitemap structure in more depth in my breakdown of how crawling and indexing actually work, so I won’t re-explain the fundamentals here. An audit’s job is to apply that knowledge to this specific site’s crawl data, not re-teach the mechanism.

Check Core Web Vitals next, both the field data in Search Console’s report and a fresh lab test on your two or three highest-traffic templates (home, a category page, a product or article page). A site can pass Core Web Vitals in aggregate while its highest-traffic template still fails, because Search Console’s field data blends every URL together.

I’ve walked through what actually moves the needle on LCP, INP, and CLS in a separate post on Core Web Vitals if you need the deeper technical detail on any of the three metrics.

Structured Data and Mobile Rendering

Spot-check schema markup on your key templates with Search Console’s Rich Results Test, not just a browser extension, since Google’s own validator catches implementation errors that third-party tools miss. I cover the mechanics of building and validating custom schema in my schema markup guide. Also confirm mobile rendering matches desktop; a template that hides content behind a mobile accordion or lazy-loads it in a way Googlebot can’t trigger will quietly lose indexation for that content.

If the site runs multiple language or country versions, check the hreflang error report here too. A broken hreflang cluster is one of the sneakier findings in an audit, since it typically shows up as one language version losing rankings for no visible on-page reason, while the actual cause is a mismatched or missing return tag on the pages it’s supposed to be linked to.

For a JavaScript-heavy site, also compare the rendered DOM Googlebot sees (via the URL Inspection tool’s rendered HTML) against what a plain view-source shows. A gap between the two, content present in the rendered version but missing from the raw HTML, means Google is relying entirely on successful JS execution to see that content at all, which is a real risk on any site with inconsistent rendering performance.

Step 3: On-Page and Content Quality

Pull every page’s title tag, meta description, H1, and word count into the same spreadsheet from Step 2. Flag anything under roughly 300 words on a page meant to rank for a competitive term, anything with a missing or duplicate H1, and anything where the title tag doesn’t actually match search intent for its target query.

Thin or duplicate content is usually the real reason behind a “Crawled, currently not indexed” status, not a technical bug. Google increasingly treats near-duplicate pages, thin category pages, and content clearly written for a keyword rather than a reader as not worth an index slot. The fix is consolidation or a genuine rewrite, not a technical patch.

I’ve covered the specific elements that move rankings, title structure, header hierarchy, keyword placement, in a full on-page SEO breakdown, so use that as the reference checklist while you’re scoring each page here.

While you’re in that spreadsheet, run a keyword cannibalization check: sort by target keyword and flag any term where two or more URLs are both trying to rank for it. This is one of the most common issues I find on sites with several years of published content, and it’s invisible unless you deliberately look for it, since neither page is technically broken.

This is also where I flag content for pruning, not just rewriting. Old, thin, or outdated pages that have earned zero organic clicks in the last 12 months per the Performance report and don’t serve a real internal-linking or informational purpose are dragging on the site’s overall quality signal. Consolidating three thin overlapping posts into one genuinely useful page, with a redirect from the two removed URLs, is often a bigger win than editing any one of them individually.

Step 4: Backlink Profile and Off-Site Signals

Pull the site’s backlink profile from Search Console’s Links report and cross-check it against a third-party tool (Ahrefs or Semrush) since Search Console only samples a subset of known links. Look for a sudden spike in low-quality referring domains, which usually means either a negative SEO attempt or leftover links from an old guest-post campaign that’s aged badly.

Check anchor text distribution too. A backlink profile where the exact-match keyword anchor makes up more than roughly 5 to 10 percent of total anchors is a genuine over-optimization flag worth documenting, even if it hasn’t triggered a manual action yet.

A disavow file only protects you if it’s actually kept current, not just submitted once. Check the site’s existing disavow file too, if one exists, against the current link profile. I’ve found disavow files left over from a link-removal campaign years earlier that were disavowing domains no longer even linking to the site, doing nothing, while genuinely toxic newer links went untouched because nobody had revisited the file since.

Step 5: Search Console Performance Diagnostics

This is the step people skip because it takes longer than a technical crawl, and it’s the one that tells you what’s actually happening with real users. Pull the Performance report over a 16-month window if the property has that much history, and compare the audit period against the same months a year earlier, not just the prior 30 days, to separate a real problem from normal seasonality.

Segment by device, country, and search type before you segment by page. A drop that’s isolated to mobile devices in one country almost always points to something specific, like a broken mobile template or a lost featured snippet in that market, rather than a site-wide penalty.

Google’s own guidance on debugging a traffic drop walks through this same segment-first approach, comparing similar time periods and checking for a corresponding spike in Page Indexing or Crawl Stats issues before assuming an algorithmic cause, and it’s worth reading in full before you draw a conclusion from a single chart.

At the query level, sort by impressions and look for queries with a high impression count but a CTR well below what that position normally gets. That gap usually means the title tag or meta description isn’t matching what the searcher expects to see, which is a quick on-page fix rather than a ranking problem at all. I also check for queries where position has slipped but impressions haven’t, since that pattern points to a competitor improvement rather than anything wrong on this site.

Split branded from non-branded queries before drawing any conclusion about overall performance. A site can show flat or even growing total clicks while its non-branded, actual-SEO-driven traffic is quietly declining, entirely hidden by branded search growth from a marketing campaign running elsewhere. I’ve caught this exact pattern more than once on sites where a paid brand campaign was masking a real organic ranking problem underneath it.

Common Mistakes I See in DIY Audits

Almost every DIY audit I’ve reviewed makes the same handful of mistakes, and they’re process errors, not knowledge gaps. The five below cost me the most time to unwind on other people’s work before I started running audits this way myself.

• Treating every non-indexed page the same way instead of reading Search Console’s actual reason for each one
• Skipping server log analysis entirely, even on large sites where crawl budget is a genuine constraint
• Fixing technical issues before checking whether thin or duplicate content is the real cause
• Comparing a traffic drop to the prior 30 days instead of the same period a year earlier
• Never revisiting an old disavow file once it’s been submitted

How I Prioritize What an Audit Turns Up

Every audit surfaces more issues than anyone has time to fix at once. I score each finding on impact and effort, then work the high-impact, low-effort quadrant first, always, regardless of how long the list of smaller technical nitpicks gets.

Issue type	Typical impact	Typical fix effort	Fix priority
Indexation errors on money pages	High	Low to medium	First
Redirect chains and broken internal links	Medium	Low	First
Thin or duplicate content	High	High	Second
Core Web Vitals failures on key templates	Medium to high	Medium to high	Second
Missing or invalid schema	Low to medium	Low	Third
Low-quality backlinks	Low unless flagged manually	Medium	Third

Detailed.com’s own public case study on running high-volume, low-cost SEO audits makes a point I largely agree with: the audits that actually produce ranking recovery are the ones that fix a small number of high-impact issues fast, not the ones that document every possible problem exhaustively before touching anything.

I’d add one caveat to that table: effort estimates shift depending on who owns the fix. A redirect chain that’s a five-minute change for a developer with direct server access can sit untouched for months if it instead needs to go through an agency ticket queue. Score effort against the actual team doing the work, not against an abstract difficulty scale, or the priority order will look right on paper and fail in practice.

How Often You Actually Need to Re-Audit

A full audit, all five steps, makes sense once or twice a year for most sites, plus an ad hoc one any time there’s an unexplained traffic drop or right after a major site migration or redesign. Running a full audit every month is usually wasted effort, because most of what it would catch, new broken links, new duplicate titles, is better handled by lightweight recurring monitoring instead.

What I do recommend monthly is a quick pass through just the Page Indexing and Crawl Stats reports, five minutes, to catch a new spike in errors before it compounds into something a full audit would need to untangle later.

A migration or redesign is the one case where I run the full audit before the change goes live, not just after. The single most common cause of a post-migration traffic collapse is an incomplete redirect map, not anything algorithmic, and catching missing redirects in a pre-launch audit against the old site’s full URL list is far cheaper than diagnosing the drop three weeks later.

A New Site Needs a Different Audit Than an Established One

Everything above assumes a site with real crawl and Performance history to look at. A site under six months old won’t have enough Search Console data for a meaningful traffic-drop investigation, and its audit should weight much more heavily toward Steps 1 through 3, crawlability, technical setup, and on-page fundamentals, since there’s no historical signal to diagnose yet.

For a new site, the most valuable audit finding is almost always a structural one: a missing XML sitemap submission, an accidental sitewide noindex tag left over from staging, or an internal linking structure that buries key pages four or five clicks deep. These are the kind of foundational errors that, left uncorrected, will suppress every later SEO effort on the site regardless of how much content or link building follows.

The Audit Checklist

• Search Console Page Indexing report reviewed, non-indexed reasons read individually, not just counted
• Full crawler pass for redirect chains, broken links, and duplicate titles or canonicals
• Core Web Vitals field data checked per template, not just site-wide average
• Schema validated with Search Console’s Rich Results Test on every key template
• Thin or duplicate content flagged from the on-page spreadsheet, not guessed at
• Backlink profile cross-checked against a third-party tool for anchor text over-optimization
• Performance report reviewed over 16 months, segmented by device and country before by page
• Findings scored by impact and effort, high-impact and low-effort fixed first

None of this fits on a single template you can resell to every client with the fields swapped out, and that’s the actual point. An SEO audit that’s genuinely useful reflects the specific way a specific site is broken, and the order above is a process for finding that, not a form to fill in.

If I had to compress all of this into one habit worth keeping: read the actual reason behind every report before acting on the summary number. Search Console, a crawler, and a log file all tell you what is happening; only reading into the specifics tells you why, and the why is the only part of an SEO audit that actually points to a fix.