Corso SEO tecnico avanzato per sviluppatori e agenzie

Un corso di SEO tecnica non serve a ripassare le basi della SEO. Serve a saper mettere le mani su un sito quando il problema non è la parola chiave sbagliata, ma il modo in cui il sito si fa leggere dai crawler, risponde dal server e gestisce le proprie URL. Se sviluppi siti, se lavori in agenzia o se gestisci un e-commerce arrivato al suo tetto di traffico, è qui che si sposta la differenza tra “il sito è a posto” e “il sito si trova”.

In questa pagina trovi cosa si impara davvero in un percorso tecnico avanzato: gli argomenti, i prerequisiti, gli strumenti, la checklist che applico a ogni sito e le domande da fare a chi vende formazione. Il contesto è italiano, con Milano come base di lavoro: è la città dove seguo la maggior parte dei progetti tra sviluppo, e-commerce e servizi digitali. Se vuoi solo capire a che punto sei, parti dalla checklist operativa e usala come test di autovalutazione prima di scriverti a qualunque cosa.

Per chi è pensato questo percorso

Sviluppatori e sviluppatrici

Se scrivi codice hai già metà del vantaggio: capisci il rendering, il tempo di risposta del server, la cache, il comportamento delle chiamate asincrone. Quello che manca di solito è il punto di vista. Perché quella richiesta lenta interessa il motore di ricerca, come si misura e come si spiega a chi paga il progetto. Il percorso serve a coprire il tratto tra “funziona” e “si trova”.

Agenzie e freelance

Le agenzie perdono clienti quando il problema tecnico resta in mano a nessuno: lo sviluppatore dice che il sito funziona, il consulente dice che i numeri non salgono, il cliente paga la riunione. Avere in casa una persona che legge un log, un report di Search Console e una cascata di richieste cambia la conversazione con il cliente e il margine sul progetto.

Chi gestisce un proprio sito

E-commerce, portali di contenuti, siti aziendali con cataloghi grandi. Sono i casi in cui un intervento tecnico fatto bene vale più di dieci articoli ottimizzati a mano. Qui il prerequisito non è tecnico, è di pazienza: serve la disponibilità a leggere i dati e a toccare la configurazione, non solo i contenuti.

Cosa significa SEO tecnico oggi: sei aree di lavoro

1. Rendering e JavaScript

Google elabora il JavaScript, però lo fa con un budget di risorse e con tempi che non decidi tu. Un contenuto che esiste solo dopo tre chiamate API e un timeout può non essere visto, o esserlo in ritardo. La conseguenza pratica è una sola: ciò che deve essere indicizzato sta nell’HTML servito, non in quello costruito nel browser. Lo stesso Google definisce il dynamic rendering un workaround e non una soluzione raccomandata, quindi la strada giusta resta il rendering lato server o una generazione statica fatta bene.

2. Crawling e indicizzazione

Qui si lavora sui file di configurazione, sulle sitemap, sulla gestione dei parametri e sulle regole di esclusione. Serve saper leggere i log del server per capire quante volte un crawler arriva, su quali URL e con quale codice di risposta. Serve anche a distinguere il traffico reale dalle richieste di bot che si spacciano per Googlebot. Si parte da comandi come curl -I e da un controllo dei record DNS, poi si arriva a una mappa delle URL che il sito espone davvero. Se vuoi un punto di partenza, ho scritto una spiegazione di come Google assegna il crawl budget a un sito e una guida pratica su come far indicizzare rapidamente una pagina.

3. Core Web Vitals e prestazioni

Dal 12 marzo 2024 la metrica di reattività è INP (Interaction to Next Paint) e ha sostituito FID. Le soglie dei Core Web Vitals sono note e verificabili: LCP entro 2,5 secondi, INP entro 200 millisecondi, CLS entro 0,1, valutati sul 75° percentile delle visite reali. Questo cambia il modo di lavorare: il punteggio di Lighthouse in laboratorio non è il bersaglio. Il bersaglio sono i dati di campo, quelli che Google registra sugli utenti veri. Due metriche che si guardano meno del dovuto sono la stabilità visiva, spiegata nella guida su come ridurre il CLS e la differenza tra PageSpeed e Core Web Vitals, che genera ancora molti malintesi nei report.

4. Architettura, URL e cannibalizzazione

Un catalogo con migliaia di URL filtrate, o un blog cresciuto per stratificazioni, produce pagine che competono tra loro. Il lavoro tecnico consiste nel ridisegnare la struttura, decidere cosa indicizzare, cosa consolidare e cosa lasciare fuori. Si toccano canonical, redirect, paginazione e gestione dei parametri, con una regola fissa: ogni modifica va misurata prima e dopo. Due letture utili per prepararsi sono il metodo del content silo e il confronto tra redirect 301, 302, 307 e 308.

5. Dati strutturati e informazioni per i motori

Schema.org non fa posizionare per magia, rende esplicito ciò che la pagina contiene. Saper scegliere il tipo giusto, evitare markup che contraddice il testo visibile e mantenere i dati allineati al contenuto è una competenza da sviluppatore, non da copywriter. Se il tema ti è nuovo, parti da cosa sono gli schema.org e come sceglierli, poi passa al caso specifico dei FAQ schema.org.

6. Misurazione e dati

Senza dati non c’è diagnosi. Si usa Search Console con la sua API, il Chrome UX Report per i dati di campo, il monitoraggio delle richieste del server e, sui siti grandi, l’esportazione dei dati in un database per interrogarli come si interroga un registro di eventi. Un intervento tecnico che non produce un numero prima e un numero dopo resta un’opinione. Per partire con il piede giusto c’è la checklist su come configurare Google Search Console e il metodo per un audit gratuito con Lighthouse e Search Console. Se invece vuoi vedere come si struttura un’analisi completa, leggi come si fa un SEO audit tecnico.

Checklist operativa: 14 controlli tecnici su ogni sito

Questa è la sequenza che uso quando apro un sito per la prima volta. Non serve un tool a pagamento per i primi dieci punti, serve metodo. Se non sai rispondere a più di cinque voci, hai già il tuo programma di studio.

1. Risposta HTTP. Controllare codice di stato su un campione di URL importanti, senza catene di redirect lunghe.
2. robots.txt. Verificare che non blocchi per errore CSS, JavaScript o intere cartelle e che la sitemap sia dichiarata.
3. Sitemap. Controllare che contenga solo URL indicizzabili, con lastmod coerente e nessuna pagina orfana.
4. Canonical. Una sola URL preferita per pagina, coerente tra tag, sitemap e link interni.
5. Rendering. Confrontare HTML servito e DOM renderizzato: il contenuto chiave deve stare nel primo.
6. Titoli e heading. Un solo H1 per pagina, gerarchia coerente, nessun titolo generato dallo stampino del template.
7. Core Web Vitals di campo. Leggere LCP, INP e CLS sul 75° percentile, non il punteggio di laboratorio.
8. Tempo di risposta. Misurare il server con cache attiva e con cache disattivata, per capire dove si perde tempo.
9. Immagini e peso. Formati moderni, dimensioni dichiarate, caricamento differito che non penalizza l’LCP.
10. Dati strutturati. Validare i tipi presenti e verificare che non contraddicano il contenuto visibile.
11. Log del server. Contare le richieste dei crawler, su quali URL e con quali codici di risposta.
12. Cannibalizzazione. Cercare gruppi di URL che si contendono la stessa intenzione di ricerca.
13. Link interni. Verificare che ogni pagina importante sia raggiungibile in pochi clic dalla home.
14. Baseline. Fissare i numeri di partenza prima di toccare qualsiasi cosa, altrimenti non saprai cosa ha funzionato.

Prerequisiti: cosa devi sapere fare prima di iniziare

Un percorso avanzato ha senso solo se la base c’è. Non serve una laurea in informatica, servono competenze concrete e verificabili.

• HTML e CSS. Saper leggere una pagina e capire quale elemento produce un problema di layout o di priorità di caricamento.
• HTTP. Metodi, codici di stato, header, cache e differenza tra richiesta e risposta.
• Un linguaggio lato server. Anche a livello base, per capire cosa succede tra la richiesta del browser e la pagina generata.
• JavaScript. Saper leggere il codice asincrono, capire quando un contenuto arriva dopo il resto e perché.
• Riga di comando e Git. Servono per interrogare un server, leggere un log e lavorare senza rompere la produzione.
• SQL di base. Sui siti grandi i dati di Search Console si interrogano con una query, non con un foglio di calcolo.

Se vuoi un test rapido, prova a rispondere a queste cinque domande: qual è il codice di stato di un redirect permanente, in quale ordine vengono lette le regole di cache, dove si dichiara la sitemap, cosa misura INP, come si verifica che una richiesta arrivi davvero da Googlebot. Tre risposte corrette su cinque indicano che sei pronto per il livello avanzato. Meno di così conviene consolidare le basi, senza vergogna: è il modo più rapido per non sprecare soldi in formazione.

Come si svolge il percorso

Laboratorio su siti reali

La parte che conta non si fa sulle slide. Si lavora su siti che hanno problemi veri: un e-commerce con filtri che generano URL infinite, un sito aziendale con contenuti che esistono solo dopo una chiamata API, un blog con decine di pagine che si contendono la stessa ricerca. Ogni esercizio produce un artefatto: un report, uno snippet di configurazione, una query, una modifica verificata con i numeri.

Strumenti che si usano davvero

Durante le sessioni si usano gli strumenti del mestiere, non le demo: i pannelli di rete e performance del browser, un crawler per mappare il sito, la riga di comando per interrogare header e DNS, Search Console con la sua API per i dati di query e pagina, il report dei Core Web Vitals per i dati di campo, un database per interrogare i log. Ognuno di questi strumenti si spiega nel suo limite, perché il punto non è conoscerli ma sapere quando mentono. Sui progetti più grandi si aggiunge il monitoraggio automatico: se non hai mai visto come si imposta, questa introduzione alle pipeline CI/CD spiega la logica dei controlli ripetuti a ogni rilascio.

Milano come contesto, online per il resto d’Italia

Milano non è uno sfondo decorativo. Il comune conta 1.364.144 abitanti su 181,67 km² ed è la città dove si concentrano le sedi italiane dei gruppi digitali, gli e-commerce nazionali e i servizi finanziari. Il Politecnico, fondato il 29 novembre 1863, conta quasi 50.000 studenti, quindi la manodopera tecnica non manca e il confronto è alto. A pochi chilometri, nel distretto di MIND nato sull’area di Expo 2015, ha sede Human Technopole, l’istituto di ricerca sulle scienze della vita insediato a Palazzo Italia nel 2019. Ne esce un mercato dove i siti sono grandi, le aspettative alte e gli errori costano: cataloghi enormi, rendering complicato, requisiti di accessibilità e tracciamento. La maggior parte dei casi che porto in aula viene proprio da lì. Le sessioni si tengono anche a distanza, quindi la provenienza non è un vincolo.

Cosa sai fare alla fine

Alla fine del percorso non hai un elenco di nozioni da ripetere, hai cose che sai fare con le mani su un sito:

• Leggere un log del server e dire quante URL vengono scansionate, quali restano fuori e perché.
• Diagnosticare un problema di indicizzazione distinguendo tra blocchi di configurazione, errori di rendering e problemi di qualità.
• Misurare le prestazioni con i dati di campo e decidere su quale delle tre metriche intervenire per prime.
• Disegnare la struttura delle URL di un catalogo e decidere cosa indicizzare e cosa consolidare.
• Scrivere e validare dati strutturati coerenti con il contenuto della pagina.
• Produrre un report tecnico comprensibile per un cliente non tecnico, con i numeri prima e dopo.
• Impostare un monitoraggio che segnali i problemi quando accadono, non tre mesi dopo.

Cinque errori che vedo nei corsi di SEO tecnica

• Teoria senza siti. Lezioni piene di definizioni e nessun esercizio su un sito reale. Alla fine sai ripetere cosa sono i Core Web Vitals e non sapresti da dove iniziare su un sito che non li passa.
• Strumenti a pagamento come soluzione. Comprato il tool, trovato il problema. Peccato che il tool segnali solo ciò che sa riconoscere e che gran parte dei problemi reali nasca da scelte di architettura.
• JavaScript ignorato. Metà dei siti moderni non viene spiegata, perché è la parte scomoda: richiede di leggere codice e di parlare con chi lo scrive.
• Nessuna misurazione. Si insegna a fare modifiche e non a costruire la baseline. Senza il numero di partenza non esiste prova del risultato.
• Ricette valide per tutti. Il consiglio copiato da un caso di successo applicato a un settore diverso produce danni, come la disindicizzazione di pagine che portavano traffico.

Domande frequenti

Serve saper programmare per seguire un percorso di SEO tecnica?

Serve saper leggere il codice, non necessariamente scriverlo da zero. Se capisci HTML, come funziona una richiesta HTTP e cosa fa un blocco di JavaScript asincrono, puoi seguire il livello avanzato. Senza queste basi il rischio è imparare comandi a memoria senza capire quando usarli.

Si può imparare la SEO tecnica senza lavorare su siti reali?

Si può capire la teoria, difficilmente si diventa operativi. Le decisioni difficili nascono sempre da un vincolo concreto: un gestionale che non si può cambiare, un template bloccato, un team che non ha tempo. Per questo ogni modulo si applica a un sito vero, anche a un sito tuo o a un progetto open source da analizzare.

Quanto dura un percorso tecnico avanzato?

Dipende dalla base di partenza e dalla frequenza. Un ciclo utile si misura in settimane di lavoro distribuito, non in ore di video: servono tempo per leggere i dati, sbagliare una configurazione e vedere l’effetto. Chi arriva con esperienza di sviluppo progredisce molto più in fretta di chi parte da zero sul codice.

Meglio un corso registrato o una sessione dal vivo?

Il video registrato è utile per i concetti e per riascoltare una spiegazione. La sessione dal vivo serve per la parte che nessun video copre: guardare insieme un sito che si comporta in modo inatteso e decidere il prossimo passo. La combinazione funziona meglio di entrambi da soli.

Per un’azienda conviene formare un dipendente o assumere un consulente?

Se il sito è il canale principale di vendita e cresce nel tempo, avere una competenza interna paga: le decisioni quotidiane vengono prese senza aspettare un appuntamento. La consulenza esterna resta utile per i passaggi critici, come una migrazione o un cambio di architettura, dove serve qualcuno che abbia già visto l’errore prima.

Cosa serve per fare pratica senza un cliente?

Un sito tuo, anche piccolo, più un dominio di prova dove poter rompere le cose. Aggiungi un progetto da monitorare con i dati di campo e una raccolta di log di qualche giorno. Con questo materiale minimo puoi applicare tutta la checklist di questa pagina e vedere risultati misurabili in poche settimane.

Contattami subito!

Se vuoi capire se il percorso è adatto al tuo livello, scrivimi raccontando in due righe che tipo di siti tratti e su quale punto ti sei bloccato. Ti rispondo con una valutazione onesta, anche quando la risposta è che ti serve prima un’altra cosa.