TECHNICAL

How to run a technical SEO audit that finds real problems

Six passes over crawl access, rendering, architecture, structured data and Core Web Vitals, plus what to do about the checks a crawler cannot make.

18 March 2026 · 8 min read

A technical SEO audit looks for the failures a content review cannot see: pages an engine cannot reach, cannot render, or cannot make sense of. Here is how to run one without drowning in findings.

Where a technical audit differs from a content audit

A content audit asks whether a page deserves to rank. A technical audit asks whether it is capable of ranking at all. The two fail differently. Thin content underperforms quietly over months. A misconfigured X-Robots-Tag header removes a section of your site from the index in a week, and nothing in your analytics explains why.

Run the technical pass first. Fixing prose on a page that no crawler can reach is effort spent on a page nobody will see.

Start with what the crawler receives

Not what your browser receives. The gap between the two is where most of the surprises live.

Pick five representative URLs (a homepage, a category, a product or article, a paginated page, a filtered page) and fetch each without JavaScript. Compare the word count to what you see in a browser. If the raw HTML is dramatically thinner, everything downstream in this audit is measuring the wrong document.

Crawl access, in the order it fails

  1. robots.txt allows the agents you want. Check the answer-engine crawlers specifically, since older files predate them.
  2. Meta robots and the header agree. A page with index in the tag and noindex in the X-Robots-Tag is removed, and the tag is the one people look at.
  3. Canonicals resolve. A canonical pointing at a redirect, a 404, or a different domain tells the engine to index something other than the page you are auditing.
  4. Status codes are honest. A soft 404 returning 200 keeps a dead page in the index and spends crawl budget on it every visit.

Architecture, which only exists site-wide

Site architecture can only be assessed across a full crawl, because it describes relationships between pages rather than properties of one. Three findings matter most: orphan pages that nothing links to, click depth pushing commercial pages out of frequent crawling, and crawl traps generating URLs without limit.

  • Orphans. Pages with no internal links pointing at them. These depend entirely on your sitemap being read and trusted, which is a thinner thread than most people assume.
  • Depth. Count clicks from the homepage. Crawl frequency drops sharply with depth, so anything commercially important sitting five or six clicks deep is being visited rarely.
  • Crawl traps. Faceted navigation that generates combinations without limit. A store with five filters and a sort parameter can produce more URLs than it has products, and every one of them consumes budget that indexable pages needed.

Structured data that matches reality

Validate it, then read it. Valid schema describing the wrong thing is worse than no schema, because it is a confident false statement.

The common failure is a template applied too broadly. A Product type on a category listing, or Article on a tag archive, will validate cleanly and misdescribe the page. Spot-check one page per template rather than trusting a site-wide pass rate.

Core Web Vitals, without the theatre

Core Web Vitals reduce to three metrics that are genuine ranking inputs: Largest Contentful Paint, Interaction to Next Paint and Cumulative Layout Shift. Anything beyond those is diagnostic, useful to an engineer, and not something to report to a stakeholder as though it affected rankings.

Layout shift is usually the cheapest to fix. Images without width and height attributes are the most common cause, and adding them is mechanical:

<!-- shifts -->
<img src="/hero.webp" alt="Scorecard showing category scores">

<!-- reserved -->
<img src="/hero.webp" alt="Scorecard showing category scores" width="1200" height="630">

The checks people skip

Some technical findings turn up constantly and rarely appear on a standard checklist. Pagination that loses its trail, a staging subdomain left indexable, redirect chains surviving a migration, and duplicate content on parameterised URLs are all common, all quiet, and all cheap to fix once someone looks.

  • Pagination that loses its trail. Page two onward with no self-referencing canonical and no link back to page one.
  • Staging left indexable. A staging. or dev. subdomain with no noindex, competing with production for its own content.
  • Redirect chains after a migration. Three hops still resolve, and they leak a little at each one.
  • Duplicate content on parameterised URLs. Session identifiers and tracking parameters generating distinct URLs for one page.

What to do about what you cannot check

Some checks will not run. A third-party API is down, a page times out, an area sits behind a login. Record those as unmeasured and keep them in the denominator.

This matters more than it sounds. A technical SEO audit that quietly drops what it could not reach produces a flattering score and hides the section of your site most likely to be broken, since unreachable pages and broken pages correlate heavily.

Turning findings into a plan

Group by cause, not by page. Two hundred pages missing a canonical is one template fix, not two hundred tasks. Then order by severity multiplied by pages affected, so the cheap site-wide wins come before the expensive one-off ones.

The free Crawld scan runs this pass as part of a 129-check rubric and reports its coverage alongside the score. The technical foundation and crawling categories are documented in full, and if you want to know what the crawler does to your site while it works, the crawler page explains it.

Scan your site free All posts