How to Do a Technical SEO Audit (Step-by-Step Checklist)

Here’s the short version: to do a technical SEO audit, you check whether search engines can crawl, render, index, and understand your site — in that order. You start with what Google has actually indexed (Search Console’s Page indexing report), then work through crawlability, site architecture, on-page technical issues, performance, mobile, security, and structured data, and you finish by prioritizing every finding into critical, important, or nice-to-have. The whole thing can be done with free tools, and you don’t need to be a developer to run it.

Okay, let’s be honest for a second: “technical SEO audit” sounds intimidating. It conjures images of terminal windows and someone muttering about log files. But here’s the part nobody tells you — most of a technical audit is just asking a series of very reasonable questions and writing down the answers. Can Google find my pages? Is anything blocking it? Is my site a tidy library or a junk drawer? You can do this. I promise it gets easier the moment you have a checklist, and by the end of this guide you’ll have one — plus a template for turning your findings into fixes that actually happen. So let’s walk through how to do a technical SEO audit from the first check to the final ticket.

What is technical SEO, really?

Strip away the jargon and technical SEO is four questions. Can search engines crawl your site — follow links and fetch your pages? Can they render it — see the content the way a visitor does, even the parts loaded by JavaScript? Will they index it — store your pages and consider them candidates for search results? And can they understand it — figure out what each page is about and how your pages relate to each other?

Every technical check you’ll ever run rolls up to one of those four. That’s genuinely comforting, because when a tool spits out forty-seven warnings, you can sort them by asking: does this stop crawling, rendering, indexing, or understanding? If it doesn’t clearly hurt one of the four, it’s probably not urgent.

One more mindset note before we dig in, because it matters: fixing technical issues removes obstacles — it doesn’t guarantee rankings. A technically clean site with thin content won’t outrank a slightly messy site with brilliant content. Think of this audit as clearing the road, not winning the race. The race is still content and relevance. But a blocked road means nobody even sees you run, so the clearing is worth doing well.

How do you check what Google has actually indexed?

Always start here, because indexing is the scoreboard. Everything else in the audit explains why the scoreboard looks the way it does.

The quick-and-dirty check: the site: operator

Type site:yourdomain.com into Google and you’ll get a rough list of your indexed pages. It’s a fine first glance — if you have 500 pages and the results look like a dozen, something is very wrong. But know its limits: the result count is an estimate, not an inventory, and it can swing wildly between searches. Use it as a smoke test, never as your source of truth.

The real check: Search Console’s Page indexing report

Google Search Console (free, and honestly the center of this whole audit) has a Page indexing report that shows two things you need: how many pages are indexed, and — the gold — the reasons pages aren’t. You’ll see buckets like “Crawled – currently not indexed,” “Discovered – currently not indexed,” “Excluded by noindex tag,” “Page with redirect,” and “Duplicate without user-selected canonical.” (Exact report names and categories evolve as Google updates Search Console, so verify what your current interface calls them — but the logic stays the same.)

Here’s how I’d read those buckets as a friend looking over your shoulder:

• Noindex exclusions: fine if intentional (thank-you pages, internal search results), alarming if your money pages are in there. Audit the list, don’t assume.
• “Discovered – currently not indexed”: Google knows the page exists but hasn’t bothered to crawl it yet. Often a signal of weak internal linking or a site Google doesn’t prioritize crawling.
• “Crawled – currently not indexed”: Google fetched it and chose not to keep it. That’s frequently a content-quality judgment, not a technical bug — worth an honest look at whether the page deserves to exist.
• Duplicates and canonical issues: Google found multiple versions of the same thing and picked one. Sometimes it picks the version you didn’t want. We’ll fix that in the on-page section.

Also spot-check individual pages with the URL Inspection tool in Search Console. It tells you, for one specific URL, whether it’s indexed, when it was last crawled, and what Google saw. When a stakeholder asks “why isn’t this page showing up?”, this tool is your first stop and usually your answer.

How do you audit crawlability?

If indexing is the scoreboard, crawlability is whether the players can even get onto the field. Five checks cover it.

1. Robots.txt sanity check

Visit yourdomain.com/robots.txt and actually read it. You’re looking for two disasters and a few untidinesses. Disaster one: Disallow: / — a single line that blocks your entire site (it happens more than anyone admits, usually a staging setting that went live). Disaster two: disallow rules blocking folders your important pages live in, like /blog/ or /products/. The untidiness: rules nobody remembers writing. If you can’t explain a rule, flag it for investigation rather than deleting it blind.

2. XML sitemap: present and clean

Your sitemap (usually at /sitemap.xml) is the list of pages you’re asking search engines to index. Two standards: it should exist and be submitted in Search Console, and it should be clean — only canonical, indexable, 200-status URLs. A sitemap full of redirects, 404s, and noindexed pages is like handing someone a shopping list where half the items don’t exist. It erodes trust in the whole list.

3. Crawl errors

Scan for pages returning 404s (gone), soft 404s (pages that say “not found” but return a 200 status, which confuses crawlers), and 5xx server errors (your server failing when Google visits). Search Console surfaces these in the indexing report; a crawler tool will find the rest. Each error type has a different fix — and because this topic deserves more room than I can give it here, I’ve written a full walkthrough on how to fix crawl errors, from diagnosing status codes to deciding when a 404 is actually fine to leave alone.

4. Redirect chains

A redirect chain is when page A redirects to B, which redirects to C, which redirects to D. Every hop wastes crawl effort and dilutes the signal passing through. These accumulate quietly over years of migrations and URL changes. The fix is simple in concept: point every redirect directly at the final destination. Your crawler tool will list the chains; your job in the audit is just to count them and flag the worst offenders.

5. Orphan pages

An orphan page has zero internal links pointing to it — it exists, maybe it’s even in your sitemap, but no path on your site leads there. Search engines treat linklessness as a statement: “even the site owner doesn’t think this matters.” Find orphans by comparing your sitemap (or CMS page list) against a crawl of your site; pages in the first list but not the second are orphans. Either link to them from relevant pages or ask honestly whether they should exist.

For the crawling itself, you’ll want a desktop or cloud crawler tool — there are several well-known ones with free tiers that handle small and mid-size sites comfortably. I’m staying vendor-neutral on purpose: they all fetch your pages the way a search engine would and report the same core issues. Pick whichever fits your budget and stack; the checklist below works with any of them.

How do you evaluate site architecture and internal linking?

This is the area people skip because it doesn’t produce a satisfying red error icon — and it’s quietly one of the highest-leverage parts of the entire audit.

Check click depth first. How many clicks does it take to get from your homepage to your important pages? As a working rule, anything you care about should be reachable within three or four clicks. Pages buried six clicks deep get crawled less often and rank worse, not because of a penalty, but because depth is how your site communicates importance. Your crawler tool reports depth for every URL; sort by it and wince accordingly.

Then check logical structure. Does your site have a shape — clear sections, hub pages that link down to detail pages, detail pages that link back up and across to siblings? Or is it a flat pile of pages connected mostly through the blog feed? A logical structure helps search engines understand which pages are your pillars and which are supporting detail, and it helps visitors not get lost. If your audit reveals a junk-drawer situation, that’s a project, not a ticket — and I’ve broken the whole rebuild process down in this guide to how to improve site architecture for SEO, which pairs naturally with this audit.

Finally, scan internal anchor text. Links that say “click here” and “read more” tell search engines nothing. Links that say “technical SEO checklist” or “pricing for small teams” are tiny, free description tags for the destination page. You don’t need to fix every anchor in the audit — just note whether descriptive anchors are the norm or the exception.

What on-page technical issues should you check?

These are the unglamorous, high-frequency findings — the ones a crawler tool finds by the hundred.

• Duplicate title tags and meta descriptions. When fifty pages share the title “Products | YourBrand,” search engines struggle to tell them apart and searchers have no reason to click one over another. Your crawler groups duplicates for you; prioritize fixing the ones on pages you actually want to rank.
• Missing or empty titles and descriptions. Less damaging than duplicates (Google will generate something), but a missed opportunity on every important page.
• Canonical tags. A canonical tag tells search engines “this URL is the official version of this content.” Check three things: important pages should have a canonical (usually self-referencing), no important page should canonicalize to a different page by accident, and parameter-laden URL variants (tracking codes, filters, sort orders) should canonicalize back to the clean version.
• Broken internal links. Links pointing at 404s waste crawl paths and frustrate humans. Export the list, fix the links at the source (update or remove them), and re-crawl to confirm.
• Broken outbound links. Lower priority, but a page full of dead external links reads as abandoned — to visitors and arguably to quality systems. Tidy the worst pages.

How do you assess performance and Core Web Vitals in plain words?

Performance is a whole discipline on its own, so in an audit your job is assessment, not optimization. Here’s the plain-language version of Core Web Vitals, Google’s three user-experience measurements:

• Loading (LCP): how long until the biggest visible thing on the page — usually a hero image or headline — actually appears. Slow LCP feels like staring at a blank page.
• Interactivity (INP): when a visitor taps or clicks, how quickly does the page respond? A laggy response feels broken even when nothing is.
• Visual stability (CLS): does the page jump around while loading, making you tap the wrong button? That jumpiness is what this measures.

Where to look: Search Console’s Core Web Vitals report shows how real visitors experience your site (when there’s enough traffic to report), and Google’s free PageSpeed Insights tool gives a per-page diagnosis. In the audit, record three things: which page templates fail, which metric they fail on, and roughly how many pages each template represents. Then point that summary at dedicated speed work — image compression, caching, script cleanup — as its own project. Don’t let the audit turn into a performance rabbit hole; note it, size it, move on.

What about mobile, HTTPS, and structured data?

Three smaller areas, each a quick pass.

Mobile experience

Google predominantly crawls and evaluates the mobile version of your site, so your mobile site is your site. Check that your pages are responsive (they adapt to small screens rather than showing a shrunken desktop page), that text is readable without pinch-zooming, that buttons and links are tappable without surgical precision, and that nothing important — content, links, structured data — exists on desktop but is missing on mobile. The low-tech test is underrated: open your ten most important pages on your actual phone and try to use them like an impatient stranger would.

HTTPS and security basics

Your entire site should load over HTTPS, full stop. Check that the certificate is valid (no browser warnings), that every HTTP URL redirects to its HTTPS version in a single hop, and that pages don’t trigger mixed-content warnings from insecure images or scripts loaded over HTTP. Also confirm you’ve picked one canonical domain version — www or non-www — and the other redirects to it. These are usually one-time fixes, which makes them satisfying audit wins.

Structured data validity

Structured data is machine-readable labeling (most commonly JSON-LD) that tells search engines “this is an article, published on this date, by this author” or “this is a product with this price.” In the audit, check two things: does your structured data validate without errors (Google’s Rich Results Test and the Schema.org validator are both free), and — this one matters — does it match the visible content on the page? Markup that claims things the page doesn’t visibly say violates Google’s guidelines and can backfire. Honest markup only; it’s a description layer, not a trick.

Do you need to worry about hreflang and JavaScript rendering?

Two advanced areas. Check whether they apply to you before spending time here.

Hreflang — only if you serve multiple languages or countries. Hreflang tags tell search engines which version of a page to show searchers in which language or region. They’re famously fiddly: every tag must be reciprocal (if page A points to page B as its French version, B must point back to A), language and region codes must be formatted correctly, and the URLs referenced must be the live, canonical ones. If your site is single-language and single-market, skip this entirely and feel zero guilt.

JavaScript rendering — the plain-language version. Some sites load their content with JavaScript after the initial page loads. Search engines can run JavaScript, but rendering is a second, delayed step after crawling — and anything that only exists after rendering is at some risk of being missed or processed late. The audit check: use Search Console’s URL Inspection tool to view the rendered page as Google sees it, and compare it to what a visitor sees. If important content, links, or metadata are visible to you but absent from Google’s rendered version, flag it as a critical finding and bring in a developer. You don’t need to understand the framework to spot the gap — you just need to compare the two views.

How do you prioritize findings so they actually get fixed?

Here’s where most audits die: as a 60-page PDF of undifferentiated warnings that nobody acts on. Don’t write that document. Instead, sort every finding into three buckets:

• Critical — blocks crawling or indexing of important pages. Robots.txt blocking real sections, noindex on money pages, important pages returning errors, sitewide HTTPS failures, rendered content missing from Google’s view. Fix these first, this week.
• Important — degrades performance or understanding at scale. Widespread duplicate titles, redirect chains on major paths, key pages buried five-plus clicks deep, failing Core Web Vitals on high-traffic templates, invalid structured data on templated pages. Schedule these over the coming weeks.
• Nice-to-have — real but minor. Broken outbound links on old posts, missing meta descriptions on low-priority pages, sitemap tidiness, anchor-text polish. Batch these into maintenance time.

Then put the findings in a simple tracker. Here’s the template I use — one row per finding:

Finding	Priority	Pages affected	Evidence	Owner	Status	Verified?
Noindex tag on 14 product pages	Critical	14	GSC export, URL list attached	Dev team	In progress	Not yet
Duplicate titles across blog category pages	Important	~80	Crawler export	Content lead	Backlog	—
Broken outbound links on 2019 posts	Nice-to-have	23	Crawler export	Anyone	Backlog	—

That “Verified?” column is the heart of the fix-verify loop, and it’s what separates audits that work from audits that decorate a shared drive. A fix isn’t done when the ticket closes — it’s done when you’ve confirmed the change landed and the symptom cleared. Re-crawl the affected URLs, re-inspect them in Search Console, request reindexing where it matters, and check the relevant report a few weeks later. Indexing changes take time to show up, so verification is patient work. Build it into the plan rather than treating it as a surprise.

How do you work with developers on technical fixes?

A lot of your findings will need developer hands, and the quality of your tickets determines the speed of your fixes. A good technical SEO ticket has five parts:

• What’s wrong, in one sentence, with the affected URLs listed or linked.
• Why it matters, in business terms — “these 14 pages can’t appear in Google at all,” not “noindex detected.”
• What done looks like, precisely: “remove the noindex robots meta tag from these URLs; they should return 200 and be indexable.”
• How you’ll verify, so nobody debates completion: “I’ll re-inspect each URL in Search Console and confirm it’s eligible for indexing.”
• Evidence attached — screenshots, crawler exports, Search Console links. Make the problem reproducible in two clicks.

One ticket per distinct issue. A ticket titled “SEO fixes” containing nine unrelated requests will sit in the backlog forever, and honestly, it deserves to.

How often should you do a technical SEO audit?

A sensible cadence for most sites: a full audit once or twice a year, a monthly mini-check (15 minutes in Search Console scanning the indexing report, Core Web Vitals, and any new errors), and an event-triggered audit whenever something big changes — a redesign, a migration, a new CMS, a merger of two sites. Migrations especially: audit before, snapshot everything, and audit again after. Most catastrophic technical SEO stories are migration stories where nobody compared before and after.

If the site is large, fast-moving, or revenue-critical, tighten all of those intervals. The monthly check is the one I’d defend hardest — it catches the accidental noindex and the broken sitemap while they’re days old instead of quarters old.

Your complete technical SEO audit checklist

Here’s the whole audit in one pass — this checklist is, in miniature, how to do a technical SEO audit from start to finish. Work top to bottom, and sort everything you find into the priority template above.

• Indexing: run a site: smoke test; review the Page indexing report in Search Console; investigate each “why not indexed” bucket; URL-inspect your top pages.
• Robots.txt: read it; confirm nothing important is disallowed; flag unexplained rules.
• Sitemap: exists, submitted, and contains only live, canonical, indexable URLs.
• Crawl errors: list 404s, soft 404s, and 5xx errors; decide fix, redirect, or leave for each.
• Redirects: find chains and loops; point redirects at final destinations.
• Orphans: compare sitemap/CMS list to crawl; link or retire orphan pages.
• Architecture: check click depth of key pages (3–4 clicks max); assess hub/spoke structure; scan anchor text quality.
• On-page technical: duplicate and missing titles/descriptions; canonical correctness; broken internal and outbound links.
• Performance: review Core Web Vitals by template; record failing templates for dedicated speed work.
• Mobile: responsive rendering, readable text, tappable targets, content parity with desktop.
• HTTPS: valid certificate, single-hop HTTP-to-HTTPS redirects, no mixed content, one canonical domain version.
• Structured data: validates without errors and matches visible page content.
• Hreflang (if multilingual): reciprocal tags, correct codes, canonical URLs referenced.
• JS rendering: compare Google’s rendered view to the visitor view; flag missing content.
• Wrap-up: every finding gets a priority, an owner, and a verification step; schedule the next audit.

And a closing thought on what happens after the audit. Technical health decides whether your pages can be found; it doesn’t make anyone care once they arrive — that’s the job of the content itself, and of actually getting it in front of people. That second part is where I’ll mention what we build at SocialBlaze: once your fixed, findable pages are live, an organic social media management platform helps you distribute them — scheduling and auto-publishing to every network from one place so your newly audit-clean content gets real eyes, not just crawler visits. To be clear, SocialBlaze is a social media management tool, not an SEO or audit tool — search and social are different channels. But they compound: search brings the intent, social brings the reach, and the same content program feeds both.

FAQ: how to do a technical SEO audit

How long does a technical SEO audit take?

For a small site (under a few hundred pages), a focused first audit takes roughly a day: a couple of hours crawling and gathering data, several hours reviewing findings, and an hour writing up prioritized tickets. Large or older sites take longer, mostly in the review stage. The monthly mini-check afterward takes about 15 minutes.

Can I do a technical SEO audit with free tools only?

Yes, genuinely. Google Search Console covers indexing, crawl errors, Core Web Vitals, and URL-level inspection; PageSpeed Insights covers per-page performance; the Rich Results Test covers structured data; and several crawler tools offer free tiers that handle small sites. Paid tools add convenience and scale, not fundamentally different data.

What’s the most common critical finding in a technical SEO audit?

Accidental blocking: a noindex tag or robots.txt rule left over from staging or a redesign that’s quietly keeping important pages out of search entirely. It’s common because it’s invisible — the site looks and works fine to every human visitor. That’s exactly why the audit starts with the indexing report rather than with the site itself.

Will fixing technical SEO issues improve my rankings?

It removes obstacles, which is necessary but not sufficient. If a technical problem was actively blocking crawling or indexing, fixing it can produce dramatic recoveries. If your site was already technically sound, polishing it further yields little — rankings then depend on content quality, relevance, and links. No one can honestly guarantee ranking improvements from any SEO work.

What’s the difference between a technical SEO audit and a full SEO audit?

A technical audit covers whether search engines can crawl, render, index, and understand your site — the infrastructure layer. A full SEO audit adds content quality, keyword targeting, competitive positioning, and backlink analysis on top. Do the technical audit first: content and link work built on a technically broken foundation underperforms.