Technical SEO Audit

A technical SEO audit is a structured inspection of whether search engines can crawl, render, index, and correctly interpret a website — the plumbing, not the prose. Skip it and you can spend a year producing good content that never ranks because a stray noindex, a robots.txt line, or a rendering dependency is silently throwing it away.

The word "audit" gets abused. A PDF of 400 auto-generated tool warnings is not an audit; it's an export. An audit ends with a prioritized list of findings, each with evidence, business impact, and a specific fix someone can ship.

What a real audit covers, phase by phase

Every serious audit walks the same pipeline a URL walks: can it be discovered, fetched, rendered, indexed, and chosen as the canonical answer. Here's the working structure, with the tools that actually earn their spot and what each phase should hand you:

A checklist fragment that shows the difference

Here's what the crawlability section of a working checklist looks like — commands, not vibes:

# Is robots.txt sane, and does it answer 200?
curl -sI https://example.com/robots.txt          # expect 200, not 5xx (5xx = Google stops crawling the site)
curl -s https://example.com/robots.txt | head -40

# Does the sitemap agree with reality?
curl -s https://example.com/sitemap.xml | grep -c "<loc>"   # URL count vs. what the crawl found

# Sample what Googlebot actually requests (last 100k log lines)
grep "Googlebot" access.log | awk '{print $7}' | sort | uniq -c | sort -rn | head -25

That last command is the single highest-value line in most audits of large sites. If the top 25 URLs Googlebot hits are parameter permutations and paginated archives instead of your revenue pages, you've found your problem before opening a single tool dashboard. Whether that's worth chasing depends on site size — crawl budget only matters past a certain scale, and for a 300-page site it doesn't.

How to run one on your own site

1. Pull Google's opinion first. Open GSC → Indexing → Pages. Every exclusion bucket ("Crawled – currently not indexed," "Duplicate without user-selected canonical," "Excluded by noindex") is a pre-sorted finding. Export them.
2. Crawl the site twice with Screaming Frog: once as plain HTML, once with JavaScript rendering. Diff titles, canonicals, and internal link counts between runs — anything that only exists in the rendered pass is a rendering dependency to flag.
3. Diff three URL sets: sitemap URLs, crawled indexable URLs, and GSC-indexed URLs. URLs in the sitemap but not the crawl are orphans; crawled-but-not-indexed clusters point at quality or duplication issues.
4. Read your robots.txt line by line against the robots.txt reference — precedence and wildcard rules trip up even experienced people, and one wrong Disallow outranks a hundred good decisions.
5. Spot-check ten money pages by hand: URL Inspection for the rendered HTML, curl -IL for redirect behavior, view-source for canonical and meta robots. Tools miss things; ten manual checks catch a surprising share of them.
6. Write up findings ranked by impact × effort, not by tool severity color. A "critical" warning on a parameter URL nobody visits loses to a "minor" noindex on a category page earning 10k visits a month.

For the full item-by-item version, the site's technical SEO audit checklist expands each phase into individual checks.

Common audit mistakes

• Shipping the tool export as the deliverable. 400 undifferentiated warnings guarantees zero of them get fixed. Triage is the job.
• Auditing the desktop site. Google indexes the mobile rendering. If your mobile template hides content or drops internal links, your desktop-based audit certified a site Google never sees.
• Never touching server logs. Crawlers simulate a crawl; logs show the real one. On any site over ~50k URLs, skipping logs means guessing.
• Testing staging and assuming production matches. Staging environments carry their own robots rules, auth walls, and noindex headers. Verify every finding against production before writing it down.
• One-and-done audits. A deploy can reintroduce any of this in an afternoon. Put the five checks that have burned you before into a weekly automated crawl and alert on deltas, not absolutes.

FAQ

How often should a site get a technical audit?

A deep one annually or after any migration, replatform, or redesign. Between those, continuous monitoring of a short list — indexation counts, robots.txt changes, 5xx rates, CWV field data — catches regressions faster than any scheduled audit.

How long does a proper audit take?

For a site under 10k URLs, a competent auditor needs roughly 15–25 working hours including the write-up. Enterprise sites with logs, multiple templates, and international sets run into weeks. Anyone quoting two hours is selling you a tool export.

What's the difference between a technical audit and a content audit?

The technical audit asks whether pages can rank (crawl, render, index); a content audit asks whether they deserve to (quality, intent match, cannibalization). Do the technical one first — content recommendations are worthless on pages Google can't index.

Which single tool is enough?

None. The workable minimum is one crawler (Screaming Frog or Sitebulb), Google Search Console, and PageSpeed Insights — all of which cost nothing at small scale. Each sees things the others structurally cannot.

What's the most commonly missed finding?

Rendering gaps. The raw HTML looks fine, the crawl looks fine, and meanwhile half the internal links only exist after a JavaScript framework hydrates — which is why the two-crawl diff in step 2 is non-negotiable.