Technical SEO & Core Web Vitals that actually move rankings
Technical problems quietly cap everything else you do. A plain-language guide to Core Web Vitals and the crawl/index checks that decide whether your content can rank at all.
Technical SEO is the floor, not the ceiling
Great content on a slow, uncrawlable site is a great answer no one can reach. Technical SEO won't win a competitive term by itself — links and content do that — but technical problems quietly cap everything else you do. Picture a page with the best answer on the web that takes 6 seconds to paint, ships a noindex tag by mistake, and competes with three duplicate URLs. It will never rank to its potential no matter how good the writing is.
The goal is unglamorous but clear: make every important page fast, crawlable and unambiguous — for search engines and the AI crawlers now reading your site too. This guide walks through the metrics that matter, the order to fix them in, and how to tell a real problem from a vanity number.
Core Web Vitals, in plain terms
Google's Core Web Vitals measure real user experience on real devices — not a lab score. Three thresholds matter, and Google grades you at the 75th percentile, meaning three out of four of your visitors must hit the target before the page counts as "good".
- LCP (loading) — how fast the largest visible element (usually a hero image, heading or banner) finishes painting. The usual culprits are unoptimized images, slow servers, and render-blocking CSS or fonts.
- INP (interactivity) — how quickly the page reacts after a tap or click, measured across the whole visit. INP replaced FID in March 2024 and is far stricter; heavy JavaScript and long main-thread tasks are the usual cause.
- CLS (stability) — how much visible content shifts unexpectedly while loading. Images and ads without reserved dimensions, and fonts that swap late, are the main offenders.
Field data vs lab data
This trips up almost everyone. A Lighthouse score in your browser is lab data — one simulated load on one machine. The Core Web Vitals that affect ranking come from field data: anonymized timings from real Chrome users, published in the Chrome UX Report (CrUX). A page can score 98 in Lighthouse and still fail CWV in the field because most of your visitors are on mid-range Android phones over 4G, not your fast laptop. Always confirm a fix against 28-day field data before declaring victory.
| Source | What it is | Use it for |
|---|---|---|
| Lighthouse / PageSpeed (lab) | One simulated load | Debugging a specific fix |
| CrUX / Search Console (field) | Real users, 28-day window | The numbers that move rankings |
| Real-user monitoring (RUM) | Your own analytics beacon | Per-template, per-device breakdowns |
A worked example: from "needs improvement" to "good"
Say a content site has a 4.1s LCP and a 240ms INP on mobile — both in the amber "needs improvement" band. Here is the realistic order of operations and the kind of gains each step buys.
First, the hero image. It is a 1.4 MB JPEG served at full resolution to every device. Converting to WebP, sizing it to the layout, and adding fetchpriority="high" typically cuts LCP by a second or more on its own. Next, render-blocking resources: self-hosting fonts with font-display: swap and deferring non-critical CSS removes the gap before first paint. Finally, INP — the third-party chat widget and analytics bundle were blocking the main thread on first tap; deferring them until interaction or idle drops INP under the 200ms line.
Notice that three changes did almost everything. That is the pattern: a small number of fixes carry the result, and the rest is noise. Resist the urge to chase a perfect score.
The crawl and indexing checklist
Before chasing speed, make sure engines can even read you. Speed is wasted on a page that is blocked, duplicated or orphaned.
| Check | Why it matters |
|---|---|
| robots.txt / XML sitemap | Engines find and prioritize the right pages |
| Indexability (noindex, canonical) | The wrong tag silently removes a page from results |
| Canonical tags | Duplicate URLs don't split your signals |
| Structured data | Eligibility for rich results + clearer entity signals |
| Internal links / orphans | A page with no internal links rarely gets crawled |
| Broken links / 4xx / 5xx | Wasted crawl budget, dead ends for users |
The most damaging issues are almost always indexation, not speed. An accidental noindex shipped in a template, a canonical pointing at the wrong URL, or a Disallow: rule that's too broad can erase whole sections from search. Check these first — a 0.3s speed gain means nothing if the page can't be indexed at all.
# A robots.txt that blocks more than you think
User-agent: *
Disallow: /blog/ # oops — this kills the whole blog
Sitemap: https://example.com/sitemap.xmlWhere the wins usually sit
Across a typical audit, the issues are not evenly spread. A rough breakdown of where ranking-relevant problems tend to cluster:
AI crawlers reward the same hygiene as search crawlers — clean structure, fast, accessible HTML and unambiguous canonicals make a page easy to both rank and quote in AI answers.
How to prioritize so you actually finish
A full crawl of a mid-size site can return hundreds of flags, and trying to clear all of them is how technical SEO projects stall. Rank every issue by two things: how many important pages it touches, and how directly it affects indexing or experience. A canonical error on a 200-page category template beats a missing alt attribute on one blog post, every time. Fix the handful that touch the most revenue pages, re-crawl, and confirm the change in field data before moving on.
Find the issues, then fix the ones that pay
Lume's site audit crawls your pages, scores Core Web Vitals and surfaces the crawl and index issues that actually cost rankings — ROI-ranked, so you fix the few that matter first instead of drowning in a flag list. Pair it with daily rank tracking to watch the fixes land. Run a free scan to see your technical health.
