Have you ever run into this: pages just won’t get indexed, rankings won’t budge no matter what, you go back and forth checking the content and find it’s actually pretty well written? Eight times out of ten it’s not a content problem — it’s a gap in the technical foundation. A technical SEO audit is like a checkup before launch and once a quarter — clear out all four layers at once: crawling, indexing, rendering, speed. Wait until traffic drops before checking, and it’ll cost you three times the effort.
An audit really just follows four layers: crawlable, indexable, renderable, fast. Miss any one layer, and no matter how good the content is, you won’t get rankings. I’ve saved the 12 items below as a template — go through them one by one before every major change, saves ten times the time vs. digging through logs after the fact. This article breaks it down layer by layer for you.
Crawling layer: first let crawlers in the door
If crawlers can’t even get in the door, the other three layers are just talk. This layer checks three things: is robots.txt blocking anything by mistake, are important pages reachable via links, are status codes stable.
The most common screw-up is writing Disallow too broadly: you want to block the backend so you write Disallow: /wp-, and end up blocking CSS and JS in /wp-content/ too — page rendering breaks, rankings drop right along with it. After writing the rules, use the testing tool to pick ten URLs and verify each one. Don’t skip this — I’ve stepped in this pit before.
Reachability is just as critical. Orphan pages with no internal links pointing to them, even if crawled, get no authority. Use a crawling tool to list pages with zero inbound links and handle them one by one. On the server side, keep an eye on 5xx rate — frequent 5xx makes Googlebot actively slow down, keep it under 1% in the last 7 days and you’re stable.
Indexing layer: let in what should be indexed, keep out what shouldn’t
Getting crawled doesn’t mean getting indexed. This layer aligns four types of indexing signals: noindex, canonical, sitemap, parameter pages.
noindex most commonly goes wrong at the template level. A certain page type’s template carries noindex, and after launch that entire category disappears — while you only spot-checked the homepage. I’ve been burned by this. Do a site-wide search before launch, don’t be lazy.
There are two typical canonical mistakes: pointing to the wrong page, or pointing all paginated pages from page 2 onward back to page 1 — causing subsequent content to never get indexed. There’s only one judgment standard: point to the single version you want to rank.
| Check item | Common pit | Correct approach |
|---|---|---|
| robots.txt | Mistakenly blocks CSS/JS or entire directories | Only block paths with truly no search value |
| noindex | Template-level accidental tag, entire category disappears | Site-wide search before launch |
| canonical | Points to wrong page or over-consolidates pagination | Points to the single version you want ranking |
| sitemap | Mixed in 404, 301, noindex pages | Only include canonical pages returning 200 |
| Parameter pages | Filter combinations generate infinite URLs | Consolidate with canonical or robots |
Rendering layer: confirm the content actually gets read
Google executes JavaScript after crawling, then renders — but rendering happens in a queue. Sites heavily dependent on frontend frameworks often run into “empty shell at crawl time” — what you see fine in the browser, crawlers see as blank.
The verification method is straightforward: use URL Inspection to look at the rendered HTML, confirm three things are present: body content, internal links, structured data. If any one is missing, it means crawlers see less than you think.
Internal links are especially easy to miss. onclick or button-based navigation isn’t recognized by crawlers — it has to be an <a> tag with href. Pagination, filters, and load-more are the three places this goes wrong most often. Also confirm that frontend-injected structured data still parses after rendering.
Speed layer: three metrics and three culprits
The passing line for Core Web Vitals is: LCP under 2.5 seconds, CLS under 0.1, INP under 200 milliseconds. Remember to look at real user data, not lab scores — lab score 90 but real-world failing is way too common, don’t be fooled by lab numbers.
The culprits are almost always the same three: uncompressed above-the-fold images, render-blocking web fonts, third-party scripts loading synchronously above the fold. Fix in this order — changing the first two usually pulls LCP back to passing. The main cause of CLS is images and ad slots without reserved dimensions — adding width/height attributes solves most of it.
Compress the four layers into a checkable checklist
Knowing the four layers isn’t enough — it has to become a table you can check off item by item before launch. Save the 12 items below as a template and reuse it, go through it before every major change.
| Layer | Check item | Pass standard | How to check |
|---|---|---|---|
| Crawl | robots not blocking by mistake | Important pages and CSS/JS crawlable | robots testing tool |
| Crawl | No orphan pages | Important pages have inbound links > 0 | Site-wide crawler tool |
| Crawl | Server stable | 5xx under 1% in last 7 days | Server and monitoring logs |
| Index | No accidental noindex | Live pages all indexable | Site-wide search for noindex |
| Index | canonical correct | Points to single authoritative version | Sample check source code |
| Index | sitemap clean | Only includes 200 canonical pages | Spot-check URLs one by one |
| Index | Parameter pages consolidated | No infinite URL combinations | Coverage excluded items |
| Render | Body not purely script-injected | Rendered DOM contains body content | URL Inspection tool |
| Render | Internal links are real a tags | Extractable after rendering | View rendered HTML |
| Render | Structured data retained | Still parseable after rendering | Rich results test tool |
| Speed | LCP under 2.5 seconds | Above-the-fold images compressed | Core Web Vitals report |
| Speed | CLS under 0.1 | Images and ad slots have dimensions | Core Web Vitals report |
Three blind spots most easily missed
- Only checking homepage and category pages: list page 3, tag pages, filter pages are where long-tail keyword indexing drops hardest
- Ignoring mobile: rendering and speed under mobile viewport often differ from desktop — run both
- Only running once: assuming templates stay clean forever after being fixed — every release can introduce regressions
Recheck rhythm: monthly for the first three months on a new site or right after a major change, quarterly once stable, and run again before every major release. One more thing to note — “crawled – not currently indexed” in the coverage report usually isn’t a technical problem, it’s insufficient content value. Don’t mix them together when fixing.
Landing in five steps
- Copy the 12 items above into a table template, save in team docs, mark owners and frequency
- Run a site-wide crawl this week, export three lists: 404s, redirect chains, orphan pages
- Use URL Inspection to sample 5 different page types, confirm body content and internal links are present after rendering for each
- Open Core Web Vitals report, sort by number of failing URLs, fix the template with the most first
- Set the next audit time, add this checklist to your release process
FAQ
How often should a technical SEO audit be done?
Monthly for the first three months on a new site or after major changes, quarterly once stable, and again before major releases. Save as a template and check off item by item — saves ten times the time vs. digging through logs after the fact.
Is checking only PageSpeed speed enough for an audit?
No. Speed is just one of four layers — crawling, indexing, rendering equally determine indexing and rankings. A robots block or accidental noindex means no matter how fast the page is, it won’t get indexed.
What LCP counts as passing? Is a lab score of 90 good enough?
Look at real user data: LCP under 2.5 seconds, CLS under 0.1, INP under 200ms. Lab score 90 but real-world failing is common — don’t be fooled by lab numbers.
What to do when an audit finds orphan pages?
Pages with no internal links get no authority even if crawled. Use a crawler to list pages with zero inbound links, prioritize adding internal links to important ones, and directly noindex those with truly no value.
