Lingue

SEO tecnico

Una guida completa al SEO tecnico — una guida per principianti in linguaggio semplice e una guida avanzata a livello di sistemi su crawling, rendering, indicizzazione e posizionamento.

Prima pubblicazione: 25 giu 2026 · Ultimo aggiornamento: 3 ago 2026 · Advanced
Lingue
AIScritto daAI v2

Due guide in una. La guida per principianti spiega il SEO tecnico da zero — il percorso crawl → index → rank, le poche fondamenta di cui ogni sito ha bisogno, come controllare il proprio sito e quali miti ignorare. La guida avanzata scende in profondità di sistema: crawl budget, la decisione di rendering, i ~40 segnali della canonicalizzazione, il linking interno, Core Web Vitals come tre problemi separati, monitoraggio continuo, migrazioni e ricerca AI. Il filo conduttore è quello a cui torno sempre — il SEO tecnico è la parte più importante del SEO finché non lo è più. È la base che permette a contenuti e link di posizionarsi, non un trucco di ranking di per sé. Non puoi posizionare una pagina che Google non indicizza, quindi il lavoro di maggior valore è di solito il più noioso.

TL;DR — La SEO tecnica è lo stesso pipeline di scansione → rendering → indicizzazione → servizio su ogni sito — non esiste un “algoritmo SEO tecnico” separato — ed è una base, non un fattore di ranking a sé stante. Tratta il pipeline come una serie di cancelli e diagnostica quale pagina è bloccata prima di cambiare qualsiasi cosa. La leva è principalmente negativa (non perdere ciò che hai guadagnato), quindi il lavoro strutturale noioso — canonicalizzazione, redirect, link interni — paga di più, e si accumula su larga scala. La maggior parte dei siti non ha bisogno di gestire il crawl budget; il rendering è un passaggio separato che può essere in ritardo; i Core Web Vitals sono tre problemi distinti e una leva di ranking minore; la canonicalizzazione è una decisione ponderata su ~40 segnali; e dal 2025 in poi, la ricerca AI condiziona l’idoneità a segnali tecnici puliti prima di classificarti o citarti. L’abilità più alta qui è la prioritizzazione — sapere cosa ignorare.

La SEO tecnica decide l’idoneità, non la posizione

La SEO tecnica è l’unica parte della SEO il cui ritorno è quasi interamente negativo: il suo compito è evitare che tu perda posizioni, non vincerle. Google non assegna posizioni per una struttura pulita. Gli stessi sistemi di scansione, indicizzazione e ranking funzionano sia che il tuo sito sia impeccabile o un disastro — non esiste un “algoritmo SEO tecnico” separato dietro di loro. Ciò che la SEO tecnica decide effettivamente è se le tue pagine possono entrare in quei sistemi, e se il motore le comprende correttamente una volta che sono dentro.

Quindi il modello mentale giusto non è “fare SEO tecnica per posizionarsi”. È “fare SEO tecnica così che i tuoi contenuti e link siano autorizzati a posizionarsi”. Questa inversione è l’intera ragione per cui il lavoro poco appariscente — canonicalizzazione, redirect, link interni — è il lavoro di maggior valore, e per cui l’abilità singola più utile in questa disciplina è la prioritizzazione: sapere cosa sistemare e, altrettanto spesso, cosa lasciare stare.

Il pipeline, come cancelli

Tutto dipende da un unico pipeline, e la clausola operativa di Google è “non tutte le pagine superano ogni fase.” Evidence for this claim Google Search describes crawling, indexing, and serving as three stages; discovery is part of the crawling stage, and not every page advances through each stage. Scope: Google Search documentation; conceptual explanation, not a promise of ranking outcomes. Confidence: high · Verified: Google: How Search Works Non immaginare un nastro trasportatore che porta ogni pagina al traguardo. Immagina una serie di cancelli, ciascuno con il suo esito positivo/negativo:

  • Crawl — scoperta (link + sitemap + protocolli push) più il fetch. Una pagina a cui nessuno linka, o una disallow in robots.txt, potrebbe non arrivare mai.
  • Render — Google esegue il tuo JavaScript in un Chrome headless recente (il Web Rendering Service) prima di poter comprendere appieno la pagina. Questo è un passaggio separato dal fetch, è stateless e può essere in ritardo.
  • Index — il motore elabora la pagina, sceglie una canonical tra i duplicati e decide se archiviarla. “L’indicizzazione non è garantita” anche quando crawl e rendering riescono.
  • Serve — comprensione della query, poi ranking attraverso molti sistemi automatizzati, poi le funzionalità di ricerca sovrapposte.

Tieni separati nella tua testa crawl ≠ render ≠ index ≠ rank e la maggior parte della SEO tecnica smette di essere misteriosa. Quando una pagina sottoperforma, non indovini e non cambi dieci cose — trovi quale cancello ha fallito e sistemi quella fase.

Un avvertimento onesto prima di prendere qualsiasi descrizione del pipeline come vangelo, inclusa la mia: è un modello, non il codice sorgente. How Search Works è un talk che tengo alle conferenze e che attraversa l’intero pipeline (slide su SlideShare), e lo apro con un avvertimento che ripeterò qui: “questa è la mia comprensione dei sistemi… non sarà completa o accurata al 100%.” Tienilo in modo flessibile e usalo per ragionare sui problemi.

Chi fa effettivamente il crawling

“Googlebot” sembra un singolo programma. È una famiglia — desktop, mobile (quello che conta, poiché l’indicizzazione è mobile-first), image, news, video e crawler per annunci — tutti che attingono dallo stesso pool di crawl budget, motivo per cui un crawl fuori controllo di immagini o parametri può affamare il crawling dei tuoi contenuti reali.

E non sono più solo i motori di ricerca. Quando ho analizzato i dati di crawl di Cloudflare Radar (un articolo di Ahrefs che ho scritto sulla nuova ondata di bot), i crawler dei motori di ricerca hanno ancora scansionato di più, ma i bot AI erano saldamente al secondo posto e sulla buona strada per superarli. Se leggi i tuoi log, il cast di personaggi è cambiato — e gestirlo (quali crawler AI permetti e confermare che quelli che ti colpiscono sono chi dicono di essere) ora fa parte del lavoro.

Crawl budget: quando conta e quando no

Google definisce il crawl budget come “l’insieme di URL che Google può e vuole scansionare,” impostato da crawl capacity (la salute del tuo server) e crawl demand (popolarità e obsolescenza). Aumenti il budget effettivo in due modi: dare ai bot più capacità o — molto più spesso — smettere di sprecarlo. Consolida i duplicati, blocca gli spazi a basso valore, restituisci 404/410 per le pagine definitivamente rimosse, correggi i soft 404, mantieni le sitemap aggiornate con lastmod accurato ed evita lunghe catene di redirect.

La parte rassicurante, e continuerò a dirlo: la maggior parte dei siti non deve preoccuparsi del crawl budget. Google stesso ti dice che se le tue pagine vengono generalmente indicizzate lo stesso giorno in cui vengono pubblicate, “you don’t need to read this guide.” (traduzione) «non hai bisogno di leggere questa guida.» Inizia a diventare un problema intorno a 1M+ pagine, o 10k+ pagine che cambiano rapidamente. Sotto quella soglia, spendi le tue energie altrove. Evidence for this claim Google says crawl-budget guidance is mainly relevant to very large sites, including sites with over one million unique pages or over ten thousand rapidly changing pages. Scope: Google Search guidance; the page-count examples are diagnostic starting points, not hard eligibility thresholds. Confidence: high · Verified: Google: Large site crawl budget guide Fabrice Canel di Bing inquadra la stessa idea in modo più diretto: meno è meglio — meno URL da indicizzare è meglio per la SEO.

robots.txt: controllo del crawling, non controllo dell’indicizzazione

La distinzione più importante in questo intero file: robots.txt controlla il crawling, non l’indicizzazione. Disallow di un URL impedisce ai bot di recuperarlo — non lo tiene fuori dall’indice. Una pagina disallow può essere comunque indicizzata (solo URL, senza contenuto) se altre pagine vi collegano, e peggio, se disallow una pagina impedisci anche a Google di vedere mai un tag noindex su di essa.

Quindi le regole sono:

  • Vuoi che una pagina sparisca dalla ricerca? Consenti il crawling e aggiungi noindex. Non usare mai robots.txt per deindicizzare.
  • Vuoi che i bot saltino uno spazio URL di basso valore (ricerca interna, combinazioni infinite di facet) e non ti interessa l’indicizzazione? Il disallow in robots.txt è corretto.
  • Gestisci i crawler AI? È anche qui che permetti o blocchi GPTBot, ClaudeBot, PerplexityBot, CCBot e compagnia — una decisione strategica, non un default.

Canonicalizzazione: una decisione ponderata, non un comando

La canonicalizzazione è dove vive molta SEO tecnica avanzata, ed è ampiamente fraintesa. rel="canonical" è un suggerimento, non una direttiva. Google lo pesa contro molti altri segnali — redirect, link interni, inclusione nella sitemap, HTTPS, struttura URL — quando sceglie l’URL rappresentativo. Il mio approfondimento sulla canonicalizzazione stima che ci siano circa 40 segnali che alimentano la selezione canonica, motivo per cui a volte vedi “Duplicate, Google chose different canonical than user” in Search Console: il tuo tag è stato superato.

Le implicazioni pratiche:

  • Non inviare segnali contrastanti. Ho passato anni su siti enterprise (ho gestito la SEO tecnica internamente in IBM), e in un talk che tengo chiamato Enterprise SEO Chaos mostro pagine reali che “redirected to one version, canonicaled to a second, and internally linked to a third.” (traduzione) «reindirizzate a una versione, canonicalizzate a una seconda, e collegate internamente a una terza.» Scegli un URL e fai sì che ogni segnale sia d’accordo.
  • La forza del segnale è approssimativamente classificata redirect > rel="canonical" > link interni > sitemap. Un 301 è un’affermazione molto più forte di un tag canonico.
  • Il contenuto duplicato non è una penalità. Gary Illyes di Google ha detto che circa il 60% del web è contenuto duplicato, e Google tratta parte di esso come normale — non una violazione di spam. Il costo è segnali divisi e crawling sprecato, non una punizione. La soluzione è consolidamento, non panico.

E una nota su JavaScript: una volta ho eseguito un test — iniettando un rel="canonical" via JavaScript su una pagina che non ne aveva nell’HTML — e Google lo ha onorato, anche se aveva pubblicamente detto che non lo avrebbe fatto. Dopo che è emerso, Google ha aggiornato la sua documentazione SEO JavaScript. La lezione non è “usa canonical JS”; è che questa roba è testabile, e i documenti non sono sempre l’ultima parola.

La decisione sul rendering

Il rendering è il passaggio che la maggior parte delle panoramiche salta, ed è dove i siti JavaScript finiscono nei guai. “During the crawl, Google renders the page and runs any JavaScript it finds using a recent version of Chrome.” (traduzione) «Durante il crawl, Google renderizza la pagina ed esegue qualsiasi JavaScript trovi usando una versione recente di Chrome.» Evidence for this claim Google processes JavaScript pages in crawling, rendering, and indexing phases and uses a recent version of Chrome for rendering. Scope: Google Search JavaScript processing; rendering and indexing remain subject to technical and quality constraints. Confidence: high · Verified: Google: JavaScript SEO basics È un servizio separato, senza stato, può memorizzare nella cache risorse per settimane, e può essere in ritardo rispetto al fetch iniziale — quindi una modifica dipendente da JavaScript può richiedere del tempo per essere riflessa.

JavaScript non è il nemico qui. Come ho scritto nella mia guida alla SEO per JavaScript, JavaScript non è dannoso per la SEO, né è malvagio — è solo diverso da ciò a cui molti SEO sono abituati. La vera decisione è come renderizzi:

  • Server-side rendering (SSR) — la scelta più sicura per la SEO; l’HTML arriva completo.
  • Generazione statica (SSG/pre-rendering) — il meglio di entrambi i mondi per contenuti che non cambiano per richiesta.
  • Client-side rendering (CSR) — il rischio più alto; il contenuto esiste solo dopo l’esecuzione di JavaScript, quindi scommetti sul passaggio di rendering.
  • Rendering dinamico — Google lo definisce un workaround, non una raccomandazione; Bing è più favorevole. Trattalo come un ponte, non come una destinazione.

Due trappole da conoscere a memoria. Primo, lazy-loading: Googlebot non scorre né clicca, quindi i contenuti che si caricano solo su interazione possono rimanere invisibili — assicurati che si carichino quando sono nel viewport. Secondo, link: Google può seguire solo un link che è un vero elemento <a href>. Un routerLink o un gestore di clic senza href non è un link crawlabile. Verifica l’output renderizzato rispetto all’HTML grezzo con lo strumento URL Inspection ogni volta che sospetti una discrepanza.

I link interni svolgono tre compiti contemporaneamente: aiutano i bot a scoprire le pagine, distribuiscono il PageRank e trasmettono contesto tematico tramite l’ancoraggio. John Mueller ha definito i link interni “super critical for SEO” e una delle leve più grandi che hai sul tuo sito — e sono d’accordo. È una delle cose con il ROI più alto che controlli direttamente.

Alcuni punti a livello di sistema:

  • Pagine orfane — pagine a cui nessun link punta — sono la prima cosa da cercare. Se non è linkata, è appena scopribile e riceve quasi nessuna equity.
  • L’architettura è gestione del funnel di crawl. Le pagine importanti stanno vicino alla home page; le pagine profonde, lontane dai clic, vengono crawlate meno e si posizionano peggio.
  • La scultura del PageRank con nofollow è morta (dal 2009). Mettere nofollow sui link interni fa evaporare quell’equity invece di redistribuirla. Gestisci il flusso con una vera architettura, non con trucchi nofollow.

Core Web Vitals: tre problemi, non uno

L’errore più grande dei professionisti con l’esperienza di pagina è trattarla come un unico problema “rendi il sito più veloce”. I Core Web Vitals sono tre problemi distinti con cause diverse e soluzioni diverse:

  • LCP (Largest Contentful Paint) — caricamento. Guidato dal tempo di risposta del server, dalle risorse che bloccano il rendering e dalla velocità con cui si carica l’asset di contenuto principale. Obiettivo sotto i 2,5 secondi.
  • INP (Interaction to Next Paint) — interattività. Guidato dall’esecuzione di JavaScript che blocca il thread principale. Obiettivo sotto i 200 millisecondi. (INP ha sostituito FID nel 2024 — se vedi ancora FID da qualche parte, il consiglio è obsoleto.)
  • CLS (Cumulative Layout Shift) — stabilità visiva. Guidato da immagini senza dimensioni, font che si caricano tardi e contenuti iniettati. Obiettivo sotto 0,1.

Due cose contano oltre alle definizioni. Dati sul campo, non dati di laboratorio: Google si posiziona sui dati CrUX reali, non sul tuo punteggio Lighthouse, quindi un Lighthouse 65 con buoni dati sul campo batte un Lighthouse 100 con dati sul campo scadenti. E proporzione: sarò onesto — non penso che i Core Web Vitals abbiano molto impatto sulla SEO, e a meno che un sito non sia estremamente lento, generalmente non darò priorità alla loro correzione per il posizionamento. Fai il lavoro per gli utenti e le conversioni; semplicemente non venderlo come una leva di ranking.

Dati strutturati: segnali per la ricerca e l’IA

I dati strutturati (usa JSON-LD) non ti fanno rankare, ma rendono le pagine idonee per i rich results e aiutano sempre più i sistemi AI a interpretare i tuoi contenuti per le citazioni. Sono davvero utili — e davvero sopravvalutati come segnale di ranking. La mia visione onesta: la maggior parte della SEO consiste nel fare bene le basi, e contenuti e link muovono l’ago della bilancia più dello schema. Implementali dove sbloccano un rich result o chiariscono un’entità; non aspettarti che alzino il ranking da soli. (E nota: gli URL del markup schema non sono link interni crawlabili — Mueller lo ha confermato.)

Internazionale, in breve

Se servi più lingue o regioni, usa URL distinti per versione e annotazioni hreflang per mapparli, e preferisci ccTLD o sottodirectory ai parametri URL. Non fare redirect automatici in base all’IP — Google lo sconsiglia esplicitamente e rompe la scansione. La SEO internazionale è abbastanza profonda da essere un pilastro a sé; questa è solo la stretta di mano tecnica.

La SEO tecnica è un sistema continuo, non un audit una tantum

La cornice che tutte le guide dei concorrenti sbagliano: la SEO tecnica non è una checklist che completi una volta. I siti cambiano costantemente — i deploy rompono i canonical, una release infila un noindex in un template, un nuovo script pubblicitario affossa l’INP, le catene di redirect si accumulano. La pratica matura è monitoraggio e rilevamento delle regressioni:

  • Controlla l’indicizzazione delle pagine in GSC per cambiamenti improvvisi nei conteggi indicizzati e negli stati esclusi.
  • Controlla le statistiche di scansione e i tuoi log per picchi di codici di risposta e cambiamenti nei pattern di scansione.
  • Rivalida scansione, rendering e redirect dopo ogni deploy significativo.

Sui file di log in particolare: li trattavo come uno strumento di risoluzione problemi ogni pochi anni. Questo è cambiato. I log sono ora il posto più chiaro per vedere quali crawler AI ti stanno realmente colpendo e con quale frequenza — qualcosa che nessun altro strumento ti mostra in modo così diretto — quindi per chiunque si interessi alla ricerca AI, sono diventati molto più utili di prima.

Migrazioni di sito: l’evento a più alto rischio

Una migrazione — nuovo dominio, HTTP a HTTPS, replatform, ristrutturazione URL — è l’evento tecnico singolo a più alto rischio, perché tocca ogni URL contemporaneamente. Mappa vecchio a nuovo 1:1, usa redirect permanenti 301/308, mantienili in posizione indefinitamente (non mi affretterei a rimuoverli — un paio di hop di redirect non è nulla di cui preoccuparsi), e usa lo strumento Cambio di indirizzo di GSC dove applicabile. Le migrazioni possono essere complesse e coinvolgere molte persone, ma niente panico — puoi sistemare quasi tutto ciò che va storto. C’è un intero cluster Site Migrations sotto questo pilastro.

SEO tecnica per la ricerca AI

Il cambiamento moderno, e va contro la pigra tesi “la SEO tecnica è morta”: dal 2025 in poi, i sistemi di ricerca AI decidono l’idoneità prima ancora di rankare o citare. Per essere citato in una risposta AI, la tua pagina deve generalmente essere canonizzata in modo pulito, abbastanza veloce, renderizzabile senza acrobazie, e strutturata abbastanza da essere interpretata con sicurezza. Segnali disordinati non solo abbassano un ranking ora — possono rimuoverti completamente dalla risposta. Poiché l’indice di Bing alimenta molte risposte LLM, Bing Webmaster Tools e IndexNow contano più di quanto suggerisca la quota di ricerca di Bing. L’igiene tecnica conta di più nell’era AI, non di meno.

Dove si trova realmente la leva

Se prendi una sola cosa da questa guida, che sia la priorità. Dedica il tuo tempo a indicizzazione, canonicalizzazione, link interni e migrazioni pulite — il lavoro che decide se le pagine esistono nella ricerca e consolidano la loro equità. Non perdere il sonno per il crawl budget, i Core Web Vitals, i contenuti duplicati o le catene di redirect brevi, a meno che tu non abbia un problema specifico e diagnosticato. E non inseguire la perfezione — dubito che esista un sito importante tecnicamente perfetto, e se esistesse, mi preoccuperei che stiano sprecando risorse in cose che non contano invece di quelle che contano.

Questo hub mappa il resto del pilastro: Come funziona la Ricerca, Migrazioni di siti, On-Page, Strumenti per i motori di ricerca e SEO JavaScript. Inizia da dove il tuo sito si sta rompendo: la pipeline ti dice a quale gate guardare per primo.

Add an expert note

Pin an expert quote

New person? Create their unclaimed profile at /admin/experts/ → Pin a quote first.