What is a technical SEO audit, and what does it actually check?

The short answer: it checks the plumbing, not the copy

A technical SEO audit is a structured check of whether search engines can crawl, render, index and trust your website. It has nothing to do with your keywords or how well your service page is written. It is about the machinery underneath: can Google reach every page that matters, does it get a fast and complete version of that page, and does it end up with one clean copy of each in the index.

Everything else in SEO sits on top of that. You can publish the best page in your category, and if one line in a robots file is blocking the folder it lives in, it will never rank, because nobody at Google has seen it.

So technical work does not win rankings by itself. It removes the reasons you cannot have them. Hold on to that distinction, because it decides whether an audit is worth paying for.

Crawling and indexing: can Google get in, and what is wrongly excluded

Start here, because nothing downstream matters if this part is broken. Crawling is Google finding your pages. Indexing is Google deciding to keep them. They are separate steps and they fail separately.

• robots.txt. One small file at the root that tells crawlers where they may go. Google’s robots.txt documentation is short and worth reading, because the classic disaster is a rule that blocked the whole site on staging and came across to production with everything else.
• Indexation. The Pages report in Google Search Console shows which URLs are indexed, which are not, and the reason for each. It is the most useful free thing in SEO, and plenty of business owners have never opened it.
• What is wrongly excluded. Noindex tags left over from a rebuild, pages blocked by a plugin setting, service pages behind a filter that produces no crawlable link. A good audit finds pages you want indexed that are not, and pages indexed that should not be: thank-you pages, internal search results, empty tag archives.
• XML sitemaps. Your sitemap should list real, indexable, canonical URLs and nothing else. Plenty of them include redirects, 404s and noindexed pages, which just teaches Google to trust the file less.
• Internal linking. Crawling follows links. A page nothing links to gets found slowly and valued lightly. Orphan pages are a crawl problem before they are a content problem.

Canonicals, duplicate content and redirect chains

This is where established sites quietly leak. Duplicate content is rarely someone copying your words. It is almost always your own site serving the same page at four different addresses.

• One URL per page. http and https, www and non-www, trailing slash and no trailing slash, upper and lower case. Pick one version and redirect the rest permanently.
• Query parameters. Filters, sorts and tracking tags can generate thousands of near-identical URLs on an online store. Canonical tags are how you tell Google which one counts.
• Canonicals that argue with each other. A page pointing its canonical at a second page, which points back at the first. Or a canonical aimed at a URL that redirects. Both are invisible in a browser and common in the wild.
• Redirect chains. A goes to B goes to C goes to D. Every hop is slower for the visitor and less reliable for a crawler, and chains pile up after every migration because nobody flattens them. Redirect once, straight to the destination.
• Soft 404s and broken internal links. Pages that return a healthy 200 status while telling the visitor "sorry, that page has moved" are one of the more common findings in a first audit.

Speed, mobile, JavaScript rendering and HTTPS

Google measures real user experience with three numbers, collectively the Core Web Vitals: how fast the main content appears, how quickly the page responds when someone taps it, and how much the layout jumps around while loading. web.dev publishes the current definitions and thresholds.

An audit should tell you which of the three is failing, on which template, and why. The cause is usually boring: oversized images, render-blocking scripts, a page builder loading assets for features you are not using, or a slow server. For an Australian site hosted overseas, distance adds latency before your code does anything.

Mobile rendering. Google indexes the mobile version of your site, so what a phone sees is what counts. The check is that mobile serves the same content as desktop, not a stripped-back version, and that text and tap targets survive the smaller screen.

JavaScript rendering. If your content only appears once JavaScript has run, Google has to render the page before it can index the words. That usually works. It is also slower and less reliable than serving finished HTML. The audit compares the raw HTML against the rendered page and flags anything that exists only after the script fires: body copy, internal links, headings. We covered the trade-off in static versus server-side rendering.

Structured data. Schema markup does not lift rankings on its own. It helps engines work out what a page is (a service, an article, a local business, a product with a price) and it is what makes rich results and AI answers possible. The audit checks the markup is present, valid, and honest about what is on the page. More on that in how to rank in AI Overviews.

HTTPS and security. A valid certificate, no mixed content, nothing still served over plain http. Also worth checking: sites that have been quietly compromised and serve spam pages to crawlers while looking perfectly normal to you. It happens more often than people expect, usually on installs nobody has updated.

What a real audit deliverable looks like

This is the part that separates a useful audit from an expensive one. What you should get is a prioritized list of fixes, each with the expected impact, the effort involved, and who does it. Not a 200-page export from a crawling tool with your logo on the cover.

Any crawler will find hundreds of issues on any site you point it at, including this one. That is what crawlers do. Most of those findings are noise: a missing meta description on page four of an archive, alt text absent from a decorative icon, a heading level skipped in a footer. Passing that list on unfiltered is not analysis. It is a receipt for running the software.

A list of problems is not a plan. What you are paying for is the shortlist: the handful of fixes worth doing, and the confidence to ignore the rest.

1. 1A summary in plain English. What is wrong, what it is costing you, what to do first. One page, readable by someone who does not work in marketing.
2. 2Issues ranked by impact, not by the tool’s severity color. A crawler’s red flags are generic. Your top ten should be specific to your site, weighted toward the pages that make money.
3. 3Effort against every fix. Twenty minutes in the CMS, half a day of developer time, or a platform decision. That column is what lets you schedule the work.
4. 4Instructions someone can follow. The exact URLs, the exact change, and how to confirm it worked.
5. 5A way to measure the outcome. Indexed page count, Core Web Vitals pass rate, crawl errors, and the traffic and rankings on the pages you touched.

If a proposal offers "a comprehensive 150-point audit", ask two questions: what does the deliverable look like, and who implements the fixes. The audit is not the product. The fixed website is. That is why our SEO service treats the technical pass as the first block of work rather than a report you buy and file.

When a technical audit is the wrong first spend

Do not buy one if your site has no content targeting anything. A technical audit removes obstacles between Google and your pages. If you have five pages and none are written to answer something people actually search for, a perfect technical score changes nothing. You will own a very fast, very crawlable website that ranks for your own business name. Write the pages first, then clear the obstacles.

A few other times to keep the money in your pocket:

• Small site, modern platform, built recently. A twenty-page site on a mainstream platform, launched in the last year or two, rarely has serious technical faults. Run the free checks below and put the budget into content or your Google Business Profile instead. Our guide to how to do SEO sets out the order of operations.
• A rebuild already scheduled. Auditing a site you are replacing in two months means paying for the same thinking twice. Put the technical requirements into the build brief instead, where they cost nothing to implement.
• Tracking is not working. If Search Console is unverified and your analytics is not recording enquiries properly, you will have no way to judge whether any fix helped. Sort out measurement first.
• Nobody is going to do the work. An audit landing in an inbox with no developer time and no budget behind it is a document, not an improvement. If there is no implementation plan, do not commission the report.

The free version takes about an hour. Verify Search Console and read the reasons under the pages it has not indexed. Run your three most important pages through PageSpeed Insights. Load your homepage with JavaScript switched off and see what survives. Open your sitemap and confirm it lists only pages you want found.

If that hour turns up nothing alarming, your technical SEO is probably fine and the growth problem lives somewhere else, usually the offer, the content or the follow-up. Good result, and it cost nothing to find out. If you would rather someone else looked, our explainer on what SEO services include covers where a technical pass fits.

Frequently asked questions