Start here before you open any tool
Every audit I've ever done that went wrong started the same way: I opened Screaming Frog before I understood the site's business context. Technical SEO without context is just a list of flags with no way to prioritise them. Before you crawl anything, answer three questions. What's the site's revenue model — is traffic directly tied to income, or is it indirect? What's the most important page type — product pages, blog posts, service pages, something else? And what's changed recently — a migration, a redesign, a new CMS, a Google algorithm update that hit them?
Those three answers will tell you where to start and where to spend most of your time. An ecommerce site losing rankings on category pages and a SaaS blog losing traffic on informational posts are completely different problems, even if they look identical in Google Search Console.
Section 1 — Crawlability
Google can only rank what it can find. Crawlability issues are quiet — they don't throw errors, they just prevent pages from getting indexed and nobody notices until traffic is already gone.
Check 1: Robots.txt
Fetch the robots.txt file manually first. Don't trust an automated tool to interpret it correctly. Look for directives that are blocking pages they shouldn't be — I've seen entire subdirectories blocked by a single missing slash. Check that the sitemap is referenced at the bottom. Check that Googlebot isn't disallowed from anything critical. If the site uses JavaScript-heavy rendering, confirm that Googlebot isn't blocked from the JS or CSS resources it needs to render pages properly — that one mistake has tanked rankings for sites that looked perfectly fine to a human visitor.
Use Google's own robots.txt tester in Search Console to test specific URLs against the live file. Or use my free robots.txt tester tool if you don't have Search Console access.
Check 2: XML Sitemap
Your sitemap should contain only the pages you want indexed — nothing more. That sounds obvious until you look at the sitemaps for most CMS-generated sites and find tag archive pages, author pages, paginated URLs, and parameter-based URLs all sitting there competing with your real content. Canonicalised pages don't belong in sitemaps. Noindexed pages definitely don't. Redirect targets don't either. Run the sitemap URLs through a tool like Screaming Frog to check status codes — any URL returning a non-200 in your sitemap is a waste of crawl budget.
Check 3: Crawl depth
Every click it takes to reach a page from the homepage is a click Googlebot also has to take. Pages more than three clicks deep from the homepage are frequently undercrawled on smaller sites and almost never crawled on large ones. Run a site crawl and filter by click depth. Any important page — a money page, a top-performing blog post, a product category — sitting at depth 4 or beyond needs to be brought closer through internal links or navigation changes.
Section 2 — Indexation
Crawlability gets Googlebot to the page. Indexation determines whether it stays. These are different problems with different causes.
- Canonical tags Every page should have a self-referencing canonical unless it's a deliberate duplicate pointing elsewhere. Check for canonical chains — page A canonicals to B, which canonicals to C. Google may ignore the whole chain and pick its own canonical anyway.
- Noindex directives Run a crawl and filter for noindex tags. Then cross-reference with your GSC index coverage report. Any page you expect to be indexed that's showing noindex is your first problem. Any page you expect to be noindexed that IS indexed means your directives aren't being respected — usually a JS rendering issue.
- Duplicate content Parameter-based URLs, session IDs, tracking parameters, print versions, mobile subdomain versions — all of these can create duplicate content at scale. Use canonical tags to consolidate, or if they shouldn't exist at all, use disallow in robots.txt plus a URL parameter rule in GSC.
- Redirect chains and loops Every hop in a redirect chain costs crawl budget and dilutes link equity. A 301 → 301 → 301 chain should be flattened to a direct 301. Loops (A redirects to B, B redirects to A) will cause those pages to drop from the index entirely over time.
The fastest way to diagnose indexation problems is to compare your sitemap URL count against your GSC index coverage number. If GSC shows 30% fewer indexed pages than your sitemap, you have a significant indexation problem and the coverage report will tell you exactly why.
Section 3 — Core Web Vitals and Page Speed
Core Web Vitals became a ranking signal in 2021. Three years later, most sites are still failing at least one metric. The frustrating part is that the fixes aren't complicated — they're just unglamorous. No framework change required. No redesign. Just disciplined implementation of things that should have been done at build time.
LCP — Largest Contentful Paint (target: under 2.5s)
LCP measures how long it takes for the largest visible element to render — usually a hero image or an H1.
The most common cause of poor LCP is an unoptimised hero image being loaded lazily,
or a hero image that's being fetched from a different origin than the page.
Preload your LCP image. Add fetchpriority="high" to the image element.
Serve it from the same origin as the page. Compress it properly — a 400KB JPEG hero image has no excuse in 2025.
Use a CDN. These four changes alone fix LCP on the majority of sites I've worked on.
CLS — Cumulative Layout Shift (target: under 0.1)
CLS is caused by elements that don't have reserved space before they load — images without width/height attributes,
ads that inject content above existing text, fonts that swap and change text block height.
The fix is almost always the same: give every element that loads async a declared size before it appears.
If you're using web fonts, add font-display: swap and preload your font files.
If you're embedding ads or third-party widgets, wrap them in a container with a fixed height.
INP — Interaction to Next Paint (replaced FID in March 2024)
INP measures how quickly the page responds to user interactions — clicks, taps, keyboard input.
The most common culprit is long JavaScript tasks blocking the main thread.
Open Chrome DevTools, run a Performance trace while clicking around the page,
and look for tasks over 50ms. Those are your targets.
Break them up with setTimeout, move work off the main thread, and defer non-critical JS.
Section 4 — Structured Data and Schema Markup
Schema markup doesn't directly improve rankings. What it does is make your pages eligible for rich results — the star ratings, FAQ dropdowns, recipe cards, and job listings that take up dramatically more SERP real estate than a plain blue link. More real estate means more clicks, even at the same ranking position.
The schema types worth implementing depend entirely on what your pages are about. For a service business: LocalBusiness, Service, FAQPage, and Person or Organization. For a blog: Article, BreadcrumbList, and FAQPage on posts that have Q&A sections. For a SaaS: SoftwareApplication and FAQPage. For ecommerce: Product, AggregateRating, and Offer.
The most common schema errors I find in audits: using the wrong type for the content, missing required properties (which Google documents clearly in their rich results test), and marking up content that doesn't actually appear on the page — which violates Google's guidelines and can trigger a manual action. Validate everything through Google's Rich Results Test before deploying.
Section 5 — Internal Linking Architecture
Internal linking is the most underrated lever in technical SEO. It's free, it's under your complete control, and it directly impacts how Google understands the relationship between your pages and which ones it considers most important.
The principle is simple: pages that earn more internal links are treated as more authoritative. In practice, most sites have the opposite of a deliberate internal linking structure — they have a navigation menu, a footer, and whatever links writers happened to include in posts. That's not a strategy. That's randomness.
What a deliberate internal linking structure looks like: identify your five most commercially important pages. Then find every blog post, tool page, or supporting page on your site that's topically related to each of those five pages. Every one of those supporting pages should have at least one contextual internal link pointing to the relevant important page. This is the simplest version of a topical cluster strategy, and it works.
Run a site crawl and look at inlinks per page. Your most important pages should have the most internal links pointing at them. If your highest-earning service page has 3 inlinks and a blog post from 2019 has 47, you have an internal linking problem — and fixing it often produces ranking improvements within weeks.
Section 6 — The stuff people always forget
- HTTPS everywhere Not just the homepage. Every page, every asset, every resource. Mixed content warnings (HTTPS page loading HTTP assets) are both a security flag and a trust signal Google notices. Run an audit for mixed content specifically.
- Mobile usability Check GSC's mobile usability report, not just whether the site looks fine on your phone. Tap target sizes, viewport configuration, font sizes below 12px — Google's crawler is now mobile-first, meaning what it sees on mobile is what determines your ranking.
- 404 and soft 404 pages True 404s that have inbound links need redirecting. Soft 404s — pages that return a 200 status code but show "no results" or "page not found" copy — are worse, because Google wastes crawl budget fetching them and eventually devalues them. Fix them at the CMS level.
- Pagination handling If you have paginated content (blog archives, product category pages), make sure pages 2, 3, 4 are either self-canonicalised or handled with rel="next"/rel="prev" if you want them indexed. Paginated URLs leaking into your index without proper handling is a silent crawl budget drain.
- Hreflang (for multilingual sites) If you run content in multiple languages or target multiple regions, hreflang implementation errors are extremely common and extremely damaging. The tag on each page must return-link to every other language version. One broken link in the chain breaks the whole thing.
How to prioritise what you find
You will always find more issues than you can fix immediately. The question is always: what first?
I prioritise in three tiers. Tier 1 — fix this week: anything blocking indexation of important pages, critical crawl errors on revenue-generating URLs, and redirect loops or chains longer than two hops. These have a direct and often immediate impact on rankings and traffic.
Tier 2 — fix this month: Core Web Vitals improvements (these take time to propagate in CrUX data), schema markup implementation, internal linking improvements for key pages, and canonicalisation cleanup. These improve over 30–90 days.
Tier 3 — fix in the next quarter: Informational architecture improvements, content consolidation for cannibalised keywords, hreflang cleanup on larger sites. Important, but not urgent unless they're directly tied to a current traffic problem.
The most important thing about a technical audit isn't finding problems — any tool can do that. It's building a prioritised action plan that a development team can actually implement. If your audit deliverable is a spreadsheet with 200 uncategorised issues, nothing will get fixed. If it's a clear document with three tiers and business impact explained alongside each recommendation, things get fixed.
What to do next
If you've worked through this checklist and found issues — good. Finding them is the easy part. Getting them fixed in the right order, with the right technical implementation, and with proper tracking to confirm they've actually improved your rankings is where most audits fall apart.
If you want to check your metadata setup quickly, my free SEO meta analyzer tool will pull your title tag, meta description, canonical, robots directives, and Open Graph data from any URL in seconds.
And if you're dealing with a technical SEO problem that's bigger than a checklist can fix — a site migration coming up, a significant traffic drop you can't explain, or a site that's technically sound on paper but still not ranking — take a look at my technical SEO consulting service. That's exactly the kind of problem I work on.