La SEO tecnica è l'insieme degli interventi che permettono a un motore di ricerca di raggiungere una pagina, leggerla e conservarla nel proprio indice. Non riguarda cosa c'è scritto dentro la pagina, riguarda se qualcuno riesce ad arrivarci e a portarsela via.
Le guide che trovi in italiano la raccontano quasi tutte come una lista di voci da spuntare: robots.txt, sitemap, canonical, Core Web Vitals, dati strutturati, analisi dei log. Il 17 settembre 2026 ho misurato le sei pagine editoriali che si posizionano in prima pagina su Google.it per "SEO tecnica". Nessuna supera la checklist che descrive.
Le sei pagine che in Italia spiegano la SEO tecnica non sono tecnicamente pulite
Ho passato le sei URL editoriali della prima pagina italiana attraverso l'On-Page API di DataForSEO, con l'esecuzione del JavaScript disattivata, cioè leggendo l'HTML esattamente come lo riceve un crawler che non renderizza. Scansione del 17 settembre 2026, una rilevazione per pagina. Sono escluse la documentazione di Google e il risultato di LinkedIn.
| Pagina in prima posizione su "SEO tecnica" | Punteggio on-page | Errori nel markup HTML | Risorse che bloccano il rendering | Peso dell'HTML | Immagini senza alt |
|---|---|---|---|---|---|
| seozoom.it/seo-tecnica/ | 95,24 | 3 | 5 | 245 KB | sì |
| digital360.it (blog-connect) | 98,90 | 0 | 11 | 128 KB | no |
| aioseo.com/it/technical-seo/ | 97,07 | 1 | 6 | 325 KB | sì |
| it.siteground.com/blog/seo-come-funziona | 92,82 | 15 | 1 | 164 KB | no |
| rankingroad.it (seo-tecnica) | 85,27 | 0 | 0 | 185 KB | sì |
| archetipo.agency/servizi/seo/seo-tech/ | 94,15 | 9 | 8 | 69 KB | sì |
Sei pagine su sei hanno almeno una risorsa che blocca il rendering o un errore di markup. Quattro su sei hanno immagini senza attributo alt. La pagina con il punteggio più basso della serie, 85,27, è quarta. La più pesante, 325 KB di solo HTML, è seconda.
Questo non significa che la parte tecnica sia irrilevante. Significa che funziona come una soglia, non come una gara. Sopra la soglia il motore ti legge e il posizionamento lo decidono altre cose. Sotto la soglia non esisti, e nessun contenuto ti salva. Il lavoro utile è capire dove passa quella linea, che è più in basso di quanto raccontino le checklist, e smettere di ottimizzare tutto il resto.
I guasti che azzerano sono pochi e si riconoscono dal sintomo
C'è una differenza di ordine di grandezza tra un problema che rallenta e un problema che cancella. Un LCP di 3,4 secondi ti costa qualche posizione. Un noindex rimasto acceso dopo il passaggio in produzione ti toglie dall'indice. Nelle revisioni tecniche che facciamo su siti aziendali italiani, i secondi sono quasi sempre pochi e quasi sempre banali.
La tabella qui sotto è quella che uso per partire, perché il sintomo che vedi non compare mai dove sta il guasto. Si legge dall'alto: il primo controllo che dà esito negativo è il problema, gli altri aspettano.
| Sintomo | Causa più frequente | Dove si verifica in due minuti |
|---|---|---|
| La pagina non compare nemmeno cercando il titolo esatto | Meta robots noindex, oppure blocco in robots.txt | Controllo URL in Search Console, riga "Indicizzazione consentita" |
| Search Console dice "Rilevata, non indicizzata" | Pagina raggiungibile solo da sitemap, nessun link interno che la punta | Ricerca del link in ingresso con un crawler desktop |
| Pagina indicizzata ma Google mostra un'altra URL | Canonical che punta altrove, o duplicato con parametri | Sorgente della pagina, tag rel="canonical" |
| Traffico crollato dopo un restyling | Vecchie URL non redirette, o redirect a catena verso la home | Elenco delle vecchie URL dal report Pagine, richiesta una per una |
| La pagina si vede nel browser ma non nel test di Google | Contenuto iniettato via JavaScript dopo il caricamento | Confronto tra HTML sorgente e HTML renderizzato |
| Impression stabili e clic in calo | Non è un guasto tecnico: è la SERP che è cambiata sopra di te | Report Prestazioni, confronto per query |
L'ultima riga è quella che risparmia più tempo. Un calo di clic a impression stabili quasi mai è tecnico, e cercare la causa nel codice porta via settimane. Se vuoi il quadro completo delle cause possibili, l'abbiamo raccolto nell'audit SEO.
Crawling, rendering, indicizzazione: i tre punti in cui si perde una pagina
Tra la pubblicazione e la comparsa in SERP ci sono tre passaggi distinti, e una pagina può cadere in ognuno per motivi diversi.
Crawling. Googlebot deve poter raggiungere l'URL. Lo impediscono il robots.txt che blocca la directory, un errore di rete ripetuto, un errore 404 restituito solo al bot. Nota che il blocco in robots.txt non toglie la pagina dall'indice, impedisce solo di leggerla: se ha link esterni può restare in SERP senza descrizione. Per togliere davvero una pagina serve il noindex, e quindi serve che il crawler possa leggerla.
Prelievo e rendering. Googlebot scarica i primi 2 MB di un file supportato, come documenta Google Search Central. Su un HTML da 245 KB il limite non lo sfiori mai, su una pagina prodotto generata da un template con migliaia di nodi inutili può capitare. Poi arriva la fase in cui il JavaScript viene eseguito, che è quella che separa Google da quasi tutti gli altri.
Indicizzazione. Il documento viene valutato e, se ritenuto abbastanza utile, conservato. Qui il canonical decide quale versione viene tenuta e quale scartata. Secondo il capitolo SEO del Web Almanac 2025 di HTTP Archive, il 67% delle pagine mobile ha un canonical e nello 0,71% dei casi il valore nell'HTML grezzo è diverso da quello nel DOM renderizzato. È una percentuale piccola su scala mondiale, ed è comunque il tipo di incoerenza che su un singolo sito produce mesi di pagine sbagliate in SERP. Quando il canonical è impostato male il risultato pratico è contenuto duplicato che si mangia da solo.
Il crawl budget quasi certamente non è il tuo problema
È il capitolo che compare in ogni guida italiana e che quasi nessun lettore italiano dovrebbe leggere. Google indica due soglie nella documentazione sulla gestione del crawl budget: siti oltre il milione di pagine uniche con contenuti che cambiano ogni settimana, e siti oltre le 10.000 pagine uniche con contenuti che cambiano ogni giorno. Sotto quelle dimensioni la stessa pagina dice che tenere aggiornata la sitemap e controllare il rapporto di indicizzazione è sufficiente, e definisce quei numeri "una stima approssimativa", non soglie esatte.
Un sito aziendale italiano medio sta fra le 40 e le 400 pagine. Il tempo speso a ottimizzare la frequenza di scansione lì dentro è tempo tolto alle due cose che invece spostano: i link interni e il contenuto delle pagine. Vale la pena leggere questa parte solo se gestisci un ecommerce con navigazione a faccette, dove le combinazioni di filtri generano decine di migliaia di URL che nessuno ha chiesto.
Core Web Vitals: le soglie vere e quanto pesano davvero
Le soglie pubblicate da Google su web.dev sono tre: LCP entro 2,5 secondi, INP entro 200 millisecondi, CLS pari o inferiore a 0,1. Il dettaglio che cambia il modo di lavorarci è un altro: la valutazione avviene al 75° percentile dei caricamenti, separatamente per mobile e desktop. Non conta la media, conta che tre visite su quattro stiano dentro. Un sito veloce per chi ha la fibra a Milano e lento per chi naviga in 4G in autostrada viene giudicato sul secondo caso.
Sul quanto pesino, i numeri del Web Almanac 2025 aiutano a ridimensionare: a giugno 2025 il 48% dei siti aveva un giudizio complessivo buono su mobile e il 56% su desktop. Rilevazione mondiale, su tutto il dataset di HTTP Archive. Se metà del web è sotto soglia e metà del web si posiziona comunque, le Core Web Vitals non sono un interruttore. Sono un criterio di spareggio che conta quando due pagine si equivalgono sul resto, ed è esattamente così che Google le ha sempre descritte. Il capitolo pratico sta nella nostra guida al page speed, insieme alle cose che spostano l'ago davvero: immagini non compresse, font caricati da domini esterni, plugin che iniettano CSS su ogni pagina.
Sempre dal Web Almanac 2025: il 91,5% delle pagine mobile è servito in HTTPS, il 70% ha un H1, la mediana delle immagini con attributo alt si ferma al 60% e il 15% degli alt presenti è vuoto. Sono le basi, e un quarto del web non le ha ancora.
I crawler delle AI non eseguono JavaScript, e questo cambia le priorità
Lo studio condotto da Vercel insieme a MERJ sul traffico bot della propria rete, pubblicato a gennaio 2025 e riferito al mese precedente, ha misurato una cosa che vale la pena tenere a mente: nessuno dei principali crawler AI renderizza JavaScript. GPTBot, ClaudeBot, quelli di Meta e ByteDance, PerplexityBot leggono l'HTML e basta. Googlebot e Gemini invece eseguono il JavaScript.
Gli altri numeri dello stesso studio: nel mese osservato Googlebot ha effettuato 4,5 miliardi di richieste, GPTBot 569 milioni, ClaudeBot 370 milioni, AppleBot 314 milioni, PerplexityBot 24,4 milioni. E il 34,82% delle richieste di ChatGPT finiva su pagine inesistenti, contro il 34,16% di Claude. Sono misurazioni sulla rete Vercel, quindi su siti prevalentemente statunitensi e costruiti con framework JavaScript: non sono la fotografia del web italiano, ma la parte sul rendering è una proprietà del crawler, non del campione.
La conseguenza operativa è netta. Se il contenuto della tua pagina compare solo dopo che il JavaScript è stato eseguito, Google lo vede e ChatGPT no. Su un sito vetrina WordPress il problema non si pone quasi mai. Si pone sui configuratori di prodotto, sulle schede caricate in AJAX, sui siti costruiti in React senza rendering lato server. Il resto del ragionamento, comprese le cose che si fanno per essere citati nelle risposte generative, sta in GEO e negli AI Overviews.
Un dato che dice quanto poco il mercato si sia mosso: sempre dal Web Almanac 2025, solo il 4,2% dei file robots.txt su mobile nomina gptbot e il 3,4% nomina claudebot, e appena il 2,1% dei siti ha un file llms.txt. Il file llms.txt, per inciso, non è supportato da nessun motore che lo dichiari pubblicamente.
Dati strutturati: cosa fanno e cosa non fanno
I dati strutturati non sono un fattore di ranking. Servono a rendere esplicito a una macchina quello che per un umano è ovvio leggendo la pagina: che questo numero è un prezzo, che questa data è quella di un evento, che questo blocco è una domanda con la sua risposta. Il vantaggio misurabile è l'accesso ai risultati avanzati in SERP, che alzano il tasso di clic a parità di posizione.
Il vantaggio secondo, meno raccontato, riguarda i sistemi che leggono senza vedere. Un modello che deve estrarre il prezzo da una pagina prodotto lo trova nel markup con certezza e nel testo con un'inferenza. Le tipologie che coprono il 90% dei casi italiani sono cinque: Product, LocalBusiness, Article, FAQPage, BreadcrumbList. Tutto il resto è ottimizzazione di dettaglio. Come si implementano lo trovi nella guida allo schema markup.
L'ordine in cui sistemare le cose su un sito da 200 pagine
Questa è la parte che nelle guide tradotte dall'inglese manca, perché sono scritte per siti di un altro ordine di grandezza. Su un sito aziendale italiano l'ordine che segue riflette il rapporto tra quanto costa l'intervento e quanto rischi se lo salti.
| Intervento | Cosa rischi se lo salti | Quando smette di essere prioritario |
|---|---|---|
| Verificare che nessuna pagina utile sia in noindex o bloccata | Assenza totale dall'indice | Mai, si ricontrolla dopo ogni rilascio |
| Redirect 301 delle vecchie URL dopo un restyling | Perdita di tutto lo storico di posizionamento | Dopo il primo mese dalla migrazione |
| Un canonical coerente su ogni pagina | Google sceglie al posto tuo quale versione mostrare | Quando il CMS lo genera automaticamente e l'hai verificato |
| Link interni che raggiungono ogni pagina utile | Pagine "Rilevate, non indicizzate" per mesi | Mai, cresce con il sito |
| LCP sotto i 2,5 secondi sulle pagine di atterraggio | Qualche posizione nei confronti alla pari | Quando le pagine commerciali sono a posto |
| Dati strutturati sulle cinque tipologie principali | Nessun risultato avanzato in SERP | Quando Product e LocalBusiness sono validati |
| Rendering lato server | Invisibilità per i crawler AI | Se il sito è WordPress o un CMS server-side, subito |
| Analisi dei log del server, crawl budget, edge SEO | Niente, sotto le 10.000 pagine | Da subito, se non gestisci un catalogo enorme |
Le prime quattro righe si controllano in mezza giornata con Google Search Console e un crawler desktop come Screaming Frog. Le altre sono progetti. Se una sola delle prime quattro è rotta, le altre non hanno senso.
In un progetto reale, la leva non è stata tecnica
Macropix è un produttore milanese di schermi LED su misura, oltre cinquemila installazioni nel mondo. Quando il progetto è partito, nel 2020, il sito non compariva per nessuna keyword di categoria del suo settore. Il risultato che raccontiamo più spesso non è il primo posto su "ledwall", keyword da 4.400 ricerche mensili: è la riga "monitor pubblicitario", passata da posizione 88 a posizione 2. La posizione 88 è la nona pagina di Google, cioè zero traffico.
Quel salto non è arrivato da un intervento sul codice. È arrivato da una pagina scritta bene su un argomento su cui l'azienda aveva qualcosa da dire, pubblicata su un sito che era già leggibile. La parte tecnica era il prerequisito, non la leva. Il racconto completo del metodo e dei numeri sta nel caso SEO per il settore manifatturiero, e gli altri progetti su cui lavoriamo sono raccolti nella pagina progetti.
Il rovescio vale però allo stesso modo: su altri progetti abbiamo visto pagine ottime restare invisibili per mesi per un noindex dimenticato in fase di rilascio. La stessa riga di codice che non fa guadagnare niente quando è giusta fa perdere tutto quando è sbagliata. È il motivo per cui il controllo tecnico va fatto per primo e poi quasi dimenticato, non per cui va fatto sempre. Se preferisci farlo fare a qualcuno, è parte di come impostiamo un progetto SEO.
Per il resto, la SEO tecnica è una sola competenza dentro un lavoro più largo: se stai partendo da zero conviene prima capire cos'è la SEO e come si incastrano le tre aree, poi tornare qui. E se la domanda è quali segnali pesino davvero sul posizionamento, l'abbiamo affrontata nell'articolo sui fattori di ranking e in quello sull'ottimizzazione on-page.
Domande frequenti sulla SEO tecnica
La SEO tecnica è l'insieme degli interventi sull'infrastruttura e sul codice di un sito che permettono a un motore di ricerca di raggiungere una pagina, leggerla e conservarla nel proprio indice. Comprende robots.txt, canonical, redirect, architettura dei link interni, velocità di caricamento, rendering e dati strutturati. Non riguarda il testo della pagina, riguarda la sua raggiungibilità.
La SEO tecnica lavora sulle condizioni di accesso: se il crawler arriva alla pagina e la capisce. La SEO on-page lavora sul contenuto della pagina una volta che è accessibile: titolo, struttura dei titoli, corrispondenza con l'intento di ricerca, link interni contestuali. La prima è un prerequisito binario, la seconda è quella che decide la posizione tra pagine tutte accessibili.
Sì, ma con un peso modesto e come criterio di spareggio. Le soglie pubblicate da Google sono LCP entro 2,5 secondi, INP entro 200 millisecondi e CLS pari o inferiore a 0,1, valutate al 75° percentile dei caricamenti. A giugno 2025, secondo il Web Almanac di HTTP Archive, solo il 48% dei siti aveva un giudizio complessivo buono su mobile: metà del web è sotto soglia e si posiziona lo stesso.
I quattro controlli che azzerano il traffico, cioè noindex, blocchi in robots.txt, canonical e redirect, vanno rifatti dopo ogni rilascio in produzione e dopo ogni aggiornamento importante del CMS o dei plugin. Il controllo completo con un crawler desktop ha senso due volte l'anno su un sito stabile, e sempre prima e dopo una migrazione.
Per la diagnosi no: Google Search Console e un crawler desktop bastano a individuare la quasi totalità dei problemi su un sito da poche centinaia di pagine. Per la correzione dipende. Su WordPress la maggior parte degli interventi si fa dal pannello o da un plugin SEO. Su un sito custom, su un ecommerce con navigazione a faccette o quando serve il rendering lato server, senza chi tocca il codice non si va da nessuna parte.
Una cosa che nel settore si dice poco: la SEO tecnica di base oggi la fa il CMS. Quel 67% di pagine mobile con un canonical corretto non l'ha messo un consulente, l'ha messo un plugin installato una volta e mai più toccato. Il valore del lavoro tecnico si è spostato dove il plugin non arriva, cioè le migrazioni, i siti costruiti su misura, i cataloghi con migliaia di combinazioni di filtri. Se il tuo sito è un WordPress aggiornato con un plugin SEO configurato bene, è probabile che il tuo problema non sia tecnico. È una buona notizia solo a metà, perché vuol dire che tocca lavorare sulla parte difficile.
