← Back to blog Performance

Technical SEO for Developers: The Complete Guide to Ranking Better

Envestis Team 18 min read

Why Developers Should Care About SEO

Technical SEO is the foundation that determines whether search engines can find, crawl, render, and index your content. You can write the best content in the world, but if Google cannot access it efficiently, render it correctly, or understand its structure, that content will not rank.

Most SEO advice is aimed at marketers: write better titles, build more backlinks, create longer content. That advice is valid but incomplete. The technical infrastructure of your website determines the ceiling for your SEO performance. No amount of keyword research compensates for a site that takes 8 seconds to load or serves critical content via JavaScript that Googlebot struggles to execute.

This guide covers the technical SEO factors that developers control directly. Each section includes the what, the why, and the how-to-fix.

Core Web Vitals: The Metrics That Matter

Google's Core Web Vitals are three specific metrics that measure real-world user experience. Since June 2021, they are a confirmed ranking factor. The metrics are:

Largest Contentful Paint (LCP)

What it measures: How long it takes for the largest visible content element (usually an image or heading block) to render in the viewport.

Target: Under 2.5 seconds.

Common causes of poor LCP:

  • Slow server response time (TTFB over 600ms).
  • Render-blocking JavaScript and CSS.
  • Large, unoptimized hero images.
  • Slow resource load times (fonts, critical CSS).
  • Client-side rendering that delays content display until JavaScript executes.

How to fix LCP:

  • Optimize server response time: Use a CDN, enable server-side caching, or move to a static hosting architecture. A static site served from a CDN edge node typically has TTFB under 50ms.
  • Preload the LCP element: If the LCP element is an image, use <link rel="preload" as="image" href="hero.webp"> in the <head>.
  • Optimize images: Use modern formats (WebP, AVIF), serve responsive images with srcset, and specify width and height attributes to prevent layout shifts.
  • Eliminate render-blocking resources: Inline critical CSS, defer non-critical CSS with media="print" onload="this.media='all'", and defer non-critical JavaScript with async or defer attributes.
  • Avoid client-side rendering for above-the-fold content: Use SSR (Server-Side Rendering) or SSG (Static Site Generation) so the HTML arrives with content already in place.

First Input Delay (FID) / Interaction to Next Paint (INP)

What it measures: FID measures the delay between a user's first interaction (click, tap) and the browser's response. INP (which is replacing FID as of March 2024) measures the responsiveness of all interactions throughout the page lifecycle, not just the first one.

Target: FID under 100ms. INP under 200ms.

Common causes of poor FID/INP:

  • Heavy JavaScript execution blocking the main thread.
  • Third-party scripts (analytics, ads, chat widgets, social media embeds) competing for CPU time. We covered this in our article on third-party JavaScript risks.
  • Large JavaScript bundles that take too long to parse and compile.
  • Long-running tasks that prevent the browser from responding to input.

How to fix FID/INP:

  • Break up long tasks: Use requestIdleCallback or setTimeout to split CPU-intensive work into smaller chunks that yield to the browser between executions.
  • Reduce JavaScript: Audit your JavaScript bundles. Remove unused code, split bundles with code splitting, and lazy load components that are not needed on initial page load.
  • Defer third-party scripts: Load analytics, chat widgets, and social embeds after the page is interactive. Use requestIdleCallback or load them on user interaction (scroll, click).
  • Use web workers: Move heavy computation off the main thread into web workers so the main thread remains responsive to user input.
  • Minimize the work your site does: Static sites with minimal JavaScript naturally have excellent FID/INP because there is almost nothing blocking the main thread.

Cumulative Layout Shift (CLS)

What it measures: How much the visible page content shifts unexpectedly during loading. When elements move around as the page loads (text jumps down because an image loaded above it, a banner pushes content down, a font swap causes text to reflow), that is layout shift.

Target: CLS score under 0.1.

Common causes of poor CLS:

  • Images without explicit width and height attributes.
  • Ads or embeds that inject content without reserved space.
  • Dynamically injected content above the fold.
  • Web fonts causing text to reflow when they load (FOUT: Flash of Unstyled Text).
  • Late-loading CSS that changes element sizing.

How to fix CLS:

  • Always set dimensions on images and videos: Use the width and height HTML attributes (or CSS aspect-ratio) so the browser can reserve space before the asset loads.
  • Reserve space for dynamic content: If you load ads or third-party widgets, set a min-height on the container so the layout does not shift when the content appears.
  • Prefer font-display: swap with preloading: Preload your web fonts with <link rel="preload" as="font" crossorigin> and use font-display: swap to minimize the text reflow window.
  • Avoid inserting content above the fold dynamically: Cookie consent banners, notification bars, and promo banners that push content down cause CLS. Position them as overlays or reserve their space in the initial layout.

Structured Data / Schema.org Markup

Structured data is machine-readable code that tells search engines what your content is about. It uses the Schema.org vocabulary and can trigger rich results in Google (star ratings, FAQs, breadcrumbs, how-to steps, event details).

How to Implement

The recommended format is JSON-LD, added as a <script type="application/ld+json"> block in the page's <head> or <body>.

Example for a business website:

<script type="application/ld+json">{"@context": "https://schema.org", "@type": "Organization", "name": "Envestis SA", "url": "https://envestis.com", "logo": "https://envestis.com/logo.png", "address": {"@type": "PostalAddress", "addressLocality": "Lugano", "addressRegion": "Ticino", "addressCountry": "CH"}, "contactPoint": {"@type": "ContactPoint", "contactType": "customer service", "availableLanguage": ["English", "Italian", "French", "German"]}}</script>

Common structured data types for business websites:

  • Organization / LocalBusiness: Company information, address, contact details.
  • BreadcrumbList: Navigation breadcrumbs that appear in search results.
  • Article / BlogPosting: Blog articles with author, date, and image.
  • FAQPage: FAQ sections that can appear directly in search results.
  • Service: Professional services offered by the business.
  • WebSite with SearchAction: Enables sitelinks search box in search results.

Validation: Use Google's Rich Results Test (search.google.com/test/rich-results) and Schema Markup Validator (validator.schema.org) to verify your implementation.

Canonical URLs

Canonical URLs tell search engines which version of a page is the "official" one when the same content is accessible at multiple URLs.

When you need canonicals:

  • The same page is accessible with and without trailing slash (/about and /about/).
  • URL parameters create duplicate content (/products?sort=price vs /products).
  • HTTP and HTTPS versions both resolve (they should not, but sometimes they do).
  • www and non-www versions both resolve.
  • Content is syndicated on other sites.

Implementation:

Add <link rel="canonical" href="https://example.com/page"> to every page's <head>. The canonical URL should be the absolute URL with your preferred protocol and domain format.

Self-referencing canonicals (where a page points to itself) are a best practice. They prevent issues when URL parameters or tracking codes create unintentional duplicates.

Hreflang for Multilingual Sites

If your website serves content in multiple languages (as most Swiss business websites should), hreflang tags tell Google which language version to show to users based on their language and location.

Why it matters for Switzerland: Switzerland has four national languages. A business website in Ticino targeting Swiss customers should ideally have content in Italian, German, French, and English. Without hreflang, Google might show the German version to an Italian-speaking user in Lugano.

Implementation:

Add hreflang link elements to each page's <head>:

<link rel="alternate" hreflang="en" href="https://example.com/en/about">
<link rel="alternate" hreflang="it" href="https://example.com/it/about">
<link rel="alternate" hreflang="fr" href="https://example.com/fr/about">
<link rel="alternate" hreflang="de" href="https://example.com/de/about">
<link rel="alternate" hreflang="x-default" href="https://example.com/en/about">

Key rules:

  • Every page must reference all language versions, including itself.
  • Hreflang annotations must be reciprocal: if page A points to page B, page B must point back to page A.
  • Use x-default for the fallback version (shown when no other language matches the user's preferences).
  • The hreflang value should match the page's actual language. Do not point a hreflang="de" annotation to a page that is actually in English.
  • For regional targeting, use language-region codes: de-CH for Swiss German, fr-CH for Swiss French, it-CH for Swiss Italian.

XML Sitemap Generation

An XML sitemap lists all the pages on your site that you want search engines to index. It helps search engines discover pages, especially on large or complex sites.

Best practices:

  • Include only canonical URLs (no duplicates, no parameterized versions).
  • Include the <lastmod> date and keep it accurate (use the actual date the content was last modified, not the current date).
  • Keep individual sitemap files under 50MB or 50,000 URLs. Use a sitemap index for larger sites.
  • For multilingual sites, use the xhtml:link element within the sitemap to specify hreflang relationships.
  • Submit your sitemap through Google Search Console and reference it in your robots.txt.
  • Automate sitemap generation as part of your build process. For static sites, tools like astro, next-sitemap, or custom build scripts can generate sitemaps at build time.

Robots.txt Configuration

The robots.txt file tells search engine crawlers which parts of your site to crawl and which to skip. It is placed at the root of your domain (example.com/robots.txt).

Common configuration:

User-agent: *
Allow: /
Disallow: /api/
Disallow: /admin/
Disallow: /internal/

Sitemap: https://example.com/sitemap.xml

Key points:

  • robots.txt is a directive, not a security measure. It tells well-behaved crawlers where not to go, but it does not prevent access. Do not rely on it to hide sensitive content.
  • Blocking CSS and JavaScript files in robots.txt can prevent Google from rendering your pages correctly. Do not block your asset directories.
  • Always include the Sitemap: directive pointing to your sitemap.
  • Test your robots.txt using the Robots Testing Tool in Google Search Console.

Rendering Strategies and SEO Impact

How your website generates HTML has a direct and significant impact on SEO. There are three main rendering strategies:

Server-Side Rendering (SSR)

The server generates the full HTML for each page on every request and sends it to the browser. The browser receives complete content immediately.

SEO impact: Good. Search engines receive fully rendered HTML without needing to execute JavaScript.

Trade-offs: Server load increases with traffic. Each request requires CPU time to render the page. TTFB can be slower than static hosting because the server does work before responding.

Static Site Generation (SSG)

All pages are pre-rendered to HTML at build time. The resulting HTML files are deployed to a CDN and served as-is to every request.

SEO impact: Best. Pages load instantly from CDN edge nodes, TTFB is minimal, there is no JavaScript dependency for content rendering, and Googlebot can crawl and index content without executing any JavaScript.

Trade-offs: Content changes require a rebuild and redeployment. Not suitable for highly dynamic content that changes per request.

Client-Side Rendering (CSR)

The server sends a minimal HTML shell with JavaScript. The JavaScript executes in the browser and generates the content dynamically.

SEO impact: Problematic. Google claims to be able to render JavaScript, but in practice there are issues:

  • There is a delay between discovery and rendering. Google has a two-phase indexing process: first it indexes the raw HTML, then it renders the JavaScript later. This can take days or weeks.
  • Not all JavaScript is rendered correctly. Complex single-page applications (SPAs) with client-side routing, lazy loading, and dynamic content injection can confuse Googlebot.
  • Other search engines (Bing, Yandex, DuckDuckGo) have less capable JavaScript rendering.
  • Core Web Vitals suffer because content only appears after JavaScript downloads, parses, and executes.

If your site uses CSR (React, Vue, Angular SPA), consider:

  • Pre-rendering critical pages to static HTML.
  • Using SSR for the initial page load (Next.js, Nuxt.js, Angular Universal).
  • At minimum, implementing dynamic rendering (serving pre-rendered HTML to search engine crawlers).

Lazy Loading Images Correctly

Lazy loading defers the loading of images that are not visible in the viewport until the user scrolls to them. This improves initial page load time but can be implemented incorrectly.

Do:

  • Use the native loading="lazy" attribute on <img> tags for images below the fold.
  • Always include width and height attributes to prevent CLS.
  • Include meaningful alt text for accessibility and image SEO.

Do not:

  • Lazy load images above the fold (the first screen the user sees). This delays LCP.
  • Lazy load the LCP element. It should load as fast as possible.
  • Use JavaScript-based lazy loading libraries when the native attribute works. The native attribute has broad browser support and does not add JavaScript overhead.
  • Hide images behind JavaScript interactions. If Googlebot cannot see the image without interacting with the page, it will not be indexed.

JavaScript SEO Pitfalls

JavaScript is the most common source of technical SEO problems on modern websites. Here are the pitfalls to avoid:

  • Content rendered only via JavaScript: If your main content is generated by JavaScript and not present in the initial HTML, Google may not index it (or may index it with delay).
  • Client-side routing without proper configuration: SPAs that use client-side routing (React Router, Vue Router) need to ensure that each route produces a unique URL that Googlebot can crawl. Use the History API, not hash-based routing (/#/page).
  • Infinite scroll without pagination: If your content loads via infinite scroll, Googlebot cannot access content beyond the initial load. Provide paginated alternatives (/blog/page/2) or use the <a href> tags that Googlebot can follow.
  • Dynamic meta tags: If your <title> and <meta description> tags are set by JavaScript after page load, Google may use the initial (empty or generic) values instead of the dynamically set ones.
  • Blocked JavaScript resources: If your robots.txt blocks JavaScript files, Google cannot execute them and cannot render your page.

Internal Linking Architecture

Internal links are how search engines discover and understand the relationship between pages on your site. A well-structured internal linking architecture distributes PageRank efficiently and helps Google understand your site's hierarchy.

Best practices:

  • Use descriptive anchor text: "Read our guide to HTTP security headers" is better than "click here."
  • Create a logical hierarchy: Homepage links to main sections, main sections link to subsections, subsections link to individual pages. Every page should be reachable within 3 clicks from the homepage.
  • Use HTML links: <a href="/page"> is crawlable. JavaScript navigation that changes the URL without <a> tags may not be followed by Googlebot.
  • Link from high-authority pages to important content: Your homepage has the most authority. Link from it to your most valuable pages.
  • Fix broken internal links: 404 errors waste crawl budget and distribute no PageRank. Use tools like Screaming Frog or Sitebulb to find and fix broken links.

Page Speed Optimization Checklist

A quick-reference checklist for the most impactful page speed optimizations. We also have a detailed article on website performance optimization and another on why websites are slow.

  1. Serve images in WebP or AVIF format with fallbacks for older browsers. These formats are 25-50% smaller than JPEG/PNG at comparable quality.
  2. Implement responsive images with srcset so mobile devices do not download desktop-sized images.
  3. Enable HTTP/2 or HTTP/3 on your server for multiplexed connections.
  4. Enable Brotli or Gzip compression for text-based resources (HTML, CSS, JavaScript, JSON).
  5. Minify CSS and JavaScript to remove whitespace, comments, and unnecessary code.
  6. Inline critical CSS for above-the-fold content and load the rest asynchronously.
  7. Defer non-critical JavaScript with the defer or async attribute.
  8. Preconnect to required origins with <link rel="preconnect" href="https://fonts.googleapis.com">.
  9. Cache static assets aggressively with long Cache-Control headers and content-hashed filenames for cache busting.
  10. Reduce third-party scripts to the minimum necessary. Each external script adds DNS lookups, TCP connections, and JavaScript execution time.
  11. Use a CDN to serve assets from edge nodes close to your users.
  12. Optimize web fonts: subset fonts to include only the characters you use, preload them, and use font-display: swap.

How to Audit with Key Tools

Lighthouse

Built into Chrome DevTools (F12, then the Lighthouse tab). Runs a comprehensive audit covering performance, accessibility, best practices, SEO, and PWA. Run audits in an incognito window to avoid browser extensions affecting results. Use the "Mobile" configuration since Google uses mobile-first indexing.

PageSpeed Insights

Google's online tool (pagespeed.web.dev) that combines Lighthouse scores with real-world data from the Chrome User Experience Report (CrUX). The field data section shows how real users experience your site, which is what Google uses for ranking. Lab data (the Lighthouse score) shows potential issues under controlled conditions.

Google Search Console

The Core Web Vitals report in Search Console shows how your pages perform for real users, grouped by status (Good, Needs Improvement, Poor). It also flags pages with indexing issues, mobile usability problems, and structured data errors. Every website should have Search Console configured.

Additional Tools

  • Screaming Frog: Crawls your site like a search engine and identifies technical issues: broken links, missing meta tags, duplicate content, redirect chains.
  • WebPageTest: Detailed waterfall analysis showing exactly when each resource loads, with testing from multiple locations worldwide.
  • Chrome DevTools Performance tab: Records and analyzes runtime performance, showing long tasks, layout shifts, and JavaScript execution bottlenecks.

Mobile-First Indexing

Google predominantly uses the mobile version of your site for indexing and ranking. This has been the default since 2019 and became mandatory for all sites. What this means practically:

  • Your mobile version must contain the same content as your desktop version. If you hide content on mobile, Google may not index it.
  • Structured data must be present in the mobile version.
  • Meta tags (title, description, robots) must be the same on mobile and desktop.
  • Images on the mobile version must have proper alt text.
  • The mobile version must be accessible to Googlebot (not blocked by robots.txt or noindex).

For responsive websites (which is the recommended approach), this is mostly automatic. The same HTML is served to both mobile and desktop, just styled differently with CSS. Problems arise when you serve different HTML to mobile users or use a separate mobile domain (m.example.com).

Why Static Sites Win at Technical SEO

Throughout this guide, you may have noticed a pattern: many technical SEO problems are caused by dynamic rendering, JavaScript dependencies, and server-side processing. Static sites avoid most of these by design.

  • LCP: Static HTML served from a CDN edge node loads faster than any dynamically rendered page.
  • FID/INP: Minimal JavaScript means minimal main thread blocking.
  • CLS: Pre-rendered HTML with explicit image dimensions has predictable layout.
  • Crawlability: Plain HTML with no JavaScript dependencies is perfectly crawlable by every search engine.
  • Indexing: No two-phase indexing delay. Content is in the HTML from the first crawl.
  • Server response time: CDN response is measured in milliseconds.
  • Security: Fewer security issues means fewer Google warnings. See our article on static vs dynamic security.

For business websites, portfolios, blogs, and informational sites (which are the majority of websites), static site generation provides the best technical SEO foundation available. We build websites on this architecture at Envestis specifically because it gives our clients a measurable advantage in search performance.

If your website has technical SEO issues that are costing you rankings, or if you want to rebuild on architecture that maximizes your search visibility, contact our team in Lugano. We specialize in high-performance, SEO-optimized web development for businesses in Switzerland.

Want to know if your site is secure?

Request a free security audit. In 48 hours you get a complete report.

Request Free Audit

Related Articles

Performance

Core Web Vitals: How Website Speed Directly Affects Your Google Ranking

Google uses Core Web Vitals as a ranking signal. Sites that load slowly, shift layout unexpectedly, or respond sluggishly to interactions get penalized in search results. Here is what the metrics mean, how to measure them, and how to fix common problems.

· 16 min read
Performance

Website Performance Optimization: The Practical Guide

A hands-on guide to making websites fast. Covers image optimization, CSS/JS bundling, font loading, caching strategies, the critical rendering path, third-party script impact, and how to measure what actually matters.

· 20 min read
Performance

CDN: Speed and Security for Your Website

A Content Delivery Network does much more than speed up your site. We cover how CDNs work, their security benefits including DDoS protection and WAF, caching strategies, and a comparison of major providers.

· 14 min read

Quick Contact