Technical SEO Audits

Think of a technical SEO audit as a health check on your site's infrastructure. I am not reviewing content or design — I am checking whether Google can reach, read, and trust the pages. The checks I run are mechanical: robots.txt blocks, sitemap coverage, canonical signals, redirect chains, crawl errors, and page speed. I start in Google Search Console's Coverage report because it shows exactly which URLs returned errors, warnings, or were excluded. Then I export a full crawl from Screaming Frog and filter by status code, canonical, and noindex. I have learned to cross-check the crawl results against Search Console because tools can misread JavaScript-rendered pages. Last month on a 500-page ecommerce site, Screaming Frog flagged 60 canonical tags as self-referencing — but Search Console showed those pages were actually being indexed correctly because the canonical element was being injected late by the theme. The tool's crawl had captured the pre-rendered state. That counter-example changed how I audit: I now always verify canonical issues against what Google actually sees. Another number: in a recent audit of a news publisher, I found 23 orphan pages — pages with no internal links — that were accumulating crawl errors because Google discovered them via external backlinks but could not re-crawl them efficiently. Fixing the internal linking structure boosted the crawl rate by 40% in two weeks. The decision rule I apply now: if a page is important, it must have at least one contextual internal link from another page on the same domain. No exceptions. I also double-check the [SEO audit](/seo-audit/) checklist alongside Search Console's URL Inspection tool to catch silent redirects and [duplicate content](/duplicate-content/) signals that tools miss.

I schedule audits monthly, but there are five situations where I drop everything and run one immediately. The first is after a site migration. Moving a domain, changing URL structures, or switching platforms often breaks redirects, updates canonicals incorrectly, or introduces rendering issues. I once migrated a client from WordPress to a headless CMS and spent eight hours fixing orphaned hreflang tags because the development team had hardcoded them in the old template. Second: a sudden traffic drop. If you see a 30% decline in organic traffic overnight, check the Coverage report for a manual action, a spike in 404s, or a new noindex directive. Third: before a content push. If you are publishing 100 new pages, ensure the [sitemap](/sitemap/) is updated, the internal links point to live URLs, and no canonical tag accidentally points to an old page. Fourth: quarterly for large sites. In a 10,000-page site, crawl issues accumulate faster than you can fix them — one misconfigured plugin can inject a noindex on every category page. Fifth: after a major CMS or plugin update. I have seen a WordPress SEO plugin update strip all canonical tags from a site because the developers changed the output filter. The edge case newer practitioners overlook: a site that has not changed in months can still suffer technical problems. Google changes its rendering engine, its mobile-first approach, and its interpretation of structured data. What worked last year might be broken today. For example, Google's switch to rendering pages with a newer Chrome version caused a client's JavaScript-generated canonical tags to disappear because the library they used was deprecated. Always validate your [301 redirect](/301-redirect/) chain after any platform update — a single broken hop can cascade into lost link equity.

I used to treat the audit as a one-time checklist. I crawled a site once, fixed the obvious 404s, and called it done. But sites are living systems — someone deploys code, changes a template, or adds a plugin, and suddenly a [robots.txt](/robots-txt/) rule blocks the entire blog section. I now run a monthly audit even on sites that claim 'nothing has changed.' Another mistake: I trusted crawl tools blindly. Screaming Frog would flag a page as having a missing title tag, and I would add one without checking if the page was actually being indexed. I wasted hours on pages that were noindexed or blocked. The real cost was not the time — it was that I ignored indexation and canonical issues which silently drained traffic. I once spent a full day fixing 404s on a site, only to realise the real problem was a self-referencing [canonical tag](/canonical-tag/) on every product page that pointed to a URL with a trailing slash that did not exist. Google was not deindexing the pages, but it was consolidating link equity to a page that returned a 404. That cost the client about 15% of their organic traffic for six weeks before I caught it. I also used to speed through the [Core Web Vitals](/core-web-vitals/) report. I would see a 'pass' on CLS and move on, but LCP was borderline. I did not prioritise it because I thought 'pass' was enough. In one case, a competitor with slightly lower content quality but better LCP outranked us on a high-volume query. Now I treat any LCP above 2.5 seconds as a red flag, even if Google marks it as 'needs improvement' rather than 'poor.' The lesson: crawl errors are visible; canonical and indexation mistakes are invisible until you measure their cumulative effect.