Technical Website Audit

A technical website audit is not a report you hand over and forget — it is a diagnostic process that I run before anything else touches the site. It focuses on four layers: crawlability (can Googlebot reach the page?), indexability (will Google store it?), performance (does it load fast enough?), and security (is HTTPS and malware clean?). I once had a client with 15,000 URLs but only 2,000 indexed because a misconfigured robots.txt disallowed half the site. That fix took ten minutes and recovered 8,000 pages in two weeks.

A technical audit deliberately ignores content quality, UX, and branding. That is its strength: it isolates the foundation. If Google cannot crawl or render your pages, all the keyword research in the world is wasted. I always start with a crawl before touching anything else. For very small sites under fifty pages, I sometimes skip the crawl tool and go straight to [Google Search Console](/seo-audit/) coverage reports, but every site gets a performance check via PageSpeed Insights.

Some argue that technical audits are overkill for small blogs. I have seen a single misapplied [canonical tag](/canonical-tag/) on a twenty-page site waste six months of link building because Google treated every page as a duplicate. The audit is quick for small sites but still necessary. My rule: if you have more than one page you care about, run a technical audit before any content campaign.

It matters most before an SEO campaign, after a migration, after a redesign, and when traffic drops without explanation. I learned this the hard way: a client migrated from HTTP to HTTPS and I forgot to update the sitemap. Within two weeks, 80% of their indexed pages disappeared from Google. A simple crawl would have caught the old URLs still pointing to HTTP 200s. That migration cost them £15,000 in lost revenue.

The audit matters differently depending on the site type. E-commerce sites with faceted navigation generate massive duplicate content from filters and sort options. Without a proper [robots.txt](/robots-txt/) or noindex strategy, Google wastes crawl budget on hundreds of near-identical category pages. I have seen a site waste 60% of its daily crawl budget on filter URLs that no one searches for.

For sites using [JavaScript SEO](/javascript-seo/), the audit must include rendering checks. JavaScript-heavy frameworks often hide content from Googlebot if the server response is slow or the bundle breaks. I run a render test via Google's URL Inspection Tool on every key page. If the rendered HTML does not contain the main text, I push for server-side rendering or dynamic rendering.

Performance matters more than many admit. I have audited sites with perfect [Core Web Vitals](/core-web-vitals/) scores but no noindex tags on product pages — all that speed was wasted. Conversely, I have seen sites with slow Largest Contentful Paint still rank because the content was unique and authoritative. Speed matters, but it is one signal among many. My decision rule: fix speed issues that affect user conversion first, then move to crawl and index problems.

I used to treat the technical audit as a one-time checklist I ran during site launch. For a client in 2021, I delivered a thirty-page audit, fixed everything, and declared it done. Six months later their traffic dropped 40% because a well-meaning developer installed a plugin that injected noindex on all new blog posts. I had no monitoring in place. Now I run a stripped-down crawl every month using the same tool and compare the results against the baseline.

Another mistake: I ignored mobile for too long. Early in my career I only checked desktop crawlability. But Google is mobile-first, so I now test every critical page on a mobile viewport via Chrome DevTools, checking that menus are reachable and content is not hidden behind JavaScript toggles. A client's mobile menu used display: none on the CSS that also hid the navigation links from Googlebot. I missed it for three months.

I also over-relied on crawl tools. Screaming Frog might report a 200 status, but Google may see a soft 404 because the page contains minimal content. I learned to cross-reference crawl data with Search Console's index coverage and with the actual rendered HTML. A page that returns 200 but contains only a generic error message is worse than a true 404 because Google wastes time trying to index it.

Finally, I thought performance only affected user experience. Then I read Google's documentation on crawl budget: slow pages are crawled less frequently. A page that takes eight seconds to load might not be revisited for weeks. That means new content on that page stays undiscovered. Now I check server response time and [sitemap](/sitemap/) freshness alongside Core Web Vitals. The crawl delay is real and it hurts sites with thin content.