How to Conduct a Technical SEO Site Audit

I think of a technical SEO audit as a plumbing check on your site's relationship with Google. You are not looking for better content or more backlinks — you are checking whether Googlebot can crawl, render, and index your pages. If the pipes are blocked, nothing else matters. I break the audit into three buckets: crawlability, indexability, and rendering. Crawlability covers things like [robots.txt](/robots-txt/) rules, XML sitemaps, redirect chains, and 404s. Indexability includes [canonical tags](/canonical-tag/), noindex directives, and duplicate content. Rendering is about JavaScript execution and structured data. On a recent audit, I found 4,000 pages returning a 302 redirect because the CMS added a trailing slash in the wrong place. Google ignored half of them. The fix was one line in .htaccess. That is why I start with a simple crawl and a look at Google Search Console's Coverage report. A decision rule I use: if you have under 5,000 pages, focus on crawlability and indexability first. Above 10,000, prioritise rendering and crawl budget. Some practitioners argue you should always start with page speed because it is a ranking factor. I disagree. If Google cannot find the page, speed does not matter. I have seen sites with perfect Lighthouse scores but zero organic traffic because the sitemap was misconfigured. So the order matters. I also check for [Technical SEO](/technical-seo/) basics like whether the site uses HTTPS and has a logical URL structure. These are quick wins that often get overlooked.

A technical SEO audit is not something you do once and forget. It matters most when something changes. New site launch: I audited a site that went live with 200 pages but only 12 indexed because the sitemap was hardcoded to a staging URL. Traffic was zero for two weeks. After a migration: I worked on a site that changed domain without mapping old URLs. They lost 80% organic traffic and it took three months to recover. The fix was a set of [301 redirects](/301-redirect/) that I should have implemented before launch. Traffic drops: before you blame an algorithm update, check the Coverage report. I once saw a drop of 70% that turned out to be a misconfigured robots.txt blocking the entire site. Fixed in five minutes. Edge case: heavy JavaScript sites. Standard crawlers miss a lot. You need to test the rendered DOM. I use Google Search Console's URL Inspection tool to check if the page content appears. If not, I investigate [JavaScript SEO](/javascript-seo/) issues. Some people say audits are only necessary for large sites. I disagree. Small sites have the same issues, just fewer pages. A missed canonical tag can hurt a 100-page site as much as a 100,000-page site. I now run a mini-audit every time I push a significant code change. It catches regressions before they become critical. For example, adding a new plugin often changes robots.txt — I have seen that happen twice. So the audit is not a one-off; it is a recurring health check.

I used to treat every 404 as an emergency. Now I check Google Search Console data to see if those URLs ever had traffic. If a 404 URL never got any organic visits, redirecting it is lower priority. I wasted hours doing that. I also ignored log files for years. I assumed the crawl budget was an SEO myth. Then I saw a client's server logs showing Googlebot hitting the same session-heavy URLs 50 times a day while ignoring new product pages. After blocking the session URLs in robots.txt, indexation doubled within two weeks. That changed my approach entirely. I also spent too much time fixing duplicate content warnings from the crawler, when Google was handling them fine. The real issue was a missing canonical on a homepage that had 8 versions. Fixing that one tag recovered 15% of traffic. That taught me to analyse [duplicate content](/duplicate-content/) reports with scepticism — not every similarity is a problem. Another mistake: I used to crawl the entire site without setting a scope. I would find thousands of warnings for staging URLs, admin pages, and tag pages that did not matter. Now I define a scope: only the production site, only the sections I care about, and I exclude obvious junk. I also missed JavaScript rendering issues for years. I checked the HTML source and thought everything was fine. Then I started using a headless browser and discovered half the content was loaded dynamically and not indexed. So I now include a rendering test in every audit. In short, prioritisation is the skill, not detection.