Technical Audit SEO: How to Run Audits That Move Rankings

A technical SEO audit is a structured, end‑to‑end check of crawlability, indexation, site speed, rendering, structured data and internal linking. The goal isn’t a 90‑page PDF — it’s a ranked backlog of fixes with owners, estimates and measurable upside.

On a typical mid‑size Shopify or WordPress site, we complete the core audit in 2–4 weeks, then support implementation and monitoring for 4–12 weeks. Expect immediate quick wins (status codes, sitemaps, broken links), medium‑term gains from speed and rendering, and durable lifts from restructuring internal linking.

What a technical SEO audit covers

Here’s the short version of our checklist. We prioritise issues by impact vs effort, not by how easy they are to screenshot.

• Crawlability and indexation: robots.txt, meta robots, canonical tags, XML sitemaps, pagination, parameter handling, faceted navigation, duplicates and near‑duplicates.
• Status codes and redirects: 2xx/3xx/4xx/5xx distribution, redirect chains/loops, soft 404s, canonical to non‑indexable, mixed http/https, www/non‑www.
• Site speed and Core Web Vitals: LCP, CLS, INP from field data (CrUX/Chrome UX) and lab tests (Lighthouse/WebPageTest). Asset weight, images, third‑party scripts, caching/CDN.
• JavaScript rendering: hydration delays, content behind JS, blocked resources, isomorphic/SSR setup for frameworks, Shopify theme bloat.
• Structured data: JSON‑LD for Product, Article, Organisation, Breadcrumb, FAQ; schema correctness vs UI; merchant listings for ecom.
• Internal linking and IA: depth to money pages, orphan pages, anchor text, breadcrumbs, collection architecture, canonical clusters.
• Logs and monitoring: Googlebot behaviour, crawl waste, recurring errors, delta tracking after fixes.

If you’d rather we run this for you, our Technical SEO service packages the audit, implementation support and monitoring.

Our audit workflow and tooling

We don’t overcomplicate the workflow. We collect the data once, store it, then slice it any way we need.

• Crawl: Screaming Frog at scale with custom extraction (XPath/JS rendering on), plus Sitebulb for visualisation and hints. We crawl all templates, parameters and paginated sets.
• Search Console and analytics: GSC API exports (coverage, sitemaps, performance, CWV), GA4 landing page and conversion data to gauge business impact, not just traffic.
• Field performance: CrUX/BigQuery for real user CWV; Lighthouse and WebPageTest for lab. We always reconcile field vs lab — lab alone is a trap.
• Server and CDN: origin headers, cache status, edge cache rules (Cloudflare), image transformation, and TLS settings.
• Structured data: Google Rich Results Test API, schema linting, and diffing schema vs page reality (e.g., price/availability/aggregateRating).
• Logs: ingest raw access logs into Postgres or BigQuery; aggregate Googlebot hits, 404s, and chain length. A simple Looker Studio dashboard suffices.
• Automation: n8n flows to fetch GSC data nightly, dedupe URLs, alert on regressions; DataForSEO for SERP snapshots and cannibalisation checks.
• Platform APIs: Shopify Admin API/GraphQL for product/collection data, metafields, inventory and canonical rules; CMS APIs for templated fixes.

We keep all sources in a single dataset (Postgres or BigQuery) so we can join: template → URL set → metrics → revenue. It stops debate and speeds sign‑off.

Crawlability, indexation and duplicates

This is the foundation. If Google can’t reach, render and index the right URL, nothing else matters.

• Robots.txt and meta robots: Block only what you must. We routinely find entire filter folders Disallowed while the same variants index via internal search pages. Tighten meta robots at template level (noindex, follow) for thin sets rather than blanket Disallows that hide issues.
• Canonical tags: Pick a single canonical per product/variant. On a Shopify store with ~50k URLs, we found ~12k duplicate variants canonicalising to themselves while sitemaps pointed to the parent. Fixing canonicals and sitemap targets cut crawl waste by ~40% and lifted impressions +18% in six weeks.
• Parameters and facets: UTM, sort, view, colour, size — decide which should index. Use GSC parameter handling as a hint, but enforce with canonicals and, if needed, noindex. Keep sitemaps clean: only indexable URLs.
• Pagination: rel=next/prev is deprecated as a signal, but logic still matters. Paginated pages should be indexable with self‑canonicals, and listing pages shouldn’t canonical to page 1 if unique items exist on deeper pages.
• Status codes: Remove soft 404s. Convert dead products to 410s unless you have a tight redirect target. Flatten redirect chains to a single 301 hop.

Quick checks that pay off:

• Compare sitemap URLs vs indexable URLs. If >5–10% mismatch, fix the sitemap first.
• Find non‑indexable canonicals. Anything canonicalising to noindex or 404 is wasted equity.
• Map thin templates (<150 words, minimal unique elements). Either enrich, consolidate or noindex.

Speed and Core Web Vitals

We prioritise field data (CrUX/Origin/URL) over lab scores. The aim is hitting passing thresholds on the highest‑traffic templates first.

• Largest Contentful Paint (LCP): inline critical CSS, defer non‑critical JS, preconnect/preload key origins, compress hero images. On a UK merchant, trimming 320KB of render‑blocking JS and moving hero imagery to AVIF took mobile LCP from 3.8s → 1.6s and raised CWV pass rate from 62% → 91% in 30 days.
• Cumulative Layout Shift (CLS): reserve image/video space, set font‑display: swap, remove layout‑thrashing carousels above the fold.
• Interaction to Next Paint (INP): kill third‑party bloat (chat, review widgets) or load them on interaction; split bundles; hydrate below‑the‑fold later.
• Caching and CDN: Cloudflare APO (for WordPress), image resizing at the edge, long‑TTL immutable assets, and cache‑busting via file hashes. For headless setups, add a surrogate cache (Varnish) and Redis for HTML fragments.
• Measurement: Track real user CWV per template in GA4 (custom dims) or a lightweight beacon, and alert when a template drops below pass thresholds.

Result to expect when done right: 10–30% improvement in organic sessions within 6–10 weeks on pages with historic underperformance from slow LCP/INP. We’ve seen organic conversion rate lift 8–15% after stabilising CLS and reducing long tasks.

JavaScript rendering and Shopify/SPA quirks

Google can render JS, but not on your schedule. Minimise what bots must execute to see meaningful content.

• Server‑side rendering (SSR) or pre‑render: For React/Next.js or Shopify Hydrogen, ensure key product/collection content and head tags render on the server. Hydrate progressively rather than blocking the main thread.
• Don’t swap titles/meta after first paint: Bots may read the initial DOM only. We’ve fixed React apps that set titles via client‑side routers post‑render — pages never earned stable snippets.
• Avoid content behind interactions: Tabs/accordions are fine if content is in the DOM at load. Don’t fetch critical copy only after a click.
• Shopify themes: Audit app blocks and scripts. We typically remove 5–10 apps, replace two with native features, and inline theme logic. One store cut JS by ~400KB and increased indexed collection pages by +24% clicks in 60 days.

Test with: Screaming Frog in JavaScript rendering mode, “Fetch as Google” via URL Inspection, and WebPageTest with filmstrips to verify above‑the‑fold paint before hydrations.

Structured data that won’t get you flagged

Schema should reflect the on‑page reality, not a wishlist.

• Product: Include name, image, description, brand, sku, gtin/ mpn, offers (priceCurrency, price, availability), and aggregateRating only if shown to users. We sync GTIN/MPN from Shopify via Admin API/GraphQL to prevent mismatches.
• Organisation and Breadcrumb: Easy wins that improve snippet clarity.
• Article/BlogPosting and FAQ: Use sparingly and only where content fits. Avoid spammy FAQ across every page.
• Validation: Google Rich Results Test, plus automated linting. We reduced schema warnings by 96% for an 8k‑SKU catalogue and increased rich result coverage 3.5×.

If merchant listings matter, also check feed hygiene in Merchant Center. Schema won’t fix a broken feed.

Internal linking and architecture that Google can follow

You’ll rarely rank what you don’t link. We map link equity by template and depth.

• Collections and hubs: Build hub pages that target mid‑tail terms and link to product or service pages. Keep click depth ≤3 for money pages.
• Breadcrumbs: Text links with consistent anchors; add JSON‑LD BreadcrumbList.
• Contextual links: Add 2–4 relevant links in body copy from evergreen posts and guides to key pages. Don’t rely only on nav/footers.
• Orphans: No page should exist without at least one crawlable path from an indexable page. Fixing orphans often surfaces ‘forgotten’ commercial pages.
• Programmatic linking: Use n8n to identify under‑linked pages and write internal links back to the CMS via API. On a B2B site we added ~3,000 contextual links in two sprints; crawl hits to priority pages rose +35% and average position improved by 3–5 spots.

Use GSC → Performance to find pages with high impressions/low CTR and strengthen their internal links and snippet quality.

Logging, monitoring and proving value

An audit is only as good as the outcomes you can prove.

• Log analysis: Segment Googlebot in logs, plot 2xx vs 3xx/4xx/5xx over time. After cleaning 29k broken links and fixing sitemaps, one client’s Googlebot 404 share dropped from 12% → 2%, and average crawl delay improved by ~30%.
• Regression alerts: n8n jobs ping Slack when sitemap count drifts, 5xx spikes, or CWV pass rate dips below thresholds.
• Dashboards: Join GSC, GA4 and logs in BigQuery; report on indexed pages, top template CWV, and revenue by template. Looker Studio is enough for stakeholders.
• Prioritisation: We score each issue by impact (traffic × revenue × severity) and effort (dev hrs). Quick wins go first; platform changes get their own sprint.

If you want a pragmatic audit with implementation help, book a free discovery call. Or read more about how we package this in our Technical SEO service.

FAQ

How long does a technical SEO audit take?

For 5k–50k URL sites, 2–4 weeks for the audit, then 4–12 weeks to implement and monitor. Enterprise sites with multiple markets can take 6–8 weeks for the audit due to log and template complexity.

What size of site benefits most?

Any site with >1k URLs usually has crawl waste and speed issues worth fixing. The biggest ROI shows up on e‑commerce (variants, filters) and content sites with legacy pagination and weak internal linking.

Do you need CMS or code access?

Read‑only access to CMS, theme files or repo accelerates everything. We can run a read‑only audit, but getting changes live (sitemaps, canonicals, speed fixes) requires collaboration with your devs or our team.

How do you measure success after an audit?

We track indexed pages, CWV pass rate, 4xx/5xx share in logs, and GSC clicks/impressions to target pages. Typical outcomes after fixing the top five issues: +10–30% organic sessions and +8–20% organic revenue within 6–12 weeks, assuming no major algorithm shocks.