Technical SEO Audit Checklist: A Step-by-Step Framework

I've taken apart hundreds of websites hunting for the reason organic traffic flatlined, and the culprits are almost always the same boring handful. A robots.txt file quietly blocking half the site. A sitemap crammed with URLs that redirect somewhere else. Images that take four seconds to paint on a phone.

None of this is exotic. It's dull, it's fixable, and it bleeds rankings every single day. A technical SEO audit exists so you catch these problems on purpose instead of tripping over them months later.

What follows is the exact framework I run, from a five-page local business to a 20,000-URL ecommerce catalog, ordered the way I actually work: check whether search engines can reach and understand your pages first, then chase speed, structure, and the smaller details that add up.

Key Takeaways

• Start every audit with crawlability and indexation. If bots can't reach or index a page, nothing else you fix matters.
• Speed and Core Web Vitals have the clearest line to both rankings and revenue, and images are usually the biggest drag.
• Mobile isn't a secondary check anymore. Google indexes most sites using the mobile version as the primary reference.
• Prioritize your findings into critical, growth, and monitor buckets. A hundred-item spreadsheet with no order helps nobody.
• Treat auditing as recurring maintenance, not a one-time project. Sites drift the moment you stop looking.

What a Technical SEO Audit Actually Is (and Why It Matters)

Strip away the jargon and a technical audit is one question asked over and over: is there anything about how this site is built that stops search engines from finding, understanding, or trusting it?

That's different from a content or link audit. Here you're poking at the plumbing, the server responses, the crawl paths, the stuff visitors never see but Googlebot reacts to constantly. A single misconfigured line can undo months of great writing. Drop a stray noindex tag on your best service page and it's invisible. Technical problems don't announce themselves; they quietly cap your ceiling.

Start With Crawlability, Because Nothing Else Matters if Bots Can't Get In

Crawlability is just a term for whether search engine bots can reach your pages and follow the links between them. If Googlebot can't crawl a page, the quality of the content and the speed of the load are both beside the point. I always start here, because a crawlability issue can mask or mimic a dozen unrelated symptoms.

First stop is robots.txt, a small text file in your site's root directory that tells search engines which sections they're allowed to visit. I've watched agencies leave a "disallow all" directive in place after a staging site went live, killing crawl access for weeks before anyone noticed the traffic drop. Read it directly, then cross-check against Google Search Console to confirm nothing important got blocked by accident.

From there, I'm looking for three things:

• Redirect chains, where one URL redirects to another that redirects again (and sometimes again), burning crawl budget and diluting value at each hop.
• 5xx server errors, which tell bots your server failed to respond and can push Google to slow down or abandon a crawl.
• Overly complex JavaScript rendering that hides links or content from crawlers that don't execute scripts the way a real browser does.

None of these checks are glamorous. They're also the ones most likely to be strangling a site's visibility without anyone realizing it.

Indexation: Confirm What's Actually Making It Into the Index

Crawling and indexing aren't the same thing, and conflating them causes a lot of wasted debugging. A page can be crawled and still never land in Google's index if something signals the engine not to bother. Indexation is the step where a search engine adds a page to its index so it can appear in results at all.

Google Search Console's indexing report sorts pages into buckets, indexed, excluded, and various error states, and it's the fastest way to spot a pattern. If a whole folder of product pages shows up as "excluded by noindex tag," that's a five-minute fix that can restore real visibility.

An older trick still earns its keep too. Search site:yourdomain.com and compare the indexed count against how many pages actually exist. A fifteen-page brochure site showing thousands of indexed URLs? Something's spawning duplicate or junk pages. A five-hundred-page site showing twelve? You've got a bigger fire to chase.

Pro Tip: While you're checking indexation, audit your canonical tags in the same pass. These snippets tell search engines which version of a page is the "real" one when near-duplicates exist. Missing or inconsistent canonicals are one of the most common causes of split ranking signals, especially on ecommerce sites with filtered category pages.

XML Sitemaps: The Map You're Handing Search Engines

An XML sitemap is a file listing the URLs you want search engines to know about, a directory you hand over so crawlers don't have to guess. Sounds like minor housekeeping. It isn't. Broken sitemaps are more common than most owners assume, and one audit guide found roughly one in four sites has a broken sitemap in some form.

Here's what I check every single time:

• The sitemap is submitted in Search Console and returns no errors
• It only includes canonical URLs returning a 200 status code (the page loads successfully), not redirects, 404s, or noindexed pages
• It stays under the technical limits of 50,000 URLs and 50 megabytes per file, splitting into multiple files with an index file when the site is larger
• It's organized sensibly, sometimes by page type or section, so you can trace indexing problems to a specific area faster

A sitemap full of dead weight doesn't just look sloppy. It wastes the limited attention a search engine gives your site during each crawl.

Site Architecture and Internal Linking

This is where I stop caring about individual pages and start caring about how the whole thing fits together. Site architecture is the hierarchy connecting your pages, and internal linking is how you wire them up.

The rule of thumb that keeps surfacing across audits, and one I agree with, is that important pages shouldn't sit more than three clicks from the homepage. Bury your best service page five levels deep in a nested tree and you're telling both users and search engines it doesn't matter. Flat, logical hierarchies with clear navigation and breadcrumbs consistently beat deep, tangled ones.

Beyond click depth, I'm scanning for:

• Orphaned pages, meaning pages with zero internal links pointing to them, which leaves them nearly invisible to crawlers that rely on links to discover content
• Broken internal links pointing to pages that no longer exist
• Generic anchor text like "click here" instead of descriptive phrases that tell users and engines what sits on the other end
• Link-stuffed pages crammed with too many outbound links, which dilutes the value passed to any single one; a reasonable ceiling is around 150 links per page

Some tools score this with metrics like Internal LinkRank, which estimates how much internal link equity a page accumulates. You don't need the precise number to get the lesson: pages your own site treats as unimportant get treated the same way by search engines.

Page Speed and Core Web Vitals

Speed is the check with the most direct, measurable line to both rankings and revenue, so I refuse to treat it as an afterthought. Google's Core Web Vitals hand you three numbers to chase.

In practice, images are the single biggest reason pages crawl on the sites I review. Compressing them, converting to modern formats like WebP, lazy loading anything below the fold, and setting up proper caching usually produce the fastest visible wins of the whole audit. After that, look at render-blocking CSS and JavaScript, plus the unused scripts left behind by old plugins and past redesigns. Aim for pages that load in under two seconds; users bail well before that.

One warning: don't stop at lab data. Run pages through PageSpeed Insights or Lighthouse, but the field data from real user visits tells you what's actually happening out in the wild, not just in a clean testing environment.

Mobile Usability

More than half of all web searches now happen on mobile devices, and Google indexes most sites using the mobile version of the page as its primary reference point. So a mobile pass isn't a bonus anymore. It's the default lens.

Confirm the viewport meta tag is set up correctly so pages scale on smaller screens. Run pages through Google's Mobile-Friendly Test. Then verify that content, navigation, and interactive elements like buttons and forms all behave the same on mobile as on desktop.

Here's a habit that gets skipped too often: test on real phones, not just browser emulators. Emulators miss the real-world quirks, sticky headers eating half the screen, tap targets that are technically clickable but practically impossible to hit with a thumb.

Duplicate Content and URL Hygiene

Duplicate content confuses search engines about which version to rank, and it splits whatever authority a page has earned across multiple URLs instead of consolidating it into one. A common threshold used to flag likely duplicates is content that's roughly 85 percent identical or more between two pages.

The sources are predictable once you know what to look for:

• Separate versions of the site reachable at both http and https, or both www and non-www
• URL parameters, especially on ecommerce, where filtering or sorting spins up dozens of near-identical URLs for the same product list
• Printer-friendly or session-based variants left over from old CMS setups

Fixing this comes down to consistent 301 redirects (a permanent redirect that passes most of the original page's value to the new URL) plus disciplined canonical tagging, so there's zero ambiguity about which version counts.

HTTPS, Redirects, and Status Codes

These are quick checks, and I still catch sites failing at least one. Confirm the SSL certificate is valid and not near expiry. Check for mixed content warnings, where a secure page loads insecure resources. Verify HSTS (HTTP Strict Transport Security) is configured so browsers always default to the secure version. Every http URL should 301 redirect to its https equivalent, with no lingering internal links still pointing at the old http versions.

Then sweep for status code problems.

None of these are hard to fix one at a time. The trouble is volume. On a large site they pile up quietly until the crawl report reads like a mess.

Structured Data and Schema Markup

Structured data is a standardized code format, most often JSON-LD, that describes your content so search engines parse it directly instead of inferring from plain text. It's what makes rich results possible, star ratings, FAQ dropdowns, event details, right there in the listing.

Depending on the page type, I check for:

• Organization and Website schema sitewide
• Breadcrumb schema to reinforce site architecture
• FAQ or BlogPosting schema on relevant content
• Local business schema for anything location-based

Run everything through Google's Rich Results Test to confirm the markup validates and matches what's visible. Mismatched schema can do more harm than none at all, so don't mark up content that isn't actually there.

Log File Analysis: The Advanced Check Most Audits Skip

Server log files record every request made to your site, including every visit from Googlebot. Analyze them and you learn exactly which pages search engines crawl, how often, and where they're wasting time on low-value URLs instead of your priority content.

This matters most on large sites, where crawl budget, the finite attention a search engine spends during any session, becomes a real constraint rather than a theoretical one. Smaller sites can usually skip it; sites with thousands of pages generally can't afford to.

Match the Checks to the Page Type

Not every page deserves identical scrutiny. Homepages, service pages, blog posts, ecommerce listings, and local landing pages each have different jobs and different failure points.

An ecommerce category page lives or dies on faceted navigation and duplicate URL parameters. A local landing page lives or dies on schema and NAP (name, address, phone) consistency. Audit everything against one generic standard and you'll miss the issues specific to each template.

How to Prioritize Findings and Set Realistic Timelines

An audit that spits out a hundred-item spreadsheet with no priority order is useless to everyone, including you. I sort findings into three buckets: critical fixes that block crawling or indexing, growth-stage improvements that compound over time, and lower-priority items worth monitoring but not rushing.

Timelines swing hard with site size.

For a sense of the effort: manual audits can eat 60 to 80 percent of a team's time on repetitive, checklist-style tasks, and a professional audit on a mid-sized site of roughly 500 pages commonly runs 25 to 50 hours. That's a big part of why agency pricing for a full engagement often lands anywhere from $500 to well over $10,000, depending on complexity.

Don't try to fix everything at once. Tackle the top handful of issues ranked by impact and effort, ship those, then circle back for the rest.

Common Mistakes I See Constantly

• Chasing a perfect Lighthouse score while ignoring the field data that reflects actual visitors
• Blocking CSS or JavaScript in robots.txt, which stops Google from rendering the page the way users see it
• Adding schema that doesn't match visible content, which can trigger penalties instead of rich results
• Fixing easy, low-impact items first and never reaching the ones that actually block indexing

Make It a Habit, Not a One-Time Project

The audit doesn't end when the spreadsheet is done. Set a recurring cadence, monthly or quarterly, to rerun the core checks: crawl errors, Search Console coverage, Core Web Vitals, sitemap health. Track impressions, click-through rate, and average ranking position after each round of fixes so you know whether the work paid off.

Sites drift. New pages ship without canonical tags. A plugin sneaks in render-blocking scripts. Someone updates the CMS and quietly breaks the sitemap. A technical SEO audit isn't a thing you run once and file away, it's closer to routine maintenance on a car you plan to keep driving.

Frequently Asked Questions

What is a technical SEO audit?

It's a systematic review of the technical elements affecting how search engines crawl, index, and understand your site, things like crawlability, indexation, site speed, mobile usability, and structured data. It focuses on how the site is built rather than what it says.

How often should I run a technical SEO audit?

Set a recurring cadence, monthly or quarterly, to rerun the core checks. Sites drift constantly as new pages get published, plugins get added, and CMS updates ship, so treating it as ongoing maintenance beats treating it as a one-off.

What's the difference between crawlability and indexation?

Crawlability is whether bots can reach and follow the links on your pages. Indexation is whether a search engine actually adds a crawled page to its index. A page can be crawled and still never get indexed if something, like a noindex tag, signals the engine to leave it out.

What are Core Web Vitals?

Three metrics from Google: Largest Contentful Paint (target under 2.5 seconds), Interaction to Next Paint (target under 200 milliseconds), and Cumulative Layout Shift (target under 0.10). Together they gauge how fast, responsive, and visually stable a page feels.

How do I find duplicate content on my site?

Check the usual sources: http versus https, www versus non-www, URL parameters from filtering and sorting, and leftover printer-friendly variants. A common threshold flags pages around 85 percent identical or more. Fix it with consistent 301 redirects and clean canonical tagging.

What is structured data and do I need it?

Structured data is standardized code, usually JSON-LD, that describes your content so search engines parse it directly instead of guessing. It powers rich results like star ratings and FAQ dropdowns. It's not mandatory, but it helps eligible pages stand out, just make sure the markup matches what's visible.

How long does a technical SEO audit take?

It depends on size. A site under 500 pages might take a day to audit and a week to fix. A 500-to-2,000-page site runs one to three days of auditing and one to three weeks of fixes. Sites above 2,000 pages can take a full week to audit, with fixes stretching one to two months.

How much does a professional technical SEO audit cost?

Agency pricing often lands anywhere from $500 to well over $10,000 depending on complexity. A mid-sized site of roughly 500 pages commonly runs 25 to 50 hours of work, which is a big driver of where the price settles.

Final Thoughts

The problems that stall organic traffic are rarely mysterious. A robots.txt file left in the wrong state, a bloated sitemap, images nobody bothered to compress. Boring, fixable, and quietly expensive.

Work the checklist in order, crawlability and indexation first, then speed, structure, and the details, and you'll catch these on purpose instead of by accident. Prioritize ruthlessly, ship the fixes that matter most, and come back on a schedule. Do that, and technical SEO stops being a fire drill and turns into routine upkeep, the quiet advantage most of your competitors never bother to maintain.