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.