← Back to JournalSEO

The Technical SEO Audit Checklist

By Frostbark Digital
The Technical SEO Audit Checklist

If your pages are not ranking and you cannot figure out why, the problem is often technical, not the words on the page. A technical SEO audit checks whether Google can crawl your site, index your pages, load them fast, and understand how they connect. This guide is for business owners and marketers who want to know what a real audit covers, why each part matters, and what it actually takes to do it well.

Here is the honest framing up front: finding the problems is the easy part. Fixing them, in the right order, without breaking something else, is the job.

Step 1: Confirm Google can crawl the site

Start with crawlability, because nothing else matters if Google cannot reach your pages.

Check your `robots.txt` file for rules that accidentally block important sections. Confirm your XML sitemap exists, lists only the URLs you want indexed, and is submitted in Google Search Console. Then run a crawl of the whole site to see what a bot actually sees.

Why it matters: A single misplaced line in `robots.txt` can hide hundreds of pages from search. It happens more than you would think, usually after a site migration or a developer ships a staging rule to production.

The real work: A proper crawl needs a tool like Screaming Frog or Sitebulb. The free Screaming Frog tier caps at 500 URLs; past that you are paying for licenses. Reading the export is its own skill. A crawl returns thousands of rows, and most of them do not matter. Knowing which ten do is the part you cannot fake.

Step 2: Audit indexation

Crawlable is not the same as indexed. This is where a lot of traffic quietly disappears.

In Search Console, open the Pages report and compare how many URLs Google has indexed against how many you expect. Then hunt for the usual suspects: stray `noindex` tags on pages that should rank, canonical tags pointing to the wrong URL, soft 404s, and duplicate pages with no canonical to settle the conflict.

Why it matters: A `noindex` tag left on after a redesign tells Google to drop the page entirely. You can have perfect content and zero visibility because of one line in the `<head>`.

The judgment call: Canonicals are where DIY audits go sideways. Pointing them the wrong way can deindex pages you wanted to keep. You need to understand intent before you change a single tag.

Step 3: Review site architecture and internal linking

Now look at how the site is organized. Architecture is what turns a pile of pages into something Google and users can navigate.

Important pages should sit within three clicks of the homepage. Your hierarchy should be logical, your URLs readable and consistent, and every page should have at least one internal link pointing to it. Pages with no inbound links, orphan pages, are effectively invisible.

Why it matters: Internal links tell Google which pages are important and pass ranking signals between them. A flat, well-linked structure helps your best pages rank. A tangled one buries them. This is the bridge between SEO and how the site is actually built.

The effort: Mapping internal links across a real site, finding orphans, and fixing anchor text is tedious manual work. For a local SEO site with a handful of service and location pages it is manageable. For an e-commerce catalog with thousands of URLs and faceted navigation, it is a project.

Step 4: Measure Core Web Vitals and speed

Google measures real user experience, and speed is part of ranking. Pull your Core Web Vitals.

The three to watch:

  • LCP (Largest Contentful Paint): under 2.5 seconds
  • INP (Interaction to Next Paint): under 200 milliseconds
  • CLS (Cumulative Layout Shift): under 0.1

Use PageSpeed Insights and the Core Web Vitals report in Search Console to see where you stand and which pages fail.

Why it matters: Slow, janky pages lose visitors and rankings. LCP problems usually trace back to server response time, oversized images, or render-blocking scripts.

Where it gets technical: PageSpeed gives you a number and a list of suggestions. Acting on them means image optimization, caching headers, deferring scripts, and font loading changes, work that lives in the codebase. Diagnosing is a tool. Fixing is development.

Step 5: Check redirects, HTTPS, and mobile

These are the foundations that quietly break.

Confirm HTTPS runs across the entire site with a valid certificate and no mixed content. Trace your redirects: every old URL should 301 to its new home, with no chains (A to B to C) and no loops. Verify the site is responsive, uses one viewport, and serves the same content on mobile as desktop, because Google indexes mobile first.

Why it matters: Redirect chains leak ranking signals and slow pages down. A broken redirect after a migration can wipe out a page's history. Mixed content can flag the whole site as insecure.

The catch: Redirect mapping during a site move is where projects go wrong most often. Miss a batch of URLs and you lose rankings that took years to build.

Step 6: Validate structured data (schema)

Schema markup is code that helps Google understand your content and can earn rich results, the star ratings, FAQs, and breadcrumbs you see in search.

Check that the right pages have valid structured data and that it matches what is on the page.

The trap: Many plugins inject schema with JavaScript, so it does not show up when you view the page source. You have to validate with a tool that renders the page, like Google's Rich Results Test. Checking source code alone produces false findings, a common DIY mistake.

Where this gets hard

Reading this list, you could run most of these checks. The honest truth is that the checklist is the map, not the trip.

Doing it well takes:

  • Paid tools. Screaming Frog, Sitebulb, Ahrefs, or Semrush. Real budgets, not free tiers, once a site has any size.
  • Time. A first audit of a small site is days. A large or messy site is weeks, and that is before any fixes.
  • Judgment. The hard part is not the list of problems. It is knowing which five of two hundred findings actually move rankings, and the order to fix them in.
  • Development. Most fixes, speed, redirects, canonicals, schema, live in the code. A finding is a diagnosis. Someone has to do the surgery.
  • Maintenance. Sites change. New pages, new plugins, new redirects. Technical SEO is not a one-time cleanup; it drifts and needs rechecking.

The common way DIY goes wrong is not missing a problem. It is changing a canonical, a `robots.txt` rule, or a redirect with good intentions and quietly deindexing pages that were ranking fine. The tools hand you findings. They do not hand you the judgment to act on them safely.

Or let us handle it

This is the overview. A smart owner can learn a lot from it, and you should. But running a technical SEO audit consistently, reading the findings correctly, and fixing them without breaking the site is a real job, done by people who do it every day.

That is what we do. If you would rather not spend weeks in a crawl export, our SEO work covers the audit and the fixes, in the right order. Book a free consultation and we will tell you honestly what your site needs.