Technical SEO audit: a checklist of what stalls a site

More often than not, a site isn't stalled because it lacks content or links — it's stalled because it gets in its own way: some pages are accidentally blocked from indexing, the index is full of junk, products have two H1s each, and the sitemap still lists URLs deleted months ago. The owner sees only the outcome — "we're not ranking for our terms" — and goes off to buy more links, when the real problem sits lower, in the foundation. A technical SEO audit is an end-to-end check of that foundation: on a large catalogue a single pass crawls thousands of URLs and raises hundreds of flags, sorted by priority. Below is the working checklist, by class of error. For each one I give how to detect it and how to fix it — and I'm honest about where the fix won't help.

Indexation: accidental noindex, junk in the index, robots and sitemap

The first thing in any audit: is the page you actually want to rank even allowed to be indexed? The most common — and most expensive — error is an accidental noindex. It lands on a page a dozen ways: a checkbox in the SEO plugin, inherited category settings, a staging mode left on after migration, a page-builder template (Elementor, Avada, Tilda) with a default noindex on certain types. You find it by crawling the site (Screaming Frog, Netpeak Spider, your own script) and reading the Meta Robots column plus the X-Robots-Tag HTTP header — the header is sneaky because it isn't visible in the HTML, it's set server-side. On a ~500-product catalogue, finding 3–5 commercial pages with a stray noindex is the norm, not the exception.

The mirror problem is junk in the index — pages that get crawled and indexed but shouldn't be: filter and sort URLs (?sort=price, ?color=red), internal search results, cart pages, tag pages, print versions, empty pagination. Each one burns crawl budget and dilutes relevance. To find it, open Google Search Console (and Yandex Webmaster) under Indexing / Pages, sort by type, and use the site: operator with parameter filters. On a large catalogue, several thousand parameter duplicates leak into the index without anyone noticing.

robots.txt and sitemap.xml are the two files that break indexation most often. Typical findings: robots.txt blocking /catalog/ entirely (yes, we've seen that after a botched migration), a sitemap listing 404 URLs, non-canonical addresses, or noindex pages — a direct contradiction: you're telling the engine to index and not-index the same URL. The fix: in robots.txt keep only genuinely utility sections blocked, and generate the sitemap dynamically from indexable, canonical, 200-returning URLs only. Then submit the sitemap for recrawl and watch the "excluded" trend in webmaster tools. Recovering an index from around 1,700 excluded down to roughly 150 on a live project takes weeks of passes, not one click.

Duplicates and canonicals: why your authority gets smeared

Duplicate content means the same page is reachable at several URLs and the engine can't tell which is the original. Classic sources: one product in multiple categories (/category-a/product and /category-b/product), www vs non-www, http vs https, trailing slash vs none, upper vs lower case, the homepage at both / and /index.php. The engine splits signals across the copies, and none of them gathers enough authority to reach the top. That's exactly where the "we keep working but nothing moves" feeling comes from.

The fix is the rel=canonical attribute: every page declares its absolute canonical URL. Duplicates point to the master version; the master points to itself (a self-referencing canonical is mandatory — its absence is a flag too). In an audit we don't just check the tag exists, we check it's correct. Frequent failures: a canonical pointing every page back to the homepage (we've seen this after a misconfigured plugin — the whole site collapsing into one URL in the engine's eyes); a canonical pointing to a noindex page; a canonical pointing to a 301 redirect. Each combination is interpreted its own way, usually not in your favour.

A separate item: http/https and www. There must be exactly one primary host, with everything else 301-redirecting to it. One-minute check: hit all four homepage variants (http, https, www, non-www) and confirm the three "wrong" ones return a 301 to the single canonical. If even one returns a 200, the engine sees four copies of your site. In practice, unmerged hosts are a common reason a young site "just won't consolidate" in the results.

H1 and meta tags: multiple, empty, templated

The H1 is the page's main heading, and there should be exactly one. Page builders (Avada, Elementor, Divi) and Bitrix/WordPress themes routinely emit two or three: one on the logo, one in the slider, one that's the real title. On a ~150-page catalogue, finding 20–30 pages with multiple or missing H1s is a typical picture. A crawler surfaces it in a single pass via H1-1, H1-2, H1 Count columns. Fix it in the template (the right way) or page by page — across many pages it's faster through the CMS API than by hand.

Title and meta description are what the user sees in the results and how the engine reads the page's topic. Three error types: empty (auto-generated from a filename, or missing), duplicated (the same title across hundreds of product cards — "Buy — Store Name"), and over-optimised (a comma-separated keyword dump that gets truncated in the snippet and reads as spam). A crawler shows duplicate titles/descriptions and their length. Length matters — titles truncate around 60 characters, descriptions around 150–160; anything longer won't fit the snippet.

On large catalogues you don't write these by hand — you write templates with substitution: "{Product} in {City} — price, specs, reviews | {Brand}". The template must produce a unique, readable, non-truncated title across thousands of pages. An honest caveat: a beautiful unique title doesn't push you to the top by itself — it improves click-through and helps the engine with topicality, but without real content and links it won't carry the page. This is hygiene, not a growth lever.

Speed and Core Web Vitals: what actually matters

Speed is a ranking factor, but not the decisive one people like to scare you with. Google measures three Core Web Vitals: LCP (how fast the main block renders, target < 2.5s), INP (responsiveness to user input, target < 200ms, which replaced FID in March 2024), and CLS (how much the layout shifts during load, target < 0.1). Key point: the score is based on field data from real users (CrUX), not on a lab test in PageSpeed. That's why "90 in PageSpeed" and a genuine speed problem can coexist happily.

What most often drags down the sites we audit: unoptimised images (product photos at 2–4 MB instead of 100–200 KB in WebP), no lazy-loading, heavy page-builder scripts, and a dozen third-party tags — chats, analytics, pixels, widgets — loaded synchronously and blocking render. CLS is usually broken by banners and images without explicit width/height: the layout jumps and the user mis-taps. Diagnose with PageSpeed Insights (field plus lab data), WebPageTest, and the Core Web Vitals report in Search Console — the last one groups similar URLs rather than showing one page, which is far more useful for a catalogue.

Honest prioritisation: if indexing is blocked and duplicates are smearing your authority, fix those first and speed later. Going from a 4-second LCP to 2 seconds rarely produces a ranking jump on its own; it removes a ceiling and improves user behaviour signals. Chasing green PageSpeed numbers for the sake of the number is a hobby; chasing real perceived load time for the user is worth it.

Broken links, redirects, schema and alt

Broken links (404s) and messy redirects waste crawl budget and hurt the experience. We look for two classes: internal links to non-existent URLs (you're linking into the void — after removing products or restructuring) and redirect chains (URL-A → URL-B → URL-C → target: every hop loses authority and crawler time). A crawler shows both Response Codes and Redirect Chains. The rule is simple: internal links should point straight at the final 200 URL, never through a 301; internal 404s are fixed by restoring the page, updating the link, or a clean 301 to the nearest equivalent.

Structured data (Schema.org / JSON-LD) isn't a direct ranking factor, but it's what earns rich snippets: price, rating, availability, breadcrumbs, FAQ, the organisation card. Without it your snippet is a bare line while a competitor's shows stars and a price — and the click goes to them. In the audit we check three things: does the markup exist, is it valid (Rich Results Test and the Schema Markup Validator), and is it honest (the rating in the markup must match what's visible on the page — Google strips rich results for faking it). On catalogues we deploy Product + Offer + AggregateRating; on services, Service and FAQPage; site-wide, Organization and BreadcrumbList.

Image alt is the attribute that describes a picture. It's needed for accessibility, for image search, and as a supplementary text signal. On a WooCommerce catalogue with 8,000+ images, alt is usually filled on 20–30%. You can't do that by hand — you mass-update through the CMS API by template, "{product} — {category} — {angle}". Honestly: alt is a weak ranking signal for regular search, but a meaningful one for image search and non-negotiable for accessibility; on a catalogue it's also the only way to keep thousands of images from being completely undescribed.

Mobile, and turning it all into a prioritised plan

Google indexes sites by their mobile version (mobile-first has been the default for years), so if your phone view has trimmed content, unreadable text, cramped buttons or horizontal scroll, that's precisely the version you're being ranked on. We don't check "is the design responsive in principle" — we check specifics: does mobile content match desktop (a common sin is hiding half the page's text on mobile for "cleanliness"), are tap targets large enough, is the font legible without zoom, does the layout stay within the viewport. Tools: device mode in DevTools and the mobile usability reports in webmaster tools.

The most important part of an audit isn't the length of the flag list, it's the prioritisation. A full pass over a large catalogue yields thousands of URLs and hundreds of findings; dump them all at once and the client drowns. So we sort by P0/P1/P2. P0 is whatever directly blocks indexing and traffic (a stray noindex on commercial pages, robots blocking the catalogue, unmerged hosts). P1 is what dilutes and slows (duplicates without a canonical, redirect chains, multiple H1s, missing schema). P2 is hygiene and polish (alt, title length, minor CLS). Close P0 first, then P1, with P2 running in the background.

And the honest part to end on: a technical audit doesn't produce growth by itself. It removes what's preventing growth — it lifts a ceiling. After it, the site stops suppressing itself and becomes able to grow on content, semantics and links. Without that foundation, every investment in content and link-building works at half-throttle — you're pouring water into a leaky bucket. So the audit isn't a one-off checkbox; it's the point where meaningful promotion can begin at all.