The short answer
A technical SEO audit is a systematic check of four things: whether search engines can crawl your pages, whether they index the right ones, whether your structure and links are sound, and whether pages render fast and pass Core Web Vitals. You can run the whole thing with free tools: Google Search Console, the URL Inspection tool, a crawler such as Screaming Frog, and Lighthouse.
Do it in order of impact. Crawling and indexing come first, because the best, fastest page in the world earns nothing if Google cannot reach it or has excluded it from the index.
- Fix crawling and indexing before speed. Reachability wins.
- The Page indexing report and URL Inspection tool answer most questions for free, in minutes.
- Group issues by pattern and fix the template, not the thousand pages it generated.
What a Technical Audit Actually Covers
Four questions, in the order that matters. Each one has its own tools and its own fixes.
Crawlability
Can search engines discover and reach your pages?
Indexability
Are the right pages indexed, and the wrong ones kept out?
Performance
Do pages render fast and pass Core Web Vitals?
Structure
Is the hierarchy and internal linking logical?
How to Run the Audit, Step by Step
This order goes from the problems that override everything else to the ones that take the most work to prove. Everything here uses free tools.
- 1
Rule out a penalty or security problem
In Search Console, open Security & Manual Actions and check both reports. A manual action or a hacked-site warning overrides everything else, so fix it first. If both say no issues, move on.
- 2
Read the Page indexing report
This is the fastest picture of what Google can and cannot index. Look at the indexed count against the pages you expect, then read the reasons for the excluded ones: blocked by robots.txt, noindex, duplicate without a chosen canonical, or crawled but not indexed. Each reason points to a different fix.
- 3
Inspect a sample of important URLs
Run the URL Inspection tool on your homepage, a key category page and a few money pages. Confirm they are indexed, check the user-declared and Google-selected canonical, and use the live test to see the rendered HTML. A mismatch between the two canonicals is a common, invisible problem.
- 4
Check robots.txt and your XML sitemap
Make sure robots.txt does not block folders you want crawled, and that your sitemap lists only final, indexable, canonical URLs, not redirects or noindexed pages. Submit the sitemap in Search Console and watch for parsing errors.
- 5
Crawl the site yourself
Run Screaming Frog (free up to 500 URLs) or a similar crawler. Sort for 4xx and 5xx responses, redirect chains and loops, duplicate or missing titles and meta descriptions, and pages with no inbound internal links. This is where most on-site technical debt surfaces.
- 6
Compare raw HTML with the rendered DOM
For a JavaScript-heavy site, view the source and compare it with the rendered HTML in the URL Inspection live test. If your main content or internal links only appear after JavaScript runs, confirm Google is actually rendering them, because content it cannot see cannot rank.
- 7
Measure Core Web Vitals on key templates
Run PageSpeed Insights and Lighthouse on one page of each template (home, category, article, product). Note LCP, INP and CLS, and whether field data exists in the Core Web Vitals report. Treat this as the last step, not the first, because speed only matters on pages that are reachable and indexed.
Deeper guides on several of these steps: robots.txt, noindex tags, canonical tags, 404 errors and redirects, crawl budget and sitemaps.
Watch Google Explain the Approach
Before the checklist, it helps to hear how Google thinks about a technical audit: understand the site's technology, use the tools properly, read the data, and prioritise. Martin Splitt covers exactly that in under five minutes.
The Technical SEO Checklist
A one-screen reference for the audit. Each row names what to check, where to check it, and what a healthy result looks like.
| Area | What to check | Where | What good looks like |
|---|---|---|---|
| Crawlability | robots.txt does not block important folders; key pages return 200 | robots.txt, Crawl stats report, Screaming Frog | No accidental Disallow on live sections; few server errors |
| Indexability | The right pages are indexed; noindex and canonicals are intentional | Page indexing report, URL Inspection | Indexed count matches the pages you want to rank |
| Canonicals | User-declared canonical matches the one Google selected | URL Inspection | No surprise canonicalization to another URL |
| Redirects | No redirect chains or loops; old URLs 301 to their closest match | Screaming Frog, browser network tab | One hop from old URL to final URL |
| Internal links | No broken internal links; important pages are not orphaned | Screaming Frog crawl | Key pages reachable within about three clicks of the home page |
| Rendering | Main content and links appear in the rendered HTML | URL Inspection live test, DevTools | Content visible without relying on a click or scroll |
| Core Web Vitals | LCP, INP and CLS pass on each key template | PageSpeed Insights, Lighthouse, CWV report | LCP under 2.5s, INP under 200ms, CLS under 0.1 |
| Mobile | Layout, tap targets and content work on a phone | DevTools device mode, real device | No horizontal scroll or content cut off on mobile |
The Core Web Vitals thresholds in the last rows are covered in depth in our guides to measuring PageSpeed and Core Web Vitals, improving LCP, optimising INP and minimising CLS.
A Worked Example
Illustrative scenario, not client data
A store owner notices that new product pages take weeks to appear in Google, and some never do. The instinct is to blame page speed. Here is how the audit order changes the conclusion.
- Penalty check: Manual actions and Security issues are both clean.
- Page indexing report: hundreds of product URLs sit under "Crawled, currently not indexed" and "Duplicate without user-selected canonical". That is the real signal.
- URL Inspection: a missing product is crawled but the Google-selected canonical points to a filtered category URL, not the product page. The site generates many near-identical URLs through filters and sorting.
- Crawl: Screaming Frog confirms thousands of parameter URLs competing with the clean product URLs, splitting signals and burning crawl activity.
- Core Web Vitals: the product template passes comfortably. Speed was never the problem.
Conclusion: the fix is canonicalization and crawl control, not speed. Set a self-referencing canonical on each product page, stop filtered and sorted URLs from being indexed, and keep the sitemap to clean product URLs only. Once Google settles on one canonical per product, indexing catches up. Rewriting images or deferring scripts would have wasted the week and fixed nothing.
Ask Google about any URL from inside the chat.
Murkuz connects Google Search Console, Analytics 4 and Bing Webmaster Tools to Claude or ChatGPT, read-only. Inspect_URL returns Google's own index status and chosen canonical for a page, and Search_Analytics shows whether a page's clicks and impressions moved after a fix. It reads your data; it does not change your site.
Common Audit Mistakes
Starting with page speed
A fast page that Google cannot crawl or has excluded from the index earns nothing. Confirm crawling and indexing first, then optimise speed on the pages that are actually reachable.
Treating every crawler warning as urgent
Audit tools flag hundreds of issues by severity, not by impact on your site. A missing meta description on a noindexed tag page does not matter. Sort by what affects indexable, important pages and ignore the noise.
Fixing symptoms instead of causes
One broken link is a symptom; a template that generates broken links on every page is the cause. Group issues by pattern and fix the template, not the thousand pages it produced.
Auditing once and never rechecking
An audit is a snapshot. A migration, a plugin update or a new section can undo a fix overnight. Recheck the Page indexing and Crawl stats reports regularly so new errors surface while they are small.
Ignoring the rendered HTML on JS sites
Viewing the raw source is not enough when a framework builds the page in the browser. Always confirm, in the live test, that Google sees your main content and internal links after rendering.
Once the technical path is clear, the next question is whether the pages deserve to rank. Our guides to what an SEO audit tool does and the best SEO audit tools help you decide when a free crawl is enough and when to pay for scale.
Further reading
The most useful material on technical SEO auditing, starting with Google's own documentation. Each one was read in full before it was added here.
Official docsGoogle Search Central
Overview of crawling and indexing topicsGoogle's own hub for how crawling and indexing work, linking the authoritative pages on robots.txt, sitemaps, canonicalization and crawl management. Start here when you want the source of truth on indexability.
Official docsSearch Console Help
URL Inspection toolDocuments the single most useful free audit tool: how to read a page's live index status, see the crawled and rendered HTML, spot what is blocking indexing, and request indexing after a fix.
Official docsweb.dev, Philip Walton
Web VitalsThe canonical definition of Core Web Vitals, with the exact Good thresholds for LCP, INP and CLS and the tools that measure each. The grounding for the performance part of any audit.
ReferenceChrome for Developers
Introduction to LighthouseExplains Lighthouse, the free auditing engine behind many performance and SEO checks, and the several ways to run it (DevTools, CLI, Node, the web UI) so you can repeat the audit on a schedule.
GuideAhrefs, Patrick Stox
The Beginner's Guide to Technical SEOA thorough practitioner walkthrough of crawling, indexing, robots directives, canonicalization and Core Web Vitals, in plain terms. A strong companion that mirrors the audit workflow on this page.
Frequently Asked Questions
What is a technical SEO audit?
A technical SEO audit is a systematic check of the parts of a site that decide whether search engines can crawl it, index it and serve it well: crawlability, indexability, canonicalization and redirects, site structure, and page speed or Core Web Vitals. It is not about the words on the page or the links pointing at it. The goal is to find the technical problems that quietly cap what the rest of your SEO work can achieve, then fix them in order of impact.
How do I do a technical SEO audit myself?
Work from the problems that override everything else down to the ones that take the most effort to prove. Start in Google Search Console: check Manual actions and Security issues, then the Page indexing report to see what Google has and has not indexed and why. Inspect a few important URLs with the URL Inspection tool to confirm the indexed status and the canonical Google picked. Crawl the site with a tool such as Screaming Frog to find broken links, redirect chains and duplicate titles. Finally run Lighthouse or PageSpeed Insights on your key templates for Core Web Vitals. Fix crawling and indexing first, because speed work on a page Google cannot reach changes nothing.
What does a technical SEO audit check?
Four areas. Crawlability: can search engines discover your pages, and is robots.txt or an accidental block in the way. Indexability: are the right pages indexed, and are noindex tags, canonicals or thin pages keeping the wrong ones in or out. Structure and links: is the hierarchy logical, are there redirect chains, broken internal links or orphan pages. Performance and rendering: do pages pass Core Web Vitals, is important content present in the rendered HTML, and is the site usable on mobile.
Can I do a technical SEO audit for free?
Most of it, yes. Google Search Console, the URL Inspection tool, Chrome DevTools, Lighthouse and PageSpeed Insights are all free, and the free tier of Screaming Frog crawls up to 500 URLs, which covers many small sites completely. Paid crawlers and monitoring tools mainly add scale for large sites, scheduling and historical tracking. For a site with a few hundred pages you can run a complete audit without paying for anything.
How often should I run a technical SEO audit?
A full audit once or twice a year is enough for most sites, plus a fresh audit after any migration, redesign or platform change. Between audits, rely on monitoring rather than repeating the whole thing: watch the Page indexing and Crawl stats reports in Search Console and act on new errors as they appear. Large or fast-changing sites benefit from more frequent crawls because problems accumulate faster.
What is the difference between a technical SEO audit and a content audit?
A technical audit asks whether search engines can access and understand your site at all. A content audit asks whether the pages deserve to rank once they can: relevance, depth, freshness and search intent. They are complementary. There is no point improving content on pages that are blocked from indexing, and no point fixing crawl paths to pages nobody wants to read. Run the technical audit first to clear the path, then work on content.
How do I check whether Google can crawl and index my site?
Open the Page indexing report in Search Console to see how many pages are indexed and the reasons any are excluded, such as blocked by robots.txt, noindex, duplicate without a chosen canonical, or crawled but not indexed. Then run the URL Inspection tool on a few important pages to confirm the live status and the Google-selected canonical. Check your robots.txt file for rules that block folders you want crawled, and make sure your XML sitemap lists only final, indexable URLs.