Technical SEO Audit

How I scope a technical SEO audit

The right depth for a technical SEO audit depends on the site, not on a standard checklist. Before quoting a scope, I look at four things:

• Platform and rendering. A standard CMS that outputs plain HTML carries different risks from a single-page application or a headless setup with client-side routing.
• URL volume and generation. A few hundred hand-built pages behave differently from a catalog or listing site where filters, sorting and search generate URLs automatically.
• Page types that drive revenue. Service, product, category, location or documentation templates get the deepest review, because that is where problems cost the most.
• Data available. Search Console and a crawl are the minimum. Server logs, a staging environment and access to the deployment process make the audit more precise.

The result is a written scope that lists the modules included, the depth for each, the data sources and what you will receive. This matters because an open-ended technical audit tends to grow without producing anything usable. If you need a broader view that also covers content, intent and tracking, the general SEO audit is the better starting point.

The four-way comparison at the center of the audit

A crawler only shows what it can find by following links. To understand what is really happening, I compare four views of the same site:

The gaps between these views are where the real findings sit. Pages in the sitemap but not linked internally are orphans. Pages crawled by bots but absent from the crawl suggest old URLs, parameters or traps. Pages linked and submitted but excluded from the index point to quality, duplication or canonical problems. Where logs are not available, I work with the other three and note the limitation. My technical SEO checklist lists the baseline controls this comparison checks against.

Diagnostic examples a technical audit uncovers

These are illustrative patterns that technical audits commonly uncover, described in general terms rather than taken from a specific client:

• Parameter sprawl. Sorting and filter combinations create large numbers of near-duplicate URLs that absorb crawl activity while new product or service pages wait to be discovered.
• Canonical conflicts. A template sets a canonical to one URL while the sitemap lists another and internal links point to a third version with a trailing slash difference.
• Links that are not links. Navigation or related-item modules use click handlers instead of real anchor elements, so crawlers never follow them.
• Soft errors. Removed pages return a normal status with an empty template, so search engines keep them indexed as thin content.
• Redirect leftovers. Chains and loops from earlier redesigns that slow crawling and dilute signals.
• Template regressions. A CMS update stripped titles or structured data from one page type and nobody noticed.

Each finding in the register explains how to reproduce it, why it matters for that template, and what correct behavior looks like.

Deliverables and the developer handover

The technical SEO audit produces a small set of working documents rather than a long slide deck:

• Issue register: one row per root cause, with affected templates, example URLs, priority, estimated effort and status
• Developer tickets: current behavior, expected behavior, acceptance criteria and test steps for each issue
• Page-type inventory: every template with its indexing intent, so future changes can be checked against it
• Configuration recommendations: robots rules, sitemap structure, canonical logic and redirect rules where relevant
• Summary for management: the main risks in plain language, with the business case for the top items
• Regression checklist: checks to run before and after each release

I hold a review call with your developers before the register is finalized. That call often changes priorities, because some fixes turn out to be trivial in your stack while others conflict with product requirements. A plan your developers agree with gets shipped. A plan written in isolation rarely does. After release, I recrawl the affected sections and update the register so you can see what is fixed, what is partial and what still needs work.

KPIs that show whether the fixes worked

Technical fixes should be measured against technical indicators first, then against business outcomes. I do not promise ranking or traffic changes, because those depend on content, competition and search engine updates. The indicators I track after a technical SEO audit include:

• Indexed versus submitted URLs for each priority template
• Excluded page reasons in Search Console, tracked by category over time
• Share of bot requests going to priority sections versus low-value URLs, from logs
• Count of open, partial and closed items in the issue register
• Core Web Vitals status by page group from field data
• Valid structured data items and enhancement errors
• Impressions, clicks and organic inquiries for the affected templates

The last indicator is where a technical audit connects to revenue. If organic inquiries flow into a CRM, I check that landing page and source data survive the form submission, so improvements on commercial templates can be traced to real leads. For longer-term work after the audit, such as release QA and log monitoring, see my technical SEO consulting service.