SEO tecnica: cos'è e quali problemi possono impedire a Google di leggere bene il sito

Cos'è la SEO tecnica

Con SEO tecnica si intende l'insieme delle condizioni che permettono a un motore di ricerca di raggiungere le pagine di un sito, leggerne il contenuto e archiviarle correttamente. Riguarda il modo in cui il sito è costruito e servito: come risponde il server, come sono organizzate le URL, cosa dice il codice, quali istruzioni riceve il crawler.

Non si occupa di quanto un contenuto sia utile, né di quanto sia autorevole il sito. Sono due piani diversi. Un sito tecnicamente impeccabile con contenuti mediocri non si posiziona; un sito con contenuti eccellenti ma inaccessibili non parte proprio. La SEO tecnica serve a togliere di mezzo il secondo caso, in modo che le altre due leve — contenuti on page e autorevolezza esterna — possano funzionare.

Una precisazione utile fin da subito: «SEO tecnica» non significa «cose difficili che deve fare uno sviluppatore». Molti dei problemi più gravi che si trovano nei siti reali sono banali — una spunta lasciata attiva in WordPress, una riga in un file di testo, un plugin configurato al volo — e vengono scoperti tardi solo perché nessuno li ha mai controllati.

Come Google scopre e legge una pagina

Prima di parlare di problemi conviene avere chiaro il percorso. Sono cinque fasi distinte, e confonderle è la fonte di quasi tutti i malintesi sulla SEO tecnica.

Due conseguenze da tenere a mente per tutto il resto dell'articolo.

La prima: indicizzato non vuol dire posizionato. Una pagina può essere archiviata regolarmente e non comparire mai tra i risultati utili, semplicemente perché altre rispondono meglio.

La seconda: scansionato non vuol dire indicizzato. Google scansiona molto più di quanto archivia, e la decisione di non archiviare una pagina è spesso una scelta di merito, non il sintomo di un errore tecnico.

I problemi che possono davvero bloccare Google

Questi sono i casi in cui esiste un ostacolo reale. Sono meno numerosi di quanto suggeriscano i report automatici, ma quando ci sono pesano molto.

Un noindex rimasto dove non doveva

È il classico incidente da messa online. Il sito viene sviluppato su un ambiente di staging con l'indicizzazione disattivata, poi va in produzione e la spunta resta attiva. Oppure un plugin applica noindex a un intero archivio «per pulizia» e ci finisce dentro anche la pagina servizi.

Il meta robots noindex è una direttiva che Google rispetta: se la vede, la pagina esce dall'indice o non ci entra. Vale la pena controllarlo periodicamente sulle pagine che contano davvero, perché è un errore silenzioso — il sito funziona benissimo per gli utenti mentre sparisce dai risultati.

Attenzione a una combinazione che si vede spesso e che non funziona: mettere noindex su una pagina e bloccarla in robots.txt. Se il crawler non può scaricare la pagina, non può nemmeno leggere il noindex, quindi la direttiva resta inapplicata. Le due cose vanno usate una alla volta.

Un robots.txt scritto con la mano troppo pesante

Una singola riga può escludere un'intera sezione del sito. Un esempio realistico: un e-commerce che vuole tenere fuori dalla scansione le pagine di filtro (/collezioni/?colore=) inserisce Disallow: /collezioni/ e blocca insieme ai filtri anche tutte le categorie di prodotto, cioè le pagine più importanti del catalogo.

Da chiarire: robots.txt governa la scansione, non l'indicizzazione. Se una URL bloccata è comunque conosciuta perché altri siti la linkano, Google può decidere di mostrarla ugualmente tra i risultati, senza descrizione e senza contenuto letto, perché non ha potuto aprirla. Per tenere una pagina fuori dai risultati serve noindex — o una protezione a monte, se il contenuto è riservato.

Errori di server e risposte lente

Un 5xx isolato normalmente non produce conseguenze durature: può far rallentare temporaneamente la scansione, ma se il server torna a rispondere correttamente la situazione si ristabilisce. Diverso è il caso degli errori ripetuti: quando il server sbaglia in modo sistematico Google riduce la frequenza di scansione per non peggiorare la situazione, e se la condizione persiste a lungo le pagine coinvolte possono infine uscire dall'indice.

Stesso discorso, in versione più sfumata, per i tempi di risposta. Non parliamo di velocità percepita dall'utente ma di quanto ci mette il server a consegnare l'HTML: se ogni richiesta richiede diversi secondi, il crawler ne fa meno a parità di tempo, e su un sito grande questo si traduce in aggiornamenti più lenti.

Canonical che punta alla pagina sbagliata

Il rel="canonical" serve a dire quale URL considerare principale quando lo stesso contenuto è raggiungibile da più indirizzi. È un suggerimento forte, non un ordine: Google può scegliere una canonica diversa da quella dichiarata se altri segnali (link interni, sitemap, redirect) raccontano un'altra storia.

Il problema nasce quando il suggerimento è sbagliato per errore. Capita con i template: tutte le pagine di una sezione ereditano il canonical della home, oppure ogni scheda prodotto punta alla categoria. Il risultato è che pagine legittime chiedono a Google di ignorarle in favore di un'altra, e Google spesso le accontenta.

Pagine che nessun link raggiunge

Se una pagina non è collegata da nessun'altra pagina del sito, esiste per chi ne conosce l'indirizzo ma non per chi naviga — e per Google è molto meno probabile che venga scoperta e considerata rilevante. Il caso tipico: schede prodotto raggiungibili solo dalla ricerca interna, o vecchie landing page rimaste online dopo un restyling del menu.

Inserire quelle URL in sitemap aiuta la scoperta, ma non sostituisce i link interni: la struttura dei collegamenti è anche il modo in cui il sito comunica quali pagine considera importanti.

JavaScript che nasconde contenuti o link

Google esegue JavaScript. Non è vero che «il JS è nemico della SEO». È vero però che il rendering è un passaggio in più, e che alcune implementazioni lo rendono fragile.

I casi problematici ricorrenti:

• il contenuto principale compare solo dopo un'interazione dell'utente (clic su un tab, scroll, apertura di un accordion caricato via fetch): il crawler non interagisce, quindi quel contenuto per lui non c'è;
• la navigazione è costruita con elementi cliccabili che non sono link (<div onclick=...>): senza <a href> non c'è un percorso da seguire;
• gli script che generano il contenuto sono ospitati in una cartella bloccata da robots.txt, quindi il rendering produce una pagina vuota;
• lo script fallisce per un errore, un timeout di un'API o una dipendenza esterna non disponibile, e il risultato è una pagina senza testo.

Il modo più rapido per togliersi il dubbio è guardare l'HTML renderizzato con lo strumento di controllo URL di Search Console: se il testo e i link ci sono, il rendering sta funzionando.

Redirect mal configurati

Un redirect 301 fatto bene è un'operazione ordinaria e non comporta di per sé una perdita di valore: Google ha ripetuto più volte che i redirect non «consumano» autorevolezza. I problemi arrivano dalle configurazioni sbagliate:

• loop di redirect, in cui A rimanda a B e B rimanda ad A: la pagina diventa irraggiungibile per chiunque;
• redirect di massa verso la home dopo una migrazione, al posto di reindirizzamenti verso le pagine corrispondenti: Google tende a trattarli come pagine non trovate;
• catene lunghe (A → B → C → D), che funzionano ma aggiungono latenza per l'utente e passaggi inutili per il crawler.

Contenuti che spariscono nella versione mobile

Google valuta e indicizza i siti basandosi principalmente sulla versione mobile delle pagine. Il criterio che conta, quindi, è cosa viene effettivamente servito su mobile.

Qui serve una distinzione che salta spesso, e che fa la differenza fra un falso allarme e un problema reale. Un contenuto presente nella pagina mobile ma inizialmente chiuso — dentro un accordion, sotto un tab, in un blocco espandibile — non è di per sé un problema: se il testo c'è nel documento renderizzato, viene considerato normalmente. Un contenuto assente dalla versione mobile, o caricato soltanto dopo un'azione dell'utente che il crawler non compie, è un'altra cosa: quel contenuto, semplicemente, non entra a far parte di ciò che Google vede.

Il malinteso frequente è pensare che un tema responsive metta al riparo. Un sito può adattarsi perfettamente allo schermo e allo stesso tempo, nel layout mobile, rimuovere blocchi di testo per «alleggerire», ridurre il menu tagliando link interni, o servire solo su desktop una sezione con i dati strutturati. In quei casi la differenza non è estetica: le due versioni non contengono le stesse informazioni.

La verifica non è «il sito si vede bene sul telefono», ma "la versione mobile contiene gli stessi contenuti e gli stessi link di quella desktop". Il modo più diretto per controllarlo è confrontare l'HTML renderizzato delle due versioni sulle pagine che contano.

Problemi che non bloccano Google, ma rendono il sito inefficiente

Qui cambia la categoria. Nessuna di queste cose è un blocco diretto come un noindex o un server che non risponde, e nessuna giustifica da sola un calo di traffico. Quando però diventano estese, possono complicare la scansione, confondere la scelta della URL canonica e riflettersi sull'indicizzazione di singole pagine. È la differenza fra tre URL sparse e un pattern che riguarda mezzo catalogo: vale la pena intervenire nel secondo caso.

Catene di redirect. Vanno accorciate quando sono strutturali — per esempio tutti i link interni che passano da http:// a https:// a https://www — non quando ne trovi qualcuna sparsa.

Contenuti duplicati. Duplicato non significa penalizzato. Google sceglie una versione da mostrare e ignora le altre. Diventa un problema quando la versione scelta non è quella che volevi tu, o quando la duplicazione è così ampia da diluire tutto il catalogo.

Parametri URL. Filtri, ordinamenti e tracciamenti generano combinazioni potenzialmente infinite dello stesso contenuto. Su un e-commerce con navigazione a faccette la moltiplicazione può diventare seria e vale la pena governarla, con canonical coerenti e — se serve — bloccando in scansione i pattern che non hanno alcun valore di ricerca. Su un sito vetrina di venti pagine è un non problema.

Sitemap sporche. Una sitemap che contiene URL in redirect, pagine 404 o versioni non canoniche non causa penalizzazioni, ma manda segnali contraddittori e rende il report della sitemap in Search Console inutilizzabile come strumento diagnostico. Il valore di una sitemap pulita è soprattutto questo: poterla usare per capire cosa succede.

404 interni. Un 404 è una risposta corretta per una pagina che non esiste più. Non danneggia il resto del sito. I 404 che meritano attenzione sono quelli raggiunti da link interni — perché sono un problema di navigazione per gli utenti — e quelli su URL che ricevono link esterni, dove un redirect verso la pagina più simile recupera qualcosa.

HTTPS e versione unica del sito. HTTPS è uno standard di base: il sito deve rispondere correttamente in https, e le varianti alternative — http, con e senza www — devono convergere su una sola versione tramite redirect coerenti e canonical allineati. Il motivo per cui va fatto è la sicurezza e il corretto funzionamento tecnico, non il posizionamento: passare a HTTPS o unificare le varianti non produce di per sé miglioramenti apprezzabili nel ranking. Il danno, semmai, arriva dal caso opposto, quando lo stesso contenuto resta raggiungibile su più versioni senza che nessuna sia indicata come principale.

Architettura dispersiva. Non è una regola meccanica sul numero di clic dalla home. È una questione di coerenza: se le pagine importanti sono sepolte in fondo a percorsi che nessuno segue, sono deboli sia per gli utenti sia per i motori.

Sitemap XML e robots.txt: cosa fanno davvero

Sono i due file di cui si parla di più e su cui circolano le convinzioni più imprecise.

La sitemap XML è un elenco di URL che segnali a Google. Aiuta la scoperta, soprattutto su siti grandi, su siti nuovi con pochi link in ingresso e su pagine poco collegate internamente. Non garantisce l'indicizzazione: inserire una URL in sitemap non obbliga Google ad archiviarla, e Google può indicizzare benissimo pagine che in sitemap non ci sono mai state. Su un sito piccolo, ben collegato al suo interno, il beneficio è modesto — ma il costo è zero e il report associato in Search Console è comodo.

Il robots.txt dice ai crawler cosa possono richiedere. Serve a evitare che vengano scansionate aree senza valore di ricerca: risultati della ricerca interna, carrelli, aree riservate, endpoint tecnici. Non è uno strumento di riservatezza — il file è pubblico e leggibile da chiunque — e non è uno strumento di deindicizzazione.

JavaScript e rendering: quando diventa davvero un problema

Un sito costruito con React, Vue o simili può posizionarsi senza difficoltà. La domanda giusta non è «usiamo JavaScript?» ma "il contenuto e i link esistono nella pagina renderizzata, senza che serva un'azione dell'utente?".

Se la risposta è sì, non c'è nulla da sistemare. Se è no, le strade sono due: spostare i contenuti critici nell'HTML iniziale (server-side rendering, generazione statica, prerendering) oppure assicurarsi che il rendering lato client sia completo e affidabile.

Un dettaglio che sfugge spesso: il rendering è un lavoro in più per il crawler, e viene distribuito nel tempo. Su siti che pubblicano molto e cambiano spesso, questo può tradursi in aggiornamenti dell'indice meno immediati rispetto a un sito servito già in HTML. Non è un difetto grave, ma è una variabile da conoscere quando si sceglie l'architettura.

Velocità e Core Web Vitals: quanto contano davvero

Le Core Web Vitals sono tre metriche che misurano l'esperienza reale degli utenti: LCP per la velocità di caricamento del contenuto principale, INP per la reattività alle interazioni, CLS per la stabilità visiva del layout. Le soglie considerate buone sono LCP sotto 2,5 secondi, INP sotto 200 millisecondi e CLS sotto 0,1, valutate al 75° percentile dei dati raccolti sugli utenti reali. INP ha sostituito First Input Delay nel marzo 2024: qualsiasi guida che parli ancora di FID è superata.

Il punto da mettere in prospettiva è il peso. Le Core Web Vitals fanno parte dei segnali di page experience, non sono la leva che decide il posizionamento: una pagina lenta ma molto più pertinente continuerà a battere una pagina velocissima e generica. Trattarle come la spiegazione di un calo organico è quasi sempre un errore di attribuzione.

Detto questo, la velocità ha un effetto molto concreto su ciò che succede dopo il clic — quante persone restano, quante compilano un modulo, quante completano un acquisto. Vale la pena lavorarci per quello, senza bisogno di raccontarsela in termini di ranking.

E i dati strutturati?

I dati strutturati sono un modo per descrivere in modo esplicito alcuni elementi di una pagina — un prodotto e il suo prezzo, una ricetta, una recensione, un evento — così che Google non debba dedurli dal testo. Aiutano la comprensione di quegli elementi specifici e possono rendere la pagina idonea a comparire in determinati risultati avanzati.

Due precisazioni, perché su questo punto si costruiscono spesso aspettative sbagliate. La prima: non aumentano direttamente il posizionamento; una pagina non sale perché ha il markup. La seconda: l'idoneità non è una garanzia, Google decide caso per caso se mostrare il risultato avanzato e può non farlo affatto.

Vale anche la pena chiarire che i dati strutturati non c'entrano nulla con i problemi visti finora: non aiutano Google a scoprire una pagina, non sbloccano una scansione impedita e non fanno indicizzare ciò che è escluso da un noindex. Sono un livello successivo, che ha senso quando le fondamenta funzionano.

Come capire se Google riesce davvero a leggere il sito

L'ordine con cui si guardano le cose conta, perché parte degli strumenti disponibili risponde a domande diverse.

1. Search Console, rapporto Indicizzazione delle pagine. È il punto di partenza. Mostra quante pagine sono indicizzate e, tra quelle non indicizzate, il motivo rilevato: bloccata da robots.txt, esclusa da tag noindex, pagina alternativa con tag canonical appropriato, rilevata ma non indicizzata, scansionata ma non indicizzata, e così via.

Due voci meritano una nota, perché generano più ansia di quanta ne meritino. «Rilevata – attualmente non indicizzata» significa che Google conosce l'URL ma non l'ha ancora scansionata. «Scansionata – attualmente non indicizzata» significa che l'ha letta e per ora ha scelto di non archiviarla. In entrambi i casi la voce descrive uno stato, non una causa: possono dipendere da priorità di scansione, da contenuti giudicati poco distintivi, dal fatto che il sito è nuovo. Non sono la prova che esista un errore tecnico da correggere.

2. Controllo URL. Su una singola pagina dice se è indicizzata, quale canonica ha scelto Google, quando l'ha scansionata l'ultima volta. Il test in tempo reale mostra l'HTML renderizzato e le risorse non caricate: è lo strumento più diretto per verificare i dubbi sul JavaScript.

3. Rapporto Sitemap. Utile per controllare che il file venga letto e che il numero di URL dichiarate corrisponda a quello che ti aspetti.

4. Statistiche di scansione. Serve su siti grandi: mostra l'andamento delle richieste, i tempi medi di risposta e i codici di stato incontrati. È il posto dove si vedono i problemi di server prima che diventino visibili altrove.

5. Un crawler (Screaming Frog, Sitebulb o equivalenti). Simula il comportamento di un bot e restituisce una mappa completa di status code, canonical, meta robots, link interni. È utilissimo per l'inventario, ma non è una fonte primaria: dice cosa vede lui, non cosa ha deciso Google. Le due cose vanno sempre incrociate.

6. I log del server. Il livello successivo: mostrano le richieste realmente effettuate dai crawler. Ha senso su progetti grandi o su diagnosi complesse, non su un sito di trenta pagine.

Problema tecnico o problema di contenuto?

Questa è la distinzione che fa risparmiare più tempo e più budget.

Se la pagina non è indicizzata, la prima verifica è tecnica: Google può raggiungerla? Può leggerla? C'è una direttiva che la esclude? Sono domande a cui gli strumenti visti sopra rispondono in modo piuttosto netto. Se la risposta è che nulla la ostacola, l'assenza dall'indice ha altre spiegazioni possibili — la pagina è considerata un duplicato e Google ha scelto un'altra URL come canonica, il contenuto è giudicato poco distintivo, la scansione non l'ha ancora messa in priorità. Non tutto ciò che tiene una pagina fuori dall'indice è un errore da correggere.

Se la pagina è indicizzata, possiamo escludere che ci sia un blocco totale. Non possiamo però concluderne che sul piano tecnico sia tutto a posto: una pagina in indice può avere un rendering solo parziale, ricevere pochissimi link interni, venire riscansionata di rado, avere una versione mobile più povera di quella desktop o un'esperienza d'uso debole. Sono problemi che non impediscono l'archiviazione ma possono limitare quanto quella pagina rende.

Quando invece la pagina è indicizzata ed è tecnicamente in ordine — contenuto completo nel rendering, link interni presenti, mobile allineato — e continua a non ricevere visite, allora è molto probabile che la questione sia altrove: intento non centrato, concorrenza più forte, contenuto sottile rispetto a quello che occupa già la prima pagina, sito troppo giovane o poco citato per competere su quella query. Nessuna ottimizzazione tecnica risolve questi casi.

Un esempio realistico: uno studio professionale pubblica dieci pagine di servizio, tutte indicizzate regolarmente, con contenuto completo anche su mobile e raggiungibili dal menu. L'audit tecnico non troverà granché, perché non c'è granché da trovare. La domanda giusta riguarda cosa dicono quelle pagine, per quali ricerche sono pensate e perché qualcuno dovrebbe sceglierle rispetto ai risultati già presenti — un tema che tocchiamo anche in perché un sito non genera contatti.

Vale anche il contrario. Riscrivere per la terza volta un testo che Google non riesce a leggere non produrrà mai risultati, e capita più spesso di quanto sembri.

Quando serve davvero un audit SEO tecnico

Un audit completo non è un adempimento periodico. Ha senso in situazioni precise:

• prima e dopo una migrazione — cambio dominio, ristrutturazione delle URL, nuova piattaforma: è il momento in cui si concentra la maggior parte dei danni tecnici reali;
• quando il numero di pagine indicizzate cambia bruscamente, in aumento o in diminuzione;
• su e-commerce e siti con molte URL generate automaticamente, dove filtri e parametri creano volumi difficili da governare a occhio;
• su siti costruiti interamente lato client, per verificare che il rendering funzioni davvero;
• quando le pagine nuove non entrano in indice dopo settimane, pur essendo linkate e presenti in sitemap;
• dopo un cambio di infrastruttura o di hosting, quando compaiono errori di server o rallentamenti.

Fuori da questi scenari, su un sito di poche decine di pagine che risponde bene e viene indicizzato regolarmente, un audit tecnico approfondito rischia di produrre un elenco di micro-segnalazioni irrilevanti. Meglio spendere quel tempo sui contenuti.

Conclusione

La SEO tecnica non fa posizionare un sito. Fa in modo che il sito possa essere valutato — che è una condizione necessaria, non sufficiente, e va tenuta al suo posto in entrambe le direzioni: né trascurata, né usata come spiegazione universale per ogni risultato deludente.

Nella pratica, la parte tecnica che conta davvero si riduce a poche domande. Google trova le pagine? Riesce ad aprirle? Vede il contenuto? Ha ricevuto istruzioni che le escludono? Quando le risposte sono in ordine, il lavoro si sposta dove deve stare: su cosa dicono quelle pagine e su quanto sono credibili rispetto a chi occupa già le prime posizioni.

Continua la lettura

SEO

SEO On Page: cos’è e come ottimizzare una pagina per Google

SEO

SEO Off Page: cos’è e perché è importante

SEO

Perché il tuo sito non genera contatti (e come risolvere)