The Technical SEO Audit Checklist I Use on Every New Client

The short answer

Before I touch content, ads, or analytics on a new engagement, I run a technical SEO audit. Not a 200-row spreadsheet of issues nobody acts on. A focused 12-section pass that tells me what's blocking growth, what's safe to ignore, and what to fix first.

This post is that checklist, in the order I work through it. If you want to run it yourself, you can. If you want to hand it to a developer, that works too. And if you'd rather have me do it, that's the SEO service.

Why I always start here

Most marketing problems on a site I've never seen before fall into one of three buckets. The site has a technical issue blocking visibility. The content isn't aligned with what people search for. Or the conversion path leaks. Each of those gets fixed differently, and the fixes interact.

If I write content for a site whose pages are accidentally noindexed, none of that work compounds. If I run ads to a page that takes nine seconds to load on mobile, I'm spending money to bounce people. The technical audit catches the foundation issues first so the rest of the work doesn't get wasted.

It also gives me an honest picture of how much technical debt I'm walking into. That changes scope, timeline, and what I'd recommend the client do first.

The 12-section audit, in order

I work through these in sequence. Earlier sections surface issues that change how I evaluate later ones. (For example, if a site is blocking GPTBot in robots.txt, the AI search visibility section gets more urgent fast.)

1. Crawlability

Can search engines and AI crawlers reach your pages? This is the most fundamental question, and it's the one that gets answered wrong most often. I check it first because if Google can't crawl a page, nothing else in this audit matters.

• Pull the site through Screaming Frog or Sitebulb and look at the response code distribution. Anything that's not a clean 200 (or an intentional 301) gets flagged.
• Check the robots.txt file for blanket Disallow rules, especially Disallow: / left over from a staging site.
• Look for orphan pages: URLs that exist but aren't linked from anywhere on the site. The crawler won't find them, and neither will users.
• Spot-check pages that should be crawlable but aren't. (Login walls, JavaScript-rendered content, infinite-scroll feeds.)

2. Indexation

Crawlability is whether the page can be reached. Indexation is whether Google decided to keep it. They're not the same.

• In Google Search Console, compare the number of indexed pages to the number of URLs you actually want indexed. They're rarely close.
• Use the URL Inspection tool on representative pages: a high-priority service page, a blog post, a product page, a category page.
• Look for accidental noindex tags. They show up on staging-to-production deploys more often than anyone admits.
• Check the Pages report for excluded URLs. Common culprits: 'Crawled, currently not indexed' and 'Discovered, currently not indexed.' Both signal Google decided your page wasn't worth the spot.

3. Robots.txt and meta directives

Robots.txt and meta robots tags are the two main levers for telling crawlers what they can and can't access. Both get misused constantly.

• Read your robots.txt line by line. Confirm every Disallow rule is intentional and current.
• Verify that the file isn't blocking CSS or JavaScript directories. Google needs to render your pages to evaluate them, and that requires the assets.
• Check that AI crawlers (GPTBot, ClaudeBot, PerplexityBot, Google-Extended) are either explicitly allowed or not blocked by accident. If you want to show up in AI search results, they need access.
• Audit meta robots tags on key pages. A noindex on a service page is a fixable disaster.

4. XML sitemap

Your sitemap is a hint to crawlers about which URLs you care about. It should match reality: every URL you want indexed, no URLs you don't.

• Confirm the sitemap is referenced in robots.txt and submitted in Google Search Console.
• Verify every URL in the sitemap returns 200 and has a self-referential canonical.
• Remove URLs that are noindexed, redirected, or returning 404s. They shouldn't be in the sitemap.
• If you have multiple content types, split into separate sitemaps (pages, posts, products) for easier diagnosis.

5. Canonicals and duplicate content

Canonical tags tell search engines which version of a page is the master. Get them wrong and you'll either fragment your authority across duplicate URLs or accidentally consolidate pages you wanted to rank separately.

• Confirm every page has a self-referential canonical (or one pointing to the intended master).
• Check for canonical chains: A canonicals to B, B canonicals to C. Resolve them so everything points at the master directly.
• Look for case sensitivity, trailing slashes, and parameter variants creating duplicate URLs that share content but split signals.
• On ecommerce sites, audit faceted navigation. Filter combinations create huge volumes of near-duplicate URLs that need either canonicalization or noindex.

6. Site architecture and internal linking

How are your pages connected? A flat, well-linked architecture distributes authority efficiently. A deep, orphan-heavy one buries your best content.

• Pull a site visualization. (Sitebulb does this well.) Look for clusters of orphaned pages, pages buried five or more clicks deep, and dead-end nodes.
• Identify your money pages (services, key products, high-converting category pages) and confirm they're linked from the homepage and main navigation.
• Check internal anchor text. If every link to your 'SEO services' page says 'click here,' you're leaving signal on the table.
• Audit your blog. Old posts should link forward to newer, related posts. New posts should link back to relevant cornerstone content. Internal linking compounds when you treat the blog as a network, not a list.

7. URL structure

URLs are mostly a UX and consistency concern at this point. Search engines have gotten very good at parsing whatever you throw at them, but human-readable URLs still help with click-through rate, sharing, and link building.

• Confirm URLs are lowercase, use hyphens (not underscores), and don't include unnecessary parameters.
• Check for URL bloat: ?utm_source tags getting indexed, session IDs leaking into URLs, tracking parameters creating duplicates.
• Look at directory depth. Important pages shouldn't sit five subdirectories deep.
• If you're planning a URL restructure, plan it carefully. Bad redirect mapping during a migration is one of the fastest ways to lose visibility I've ever seen.

8. Redirects

Redirects are how you preserve authority across URL changes. Done well, you keep most of your equity. Done badly, you lose pages from the index for months.

• Identify redirect chains (A redirects to B redirects to C). Resolve every chain so the original URL points to the final destination directly.
• Look for redirect loops (A redirects to B, B redirects to A). These break crawling entirely.
• Confirm 301s are used for permanent redirects, not 302s or meta refreshes. Search engines treat the latter differently.
• Audit any recent migration. If you migrated platforms in the past 12 months and didn't map redirects URL by URL, this is probably your single highest-leverage fix.

9. Core Web Vitals and page speed

Core Web Vitals are Google's three-metric scorecard for page experience: Largest Contentful Paint (LCP), Interaction to Next Paint (INP), and Cumulative Layout Shift (CLS). They're a ranking factor, but the bigger reason to care is that slow pages convert worse.

• Pull Core Web Vitals data from Search Console for both mobile and desktop. Mobile usually fails first.
• For pages failing LCP, look at hero images, web fonts, and render-blocking JavaScript. Most LCP problems on small business sites are unoptimized hero images.
• INP issues usually come from heavy third-party scripts (chat widgets, analytics suites, A/B testing tools). Audit what's loading and what's actually being used.
• CLS issues come from images without dimensions, fonts that flash, and ads or embeds that load late. Reserve space in the layout for anything that loads asynchronously.

10. Mobile usability

Google indexes mobile-first. If your mobile site is broken, your rankings are broken, regardless of how good the desktop version looks.

• Test the site on a real phone, not just Chrome devtools. Devtools lies about touch target sizes and text legibility.
• Check the Search Console Mobile Usability report (or its successor in the Page Experience report) for systemic issues.
• Confirm tap targets are large enough and spaced apart, text is readable without zooming, and content fits the viewport without horizontal scroll.
• Test forms on mobile. The fastest way to find your conversion problem is often filling out your own form on a phone with a thumb instead of a mouse.

11. Schema markup and structured data

Schema (JSON-LD structured data) tells search engines and AI systems what your content is, not just what it says. It's underused and high-leverage, especially for local businesses and content-driven sites.

• Run key pages through the Rich Results Test and Schema Markup Validator.
• Confirm Organization or LocalBusiness schema on the homepage.
• Add Article schema to blog posts, FAQ schema to pages with genuine FAQ content, and Product or Service schema where applicable.
• Don't add schema you can't substantiate. Fake review schema or made-up FAQ markup will get you a manual action.

12. AI crawler accessibility

This is the section that didn't exist on most audit checklists three years ago. AI search engines (ChatGPT, Perplexity, Claude, Google AI Overviews) use their own crawlers, and a lot of sites are blocking them by accident.

• Check robots.txt for explicit rules on GPTBot, ClaudeBot, PerplexityBot, Google-Extended, CCBot, and Applebot-Extended.
• Decide deliberately which AI crawlers you want to allow. The default should be 'allow,' unless you have a specific reason to block (licensed content, paywalls, etc.).
• Verify your site renders for AI crawlers. Some platforms heavily JavaScript-render content that AI bots can't see.
• Test whether your brand actually shows up in AI answers. The post Does Your Website Show Up in ChatGPT? walks through how to check.

What I find most often

Across the audits I've run, the same five problems show up over and over. If you only have an hour to spend, start with these.

1. 1Accidental noindex tags left over from a staging or development environment. Almost always invisible until you check.
2. 2Broken redirect chains from a platform migration done two years ago that nobody followed up on.
3. 3Massive index bloat from faceted navigation, pagination, or auto-generated tag pages on the blog.
4. 4AI crawlers blocked in robots.txt because someone copied a 'disallow all bots' template without understanding what it did.
5. 5Schema markup that was added once, never validated, and now references fields that don't match what's on the page.

Almost every technical SEO problem I've fixed in the past two years was created on purpose, by someone who thought they were doing the right thing. The fix is rarely glamorous. It's just paying attention.

The tools I actually use

There are dozens of SEO tools that can run a technical audit. These are the ones I reach for, in order of how often I use them.

• Google Search Console. Free, authoritative, and the source of truth for indexation, Core Web Vitals, and manual actions. If you only have one tool, this is it.
• Screaming Frog SEO Spider. Best-in-class crawler. The free version covers up to 500 URLs. Paid version unlocks scheduling and integrations.
• Sitebulb. Visual site audits. Better than Screaming Frog if you prefer interactive reports over raw data.
• PageSpeed Insights and the Chrome User Experience (CrUX) report. For Core Web Vitals investigation.
• The Rich Results Test and Schema Markup Validator. For structured data debugging.
• Ahrefs or Semrush. Mostly for backlink and ranking data, but their site audit modules are solid.

Where this connects to analytics

A clean technical audit is half the foundation. The other half is making sure your analytics are tracking the right thing. If your site is healthy but you can't tell whether traffic converts, you're flying blind on the next decision.

Once you've worked through this checklist, run the GA4 audit checklist next. It's the analytics equivalent of this post: 15 things to verify before you trust your data.

When to do this yourself, when to hire

You can run this checklist yourself if you're comfortable in Search Console, you have someone who can change robots.txt or redirects without breaking the site, and you have the time. The audit takes me four to six hours on a small site, longer on anything with real complexity.

Hire it out if you've never done one before, if you're inheriting a site after a migration, or if your traffic dropped recently and you need to know why fast. The cost of running this badly (or skipping it) usually dwarfs the cost of hiring someone to do it right.

Getting started

If you want to work through this yourself, here's the order I'd follow.

1. 1Open Search Console and pull the Pages report, the Core Web Vitals report, and the Sitemaps report. Read all three before doing anything else.
2. 2Run a Screaming Frog crawl. Filter for non-200 response codes, noindex tags, and orphan pages.
3. 3Read your robots.txt and your XML sitemap line by line.
4. 4Spot-check three pages of different types (homepage, service page, blog post) using the URL Inspection tool.
5. 5Run the homepage and one service page through the Rich Results Test. Note what schema is and isn't there.
6. 6Make a short list of fixes ordered by impact. Fix the noindex tags first.
7. 7If any of this feels over your head, reach out and I'll walk you through it. The full audit is part of every SEO engagement I run.

Most sites I look at, especially the outdoor and DTC brands that make up most of my engagements, have at least three issues from this list, and at least one is costing them real traffic. The work isn't glamorous. It's just necessary. Get the foundation right, and everything you do after this compounds.

Frequently asked questions

How long does a technical SEO audit take?

Four to six hours of focused work on a small site (under 500 URLs). Eight to twenty hours on a larger site or one with platform-migration history. The Search Console pull and the Screaming Frog crawl are fast. The slow part is interpreting what you find and writing the fix list.

Is a technical SEO audit different from a full SEO audit?

Yes. A technical audit covers crawlability, indexation, schema, and site health, the foundation layer. A full SEO audit also covers content quality, keyword targeting, backlink profile, and competitive positioning. The technical audit is a prerequisite. Skip it and the rest of the SEO work sits on a shaky base.

How often should I run this checklist?

On any new engagement, before any major content or campaign push, after any platform migration or redesign, and at minimum once a year. Set a recurring calendar reminder. Sites drift, dependencies break, and the cost of catching a noindex tag late is much higher than the cost of running this audit on a quarterly cadence.

Can I run this checklist without paid SEO tools?

Yes. Google Search Console is free and covers the majority of what you need. Screaming Frog is free for the first 500 URLs, which is enough for most small business sites. The Rich Results Test and Schema Markup Validator are free. Don't let tool budget block you from doing this work.

Keep reading