A technical SEO audit, explained for business owners

Most business owners meet a technical SEO audit as a PDF with a score out of 100 and two hundred warnings in red. It looks alarming, it is hard to act on, and half the warnings do not matter. The useful part, the five things actually holding the site back, is buried somewhere on page forty.

A good audit is the opposite: short, prioritised, and written for the person paying for the fixes. Here is what it should cover and how to read one.

01What is a technical SEO audit?

A technical SEO audit is a structured check of whether search engines and AI crawlers can find, crawl, render and index the pages on your website, and whether anything in the way the site is built is holding those pages back. It looks at the machinery of the site rather than the quality of the writing.

Think of it as checking the road before judging the shop. If the road to a page is blocked, broken or slow, the quality of the page does not matter, because search engines either cannot reach it or will not show it. Once the road is clear, content and authority work can do their job. The audit is how you find out whether the road is clear.

02What does a technical SEO audit check?

A technical SEO audit checks each stage a page passes through on its way to appearing in search: whether crawlers can reach it, whether they can read and render it, whether it is indexed, and whether it performs well enough to be shown. It also covers site-wide settings such as HTTPS, structured data and hreflang.

Fig. 01Funnel

The stages a technical audit checks

From the widest stage to the narrowest:

1. Discovered: Linked internally, listed in the XML sitemap
2. Crawled: Not blocked by robots.txt, server responds reliably
3. Rendered: Main content present in the HTML, not hidden behind scripts
4. Indexed: No noindex, correct canonical, not a duplicate
5. Shown: Fast, mobile-friendly, secure and eligible for snippets

In plain terms, the audit works through:

1. Crawling. Is robots.txt blocking anything important? Does the server respond quickly and reliably? Are search and AI search crawlers, such as Googlebot, Bingbot, OAI-SearchBot and PerplexityBot, allowed where you want them?
2. Discovery. Is there an accurate XML sitemap? Can every important page be reached through internal links within a few clicks?
3. Rendering. Is the main content in the HTML the server sends, or does it only appear after JavaScript runs? Several AI crawlers do not run JavaScript.
4. Indexing. What does Search Console's Page indexing report show? Are pages excluded by noindex, canonical tags or duplication?
5. Performance. How do pages score on Core Web Vitals for real visitors? Our guide to Core Web Vitals explains the measures.
6. Links and redirects. Broken internal links, redirect chains, and old URLs that return errors.
7. Security and basics. HTTPS everywhere, no mixed content, sensible title tags and headings.
8. Structured data. Valid, accurate markup that matches the page. See schema markup for service businesses.
9. International settings. Hreflang and market versions for sites serving more than one country.

03What should you receive at the end of an audit?

You should receive a written audit in plain language, a fix list in priority order with the reason for each priority, and a clear note of who needs to do each fix. A raw export from a crawling tool is evidence for the audit, not the audit itself.

Here is what a useful audit report looks like, as a passage you can use to judge any audit you are given. It opens with a short summary, a page at most, saying what is working, what is holding the site back and what to fix first. Each finding then states the problem in one sentence, gives examples of affected URLs, explains why it matters for this business rather than in general, and estimates the effort to fix. Findings are grouped by priority, not by tool category, so the first few items are the ones that change outcomes. Warnings that do not matter for this site are listed separately or left out, with a note explaining why. The report names what the audit could not check, for example private analytics data or server logs. And it ends with a short plan: what to fix this month, what next, and how progress will be checked. If an audit cannot be summarised this way, it has not finished the job of judgement.

That is the shape of our own search and AI visibility work: a written audit, a fix list in priority order and a monthly visibility note.

04How do you decide which fixes come first?

Rank every finding by its impact on pages that matter to the business and by the effort to fix it. Do high-impact, low-effort fixes first, plan the high-impact, high-effort ones, batch the quick minor ones, and question whether the rest are worth doing at all.

Fig. 02Matrix

Prioritising audit findings

Horizontal axis from Low effort to High effort; vertical axis from Low impact to High impact.

• High impact, Low effort: Do first: indexing blocks, broken key redirects
• High impact, High effort: Plan and schedule: rendering, site structure, speed rebuilds
• Low impact, Low effort: Batch when convenient: minor tags and small link fixes
• Low impact, High effort: Question it: cosmetic warnings and tool scores

Impact depends on the business. A slow blog post matters less than a slow service page that brings enquiries. A noindex on an old tag archive may be correct; a noindex on your main service page is an emergency. This is why the audit must start from which pages matter, not from a tool's default severity.

05Are there regional factors in a technical audit?

The checks are the same everywhere, but a few findings come up more often by region. Hosting far from the audience slows pages; multi-market sites often have hreflang errors; bilingual sites need correct language and direction settings; and enquiry tracking, such as WhatsApp clicks, is often missing.

• India. Budget shared hosting is common and often slow under load; a content delivery network helps. Many sites in Hyderabad, Mumbai and Pune also track form fills but not WhatsApp or phone clicks.
• UAE. Arabic pages need correct lang and dir attributes and their own URLs, with hreflang linking them. See our guide to business websites in Dubai.
• UK. Accessibility issues and cookie banners that load tracking before consent often appear alongside technical findings, and are worth fixing at the same time.

06What should you ask before commissioning an audit?

Ask what the audit will cover, what you will receive, who will interpret the findings, and whether fixes are included or separate. A clear answer to each tells you whether you are buying judgement or a tool export. Also ask what access is needed, because an audit without Search Console data sees only part of the picture.

Questions worth asking any auditor, including us:

• Which pages will you treat as most important, and how will you decide? The answer should start from your business, not from the tool.
• Will you use Search Console and analytics data, or only a crawl? A crawl shows what is on the site; Search Console shows how Google actually sees it.
• What will the deliverable look like? Ask to see an example with the client details removed.
• How will findings be prioritised? Look for impact and effort, not just severity labels.
• Who will make the fixes, and on which platform? Some fixes need a developer; some can be done in the CMS by your team.
• How will we know the fixes worked? There should be a plan to recheck.

07When should you run a technical SEO audit?

Run a full audit before and after any redesign or platform migration, when search traffic drops without an obvious cause, and at least yearly for a stable site. Most technical problems arrive with change: a new plugin, a template update, a hosting move or a migration that skipped redirects.

If you are planning a redesign, the audit before it is the most valuable one, because it identifies the pages and settings the new site must protect. Our guide to modernising a website without losing rankings covers that process. For the studio's own builds, such as WurkSpaces and Chanakya, launch checks include redirects and search set-up as standard.

08What to do next

Open Google Search Console and look at two reports: Page indexing and Core Web Vitals. Write down how many pages are indexed, the top three reasons pages are not, and whether mobile pages pass. Then ask whether your most important service pages are among the indexed, passing ones. If they are not, that is your first fix. When you want the full audit and a fix list you can act on, book a call.