Technical SEO Audit: What It Checks and How to Get One

A technical SEO audit is a review of the parts of a website that search engines and AI answer engines have to read before they can rank or cite it. It looks at crawling, rendering, indexing, speed and structured data rather than keywords or copy. The output is a prioritised list of faults, each with a reason and a fix attached.

• A page that renders only after JavaScript runs can be invisible to a crawler that does not execute scripts, which is why rendering tests belong in every audit.
• Redirect chains and orphan pages consume crawl budget, which delays discovery of the pages you actually want indexed.
• Core Web Vitals are built from real user data, so a good lab score alone does not prove a site is fast.

Sites assembled with AI website builders run into the same test, because the templates often ship with duplicate meta tags and heavy scripts.

What does a technical SEO audit actually check?

A technical SEO audit checks whether search engines can crawl, render and index your pages, how quickly they load, and whether the site's code sends clear signals about which URLs matter.

Think of it as an MOT for the machinery behind your pages. We inspect robots.txt, XML sitemaps, canonical tags, redirect chains and status codes — the plumbing that decides which URLs a search engine can reach and which it ignores.

Then we test rendering. On a JavaScript site we check what a crawler sees before scripts run and what it sees afterwards. Mismatches here are one of the most common reasons a page exists for years but never ranks.

Speed gets measured on real devices, not just a lab score. Core Web Vitals, server response times and image weight all count, because a slow page burns crawl budget and loses visitors before they read a word.

Finally we look at structured data, internal linking and duplicate content. Those three tell search engines what a page is about and which version deserves to be shown.

Redirect chains, orphan pages and the faults that quietly waste crawl budget

Redirect chains, orphan pages and soft 404s waste the limited crawl budget a search engine gives your site, so useful pages get discovered late or not at all.

Every site gets a crawl budget. It is not a published number, but the effect is real: each redirect chain, each link pointing at a 404, and each faceted URL spawning thousands of near-duplicates eats into it.

Two faults turn up again and again. The first is the orphan page — good content that nothing links to, so crawlers rarely find it. The second is the soft 404, where a removed product returns a success status and a polite message, leaving the index full of dead ends.

Canonical tags and hreflang sit in the same bucket. If your UK and international versions point at each other incorrectly, or your canonicals aim at a redirect, search engines choose a version for you. It is rarely the one you wanted.

Does a technical audit matter more for JavaScript-heavy sites?

Yes, because client-side rendering can hide content from crawlers entirely, so a JavaScript site needs its rendering path tested before any content or keyword work begins.

Modern front-end frameworks render in the browser. A crawler that does not execute JavaScript sees an empty shell, which means content, links and metadata can all go missing. Google renders pages, but it queues that work, and other crawlers are far less forgiving.

We test three things: what the raw HTML contains, what a rendered DOM contains, and whether the two agree on titles, canonicals and internal links. Where they disagree, we usually recommend server-side rendering or pre-rendering for the pages that carry commercial weight.

Sites assembled with AI website builders run into the same test. They can be perfectly solid, but the templates often ship with duplicate meta tags and heavy scripts, so we check the output rather than assume it works.

Ready-made crawlers or a custom checker: which do you need?

Ready-made crawlers cover most sites, but a custom checker earns its place when you need tests that off-the-shelf tools cannot run, such as internal API checks, log-file analysis or monitoring wired into your release cycle.

For most sites a desktop crawler, Google Search Console and a log-file sample are enough. You get broken links, status codes, duplicate titles and index coverage in an afternoon, and the list is usually longer than anyone expected.

A bespoke checker makes sense when standard tools cannot see what you need. Picture a store where prices load from an internal API, an app sitting behind a login, or a site that changes every week. We build checkers that run those tests on your pipeline and flag problems before a bad deploy goes live.

If you are weighing up a bespoke checker, our breakdown of custom software cost sets out the moving parts. Where the same checks need to run on a schedule, AI automation can pick them up and report changes without anyone opening a crawler.

How long does a technical SEO audit take, and what drives the scope?

A small site can be audited in a few days while a large store or multi-language build takes several weeks, and the scope follows the number of URLs, the tech stack and how much of the fixing you want handled for you.

A brochure site with a handful of templates can be reviewed in a couple of days. A shop with tens of thousands of product URLs, filters and regional folders takes longer, mainly because crawling and rendering tests need time to run and interpret properly.

Everything else comes down to scope. Do you want a findings document you act on yourself, or do you want us to implement the fixes? Are we working alongside your developers, or are we the developers? Settle those two questions before anyone gives you a number.

If you want a second opinion before committing to a rebuild, a free technical review of your crawl and index setup is the sensible place to start. It costs you a conversation and often saves a wasted project.

What should you fix first once the audit lands?

Fix anything blocking crawling or indexing first, then page speed on your busiest templates, then structured data and internal links, because nothing else shows results while pages are unreachable.

Start with whatever stops a page being found. A stray robots.txt rule or a noindex tag left over from staging cancels out every other improvement you make, so clear those before touching anything else.

Next comes speed on the templates that carry the most traffic. You do not need every page to be perfect — fix the ones that earn money and the ones that link out to everything else.

Then structured data and internal linking. This is the stage where you tell search engines what a page is, not just that it exists, and where you steer crawlers towards the pages worth ranking.

Will a technical audit help you appear in AI answers?

It helps, because AI answer engines depend on the same crawlable, well-structured pages that search engines do, and a site they cannot parse is a site they will not quote.

Answer engines and AI assistants build their replies from pages they can fetch and parse. A site that hides content behind rendering, blocks crawlers by default, or buries its facts inside images gives them nothing to work with.

That is why a technical audit and answer engine optimisation overlap so much. Clear headings, a plain-language answer near the top of a page and structured data all make it easier for a machine to lift a sentence and credit you for it.

Our wider notes on generative engine optimisation cover the content side of that work. The technical side is simple enough: if the crawler cannot read it, no assistant will repeat it.

If you want a second opinion before committing to a rebuild, a free technical review of your crawl and index setup is the sensible place to start.