What a real technical SEO audit covers — and what a plugin scan misses

The difference between an audit and a scan is diagnosis. A scan lists symptoms — "12 images missing alt text, 3 titles too long" — with no model of which ones matter. An audit builds a causal picture: crawl data cross-referenced with index data, cross-referenced with log files and field performance, ending in a fix list ordered by expected impact. On the sites we've audited, the median scan-type report surfaces fewer than half of the issues that actually suppress rankings, because the serious problems live below the page level.

Layer 1 — Crawl behavior

First question: what does a crawler actually experience on this site? We run a full crawl emulating Googlebot's mobile user agent and compare it against the site owner's mental model of the site. The gap is always informative. Typical findings:

• Redirect chains. Three or more hops between the linked URL and the final one. Each hop leaks link equity and crawl time; chains of 5+ frequently stop being followed at all.
• Orphan pages. URLs in the sitemap or index with zero internal links pointing at them. Orphans get recrawled rarely and rank accordingly.
• Crawl traps. Faceted navigation, calendar archives, and parameter combinations that generate effectively infinite URL space. One e-commerce crawl we ran hit 250,000 URLs on a site with under 2,000 real pages before we stopped it.

Layer 2 — Indexation

Crawled is not indexed. We reconcile three lists: URLs the site wants indexed (canonical, in-sitemap, 200 status), URLs Google has indexed, and URLs Google has seen but excluded. The two mismatches are both problems. Money pages sitting in "Crawled — currently not indexed" mean Google fetched the page and declined it — usually a quality or duplication verdict, not a technical accident. The inverse, index bloat, means thin parameter or tag pages are consuming your crawl allocation and diluting sitewide quality signals. On local service sites we routinely find 10–40% of the index made up of URLs the owner didn't know existed.

Layer 3 — Rendering

Google indexes what it renders, not what your server sends. If key content, internal links, or structured data are injected client-side by JavaScript, we verify they survive rendering: raw HTML versus rendered DOM, mobile agent. Common failures include navigation menus that only exist after a script runs (the crawler's discovery path disappears), lazy-loaded content below the first viewport never entering the DOM without interaction, and JS-injected canonicals and meta robots that disagree with the server-sent versions — Google can honor the wrong one.

Layer 4 — Performance and Core Web Vitals

We assess field data first — the Chrome UX Report numbers Google actually uses — then use lab runs to find the causes. The thresholds are public and non-negotiable: LCP under 2.5 seconds, INP under 200 milliseconds, CLS under 0.1, at the 75th percentile of real visits on mobile. The most common local-site failures are oversized hero images (a 2–4 MB unoptimized photo behind the LCP element), render-blocking third-party scripts — chat widgets, page builders, tag soup — and layout shift from ads or late-loading embeds. Passing a lab test on office wifi while failing in field data is the norm, not the exception; the field number is the one that counts.

Layer 5 — Structured data

Schema markup is how a site declares its entities: what the business is, where it operates, what it sells, what its pages are. We validate that structured data exists on the right templates, parses without errors, matches the visible page content (mismatches risk manual actions), and uses the most specific applicable types. For local businesses this layer has grown in importance for a second reason: structured data is one of the clearest signals AI retrieval systems consume — covered in depth in our AI search optimization post.

Layer 6 — Architecture and internal linking

Internal links are the site's own statement of what matters. We measure click depth from the homepage for every money page (target: three or fewer), the internal link count into each revenue page versus blog posts and utility pages, and anchor text distribution. A site whose highest-earning service page receives four internal links while a 2019 blog post receives sixty has an architecture problem no amount of new content fixes. Fixing internal linking is the cheapest ranking improvement in technical SEO — it requires no new pages, no new links, no budget beyond attention.

Layer 7 — Duplication and canonicalization

Every URL variant that serves the same content splits that content's signals. We check protocol and host consolidation, trailing-slash and case variants, parameter handling, printer/AMP/legacy versions, and — critical for multi-location service businesses — near-duplicate city pages. Ten "SEO for [city]" pages with 90% shared content don't rank in ten cities; they compete with each other in all of them and depress the site's quality profile. The fix is consolidation or genuine differentiation, and choosing which requires demand data, which is a content strategy decision as much as a technical one.

Layer 8 — Server and log-level verification

When log files are available, they replace inference with observation: which URLs Googlebot actually fetches, how often, and what status codes it receives. Logs surface problems no crawl can see — intermittent 5xx errors that only occur under load, bot traffic burning crawl budget on parameter URLs, and sections Google has quietly stopped visiting. On one audit, logs showed Googlebot spending 70% of its requests on a broken filtered-search subtree; blocking it redirected that attention to revenue pages within weeks.

What comes out the other end

The deliverable is not the finding count — it's the ordering. Every issue gets scored on expected ranking impact and implementation effort, and the report leads with the intersection: high impact, low effort. A typical prioritized output for a local business site reads like this: fix indexation of three money pages (days, high impact), consolidate duplicate city pages (a week, high impact), compress LCP images sitewide (days, medium impact), restructure internal links to service pages (a week, medium impact), and only then the long tail of title tweaks and alt text. That ordering is the entire value of the audit; the same findings in alphabetical order are nearly worthless.

It's also worth saying what an audit can't do: it can't create demand, and it can't build authority. It removes friction. A technically clean site with no content targeting real queries and no links still ranks for nothing — which is why audits pair with local SEO, content, and link building rather than replacing them.

Get the real version

Our technical SEO audit service runs all eight layers and returns the prioritized roadmap described above. If you want a first-pass read before committing to anything, send us your URL — we look before we talk. More posts on the blog.