SEO fundamentals

The technical SEO audit checklist that finds real problems

What a technical SEO audit should actually contain, how to read indexation and Core Web Vitals data correctly, and how to tell a useful audit from a colour coded crawler export.

11 min read

What separates a real audit from a ninety page export

A technical SEO audit is one of the easiest deliverables to fake. Any crawler produces a ninety page document in an afternoon: every missing meta description, every image without alternative text, every heading longer than seventy characters, colour coded red, amber and green. It looks thorough, and it is mostly noise. The report reads almost identically whether your site has a serious indexation problem or none at all, because nothing in it was decided by a person who understood what the site is for.

A useful audit starts at the other end. It asks which pages are supposed to earn money, whether Google can reach them, whether it chooses to index them, whether it can tell which of your similar pages to rank, and whether the page is usable on a mid range phone. Everything else is secondary. The output is short, ordered, and written so a developer can act without a translation meeting. Fifteen findings with an owner and an expected impact beat four hundred rows sorted by a severity colour no search engine recognises.

This is also a cheap way to test a prospective partner. Ask any candidate for a redacted audit delivered to a client of similar size. If what comes back is a raw crawler export with a cover page, you have learned a great deal for free. The same test applies when comparing listings of SEO agencies or shortlisting software from a catalogue of SEO tools: the question is never which crawler a team runs, it is what they do with the output. Our guide on how to choose an SEO agency covers the rest.

Crawlability and crawl budget waste

Crawling is where an audit should begin, because nothing downstream matters if the crawler never arrives. Start with the blunt blockers: robots.txt rules disallowing directories nobody remembers adding, staging subdomains left open to the world, bot protection returning 403 to Googlebot, and server errors that only appear under load. A crawl launched from a laptop will not reveal any of that reliably. You need server logs, or at minimum the crawl statistics report in Search Console, which shows what Google actually requested and what your server actually returned.

Crawl budget waste is the subtler problem and by far the more common one on large sites. Faceted navigation multiplies a thousand product pages into hundreds of thousands of filter combinations. Session parameters, sort orders, internal search result pages, calendars that run to the year 2098: all of them get crawled, none of them deserve to rank. On a small brochure site this is harmless. On a catalogue with heavy templates it means Google spends its attention on parameter noise and revisits your commercial pages every few weeks instead of every few days.

The fix is rarely a single robots.txt line. It is a decision, template by template, about which URL patterns should be linked, which should be crawlable but not indexable, and which should not exist at all. That work sits between marketing and engineering, which is why it stalls so often: neither side owns the decision and neither wants to break the catalogue. Scoping it properly is part of any serious SEO engagement, and it should appear in the proposal as named deliverables rather than as a vague technical optimisation line.

  • Ratio of crawled URLs to URLs you would genuinely want indexed
  • Facet and parameter combinations reachable through plain links rather than blocked
  • Response codes over time: bursts of 5xx, soft 404s, redirect chains longer than one hop
  • Average response time per template in the crawl statistics report
  • Sitemaps listing redirects, 404s, or URLs carrying a noindex tag
  • Pages discovered only through the sitemap and never through an internal link

Reading the indexation report properly

The page indexing report is the most misread screen in SEO. Every status has a specific meaning, and the difference between two of them usually decides whether you have a content problem or a plumbing problem. Discovered, currently not indexed means Google knows the URL exists and has not bothered to fetch it: that is a signal about site level quality and crawl demand, not about that one page. Crawled, currently not indexed means Google fetched the page, looked at it, and declined. That is a verdict on the content itself.

Alternate page with proper canonical tag is normal and healthy. Duplicate, Google chose different canonical than user is not: your canonical declares one thing and Google disagrees, which almost always exposes near identical templates. Excluded by noindex tag is only a problem when the tag sits on a page you wanted indexed, which happens more often than anyone admits after a deployment from staging. Soft 404 points at thin or empty pages, typically out of stock products, empty filter results, or category pages whose inventory has drained away.

A real audit quantifies these buckets against your commercial page set rather than against the whole site. Ten thousand excluded URLs means nothing on its own. Ten thousand excluded URLs of which four hundred are products you actively sell is an emergency. The URL inspection tool then confirms individual cases: last crawl date, the canonical Google selected, and the rendered HTML it saw. An audit that stops at the total count is writing for a dashboard rather than for a decision, which is the same failure we describe in SEO KPIs and reporting.

Duplicates, cannibalisation, canonicals and pagination

Duplication rarely looks like copy and paste. It looks like three articles written eighteen months apart about the same question, two category pages differing by a single filter, or a printer friendly version nobody ever removed. Google picks one, and often not the one you would have picked. The symptom in Search Console is a query whose ranking URL keeps swapping week to week, or two URLs each collecting a handful of impressions while neither reaches the top ten. That is cannibalisation, and it is a content architecture problem wearing a technical costume.

Canonical tags are your declared answer to that question, and they are wrong surprisingly often. The recurring failures: a template emitting the homepage as canonical for every URL, canonical chains where A points to B which points to C, tags injected into the body instead of the head, and canonicals contradicted by the sitemap or by a language cluster. If you run several country or language versions, the interaction between canonical and hreflang deserves a dedicated pass, which we walk through in international SEO and hreflang.

Pagination is the part most audits skip. The old rel next and rel prev hints are long gone, so modern handling is simple and easy to verify: each paginated page self canonicalises, stays indexable, and links to its items. Pointing every page back to page one hides your deep inventory from discovery entirely. Infinite scroll with no distinct URL per page has the same effect. On large catalogues this single decision can determine whether half your products are ever crawled, a theme we develop further in the ecommerce SEO guide.

  • Queries where the ranking URL alternates between two of your own pages
  • Templates emitting an identical canonical tag for every URL they generate
  • Paginated pages canonicalising to page one and hiding deep inventory
  • Filter and facet pages that are indexable, thin and nearly identical to each other
  • Sitemap entries that contradict the canonical tag on the page itself

Internal links, orphan pages and JavaScript rendering

Internal linking is the cheapest ranking lever most sites never pull, and it is trivially auditable. Map click depth from the homepage: any commercial page more than three clicks deep is being told, structurally, that it does not matter. Count incoming internal links per URL and compare that ranking against your revenue ranking. On most sites the two lists barely overlap, because navigation and footers distribute link equity according to a menu designed in a meeting rather than according to what customers actually buy.

Orphan pages are the extreme case: URLs that exist in the sitemap or in analytics but receive no internal link at all. They are common after migrations, after campaign landing pages are archived, and on any site where content is published through a separate system. An audit should list them by name with a recommendation for each: link it properly, merge it into a stronger page, or remove it. Anchor text matters here too, though far less than the presence or absence of the link itself.

Rendering is the last discovery question. Compare the raw HTML your server returns with the rendered DOM Google sees, template by template. Content injected after a click, navigation built from JavaScript event handlers instead of anchor elements, and product listings assembled entirely in the browser are all ways to become invisible while looking perfectly fine to a human. These findings almost always land on the engineering side, so an audit is only useful if it names the framework behaviour and the fix; scope that with your web development team before promising a timeline.

Core Web Vitals in the field, and structured data that earns something

Performance is where lab and field data are confused most often. A laboratory score comes from a single simulated run, and it moves several points between two tests of the same unchanged page. Field data comes from the Chrome user experience report: real visits, real devices, real networks, aggregated over a rolling twenty eight day window and grouped by URL pattern. Google evaluates the field data. An audit reporting only a laboratory score has measured a laboratory, which is why two agencies can report contradictory numbers for the same site.

Read the three metrics as questions rather than as numbers. Largest contentful paint asks whether the main element appeared quickly, and usually fails because of an unpreloaded hero image, a render blocking font, or a slow first response from the server. Interaction to next paint asks whether the page answered when someone tapped, and usually fails because of heavy JavaScript, often third party tags nobody has audited in two years. Cumulative layout shift asks whether things moved under the reader's thumb, and is normally traceable to one injected banner or one image without dimensions.

Structured data deserves the same discipline. Markup only pays when it maps to a rich result Google currently supports and faithfully describes the page: product with price and availability, breadcrumbs, events, organisation details. Marking up an article as a product, or adding review markup for reviews absent from the page, is decoration at best and a manual action risk at worst. Validate against a rich results test, then check whether the enhancement actually appears in Search Console in the following weeks. If it never appears, the markup costs maintenance and returns nothing.

Migrations, redirects and prioritising by expected impact

Most catastrophic traffic losses are not algorithmic. They are migrations done without a redirect map. The rule is unglamorous and rarely followed: every old URL with traffic, links or impressions redirects in one hop to its closest equivalent, not to the homepage, not through a chain, and not to a category that vaguely resembles it. Mass redirects to the homepage are treated as soft 404s and lose everything the old page earned. Build the map before launch from crawl data, Search Console exports and log files, then verify it after.

Prioritisation turns a list of findings into a plan, and it is the part tool exports cannot do. Severity colours describe the crawler's opinion, not your business. A better ordering multiplies pages affected by commercial value and by the probability the fix changes anything, then divides by effort. A canonical bug across two thousand product pages outranks a missing alt attribute on four hundred blog images every time, even when the crawler paints the second one red. When comparing candidates on the agency leaderboard, ask how they built their last priority order.

Finish with three columns most audits omit: who implements each item, what evidence will show it worked, and when it will be checked. Technical work travels well across borders because it depends on your stack rather than your market, so a team in Germany or Spain can audit a site sold anywhere, and independent SEO freelancers often do this specific work better than large teams. What does not travel is accountability. An audit nobody is contractually obliged to implement is an expensive document, and the most common way technical SEO budgets are quietly wasted.

  • One hop redirects from every old URL with traffic, links or impressions
  • A post launch check of index coverage, redirects and vitals in the first two weeks
  • Findings ordered by pages affected times commercial value divided by effort
  • A named owner for each item: marketing, engineering, or the agency
  • A stated verification date and the metric that will prove the fix landed

Frequently asked questions

How much does a technical SEO audit cost?

In Europe in 2026, a serious technical audit for a small or mid sized site usually runs from 1,500 to 6,000 euros, and considerably more for large ecommerce or multi country platforms. Anything priced at a few hundred euros is almost always an automated crawler export with a cover page. The cost tracks the analyst hours spent interpreting data, not the number of pages in the document.

How long should a technical SEO audit take?

Two to four weeks is normal for a mid sized site: a few days of crawling and data collection, then most of the time spent on interpretation, prioritisation and writing implementation notes a developer can follow. Much faster usually means less interpretation. Much slower often means the work is queued behind other clients rather than genuinely deeper.

What is the difference between a technical SEO audit and a full SEO audit?

A technical audit covers how search engines access, render, index and choose between your pages: crawling, indexation, canonicals, performance and structured data. A full audit adds keyword and market analysis, content quality, the backlink profile and competitor comparison. Most sites need the technical layer first, because publishing content on a site Google cannot index properly wastes the content budget.

How often should a website be audited technically?

Once a year is enough for a stable brochure site. Quarterly monitoring makes sense for large catalogues, where new templates, filters and parameters appear continuously. Any migration, replatform or design overhaul deserves its own audit before launch plus a verification pass in the two weeks after, when most damage is still cheap to reverse.

Can I run a technical SEO audit myself?

You can get a long way with Google Search Console alone, which is free and shows real data: the page indexing report, crawl statistics, URL inspection and the Core Web Vitals report. A crawler adds site structure, internal linking and orphan page detection. What is hard to buy off the shelf is the interpretation, meaning the judgement about which findings will actually change revenue.

Does a technical SEO audit include implementing the fixes?

Usually not. Most audits stop at documented, prioritised recommendations, and implementation is quoted separately or handed to your own development team. Clarify this before signing, and agree who verifies the result, because an audit whose recommendations are never implemented is one of the most common ways an SEO budget disappears without any effect.

Read next