Technical SEO is the foundation that other SEO activity builds on. The best content and the most high-quality backlinks will underperform if search engines cannot efficiently crawl, render, and index your pages. For developers, technical SEO is an area where coding decisions made early in a project’s life can have outsized, long-lasting effects on organic traffic — for better or worse.

Crawlability and Indexation

Before rankings, there is indexation — Google must be able to discover and index your pages before they can rank. A robots.txt that accidentally blocks crawlers from key sections, noindex directives left on pages that should be indexed, and canonical tags pointing to incorrect URLs are among the most common issues found in technical audits. These are often introduced during development or staging deployments and never removed.

Audit your robots.txt to confirm it does not disallow crawling of sections you intend to rank. Check your canonical tags programmatically — look specifically for paginated pages canonicalised to the first page, which prevents individual pages from accumulating ranking signals. Verify that your meta robots tags are not applying noindex directives too broadly.

Core Web Vitals: What Google Is Actually Measuring

Core Web Vitals are Google’s user experience metrics that directly influence rankings. The three metrics are Largest Contentful Paint (LCP), measuring perceived load speed; Cumulative Layout Shift (CLS), measuring visual stability; and Interaction to Next Paint (INP), measuring responsiveness to user input.

LCP is most commonly affected by render-blocking resources, large unoptimised images, and slow server response times. The LCP element is typically the largest image or text block in the viewport — identifying it in Chrome DevTools and tracing its load path is the starting point for LCP improvement. CLS is most commonly caused by images and embeds without explicit dimensions, dynamically injected content above existing content, and web fonts that cause layout shift during load.

Page Speed and Server Response Time

Server response time (Time to First Byte — TTFB) is the time from request to first byte of response. A TTFB above 600ms is generally considered problematic. For dynamic pages, this is typically addressed through caching: full-page caching with Redis or Varnish, database query caching, and CDN edge caching for static assets. For static assets, a CDN is standard practice — serving assets from an origin server geographically distant from the user adds latency that compounds across the many assets a page requests.

Structured Data and Rich Results

Structured data (Schema.org vocabulary implemented as JSON-LD) allows Google to understand the content of a page at a semantic level and surface rich results — star ratings, FAQs, event dates, product prices — directly in search results. Rich results increase click-through rate independent of ranking position. For service businesses, FAQ schema on service pages and LocalBusiness schema for location-based businesses are high-value, relatively low-effort implementations.

Duplicate Content and Canonical Architecture

Duplicate content dilutes ranking signals by splitting them across multiple URLs that contain the same or very similar content. Common sources include protocol variants (http vs https), www vs non-www, trailing slash variants, URL parameters from tracking or filtering, and paginated series. Each of these should be handled with consistent 301 redirects to a canonical form, with canonical tags confirming the canonical version for search engines.

Running a Screaming Frog crawl of your site and reviewing the canonical and redirect report is a reliable way to surface duplicate content issues that might not be visible through normal site browsing.

Google’s Core Web Vitals are three performance metrics that measure real user experience — not theoretical performance scores — and they carry direct weight in Google’s ranking algorithm through the Page Experience signal. Understanding what they measure and what actually improves them is essential for anyone responsible for a website’s organic visibility and user experience.

Largest Contentful Paint (LCP): Perceived Load Speed

LCP measures the time from navigation start to when the largest visible content element in the viewport has finished rendering. In practice, this is typically the hero image, a large text heading, or a video poster image. Google’s threshold for a “good” LCP is 2.5 seconds; above 4 seconds is “poor.”

The most impactful improvements for LCP are: removing render-blocking resources (synchronous scripts and stylesheets in the head that prevent rendering from starting), preloading the LCP image with a link rel=”preload” tag so the browser discovers it immediately rather than after parsing CSS, serving images in modern formats (WebP, AVIF) at appropriate dimensions, and ensuring the server responds quickly to the initial HTML request (TTFB under 600ms).

Cumulative Layout Shift (CLS): Visual Stability

CLS measures the sum of all unexpected layout shifts that occur during the page’s lifetime. A layout shift happens when a visible element changes position without user interaction — the classic example is text jumping down when an image above it loads without reserved space, or a button moving when a banner appears above it after the page has already rendered.

The primary fix for CLS is dimension reservation: images and video elements should always have explicit width and height attributes (or a CSS aspect-ratio) so the browser allocates space for them before they load. Dynamically injected content should be inserted below the current viewport position or in reserved space. Web fonts cause CLS when the fallback font renders at different dimensions from the loaded font — using font-display: optional or size-adjust with system fonts mitigates this.

Interaction to Next Paint (INP): Responsiveness

INP replaced First Input Delay (FID) as a Core Web Vital in March 2024. Where FID only measured the delay before the browser processed the first interaction, INP measures the full duration of all interactions during the page lifecycle — from input event to the next visual update after the interaction. The threshold for “good” is 200ms; above 500ms is “poor.”

Poor INP is almost always caused by long tasks on the main thread blocking the browser from responding to user input. JavaScript execution that takes more than 50ms is classified as a long task. Improvements include breaking long tasks with scheduler.yield(), reducing JavaScript bundle size, deferring non-critical scripts, and using web workers for CPU-intensive work that does not need main thread access.

Measurement and Tooling

Chrome DevTools’ Performance panel and Lighthouse provide lab measurements — useful for diagnosing issues during development. Field data from real users is more authoritative and is available through Chrome User Experience Report (CrUX), PageSpeed Insights, and Google Search Console’s Core Web Vitals report. Discrepancies between lab and field data are common and usually explained by differences in network conditions, device capabilities, and the specific user journeys that field data captures.