Un sito web SEO friendly è un sito che Google riesce a scansionare, renderizzare e interpretare senza attriti, e che una persona riesce a usare dal telefono. Quasi tutto quello che lo rende tale viene deciso prima che esista una riga di contenuto: dove vive il dominio, quanto è profonda l'architettura, quanta parte del testo dipende dal JavaScript. Sono anche le decisioni che costano di più da cambiare dopo.
Le guide italiane su questo argomento elencano le buone pratiche senza quantificarle. Qui i numeri ci sono, e vengono dal Web Almanac 2025, da uno studio di Vercel e MERJ su come Googlebot tratta il JavaScript, dalla documentazione di Google e dai dati Search Console di un progetto italiano che seguiamo.
Le decisioni che dopo non si tornano indietro
Questa tabella è il modo più rapido che ho trovato per spiegare a un cliente perché la SEO va chiamata al momento del wireframe e non al lancio.
| Decisione | Quando si prende | Cosa costa correggerla dopo |
|---|---|---|
| Dominio unico o sezioni su sottodominio | Prima di comprare l'hosting | Migrazione, catena di redirect, autorevolezza da ricostruire da zero |
| Profondità dell'architettura | Wireframe | Rifacimento di menu, breadcrumb e link interni |
| Formato degli URL | Primo popolamento | Un redirect 301 per ogni pagina, da mantenere per anni |
| CMS e tema | Scelta tecnologica | Rifacimento del front end |
| Quota di contenuto che dipende dal JavaScript | Scelta del framework | Introduzione del rendering lato server su un progetto già in produzione |
| Gestione delle lingue | Prima della seconda lingua | Hreflang, contenuti duplicati, pagina sbagliata in SERP per mesi |
Le ultime due righe sono quelle che nelle prime pagine italiane su questa query non compaiono quasi mai, ed è lì che oggi si perde più visibilità.
Dominio unico o sottodominio: un dato di prima mano
Google non penalizza un sottodominio in quanto tale. Il punto è un altro: un sottodominio è un secondo sito da far crescere, e quasi nessuno lo fa crescere davvero.
Un e-commerce italiano di attrezzatura outdoor che seguiamo ha lo shop su un sottodominio separato dal sito principale, scelta presa anni fa quando il sito è stato costruito. Questi sono i dati organici dei due host nello stesso periodo.
| Host | Clic organici | Impressioni | Posizione media su mobile |
|---|---|---|---|
| Dominio principale (www) | 4.484 | 190.200 | 5,2 |
| Sottodominio dello shop | 82 | 4.718 | 13,3 |
Il sottodominio raccoglie l'1,8% dei clic del dominio principale e si posiziona in media otto posizioni più indietro. Non è un esperimento controllato: i due host hanno contenuti diversi e storie di link diverse. È proprio questo il punto. Dividere il sito in due host significa dover fare due volte il lavoro di autorevolezza, e nei fatti lo si finisce per fare su uno solo.
La regola che applico: sottocartella per tutto quello che deve posizionarsi, quindi blog, shop e pagine di categoria; sottodominio solo per quello che con la ricerca non c'entra, come un'area riservata o uno strumento interno. La scelta del dominio e della sua struttura viene prima di ogni altra cosa.
L'architettura: quante pagine, e a che distanza dalla home
Un'architettura SEO friendly nasce dalla ricerca delle parole chiave, non dall'organigramma aziendale. Ogni pagina risponde a una domanda, e domande diverse vogliono pagine diverse anche quando il commerciale le considera lo stesso prodotto.
Macropix, produttore milanese di schermi LED e cliente Visilay di lunga data, ha una pagina per ledwall, una per la versione indoor, una per la outdoor e una per i totem. Quattro pagine per quella che internamente è una sola famiglia di prodotto: la separazione viene dall'intento di ricerca, non dal catalogo.
Due vincoli pratici da rispettare in fase di wireframe. Nessuna pagina che vuoi posizionare dovrebbe stare a più di tre clic dalla home, e le breadcrumb sono il modo più economico per accorciare quella distanza su ogni pagina profonda. E ogni pagina nuova deve ricevere almeno un link interno da una pagina che Googlebot visita già: una pagina che esiste solo nella sitemap è una pagina che Google scopre tardi.
Gli URL si scrivono una volta sola
Corti, in minuscolo, parole separate da trattini, senza date e senza numeri di versione, senza parametri per i contenuti che devono posizionarsi. La regola più utile è anche la più noiosa: un URL non si cambia se non c'è un motivo serio, perché ogni cambio è un redirect da mantenere finché il sito esiste.
Il canonical è la seconda metà del lavoro e manca più spesso di quanto si pensi: secondo il capitolo SEO del Web Almanac 2025 il tag canonical è presente sul 68% delle pagine desktop analizzate. Il restante terzo lascia decidere a Google quale versione dell'URL conta, e Google decide bene solo qualche volta.
Il CMS pesa più del tema che ci metti sopra
Il capitolo CMS del Web Almanac 2025 incrocia i dati di campo del Chrome UX Report con la piattaforma usata. Il 45% dei siti WordPress supera i Core Web Vitals; su Duda la quota arriva all'85%. Il campione è mondiale e una media non descrive nessun sito in particolare, ma dice una cosa vera: la piattaforma sposta il punto di partenza.
WordPress non è lento di suo. È che la media di WordPress è fatta di temi pesanti e di plugin accumulati per anni. Se la scelta cade lì, e per la maggior parte dei siti aziendali italiani è una scelta ragionevole, la decisione vera sono il tema e il numero di plugin, non il CMS.
Quanto JavaScript può reggere il sito
Google renderizza il JavaScript, e i dati lo confermano: nello studio di Vercel e MERJ su oltre 100.000 richieste di Googlebot al sito nextjs.org, il 100% delle pagine HTML indicizzabili è stato renderizzato per intero, comprese quelle con interazioni JavaScript complesse.
Il problema è il tempo. Nello stesso studio la latenza della coda di rendering aveva una mediana di 10 secondi, un 75° percentile di 26 secondi, un 90° percentile intorno alle 3 ore e un 99° percentile intorno alle 18 ore. La documentazione di Google lo dice con più cautela: "The page may stay on this queue for a few seconds, but it can take longer than that".
La parte che in Italia non racconta nessuno riguarda gli altri crawler. Secondo la rilevazione di Vercel sui propri log, nessuno dei principali crawler AI esegue JavaScript: GPTBot di OpenAI, ClaudeBot di Anthropic e PerplexityBot scaricano i file JS senza eseguirli. Nel mese analizzato, dicembre 2024 sulla rete Vercel e quindi su un traffico prevalentemente statunitense, GPTBot aveva fatto 569 milioni di richieste, ClaudeBot 370 milioni e PerplexityBot 24,4 milioni: insieme circa il 28% del volume di Googlebot. In Italia non esiste una rilevazione equivalente, ma i crawler sono gli stessi e il comportamento non cambia da un mercato all'altro.
Tradotto in una decisione di progetto: il testo che vuoi far leggere deve stare già nell'HTML che il server restituisce. Se il sito usa React, Vue o un framework simile, il rendering lato server non è un'ottimizzazione, è un requisito. La verifica costa trenta secondi: apri la pagina con JavaScript disattivato nel browser e guarda che cosa resta. Sul fronte dei modelli generativi vale la pena leggere anche cosa succede ai contenuti prodotti con l'AI e a che serve davvero un file llms.txt.
Le soglie di prestazione, quelle vere
I Core Web Vitals sono tre e le soglie non cambiano da anni. Si misurano sul 75° percentile delle visite reali, non su un test in laboratorio.
| Metrica | Cosa misura | Soglia "buono" al 75° percentile |
|---|---|---|
| LCP | Comparsa dell'elemento principale della pagina | 2,5 secondi o meno |
| INP | Reattività del sito alle interazioni | 200 millisecondi o meno |
| CLS | Stabilità del layout durante il caricamento | 0,1 o meno |
La distanza tra la teoria e il web reale è ampia. A luglio 2025 il 48% dei siti superava i Core Web Vitals su mobile e il 56% su desktop, in miglioramento rispetto al 44% e 55% del 2024. Un dato meno noto dello stesso capitolo: le pagine interne passano più spesso delle home, con 11 punti di vantaggio su mobile e 14 su desktop. Se un sito ha un problema di prestazioni, molto spesso ce l'ha sulla home, che è anche la pagina che si guarda per prima e si sistema per ultima. Su come intervenire c'è la guida alla velocità delle pagine.
Il telefono è la versione che conta
Da ottobre 2023 Google indicizza tutto il web con Googlebot smartphone. Quello che non c'è nella versione mobile, per Google non c'è. Sull'e-commerce outdoor citato sopra, nello stesso periodo, il 69% dei clic organici e il 65% delle impressioni arrivano da mobile.
Gli errori che vedo più spesso sono due, e nascono entrambi in fase di progettazione grafica: contenuto presente sul desktop e rimosso dal breakpoint mobile, e immagini servite alla stessa risoluzione su tutti i dispositivi. Il secondo si risolve con srcset e formati moderni, e l'ottimizzazione delle immagini è il primo posto dove guardare quando l'LCP non rientra.
Cosa si controlla prima di mettere online
Sono controlli da fare una volta, e sono gli stessi che poi ritrovo mancanti negli audit. La colonna di destra dice quanto sono diffusi sul web, secondo il Web Almanac 2025.
| Elemento | Quota di pagine o siti che ce l'ha (desktop, 2025) |
|---|---|
| robots.txt che risponde 200 | 84,9% (nel 13,3% dei casi risponde 404) |
| HTTPS | 91,7% |
| Meta description | 67,7% |
| Tag canonical | 68% |
| H1 presente | 71% |
| Immagini con attributo alt | 60% (valore mediano) |
| File llms.txt | 2,13% |
A questi aggiungo la sitemap XML inviata in Search Console, i dati strutturati sui tipi di pagina che li prevedono, e title e meta description scritti a mano sulle pagine che contano. Se il sito nasce già multilingua, l'hreflang si imposta prima di pubblicare la seconda lingua e non dopo: la SEO internazionale è la voce che genera più lavoro di recupero.
Se il sito è già online
Rifare tutto raramente conviene. L'ordine con cui intervengo, dal rapporto effetto-costo migliore al peggiore:
- Verificare che il testo sia nell'HTML del server. Se non c'è, tutto il resto è inutile.
- Sistemare canonical, robots e indicizzazione: sono ore di lavoro, non settimane.
- Intervenire sui link interni e sulla profondità delle pagine che già portano impression.
- Lavorare su LCP e immagini, partendo dalle pagine con più impression in Search Console.
- Toccare gli URL solo se c'è un problema strutturale, mai per estetica, e sempre con redirect 301 uno a uno.
Il resto è SEO tecnica ordinaria e ottimizzazione on page, che si fanno a sito vivo senza rimetterlo in cantiere.
Quanto ci mette un sito nuovo a portare traffico
Le aspettative sbagliate su questo punto rovinano più progetti di qualunque errore tecnico. Uno studio Ahrefs del 2025 su un milione di URL trova che l'1,74% delle pagine pubblicate entra nella top 10 entro un anno, che la pagina in prima posizione ha in media 5 anni e che il 72,9% delle pagine in top 10 ha più di tre anni. Un studio precedente, del 2023, su un indice di 14 miliardi di pagine, aveva misurato che il 96,55% non riceve alcun traffico da Google.
Entrambi i campioni sono in prevalenza in inglese e su mercato statunitense. In italiano la concorrenza su molte query è più bassa e i tempi possono accorciarsi, ma l'ordine di grandezza resta quello: mesi, non settimane. Per contesto, secondo l'Istat nel 2025 il 76,5% delle imprese italiane con almeno 10 addetti ha un sito web, quindi la concorrenza esiste anche nelle nicchie industriali.
Su Macropix la keyword "monitor pubblicitario" è passata da posizione 88 a posizione 2, e sul cluster monitorato il dominio tiene una share of voice del 25,55%, davanti ad amazon.it. La prima posizione su "ledwall" è arrivata dopo un lavoro pluriennale sull'intera struttura del sito, non dopo un intervento singolo. Il caso completo sta nell'articolo sulla SEO per l'industria manifatturiera, gli altri progetti sono raccolti nella pagina progetti.
Se il sito è ancora sulla carta, questa è la fase in cui un intervento SEO costa meno di tutte le altre, e infatti è anche quella in cui viene chiesto meno spesso: la consulenza SEO in fase di progettazione vale più di sei mesi di recupero dopo il lancio.
La regola che imporrei a un progetto nuovo
Se potessi imporre una sola verifica a chi costruisce un sito, sarebbe questa: aprire una pagina qualsiasi con il JavaScript disattivato e trovarci dentro il testo, i link e i titoli. Da lì discende quasi tutto il resto, perché un sito che regge quella prova regge anche la coda di rendering di Google, i crawler che il JavaScript non lo eseguono e un telefono in 4G a metà tacca. Nel 2020 quella prova serviva a un solo destinatario. Oggi i destinatari sono almeno quattro, e tre non hanno un motore di rendering.
Domande frequenti
No. Il tema incide su prestazioni e struttura dei titoli, ma non decide dominio, architettura, URL, rendering e gestione delle lingue, che sono le voci più costose da correggere. Il Web Almanac 2025 misura che il 45% dei siti WordPress supera i Core Web Vitals: la differenza tra questi e gli altri sta quasi sempre nel numero di plugin e nel peso del tema, non nell'etichetta "SEO friendly" del tema stesso.
Sottocartella, se devono posizionarsi. Google non penalizza i sottodomini, ma un sottodominio va fatto crescere come un sito a sé. Su un e-commerce italiano che seguiamo, il sottodominio dello shop raccoglie l'1,8% dei clic organici del dominio principale e si posiziona in media otto posizioni più indietro. Il sottodominio resta la scelta giusta per aree riservate e strumenti interni.
Le soglie ufficiali dei Core Web Vitals, misurate sul 75° percentile delle visite reali, sono: LCP entro 2,5 secondi, INP entro 200 millisecondi, CLS pari o inferiore a 0,1. A luglio 2025 le rispettava il 48% dei siti su mobile e il 56% su desktop. Il valore che conta è quello di campo del Chrome UX Report, non il punteggio di un test in laboratorio.
Non in sé. Nello studio di Vercel e MERJ su oltre 100.000 richieste di Googlebot, il 100% delle pagine HTML indicizzabili è stato renderizzato, ma la coda di rendering aveva una mediana di 10 secondi e un 90° percentile intorno alle 3 ore. In più, GPTBot, ClaudeBot e PerplexityBot non eseguono JavaScript. Con il rendering lato server il problema non si pone; senza, il contenuto rischia di essere invisibile ai motori di risposta.
Quasi mai. Nell'ordine: verifica che il testo sia nell'HTML restituito dal server, sistema canonical e indicizzazione, poi link interni e profondità delle pagine, poi LCP e immagini partendo dalle pagine con più impression. Gli URL si toccano solo per un problema strutturale, con redirect 301 uno a uno. Un rifacimento completo si giustifica quando il rendering è interamente lato client e la piattaforma non permette di cambiarlo.
Secondo lo studio Ahrefs 2025 su un milione di URL, l'1,74% delle pagine pubblicate entra nella top 10 entro un anno e la pagina in prima posizione ha in media 5 anni. Il campione è prevalentemente in inglese: in italiano, su nicchie meno affollate, i tempi si accorciano, ma l'unità di misura restano i mesi. Su un cliente industriale la prima posizione sulla keyword principale è arrivata dopo anni di lavoro sull'intera struttura del sito.
