How to Perform a Technical SEO Audit

Think of a technical SEO audit like a home inspection before buying a house. You are not redecorating yet — you are checking if the foundation is cracked, the plumbing works, and the doors actually open. The crawl is your flashlight. [Search Console](/seo-audit/) is the blueprints. Together, they show you what Google can and cannot see. I run a crawl with Screaming Frog or Sitebulb first, then pull Search Console's coverage report and sitemap status. The crawl gives me raw URLs, status codes, meta robots tags, and internal link counts. Search Console tells me how Google actually sees those URLs — which ones are indexed, which are excluded, and why. If you only crawl, you miss the difference between 'crawled but dropped from index' and 'crawled and indexed.' That difference changes what you fix.

A solid audit covers four layers: crawlability, indexability, rendering, and performance. Crawlability means your important pages are reachable via internal links and not blocked by robots.txt or login walls. Indexability means those pages have no noindex tag, a correct canonical, and no redirect chain that ends somewhere irrelevant. Rendering matters when your site depends on JavaScript to load key content — Google might see an empty div. Performance covers Core Web Vitals, mobile-friendliness, and server response times. I check each layer, but I always handle crawlability and indexability before touching page speed. A fast page that is not indexed helps no one.

I have stopped counting how many audits I have seen that list 200 issues without any priority. A good audit does not just dump problems — it tells you which one to fix first. I use a simple rule: anything that blocks indexing of a page that drives revenue or traffic gets fixed today. Everything else goes on a backlog. That is the difference between an audit that gathers dust and one that changes the site's performance within a week.

After a site migration. That is the single most common moment to run a technical audit. I worked on a domain migration last year where the new site looked fine to the marketing team, but the crawl revealed that 60% of the old URLs returned a 404 with no redirect. Google was already dropping those pages from the index. We had lost three weeks of traffic before anyone noticed. A post-migration audit should be run within 24 hours of go-live, then again after a week to catch any deferred redirects or missing [canonical tags](/canonical-tag/).

Before a major content push. If you are launching a new section, adding 500 product pages, or running a campaign, you need to confirm the infrastructure is ready. I check robots.txt to make sure the new paths are not accidentally blocked, and I verify the sitemap includes the new URLs. I once launched a campaign with 200 landing pages only to find the [robots.txt](/robots-txt/) had a disallow for the entire campaign folder that had been there since the last site redesign. That cost two weeks of zero organic traffic.

When traffic drops unexpectedly. A sudden loss of organic traffic often points to a technical issue — a rogue noindex directive from a developer release, a sitemap that stopped updating, or a server change that increased response times. I always check the Search Console coverage report first. If the number of indexed pages has dropped, I look for recent changes to [directives](/directive/) or redirects. If the pages are still indexed but rankings fell, I check [Core Web Vitals](/core-web-vitals/) and mobile usability. Performance regressions can happen overnight after a code deployment, and they can cause Google to demote pages within days.

Some people tell you to audit every quarter regardless. I do not believe in calendar-based audits. I audit when something changes or when something breaks. Running an audit on a static blog every three months is a waste of time — you will find the same minor issues. Save your audit for moments that actually matter.

Running a crawl without checking Search Console first. I did this for years. I would find 400 broken links, spend hours documenting them, then open Search Console and see that Google had already excluded those URLs from the index — they were old, orphaned pages that nobody visited. The real problem was that my main product pages were not in the sitemap at all, but I missed that because I did not cross-reference the coverage report. Now I open Search Console before I even launch the crawler. I load the sitemap report and the index coverage report, export the lists, then feed those lists into the crawler as a seed. It saves me three hours per audit.

Prioritising page speed over crawlability. I used to think that making the site fast was the most impactful fix. Then I ran an audit for a client whose homepage was loading in under two seconds, but the entire category section was blocked by a noindex tag that a developer had accidentally applied. I had spent a week optimising images and deferring JavaScript while the real issue was right there in the meta tags. Now I fix crawlability and indexability first, then performance. A slow but indexable page still has a chance. A fast page that no search engine can find is a ghost.

Not checking mobile rendering separately. I assumed that if a site passed the mobile-friendly test, Google could render the content. Then I found a site whose navigation collapsed on mobile due to a CSS grid bug, and Google could not reach any subpages because the mobile menu items were not actually links in the rendered HTML. The desktop crawl showed perfect internal linking, but the mobile crawl showed a site with just a homepage and a contact page. Now I always run a separate mobile crawl or use a tool that renders pages as Googlebot Smartphone. The difference can be stark and expensive.