LCP, INP and CLS explained without jargon, plus crawl budget, rendering, indexing and the technical checks that move rankings.
Key takeaways
- Core Web Vitals are a real but light ranking signal — their strongest case is conversion, not rankings.
- Field data (real users) decides how you are assessed. Lab scores are a diagnostic tool, not the target.
- LCP is usually an image and priority problem; INP is usually a JavaScript problem; CLS is usually a reserved-space problem.
- Crawl budget only matters at scale, but index bloat wastes it on almost every large e-commerce site.
- Fix indexing first, performance second. An unindexed fast page still earns nothing.
What technical SEO is actually for
Technical SEO answers one question in several forms: can search engines reach, render, understand and choose to index your pages, quickly enough and consistently enough to compete? Everything else — content, links, local signals — depends on that answer being yes.
This guide covers the areas that matter most in practice, roughly in the order we work through them on client sites: indexing, crawling, rendering, Core Web Vitals and structured data.
Indexing: the check that comes before everything
The first number to look at on any site is the ratio of pages you want indexed to pages actually indexed. Search Console’s Indexing → Pages report gives you both halves.
Reading the exclusion reasons properly
“Crawled – currently not indexed” is the one that worries people most, and it is usually a quality judgement: Google fetched the page and decided it was not worth storing. The common causes are thin content, near-duplication across templates, and pages with no internal links or external signals suggesting anyone cares about them. The fix is rarely technical — it is consolidation, depth or removal.
“Discovered – currently not indexed” means Google knows the URL but has not fetched it. At scale this points to crawl capacity or internal linking; on small sites it is usually temporary.
Duplicate and canonical messages mean Google disagreed with your canonical choice or you never made one. Check for parameter variants, print versions, pagination handling and protocol inconsistencies.
Index bloat
The opposite problem is just as common: tens of thousands of indexed URLs you never intended to exist. Tag archives, search result pages, filter combinations, session parameters, calendar pages that extend to 2087. Each one consumes crawl capacity and dilutes the site’s apparent quality. The audit question is simple — for every URL pattern, does a searcher ever want to land here? If not, it should be blocked, canonicalised or removed.
Crawling and crawl budget: when it matters
Crawl budget is not a concern for a 300-page business site. Google will happily crawl it all. It becomes decisive on large e-commerce and listing sites, where crawl spent on duplicate parameter URLs is crawl not spent discovering your new products.
What server logs tell you that nothing else does
Log files record what Googlebot actually requested, how often, and what response it got. Analysing a month of logs typically reveals things no crawler can: that 58% of Googlebot requests hit faceted URLs, that a redirect chain is being re-crawled daily, that your most important category page has not been visited in three weeks.
Practical crawl efficiency work
- Collapse redirect chains to single hops, and update internal links to point at final URLs.
- Block genuinely useless parameter patterns in robots.txt; canonicalise the ones that need to remain accessible.
- Keep XML sitemaps accurate — only canonical, indexable, 200-status URLs. A sitemap full of redirects and 404s wastes trust and crawl.
- Reduce click depth. Pages five clicks deep get crawled rarely, if at all.
- Fix internal links to 404s and 301s; they are pure waste and easy to find.
Rendering: what Google sees on a JavaScript site
Google renders JavaScript, but rendering is queued, resource-limited and slower than initial crawling. The practical implications for any React, Vue, Angular or headless build:
- Critical content must be in the rendered DOM, and ideally in the initial HTML. Server-side rendering or static generation removes the uncertainty entirely.
- Internal links must be real anchors with href attributes. A div with a click handler is not a link and will not be followed.
- Nothing important should require interaction. Content behind a “load more” button or a tab click that fetches on demand may never be seen.
- Do not block your JS and CSS in robots.txt. Google needs them to render the page as users see it.
The test that settles arguments: URL Inspection in Search Console, “View crawled page”, and read the rendered HTML. If your content is not there, no amount of local testing matters.
Core Web Vitals, explained without the jargon
Three metrics, each measuring a different kind of user frustration. Assessment uses field data — the 75th percentile of real Chrome users over 28 days — not lab scores. That distinction matters: a perfect Lighthouse score with failing field data means your real users have slower devices and worse networks than your laptop.
LCP — Largest Contentful Paint (target: under 2.5s)
How long until the biggest thing above the fold appears. On most sites that is the hero image or heading. Typical causes and fixes:
- Hero image loaded lazily or discovered late → preload it, set
fetchpriority="high", never lazy-load above-the-fold images. - Oversized images → serve correctly sized WebP or AVIF with responsive
srcset. - Render-blocking CSS and fonts → inline critical CSS, preload fonts, use
font-display: swap. - Slow server response → caching, a CDN, and database or template optimisation.
INP — Interaction to Next Paint (target: under 200ms)
How quickly the page visually responds when someone taps or clicks. This replaced First Input Delay and is a harder test, because it measures every interaction rather than only the first. It is almost always a JavaScript problem:
- Long tasks blocking the main thread → break them up, defer what is not needed immediately.
- Heavy third-party scripts (chat widgets, tag managers, A/B tools) → load on interaction or delay until idle.
- Expensive event handlers → debounce, and move heavy work off the critical path.
- Large hydration payloads in frameworks → code-split and hydrate selectively.
CLS — Cumulative Layout Shift (target: under 0.1)
How much the layout jumps around while loading. Nearly always caused by not reserving space:
- Images and videos without width and height attributes.
- Ads, embeds and iframes injected into unreserved containers.
- Web fonts causing reflow → preload and match fallback metrics.
- Banners, cookie bars and notices inserted above existing content.
How much do CWV affect rankings?
Less than most articles imply. They act as a tie-breaker among pages of comparable relevance, not as a way to outrank stronger content. The stronger argument is commercial: mobile conversion rates measurably decline as LCP climbs past 2.5 seconds. Treat CWV as a revenue project that happens to help SEO.
Structured data: what is worth implementing
Structured data does not directly improve rankings. It makes pages eligible for rich results, and rich results substantially improve click-through — which is why it earns its place.
The types worth implementing for most businesses:
- Organization / LocalBusiness — sitewide identity, address, phone, hours, social profiles.
- BreadcrumbList — cleaner SERP display and clearer hierarchy signals.
- Article — for editorial content, with real author and date information.
- FAQPage — on pages with genuine question-and-answer content that is visible to users.
- Product / Offer / AggregateRating — essential for e-commerce; drives price, availability and star ratings in results.
- Service — for service pages, tied to the providing organisation.
Implement it in JSON-LD, validate with the Rich Results Test, and then monitor the Enhancements reports in Search Console — markup silently breaking after a template change is extremely common. And never mark up content that is not visible on the page; that is a manual action waiting to happen.
Migrations: where technical SEO earns its fee
Replatforming, redesigning or changing domains is the highest-risk event in a site’s SEO life. The failure pattern is consistent: URLs change, redirects are partial, and three months later nobody can reconstruct what the old structure was.
The process that prevents it:
- Baseline everything before launch: full crawl, ranking snapshot, Search Console export, analytics benchmark, top-pages list by traffic and revenue.
- Build a URL-to-URL redirect map for every indexed URL. One hop, no chains, no blanket redirects to the homepage.
- QA on staging with a crawl comparison against the baseline: titles, metas, headings, canonicals, schema, internal links.
- Verify the staging noindex is removed at launch. This single check would have saved several sites we have been called in to rescue.
- Monitor for 30 days: index coverage, 404 logs, ranking movement, Core Web Vitals. Expect a short dip; act if it deepens past week two.
A technical SEO checklist you can run quarterly
- Index coverage: indexed vs. intended, exclusion reasons reviewed.
- Crawl: no internal links to 404s or redirect chains; click depth under four for money pages.
- Sitemaps: only canonical 200 URLs; submitted and clean in Search Console.
- Robots.txt: no accidental blocks on CSS, JS or key sections.
- Canonicals: self-referencing where appropriate, consistent across parameters.
- Core Web Vitals: field data pass rate on mobile, tracked over time.
- Structured data: valid items and zero errors in the Enhancements reports.
- HTTPS: no mixed content, valid certificate, single canonical protocol and hostname.
- Mobile: usable viewport, no horizontal scroll, tap targets adequately sized.
- Rendering: critical content present in the rendered HTML Google reports.
Frequently asked questions
Yes, but a light one. They are part of the page experience signals and function as a tie-breaker between comparable pages rather than a primary driver. Content relevance and authority still dominate. We prioritise CWV work for its conversion impact, and treat the ranking benefit as a bonus.
Because they measure different things. Lighthouse is a lab test on your machine and connection. Search Console reports field data from real Chrome users at the 75th percentile — slower phones, worse networks, more third-party scripts firing. Field data is what counts for assessment, so always debug against it.
Three signals together: a large URL count (tens of thousands), Search Console showing many “Discovered – currently not indexed” pages, and log data showing most Googlebot requests going to low-value URLs. If you have a few hundred pages, crawl budget is almost certainly not your issue.
For SEO-critical pages, server-side rendering or static generation removes all rendering uncertainty and is the safe default. Client-side rendering can work, but it adds risk, delay and debugging overhead. If your commercial pages depend on organic search, do not make their indexability contingent on a rendering queue.
Indexing fixes can show within days to a few weeks — you are removing a blocker. Core Web Vitals field data needs 28 days to fully reflect a change, so allow six to eight weeks to see a clean before-and-after. Structural improvements to crawl efficiency show gradually over one to three months.
About Daniel Whitfield
Head of SEO Strategy at Orlando SEO Company
Daniel works on client SEO strategy at our Orlando agency and writes here about what actually moves rankings in Central Florida markets. Questions about this article? Get in touch.