Core Web Vitals · Lighthouse · Schema

Ottimizzazione SEO tecnica — come si fa, fase per fase

Audit checklist, fix dei Core Web Vitals, structured data, render-blocking, mobile-first.

Puoi avere i contenuti migliori del mondo, ma se il tuo sito è lento, rotto o incomprensibile per Google, non andrai da nessuna parte. L'Ottimizzazione SEO tecnica è l'ingegneria che permette al tuo sito di competere. Velocità, sicurezza, architettura informativa.

4.9/5Rating

150+Clienti

+250%ROI Medio

I Nostri Risultati

100

Speed

Zero

Errors

Top

Tech

Garanzia Soddisfatti o Rimborsati

Core Web Vitals 2026: cosa sono e perché Google li usa come ranking factor

Dal giugno 2021 Google ha introdotto i Core Web Vitals come segnale di ranking ufficiale (Page Experience Update). Da marzo 2024 INP ha sostituito FID. Sono i 3 numeri che misurano l'esperienza utente percepita. **LCP — Largest Contentful Paint (target: <2.5 secondi)** Tempo per renderizzare il principale elemento sopra la fold (hero image, H1, contenuto principale). LCP lento = utenti che abbandonano prima di vedere qualsiasi cosa. **INP — Interaction to Next Paint (target: <200 ms)** Tempo tra un'interazione utente (click, tap) e la risposta visiva del sito. INP alto = sito "lagga" alle interazioni. **CLS — Cumulative Layout Shift (target: <0.1)** Quanto il layout della pagina "salta" dopo il caricamento iniziale (banner che spuntano spostando i pulsanti, immagini senza dimensioni dichiarate, font che cambiano height). CLS alto = utente clicca cose sbagliate.

1
Come misurare i tuoi Core Web Vitals (oggi)

Tre strumenti gratuiti: (1) **PageSpeed Insights** (https://pagespeed.web.dev/) ti dà sia dati lab che dati field reali (CrUX), per ogni URL. (2) **Search Console > Core Web Vitals** ti dà aggregato sito completo, divide URL in Good/Needs improvement/Poor. (3) **Lighthouse** in Chrome DevTools (Audit tab) per analisi tecnica deep per URL singola.

2
Differenza tra Lab e Field data

Lab data = test sintetico controllato (PageSpeed Insights, Lighthouse) — utile per debug. Field data = dati REALI degli utenti aggregati da CrUX (Chrome User Experience Report). Google usa **field data** per il ranking, non lab. Se i tuoi field data sono Poor ma lab Good, c'è disallineamento da indagare.

Come fixare LCP (Largest Contentful Paint) — passo per passo

LCP lento è quasi sempre causato da uno di questi 4 problemi. Ecco come diagnosticare e fixare. **1. Server response time (TTFB) lento** Se il TTFB (Time To First Byte) è >800ms, qualsiasi altra ottimizzazione frontend non basta. Cause comuni: hosting condiviso scadente, database lento, mancanza di CDN, server overload. Fix: migrare a hosting decente (Cloudflare Pages, Vercel, edge), abilitare caching server-side, ridurre query DB. **2. Render-blocking resources** File CSS o JS sincroni nel <head> che bloccano il rendering iniziale. Fix: inline del **critical CSS** (solo CSS necessario per above-the-fold), deferire/async di tutto il JS non critico, lazy-loading dei JS di analytics. **3. Immagine LCP non ottimizzata** L'elemento più grande sopra la fold è quasi sempre un'immagine. Fix: formato moderno (WebP o AVIF, −60% peso vs JPEG), `<img loading="eager" fetchpriority="high">` sull'LCP (non lazy), dimensioni `width`/`height` dichiarate per evitare CLS, `<picture>` con `srcset` per responsive. **4. Web fonts in blocco** Font Google caricati con `@import` o `<link>` standard causano FOIT (Flash of Invisible Text). Fix: `<link rel="preload">` per i font critici, `font-display: swap` nelle declarations CSS, self-hosting dei font su edge CDN del sito.

1
Target LCP e impatto stimato

Da Google: passare da LCP "Poor" (>4s) a "Good" (<2.5s) può ridurre il bounce rate del 25-50% e aumentare conversion rate del 10-30%. Su siti e-commerce di volume, anche 100ms di miglioramento valgono milioni di euro all'anno (analisi di settore Cloudflare, Akamai, Google).

2
Cosa NON funziona (anti-pattern)

Plugin WordPress generici di "speed optimization" tipo WP Rocket, WP Super Cache, Autoptimize: aiutano ma non sostituiscono ottimizzazione tecnica. Tool "AMP" è obsoleto, Google ne ha rimosso il boost dal 2021. Compressione gzip da sola: necessaria ma insufficiente.

INP (Interaction to Next Paint): la metrica che ha sostituito FID nel 2024

INP è la nuova metrica di interattività. Misura quanto velocemente il sito risponde alle azioni utente (click, tap, key press). Target: <200ms al 75° percentile delle interazioni. ### Cause comuni di INP alto **1. JavaScript pesante che blocca il main thread** Script di terze parti (chat widget, analytics, tag manager, ads) che monopolizzano il thread principale. Fix: caricare async/defer, valutare se servono tutti, considerare GTM Server Container per ridurre il payload client. **2. Long tasks (>50ms)** Funzioni JS che bloccano il main thread per più di 50ms. Fix: spezzettare in micro-task con `requestIdleCallback` o `setTimeout(fn, 0)`, code splitting per caricare codice solo quando serve. **3. Layout shift durante interazione** Banner che appaiono durante il tap su un pulsante, modali che spostano elementi. Fix: spazio riservato a priori per banner/modali (no `display: none` → `display: block`). ### Misurazione real-time Chrome DevTools > Performance Insights > Real-time INP tracking. Mostra quale interazione specifica è la più lenta. Spesso è 1 sola sequenza problematica che pesa sul percentile.

1
Tool gratuiti per debug INP

**Web Vitals Chrome Extension** (https://chrome.google.com/webstore/detail/web-vitals/ahfhijdlegdabablpippeagghigmibma): badge live nel browser, mostra LCP, INP, CLS in tempo reale durante la navigazione. **Chrome DevTools Performance tab**: registra una sessione, analizza il flame chart per identificare long tasks.

2
Differenze rispetto a FID (deprecato)

FID misurava solo il PRIMO input (di solito il più veloce). INP misura il p75 di TUTTE le interazioni durante la sessione, dando un quadro più realistico. Molti siti che avevano "FID Good" sono passati a "INP Poor" senza modifiche tecniche — semplicemente, era stata misurata male prima.

Structured Data Schema.org: implementazione corretta per Rich Results

I Rich Results (recensioni con stelline, prezzi prodotto, FAQ accordion, breadcrumb) richiedono structured data validi. Il formato standard è JSON-LD nel `<head>` o `<body>`. ### Schema più usati per tipologia sito **E-commerce**: `Product` (con offers, aggregateRating, review), `BreadcrumbList`, `Organization`. **Local Business**: `LocalBusiness` (con address, openingHours, geo), `Service` per ogni servizio offerto. **Blog/Editoriale**: `Article` (con author, datePublished, publisher), `FAQPage` per le sezioni FAQ. **Software/App**: `SoftwareApplication` (con softwareVersion, applicationCategory). **Course/Education**: `Course` (con provider, courseCode, offerings). ### Validazione obbligatoria Tutti gli schema vanno validati con il **Rich Results Test ufficiale Google** (https://search.google.com/test/rich-results). Schema invalidi non producono Rich Results e in alcuni casi possono triggherare manual action (penalizzazione manuale). ### Anti-pattern frequenti - ⚠️ Schema markup di prodotti che NON ESISTONO sulla pagina (Google rileva e penalizza) - ⚠️ AggregateRating con review fake (Google sa, lo controlla via crawling delle review effettive) - ⚠️ FAQPage schema senza che le FAQ siano visibili al utente sulla pagina (dovrebbe essere identico ai contenuti rendered)

1
Schema markup avanzato (2026)

**Speakable** per voice search (Google Assistant, Alexa). **HowTo** per guide step-by-step (richiede però immagini per ogni step). **VideoObject** per video embed (con thumbnailUrl, duration, contentUrl). **JobPosting** per portali lavoro (richiede salary, location, datePosted, validThrough).

2
Implementation a livello sviluppo

Su React/Next.js: usare componenti come **next-seo** o **react-schemaorg** per type-safety. Su WordPress: plugin come Yoast SEO Premium o Rank Math hanno schema generatori (con limiti). Per progetti custom: scrivere componente `<JsonLd>` che inietta script type=application/ld+json nel head.

Domande Frequenti sulla Gestione Ottimizzazione SEO

Rispondiamo alle domande più comuni che riceviamo dai nostri clienti

1Quanto tempo serve per migliorare i Core Web Vitals?

Fix tecnici puri (critical CSS, immagini WebP, font preload): 1-3 settimane. Cambio hosting o re-architettura del frontend: 4-12 settimane. I dati field CrUX si aggiornano con cadenza 28 giorni rolling, quindi anche dopo fix immediati vedi miglioramenti in Search Console dopo ~4 settimane.

2Posso fare l'ottimizzazione tecnica SEO senza riscrivere tutto il sito?

Sì, nella maggior parte dei casi. Il 70-80% dei problemi tecnici si risolve senza re-build completo: critical CSS inline, lazy-loading, ottimizzazione immagini, structured data, fix meta tag, sitemap pulita. Solo siti con architetture irrimediabilmente compromesse (PHP legacy senza caching, WordPress con 50+ plugin attivi, ecc.) richiedono migrazione.

3Lavorate su WordPress, Shopify, custom?

Sì a tutti. WordPress: focus su pulizia plugin, caching server-side, immagini ottimizzate, schema via Yoast/Rank Math. Shopify: structured data via metafield, performance limitata dal platform (è SaaS). Custom React/Next.js: massima flessibilità per ottimizzazioni deep, target Lighthouse 95+.

4Garantite Lighthouse score 100/100?

No. Lighthouse 100 è quasi sempre un costo-beneficio sfavorevole: per arrivarci serve rimuovere funzionalità (chat widget, video player, ecc.) che il cliente vuole tenere. Target realistico: Performance Mobile ≥85, Accessibility ≥90, Best Practices ≥90, SEO 100. Questi numeri sono già sopra il 95° percentile dei siti italiani.

5Quanto costa un audit tecnico SEO?

Audit one-shot completo: €1.500-€2.500 in base alla complessità del sito (numero pagine, CMS, presenza e-commerce). Output: PDF di 30-50 pagine con gap analysis quantitativa, priorità ABC, stima effort per fix. Se poi vuoi che l'implementazione la facciamo noi: passaggio a retainer mensile o sprint.