What we check first in a technical SEO audit

Many technical SEO audits arrive as a spreadsheet with hundreds of rows, color-coded by severity and generated largely by a crawler. They are rarely wrong, but they are rarely useful either. The team receiving them does not know which ten items matter, so either nothing gets fixed or engineers spend weeks on warnings that move nothing. Our audits are structured around a different question: what is stopping this site's important pages from being found, understood and chosen? That leads us to check a small set of things first, in a particular order, before looking at anything else.

1. Is the site being indexed the way you think it is?

Indexation problems are the most damaging and often the least visible. We start by comparing three lists: the URLs you want indexed, the URLs search engines have discovered, and the URLs actually indexed. Search Console's page indexing report and a full crawl give most of what we need.

What we typically find:

• Important pages excluded as "crawled, currently not indexed" or "duplicate, Google chose different canonical", which usually signals thin, duplicated or weakly linked content.
• Large volumes of junk indexed: internal search results, filtered category pages, tag archives, parameter variations and staging copies.
• Accidental noindex or robots.txt blocks on sections that should rank, often left over from a launch.

On a mid-sized content site we audited, 62 percent of indexed URLs were tag and date archives with no traffic. Cleaning that up did not immediately raise rankings, but it shifted crawl activity toward the pages that mattered, and new articles began appearing in results within days rather than weeks.

2. Can crawlers reach and render the important content?

Next, we check whether search engines see what users see.

• Rendering. On JavaScript-heavy sites, we compare the raw HTML against the rendered DOM. Content, links or structured data that only appear after client-side rendering are at risk, particularly for non-Google crawlers and AI search systems that often do not execute JavaScript at all.
• Internal link paths. Pages more than four or five clicks from the home page, or reachable only through search forms or infinite scroll, are crawled less and rank less.
• Status codes. Redirect chains, internal links to 404s and soft 404s waste crawl budget and dilute signals.
• Server logs where available. Logs show what crawlers actually request, which is often surprising: we have seen bots spend most of their time on calendar pages or faceted URLs nobody knew existed.

3. Are the signals consistent?

Search engines weigh many signals to decide which URL represents a piece of content. When those signals disagree, they make their own choice, which may not be yours. We check that each important page has:

1. A self-referencing canonical, or a canonical pointing at the intended primary version.
2. Internal links that point at the canonical URL rather than variants.
3. Inclusion in the XML sitemap, which should contain only canonical, indexable URLs returning 200.
4. Consistent hreflang annotations on international sites, with return links in place.
5. One version of the site: HTTPS, one hostname and one trailing-slash convention, with everything else redirecting.

Most canonical problems are not tag problems. They are the site sending five different signals and hoping the search engine picks the right one.

4. Performance and page experience, briefly

Core Web Vitals matter, but they are rarely the reason a site has lost significant visibility. We look at field data for key templates and flag anything failing, particularly Interaction to Next Paint on heavy templates and Largest Contentful Paint on mobile. Where performance is the bottleneck for conversion as well as SEO, it becomes its own workstream.

Check the templates, not just the pages

Most technical issues live in templates rather than individual pages. When we find a problem on one product page, we check every page built from the same template, because a missing canonical or a slow hero image on one template can affect thousands of URLs at once. We group crawl findings by template early in the audit, which usually shrinks a list of thousands of URL-level warnings into a few dozen template-level causes. It also makes estimates realistic: one template fix is often a day of engineering, however many URLs it touches, and developers can verify it with a handful of representative pages.

5. Only then, everything else

After those four areas, we review structured data, title and meta patterns, image optimization, duplicate content between templates, pagination and the long tail of crawler warnings. These matter, but they seldom explain a significant problem on their own.

How we prioritize the findings

Every finding is scored on three dimensions: the estimated impact on important pages, the engineering effort, and the confidence we have that the fix will help. The final report leads with a short list, usually eight to fifteen items, grouped into what to fix this sprint, this quarter and when convenient. Each item includes the affected URLs or templates, the specific change required and how to verify it worked. The full crawl data is included as an appendix for reference, not as the deliverable.

We also recommend what to measure after the fixes: indexed pages by section, crawl requests to important templates, impressions for target queries and organic conversions, reviewed monthly for at least three months.

This is the structure of our technical SEO audits. When the findings point to linking problems, we usually follow with internal link architecture work, and performance findings feed into Core Web Vitals optimization.

Want an audit your developers can act on?

Send us your domain and a sense of what has changed recently, and we will quote a fixed price for an audit with a prioritized fix list. Request an audit quote.