How to audit a website for technical health (Core Web Vitals + 2026 guide)

Why technical health is downstream of every other audit

Three things happen when your site is technically broken:

1. Google ranks you lower. Core Web Vitals are explicit ranking factors. INP - which replaced FID in March 2024 - is unforgiving: anything above 200ms degrades rankings.
2. AI engines stop citing you. ChatGPT, Claude, and Perplexity preferentially cite pages they can actually load. Sites that fail Lighthouse mobile <50 drop out of AI citation candidate pools.
3. Visitors leave before reading. Per Google's mobile page-speed research, bounce probability jumps 32% as page load goes from 1s to 3s, and 90% as it goes from 1s to 5s. The site in the worked example below is at 7.1s.

The 8 checks

1. Core Web Vitals - the metrics Google actually uses

The three metrics in Google's 2026 ranking algorithm, per web.dev's Core Web Vitals reference:

• LCP (Largest Contentful Paint) - ≤2.5s good, 2.5-4s needs improvement, >4s poor.
• INP (Interaction to Next Paint) - replaced FID March 2024. ≤200ms good, 200-500ms needs improvement, >500ms poor.
• CLS (Cumulative Layout Shift) - ≤0.1 good, 0.1-0.25 needs improvement, >0.25 poor.

What to check:

• Run PageSpeed Insights on your homepage and 3 key pages
• Look at Field data (real user metrics from the Chrome User Experience Report (CrUX)), not Lab data. Field data is what Google ranks on.
• Test on mobile, not desktop - mobile is the ranking signal

What most tools miss: the lab-vs-field distinction. Lighthouse can score 95 with green Field data that's actually red. AuditHQ pulls CrUX data via the PSI API, not Lighthouse-only.

2. Mobile experience - the WCAG 2.2 target size update

Since WCAG 2.2 (October 2023), tap targets must be ≥24×24 CSS px under success criterion 2.5.8 Target Size (Minimum).

• <meta name="viewport" content="width=device-width, initial-scale=1"> present (NOT maximum-scale=1.0, user-scalable=no)
• Buttons, links, form controls measure at least 24×24 CSS pixels on mobile
• No horizontal scrolling on 360px-wide viewport
• Base font size ≥16px on mobile (smaller triggers Safari's zoom-to-input)

3. SEO technical basics

Reference: Google's Search Central documentation.

• <title> 50-60 chars, unique per page, primary keyword in first 30 chars
• <meta name="description"> 140-160 chars, unique per page
• <link rel="canonical"> - points to itself unless deliberate duplicate
• hreflang tags for international sites (with x-default)
• JSON-LD schema (Organization, Article, BreadcrumbList, FAQPage)

What most tools miss: unique meta-description per page. Most SMB sites have the homepage description copied across every page.

4. Crawlability - robots.txt, sitemap, soft-404

• robots.txt at the root - allows public pages, blocks app routes
• AI crawler rules (GPTBot, ClaudeBot, PerplexityBot, Google-Extended) explicitly handled
• sitemap.xml referenced in robots.txt
• Sitemap is current - <lastmod> dates within the last 30 days for active content
• No soft 404s - pages that return 200 with "Sorry, page not found" content
• No broken internal links → quick crawl with Screaming Frog

5. Heading hierarchy + semantic HTML

• Exactly one <h1> per page
• <h2> through <h6> in sequence, no skipped levels
• Real semantic elements: <main>, <nav>, <header>, <footer>, <article>, <section>, <aside> - per the MDN HTML elements reference
• Lists as <ul> / <ol>, not <div> stacks. Tables as <table>, not CSS grids.

6. Image optimisation

Images are typically 60-70% of page weight per the HTTP Archive Web Almanac.

• Format: WebP or AVIF. AVIF saves ~50% vs WebP, which saves ~30% vs JPEG.
• loading="lazy" on every image below the fold. fetchpriority="high" on the LCP image - see the fetchpriority web.dev guide.
• width and height attributes set explicitly - prevents CLS.
• alt text descriptive (>5 words), not "image".
• Responsive variants via srcset and sizes.

The single highest-leverage one-line change in this entire article is the LCP preload hint. Put this in index.html <head>:

<link rel="preload" as="image" href="/assets/hero.avif" fetchpriority="high">

Typically shaves 0.5-1s off LCP. Free.

7. Resource loading - what blocks the render

• <script> tags should have async or defer unless critical inline
• Use type="module" for modern JS
• <link rel="preconnect"> for critical third-party origins
• <link rel="preload"> for the hero image + critical fonts
• <link rel="modulepreload"> for critical ES modules
• Fonts use font-display: swap
• Critical CSS inlined; non-critical loaded async with media="print" swap pattern
• Speculation Rules API for likely-next-page prerender (Chrome 121+)

8. Accessibility - WCAG 2.2

• 2.4.11 Focus Not Obscured (Minimum)
• 2.4.13 Focus Appearance - focus indicator has minimum contrast ratio
• 2.5.7 Dragging Movements - drag has a single-pointer alternative
• 2.5.8 Target Size (Minimum) - 24×24 CSS px
• 3.2.6 Consistent Help - help links in consistent location
• 3.3.7 Redundant Entry - don't re-ask for info already provided
• 3.3.8 Accessible Authentication (Minimum) - no cognitive function test required

For the AI-search side of technical health, see the AI Citation audit guide; for the security-header side (HSTS, CSP, X-Frame-Options), see the security audit guide.

Worked example - a real SMB we audited

Composite score: 58/100 - Grade C

The site is a Vite + React SPA with SSG pre-rendering, hosted on Netlify behind Cloudflare. Schema.org markup, per-page canonical and meta, hreflang en-AU, robots.txt friendly to AI crawlers, sitemap with lastmod dates. Above average.

But the audit found:

• Performance: 32/100. PSI returns a Performance score of 46/100 with LCP at ~7.1 seconds on mobile. Google's threshold is 2.5s. Fails by almost 3×. With Google's own 90%-bounce-at-5s research, the site is structurally losing traffic before any visitor sees the work.
• All 21 images are JPG. Zero WebP. Zero AVIF. The primary LCP driver. Converting via vite-imagetools typically delivers 30-50% LCP improvement.
• No <link rel="preload"> for the hero image. Adding one line typically shaves 0.5-1s off LCP for free.
• No explicit width/height on <img> tags. Causes CLS - page jumps as images load.
• 3 of 6 security headers stripped at the edge. Both vercel.json and public/_headers correctly define CSP, X-Frame-Options, Permissions-Policy. Cloudflare strips them before they reach the browser. Fix is a Cloudflare Transform Rule in the dashboard - 30-min config change.
• Blog posts not pre-rendered. The SSG build (build-ssg.mjs) pre-renders 10 core routes but omits the 14 blog post slugs. Google crawls /blog/{slug} and sees <div id="root"></div>. A site: search returns ~1 indexed page despite a 22-URL sitemap.
• No prefers-reduced-motion support. Framer Motion ships with useReducedMotion() but it's not used.
• Cache-Control: no-cache, must-revalidate on everything, including content-hashed static assets that should be cached for a year.

Score breakdown

The three fixes that move this site from C to B in a developer-day:

1. Image pipeline (~4 hours). Convert all 21 images to WebP + AVIF via vite-imagetools. Add explicit width/height to every <img>. Add the LCP preload tag shown earlier. Expected LCP: 7.1s → under 3s.
2. Cloudflare Transform Rules (~45 min). Add CSP, X-Frame-Options, Permissions-Policy as Response Header Modification rules. Verify with securityheaders.com. No code change.
3. Blog SSG (~90 min). Add the 14 blog slugs to the routes array in build-ssg.mjs. Rebuild. Submit the sitemap in Google Search Console.

Run it on your site automatically

FAQ

Written by Adam Savage, Founder of AuditHQ - 17 years building digital products. Last updated 13 May 2026.