Dev.to WebDev πŸ›  Dev πŸ‘ 0 πŸ“– 6 min read

How to Run Your First Technical SEO Audit (Free Checklist, Any Crawler)

How to Run Your First Technical SEO Audit (Free Checklist, Any Crawler) Your site is live, traffic is flat, and someone told you to "run a technical audit." That usually means opening a crawler, staring at 40 tabs of i

How to Run Your First Technical SEO Audit (Free Checklist, Any Crawler)

Your site is live, traffic is flat, and someone told you to "run a technical audit." That usually means opening a crawler, staring at 40 tabs of issues, and fixing things in whatever order the tool lists them.

Don't do that. Run the audit in this order instead β€” it takes about an hour on a small site, and you only need a free crawler to do it.

Disclosure: I work with SEOSage, one of the desktop crawlers listed here. Everything below works in any crawler, including the free ones. Skip the comparison table entirely and the checklist still does the job.

What you need before you start

  1. A desktop crawler. Screaming Frog SEO Spider (free up to 500 URLs), Sitebulb (free trial), or any equivalent that runs on your own machine. Desktop crawlers run locally, so there's no upload queue and no per-page metering while you learn.
  2. Google Search Console access for the site (free, and you'll use it to cross-check the crawl).
  3. A spreadsheet to log what you found and what you changed. A simple sheet with URL / Issue / Fixed? columns is enough.
  4. An hour with no meetings. Audits get abandoned halfway more often than they get finished.

Step 1: Crawl the site

Open your crawler, paste in your homepage URL, and start with the default configuration. For a first audit you don't need JavaScript rendering, external link checking, or API integrations turned on. A plain crawl of internal HTML pages is the right scope.

While it runs, note three numbers at the end: total URLs found, how many returned a 200 status, and how many were redirects or errors. Those three numbers are your baseline. Every fix below moves one of them.

If your site is bigger than your free crawler's limit, crawl in sections: homepage plus one directory at a time (for example /blog/, then /products/). The checklist works the same on a partial crawl β€” you just repeat it per section.

Step 2: Check status codes

Filter your crawl to non-200 responses and work through them in this order:

5xx errors (server errors). These are the only truly urgent ones. A 500 means the page is down for everyone, including Google. Fix the server issue or restore the page before anything else on this list.

404s (not found). For each broken URL ask two questions: does anything internal link to it, and did it used to have content? If it had content and internal links, either restore the page or redirect it to the closest equivalent. If it never had content and nothing links to it, leave it β€” a clean 404 is fine.

Redirects (3xx). A single redirect is not a problem. Chains are. Sort by redirect chain length and flatten anything with two or more hops so every old URL lands directly on the final page. Look specifically for loops (A β†’ B β†’ A), which crawlers flag clearly and browsers handle badly.

Write every fix into your spreadsheet as you go. Do not trust yourself to remember which 404 you decided to leave alone.

Step 3: Check indexability

A page can return a perfect 200 and still be invisible to Google. In your crawl, check three signals:

  • noindex tags. Look for pages carrying a meta robots noindex or an X-Robots-Tag: noindex header. On a first audit, most of these are staging leftovers or a theme default someone forgot to remove. Every important page β€” homepage, services, products, key articles β€” should be indexable.
  • robots.txt blocks. Check whether any important directory is disallowed. Crawlers show this as "blocked by robots.txt." A blocked page can't be crawled, so Google only sees it if other sites link to it.
  • Canonical tags. Each page should either canonical to itself or deliberately point at a preferred version. Watch for: canonicals pointing to the homepage from every page (a classic plugin misconfiguration), canonicals pointing at redirected URLs, and missing canonicals on paginated or parameter versions of pages.

Cross-check in Search Console under Pages β†’ Why pages aren’t indexed. If the crawler and Search Console disagree, believe Search Console about what Google actually did, and use the crawler to find the cause.

Step 4: Check titles and headings

Filter for these four problems:

  1. Missing title tags. Usually templates that were never finished.
  2. Duplicate titles. Often product or category pages generated from the same template. Rewrite the worst offenders manually; fix the template for the rest.
  3. Missing or multiple H1s. One H1 per page that matches what the page is actually about. Multiple H1s aren't a disaster, but a missing H1 usually means a heading structure problem worth fixing.
  4. Overly long titles. Anything much over ~60 characters gets truncated in results. Shorten the ones on pages you actually want clicked β€” don't churn through all of them.

Do not rewrite every title on the site in one sitting. Fix missing and duplicate first; they carry the most weight for the least effort.

Step 5: Check internal linking and orphan pages

Internal links are how both visitors and crawlers distribute attention around your site. Look for:

  • Orphan pages: URLs with zero internal links pointing to them. Crawlers compute this from the crawl itself; Search Console also lists some under "Alternate page" reports. If a page matters, link to it from a relevant parent page. If it doesn't matter, consider removing it rather than leaving it stranded.
  • Pages buried too deep: anything more than 3–4 clicks from the homepage tends to get crawled rarely and ranked weakly. Flatten where it makes sense for humans, not just bots.
  • Broken internal links: every internal link pointing at a 404 or a redirect chain is wasted. Your status-code work in Step 2 gives you the target list; now fix the source links.

Step 6: Compare sitemap vs crawl

Your XML sitemap is a promise; your crawl is the reality. Compare the two lists:

  • In sitemap but not crawlable (404, redirected, noindexed): remove or fix. A sitemap full of dead URLs wastes crawl attention and signals neglect.
  • Crawlable and important but not in sitemap: add it, especially new sections the sitemap generator missed.
  • Redirected URLs in the sitemap: update them to the final destination URL.

In Search Console, submit the cleaned sitemap and note the date. Sitemap fixes are boring and genuinely effective β€” this is the step people skip that shouldn't be skipped.

Step 7: Re-crawl and diff

A week after your fixes (or immediately, for status-code fixes), crawl again with the same configuration and compare:

  • Total non-200s down?
  • Redirect chains flattened?
  • noindex only where you intended it?
  • Sitemap and crawl now matching?

This before/after diff is your report. If you do audits for clients, this comparison β€” not the raw issue count β€” is what demonstrates the work. If it's your own site, the diff tells you whether to keep going down this checklist or move to content work.

Which crawler should you use?

Any desktop crawler that runs locally will do this whole checklist. The honest differences:

Tool Platform Free tier Practical note
Screaming Frog SEO Spider Mac, Windows, Linux Free up to 500 URLs The long-standing default; paid licence removes the cap
Sitebulb Mac, Windows Trial Strong visual reports and prioritised hints
SEOSage Mac, Windows 14-day trial Desktop crawler with unlimited local crawls and traffic data overlaid on issues

Disclosure again, since one row is mine: I work with SEOSage. Pick based on your OS, site size, and whether the free cap covers you β€” the checklist above is identical in all three.

Your first-audit recap

  1. Crawl with defaults; note your baseline numbers.
  2. Fix 5xx, then 404s, then flatten redirect chains and loops.
  3. Remove accidental noindex and robots blocks; sanity-check canonicals.
  4. Fix missing/duplicate titles and broken heading structure.
  5. Link or remove orphan pages; fix broken internal links.
  6. Clean the sitemap so it matches reality.
  7. Re-crawl and diff to prove it worked.

Run this once a quarter and after any site migration, redesign, or traffic drop you can't explain. The first pass takes an hour; later passes take twenty minutes because you're mostly reading the diff.

Have a step you always add to a first audit? I'd genuinely like to hear it in the comments.

πŸ“° Read the original article on Dev.to WebDev

Originally published by Dev.to WebDev. Aggregated on AIWithGhost for educational purposes β€” full credit and traffic to the original publisher.