La SEO si divide in due parti che vengono quasi sempre confuse. Una è editoriale e non ha scorciatoie: essere la risposta migliore alla domanda di chi cerca. L'altra è tecnica, ed è verificabile: il sito è leggibile e indicizzabile, oppure non lo è, e lo si può controllare con un comando.
Questo articolo riguarda la seconda, perché è quella su cui si interviene con certezza — e perché quando è rotta, nessuna quantità di contenuto la compensa.
La sequenza, e perché conta#
Che cosa fa un crawler, passo per passo. Capire questa sequenzaspiega quasi tutti gli errori di SEO tecnica. 1. SCANSIONE richiede l'URL, riceve l'HTML che il server manda 2. ANALISI estrae contenuto e link da quell'HTML 3. RESA (rendering) esegue il JavaScript — in una CODA SEPARATA, più tardi, e non per ogni pagina 4. INDICIZZAZIONE decide se e come conservare la pagina 5. POSIZIONAMENTO decide quando mostrarlaIl passaggio critico è il 3. Se il contenuto compare solo dopol'esecuzione del JavaScript, non è presente al passo 2: l'indicizzazionedipende da una seconda visita che avviene più tardi e non è garantita.È il motivo tecnico — non ideologico — per cui il contenuto che deveposizionarsi conviene servirlo già nell'HTML.Il passo 3 è quello che genera più problemi. La resa del JavaScript avviene in una coda separata, con risorse limitate, e non è garantita per ogni pagina di ogni sito. Un contenuto che esiste solo dopo l'esecuzione degli script è un contenuto la cui indicizzazione dipende da una seconda visita che potrebbe arrivare tardi, o non arrivare.
Non è un argomento contro i framework: è un argomento a favore del rendering lato server per il contenuto che deve posizionarsi, che è disponibile in tutti gli strumenti moderni. La discussione su quando serve un framework è ripresa in quando conviene un framework.
Verificare in un comando#
# La verifica che vale piu' di qualunque opinione: cosa vede# davvero un crawler? curl non esegue JavaScript, esattamente# come il passo 2 della sequenza.curl -s https://esempio.it/servizi | grep -c 'listino'0# Zero: il contenuto NON e' nell'HTML iniziale.# Confronto con quello che vede un browser (che esegue il JS):# DevTools → Elements mostra il DOM dopo il rendering.# Se i due divergono sul contenuto che deve posizionarsi,# c'e' un problema tecnico da risolvere prima di scrivere altro.# Quanto pesa l'HTML servito, e quanto ne e' testo:curl -s https://esempio.it/servizi | wc -c248310curl -s https://esempio.it/servizi | sed 's/<[^>]*>//g' | tr -s ' \n' ' ' | wc -c3820# 248 KB di markup per 3,8 KB di testo: 1,5%. Non e' un errore# di SEO, ma dice qualcosa su come e' costruita la pagina.L'equivoco su robots.txt#
# L'equivoco che produce più danni: robots.txt controlla la SCANSIONE,# non l'indicizzazione.# ✗ Questo NON esclude la pagina dai risultati.User-agent: *Disallow: /pagina-riservata# Anzi: la pagina può comparire lo stesso se qualcuno la collega, e# paradossalmente NON PUÒ ESSERNE ESCLUSA — perché il motore non è# autorizzato a leggerla, quindi non vede il noindex che c'è dentro.# ✓ Per escludere davvero una pagina: lasciarla scansionabile,# e dirlo nell'HTML o nell'intestazione HTTP.# <meta name="robots" content="noindex, follow"># X-Robots-Tag: noindex# robots.txt serve a un'altra cosa: risparmiare scansioni su URL# che non hanno valore (filtri, ordinamenti, ricerche interne),# che su siti grandi è un problema reale.Un solo URL per contenuto#
<!-- Lo stesso contenuto raggiungibile in più modi è la causa più comune di "pagine alternate" in Search Console. --> https://esempio.it/blog ← quella buona https://esempio.it/blog/ ← slash finale http://esempio.it/blog ← senza TLS https://www.esempio.it/blog ← con www https://esempio.it/blog?utm_source=… ← parametri di campagna<!-- Il canonical dichiara qual è quella buona. Ma è un SUGGERIMENTO: il motore può ignorarlo se il resto del sito dice altro. --><link rel="canonical" href="https://www.esempio.it/blog"><!-- La soluzione robusta è a monte: un redirect 301 verso la forma canonica, così esiste UN SOLO URL raggiungibile. Il canonical resta come rete di sicurezza, non come unica difesa. -->La duplicazione di URL è la causa più comune delle «pagine alternate» in Search Console. Il canonical le riunisce, ma il motore deve comunque scansionarle tutte per scoprirlo — e su un sito grande quel lavoro sprecato ha un costo reale in termini di frequenza di scansione.
// Normalizzazione degli URL lato server. Attenzione a un dettaglio// che è anche una vulnerabilità: le barre doppie.app.use((req, res, next) => { // Un Location che comincia per "//" è un URL protocol-relative: // //altro-sito.com/ manda il visitatore su un host esterno. // Vanno collassate NELLO STESSO passaggio della normalizzazione. const normalizzato = req.path .replace(/\/{2,}/g, '/') // barre doppie → una .replace(/(.)\/+$/, '$1'); // niente slash finale if (normalizzato !== req.path) { const i = req.originalUrl.indexOf('?'); const query = i === -1 ? '' : req.originalUrl.slice(i); return res.redirect(301, normalizzato + query); } next();});La sitemap#
<!-- La sitemap non "fa indicizzare": segnala cosa è cambiato. Il campo che conta è lastmod, ed è utile solo se è ATTENDIBILE. --><url> <loc>https://www.esempio.it/blog/articolo</loc> <lastmod>2026-08-23</lastmod> <priority>0.7</priority></url><!-- ✗ Un lastmod che coincide con la data di generazione della sitemap (cioè "oggi" per tutte le pagine) è rumore: dopo poche volte il motore smette di considerarlo. ✓ Deve riflettere l'ultima modifica REALE del contenuto. priority e changefreq sono largamente ignorati: non vale la pena spenderci tempo. -->La sitemap non «fa indicizzare»: comunica quali URL esistono e quando sono cambiati. L'unico campo che conta davvero è lastmod, ed è utile solo se è attendibile. Una sitemap generata ogni notte che mette la data di oggi su tutte le pagine è rumore: dopo qualche settimana quel segnale viene ignorato, e con esso si perde la possibilità di comunicare gli aggiornamenti veri.
Leggere Search Console#
Come si legge Search Console, che è la parte più utile e la meno usata.Tre diagnosi diverse a partire da tre situazioni: Pagina con ZERO impressioni → non è un problema di posizionamento: è un problema di ARGOMENTO. Nessuno cerca quella cosa, o la cerca con altre parole. Intervenire sul titolo non serve. Molte impressioni, pochi clic → il motore la mostra, le persone non la scelgono. È un problema di TITOLO e DESCRIZIONE. Pagina ESCLUSA dall'indice → problema TECNICO, e il motivo è scritto accanto: "Scansionata, attualmente non indicizzata" → contenuto ritenuto poco utile, o troppo simile ad altre pagine "Rilevata, non scansionata" → budget di scansione, o il server risponde lentamente "Pagina alternativa con tag canonical" → duplicazione: vedi sopra "Bloccata da robots.txt" → l'equivoco descritto prima L'ordine di intervento è quello: prima si risolvono le esclusioni, poi i titoli, poi si scrive altro contenuto.Questa è la parte che cambia più spesso le priorità di chi la legge per la prima volta. Il rapporto sulle pagine escluse è il più utile e il meno consultato: contiene l'elenco esplicito delle pagine che il motore ha deciso di non conservare, con il motivo accanto. Sono problemi tecnici da risolvere prima di scrivere altro contenuto, perché finché restano non c'è nulla che possa posizionarsi.
I link interni#
// La leva più sottovalutata, perché è l'unica interamente sotto il// vostro controllo: i link interni distribuiscono rilevanza fra le// pagine e comunicano di cosa parla ciascuna.// ✗ Anchor generici: non dicono niente né all'utente né al motore<a href="/blog/core-web-vitals">clicca qui</a><a href="/blog/core-web-vitals">leggi di più</a>// ✓ Anchor che descrive la destinazione<a href="/blog/core-web-vitals">cosa misurano davvero i Core Web Vitals</a>// E la struttura: ogni pagina importante dovrebbe essere raggiungibile// in POCHI passi dalla home. Una pagina a cui non punta nessun link// interno ("orfana") esiste solo nella sitemap, ed è il segnale più// forte che si possa dare al motore che quella pagina non conta.$ # Trovare le pagine orfane: quelle in sitemap che nessuna pagina collega$ diff <(curl -s https://esempio.it/sitemap.xml | grep -oP '(?<=<loc>)[^<]+' | sort) \> <(curl -s https://esempio.it/ | grep -oP 'href="\K/[^"]*' | sort -u)È la leva più sottovalutata dell'intera SEO tecnica, e l'unica su cui non dipendete da nessuno. Il testo del link comunica di cosa parla la destinazione; la struttura dei collegamenti comunica quali pagine considerate importanti. Una pagina «orfana» — presente in sitemap ma collegata da nessuna parte — sta dicendo al motore che nemmeno voi la ritenete rilevante.
L'intento di ricerca viene prima delle parole#
| Ricerca | Intento | Pagina che si posiziona |
|---|---|---|
| «come funziona un chatbot» | informazionale | guida, articolo esplicativo |
| «migliori CRM per studi legali» | commerciale | confronto, tabella, criteri |
| «sviluppatore web preventivo» | transazionale | pagina di servizio, contatti |
| «nome azienda» | navigazionale | home, pagina contatti |
| «sito web costo» | misto | guida che contiene i criteri e porta al contatto |
Il modo più rapido per capire quale intento il motore ha riconosciuto per una ricerca è guardare cosa mostra già: se in prima pagina ci sono solo guide, una pagina commerciale non entrerà, per quanto sia scritta bene. Sono pagine diverse per persone in momenti diversi.
Cosa non è sotto controllo#
Gli aggiornamenti dell'algoritmo, evidentemente. E in misura crescente le risposte generate direttamente nella pagina dei risultati, che riducono i clic anche a parità di posizione: una tendenza che vale la pena mettere in conto nelle aspettative, e che non si contrasta con espedienti tecnici.
La conclusione operativa è che vale la pena investire in ciò che resta stabile: un sito tecnicamente corretto — che è verificabile, si fa una volta e continua a valere — e contenuti che rispondono meglio degli altri. Tutto il resto è ottimizzazione di un comportamento momentaneo del motore, e scade con esso.