Technical SEO audit: the five things we check before anything else

Technical SEO is the part of the discipline that's least visible and most likely to quietly cap everything else you're doing. Great content on a page Google can't properly crawl or index is invisible no matter how good it is. Before touching keywords or content strategy, we run the same five checks on every new site, because fixing a technical problem is often the fastest visibility win available.

We pull the site's coverage report and check for pages accidentally blocked by robots.txt, noindex tags left over from a staging environment, or a sitemap that's stale or missing entirely. This sounds basic, and it is, which is exactly why it gets missed: nobody expects a live production site to have a leftover noindex tag from before launch, but we find it more often than you'd think, sometimes on pages that should be driving significant organic traffic.

Ecommerce sites in particular tend to generate multiple URLs for the same product through filtering and sorting parameters. Without proper canonical tags, that splits ranking signal across near-duplicate pages instead of consolidating it onto one. We check whether canonical tags exist, and more importantly whether they actually point to the right version, since a canonical tag pointing to the wrong URL is arguably worse than having none at all.

We pull real field data from Search Console rather than a single lab test, and flag any template that's failing the LCP, INP, or CLS thresholds for a meaningful share of visitors. This overlaps with pure performance work, but from an SEO audit it matters specifically because it's a ranking signal, not just a user experience one, and fixing it serves both goals at once.

Schema markup that's present but malformed is nearly as useless as having none, since search engines simply skip invalid markup rather than partially using it. We validate every schema type in use against Google's actual requirements, not just check that a script tag exists somewhere on the page, using the same testing tools search engines use to parse it.

Pages with no internal links pointing to them are effectively invisible to both crawlers and users, no matter how good the content is. We map the internal link graph and flag orphaned pages, which are almost always older content that quietly stopped getting traffic once the navigation or related-content modules changed, and which are usually simple to fix once identified.

On one audit, we found that a client's entire blog subdirectory had been accidentally excluded from the sitemap during a platform migration eight months earlier. Organic traffic to that section had been quietly declining the whole time, and nobody had connected the dip to a technical cause because the content itself hadn't changed.

Google's indexing is mobile-first, meaning the mobile version of a page is what actually gets evaluated for ranking in most cases. A site that looks fine on desktop but has content hidden or broken on mobile, sometimes deliberately, sometimes by accident, is effectively showing Google a worse version of itself than most visitors realize.

A sitemap listing pages that return errors, redirect elsewhere, or are marked noindex sends mixed signals to search engines and wastes crawl budget on pages that shouldn't be prioritized. We audit sitemap contents against actual page status, not just confirm a sitemap file exists at the expected URL.

A full technical audit isn't a one-time exercise. We recommend a lighter version quarterly and a full audit annually, since platform updates, plugin changes, and content migrations all introduce new technical issues over time even on a site that started in good shape.

An audit often surfaces more issues than are worth fixing immediately. We rank findings by estimated traffic or revenue impact against estimated effort to fix, and present that prioritized list to the client rather than a flat list of everything that's technically wrong, so limited engineering time goes toward the fixes that will actually move the needle first.

A platform migration is the highest-risk moment for technical SEO, since URL structures, redirects, and page templates can all change at once. We run this same audit against the staging version of the new site before launch, specifically to catch regressions before they go live rather than discovering them in a ranking drop weeks after migration.

Most audits happen on familiar platforms, WordPress, Shopify, a standard Next.js build, where we know exactly where to look for common issues. For a genuinely custom or unusual platform, we spend additional time upfront understanding how that specific system handles rendering, redirects, and metadata before running the standard checklist, since assumptions that hold for common platforms don't always transfer directly to a bespoke system built differently.

We also maintain a running library of past audit findings across client sites, anonymized, which helps us recognize recurring patterns faster on a new client's site rather than starting the diagnostic process completely from scratch each time. Certain platforms and certain common implementation mistakes show up again and again across otherwise unrelated client sites, and this accumulated pattern recognition consistently speeds up how quickly we can identify a new client's most impactful technical issues during that crucial first audit.

A technical audit full of crawl-budget jargon and status-code tables is useless to a marketing lead who has to decide what gets prioritized. We translate every finding into plain business language, this page isn't showing up in search because of X, and fixing it should recover roughly this much of the traffic it used to get, so the person making the prioritization call understands the actual stakes without needing to understand the underlying technical mechanism.

We've found this translation step matters more for getting fixes actually implemented than the technical accuracy of the audit itself. A perfectly accurate audit that never gets acted on because nobody understood why it mattered accomplishes nothing, and we'd rather sacrifice a little technical nuance in the writeup than lose a fix to a communication gap between the SEO work and the people who control the engineering backlog.

We also flag which findings are quick wins a client's own team could fix within a day versus which ones genuinely need developer time on our side, so the client isn't waiting on us for something they could resolve themselves that same afternoon, and isn't attempting a fix in-house that's more involved than it initially looks.