Lead with traffic at risk, not issue count
A technical SEO audit checks whether search engines can crawl, index, render, and rank your pages, then fixes what is broken in priority order. Most audits fail at that last step. A crawler spits out 300 warnings, you paste them into a spreadsheet, and you spend a week fixing 900 missing alt tags while a single broken canonical on your product template quietly deindexes 40% of your catalog.
The discipline that fixes this is scoring severity by affected-URL share. One canonical mistake on a template that generates 40% of your indexed URLs outweighs every cosmetic warning combined. Run every finding through four questions in order: can Google reach it, will Google index it, will Google rank it, and only then, is it polished. Work top-down. A technical SEO audit sits inside the broader practice of technical SEO; the audit is how you find the specific things worth fixing.
Step 1: Can Google reach it? (crawl and log files)
Start with reachability, because nothing downstream matters if Googlebot never arrives. You need two data sources that most people never reconcile: a crawler's view of your site and Google's actual crawl behavior.
Run a full crawl with a tool that follows internal links the way a bot does, and record the total count of indexable URLs it discovers. Then open the Crawl Stats report in Search Console (Settings, then Crawl stats) to see how often Googlebot visits and where it spends its requests. Google's own Crawl Stats documentation notes the report is aimed at advanced users and covers total requests, response codes, and crawl purpose. If 60% of Googlebot's requests hit paginated filter URLs or an old parameter-based faceted navigation, that budget is leaking away from pages you care about. The mechanics of discovery and crawl scheduling are covered in crawling and indexing.
Log file analysis is the deepest layer. Your server logs record every real Googlebot hit with a timestamp and status code. Parse them and you can answer questions a crawler cannot: which URLs Googlebot never touches, which it hammers daily, how many requests return 404 or 500. Crawl budget matters most on large sites; Google defines it as the URLs it can and wants to crawl, and its crawl budget guidance is aimed at sites over 10,000 frequently changing pages. On those sites, logs are where you discover Google wasting a third of its budget on a redirect chain nobody remembered.
Two files gate reachability before anything else:
- Your robots.txt file can disallow entire directories by accident. A single stray Disallow line that blocks /products/ is the most expensive one-line mistake in SEO.
- Your XML sitemap tells Google which URLs you consider canonical and worth crawling. A sitemap full of redirects, 404s, or noindexed URLs sends mixed signals and wastes crawl budget.
Step 2: Will Google index it? (status codes, canonicals, noindex)
Reaching a page and indexing it are different questions. This is where the worked example lives.
Take your crawler's count of indexable URLs and compare it to Search Console's Page indexing report. Watch the "Discovered — currently not indexed" bucket. Google's Page indexing documentation describes these as URLs Google found but has not crawled yet, often because crawling them was expected to overload the site, so the crawl got rescheduled. When that bucket is large and growing, it usually means one of two things: crawl budget is going elsewhere (back to Step 1), or you are generating thousands of thin, near-duplicate URLs Google has decided are not worth the trip.
Here is the reconciliation in practice. Say your crawler reports 12,000 indexable URLs but Search Console shows 7,000 indexed, with 4,000 in "Discovered — currently not indexed." That 4,000 is your leak. Sample 20 of those URLs. If they are all filter combinations like /shoes?color=red&size=9, the fix is to stop generating crawlable links to them, not to beg Google to index them.
Then check the signals that block or redirect indexing:
| Signal | What to check | Common failure |
|---|---|---|
| HTTP status | 200 for pages that should index | Soft 404s: a 200 response with empty or error content |
| Redirects | 301 for permanent moves | Chains of 3+ hops, or 302s used where 301 belongs |
| Canonical | Points to the preferred URL | Template bug pointing every page at the homepage |
| Noindex | Present only where intended | A staging noindex tag shipped to production |
Google follows up to 10 redirect hops and treats a 301 as a strong signal but a 302 as a weak one, per Google's guidance on HTTP status codes. A page returning 4xx gets dropped from the index; 5xx errors make Google slow its crawl and eventually drop content too. Canonical tags are the single highest-leverage template-level check in the whole audit, because one bad canonical multiplies across every URL that template renders.
Step 3: Will Google rank it? (render and content)
A page can be crawled and indexed and still rank nowhere, because Google cannot see the content or the content is not good enough.
Use the URL Inspection tool in Search Console to fetch a live version and view the rendered HTML, as described in Google's URL Inspection documentation. Compare the rendered output to your source. If your main content, internal links, or headings only appear after JavaScript runs and they are missing from the rendered HTML, you have a rendering problem. Sites built on client-side frameworks hit this constantly; the fixes are covered in JavaScript SEO.
Rendering also determines whether Google measures your page as fast or slow. Core Web Vitals are a confirmed ranking signal, so audit them with field data, not just lab scores. Google's thresholds, per web.dev's Core Web Vitals guide, are LCP under 2.5 seconds, INP at or below 200 milliseconds, and CLS at or below 0.1. Our guides to Core Web Vitals and practical ways to improve page speed walk through the metrics and fixes. Layout shift and slow Largest Contentful Paint on a template powering thousands of URLs is, again, a traffic-at-risk problem, not a one-page problem.
Content-level checks here: title tags and H1s that actually target the query, internal linking that passes authority to money pages, and structured data validity. If you run multiple language or country versions, hreflang errors quietly cannibalize rankings across regions, and they stay invisible until you audit them deliberately. This matters for teams serving distinct city-level or vernacular SERPs, where a Hindi or Tamil variant can outrank or undercut its English counterpart depending on how cleanly the hreflang cluster resolves.
Step 4: Polish
Everything that survives the first three filters lands here: missing alt text, minor heading-hierarchy issues, schema markup you could add for richer results, image compression on low-traffic pages. These are real improvements. They are also the things you do after the template canonical is fixed, not instead of it. Batch them and clear them in a maintenance sprint.
Turning the audit into a prioritized report
The output of a good audit is not a list of 300 problems. It is a ranked report where the top item reads "canonical bug affecting 4,800 URLs (38% of indexed pages)" and the missing alt tags sit near the bottom with their real weight. Ranking by affected-URL share is what DeployFlare's site audit produces automatically. It crawls your site, reconciles against your connected Search Console data, and orders findings by how much of your indexed footprint each one touches, instead of dumping a flat severity list you re-sort by hand. It runs from ₹499/month, billed in INR with UPI and GST, and you can see how it stacks up against the heavyweights on our Ahrefs alternative page.
Run a full technical SEO audit quarterly, and a lighter crawl-plus-indexing check monthly if you publish frequently or change the site often. The four-question flow keeps you honest: reach, index, rank, polish, in that order, weighted by traffic at risk.