La SEO tecnica riguarda il funzionamento e la struttura del sito che permettono ai motori di ricerca di raggiungere le pagine, elaborarne i contenuti e valutarle per l’indicizzazione. Comprende controlli su accessibilità, risposte del server, impostazioni di scansione, versioni degli URL e prestazioni.
Per un professionista o una piccola attività, conoscere questi aspetti serve soprattutto a riconoscere i problemi e a formulare richieste precise a chi gestisce il sito. Una pagina esclusa per errore richiede un intervento diverso da una pagina indicizzata che non risponde bene alle ricerche dei potenziali clienti.
Vediamo quali verifiche fare, come leggere le principali segnalazioni e come stabilire un ordine di lavoro.
Che cosa comprende la SEO tecnica
Il lavoro tecnico si collega ai contenuti, ma affronta domande specifiche: il server restituisce la pagina? Il motore può leggerla? Le impostazioni consentono l’indicizzazione? Quando esistono più versioni, qual è quella principale?
Una verifica può riguardare tutto il sito oppure partire da un problema circoscritto, come una pagina di servizio scomparsa dopo un aggiornamento. L’obiettivo è capire il comportamento effettivo e confrontarlo con quello desiderato.
Per il quadro generale trovi la guida all’ottimizzazione SEO. Se invece devi rivedere testi, titoli e organizzazione dei paragrafi, puoi approfondire la SEO on-page.
Da dove iniziare un controllo tecnico
Prepara un elenco delle pagine importanti: homepage, servizi, prodotti o categorie principali e alcuni articoli rappresentativi. Se il problema è comparso dopo una modifica, annota anche la data e ciò che è stato cambiato.
Per ciascun URL scrivi che cosa ti aspetti. Una pagina di servizio pubblica può dover comparire su Google; una conferma di invio del modulo può essere esclusa intenzionalmente. Il numero totale delle pagine non indicizzate, da solo, non misura la gravità della situazione.
Inizia quindi dalle segnalazioni sulle risorse che dovrebbero essere accessibili e dai problemi che coinvolgono più pagine. Conserva URL, messaggio rilevato e data del controllo: sono informazioni utili per chi deve indagare.
Search Console: controllare una pagina specifica
Lo strumento Controllo URL permette di esaminare le informazioni sulla versione indicizzata e di eseguire un test sulla pagina pubblicata. Sono verifiche diverse: il dato conservato nell’indice può riferirsi a una scansione precedente, mentre il test pubblicato controlla la situazione attuale nei limiti dello strumento.
Confronta stato, data della scansione e indicazioni sulle versioni canoniche. Un test positivo non garantisce che Google indicizzi la pagina o la mostri per una determinata ricerca.
Se una pagina risulta esclusa, leggi il motivo prima di intervenire. Potrebbe esserci un noindex voluto, una versione duplicata o una pagina che Google ha rilevato senza includerla nell’indice. Quest’ultima situazione non dimostra automaticamente un errore del server.
Dopo una correzione puoi utilizzare le funzioni pertinenti di richiesta o convalida, senza aspettarti un aggiornamento immediato dei report.
Robots.txt e noindex: due funzioni diverse
Il file robots.txt indica ai crawler quali URL possono scansionare. Non è un sistema per proteggere informazioni riservate e non garantisce l’esclusione di una pagina dai risultati.
Il noindex comunica invece che una risorsa non deve essere indicizzata. Può essere presente nel codice della pagina o nelle intestazioni HTTP. Per applicarlo, Google deve poterlo leggere: bloccare contemporaneamente la scansione può impedirne il rilevamento.
Un errore possibile dopo la pubblicazione
Immaginiamo che una pagina venga preparata con noindex durante la revisione e poi pubblicata mantenendo quell’impostazione per errore. Il controllo deve chiarire dove viene generata l’istruzione e se riguarda soltanto quella pagina o un intero gruppo.
Non rimuovere tutte le esclusioni per aumentare il numero di URL indicizzabili. Prima definisci quali pagine devono poter comparire nella ricerca e quali no. Per dati riservati servono adeguati controlli di accesso: il noindex non sostituisce una protezione.
Sitemap XML: che cosa verificare
La sitemap fornisce ai motori informazioni sulle risorse del sito. Può aiutare a scoprirle, ma non obbliga Google a scansionarle o indicizzarle.
Controlla che sia raggiungibile e che gli URL elencati siano coerenti con le versioni che vuoi indicizzare. Se contiene pagine eliminate, indirizzi che reindirizzano o risorse escluse intenzionalmente, chiedi di verificarne la generazione.
La sitemap affianca la navigazione: una pagina importante dovrebbe essere raggiungibile anche attraverso collegamenti pertinenti nel sito. Se è presente soltanto nel file XML, vale la pena rivedere come viene collegata.
Canonical e duplicati: indicare la versione principale
Uno stesso contenuto può essere accessibile da URL diversi, per esempio per la presenza di parametri. La canonicalizzazione riguarda la scelta della versione rappresentativa di contenuti uguali o molto simili.
Il rel=”canonical” indica una preferenza al motore; Google può scegliere una versione diversa. Non reindirizza il visitatore e non sostituisce un redirect quando una pagina viene spostata.
Verifica che l’indirizzo indicato sia pertinente, accessibile e coerente con i collegamenti interni e la sitemap. Una pagina di servizio con canonical impostato per errore sulla homepage invia un’indicazione da correggere, non un aiuto al suo posizionamento.
La presenza di URL duplicati non dimostra da sola una penalizzazione. Occorre capire come sono generati e quale comportamento serve. Non assegnare la stessa canonical a pagine diverse soltanto perché appartengono allo stesso argomento.
Codici HTTP: pagine disponibili, errori e limitazioni
Quando viene richiesto un URL, il server restituisce un codice HTTP. La documentazione di Google sui codici di stato aiuta a interpretarne l’effetto sulla scansione.
| Codice | Significato essenziale | Che cosa verificare |
|---|---|---|
| 200 | Richiesta riuscita. | Che il contenuto restituito sia quello previsto: il codice non garantisce l’indicizzazione. |
| 301 o 308 | Reindirizzamento permanente. | Che la destinazione sia corretta e raggiungibile. |
| 404 o 410 | Risorsa non trovata o rimossa. | Se la rimozione è voluta e se restano collegamenti da aggiornare. |
| 429 | Troppe richieste. | Limiti del server o dei sistemi di protezione e frequenza del problema. |
| 5xx | Errore lato server. | Disponibilità del servizio e cause da approfondire con il supporto tecnico. |
Un singolo controllo descrive una richiesta in un momento preciso. Ripeti la verifica quando necessario e confrontala con i dati disponibili: un blocco temporaneo non equivale automaticamente a una pagina eliminata.
Reindirizzamenti: scegliere la destinazione corretta
I reindirizzamenti accompagnano persone e motori da un vecchio URL a un altro. La scelta tra permanente e temporaneo dipende dalla natura dello spostamento.
Se cambi l’indirizzo di una pagina di servizio, prepara una corrispondenza tra vecchio e nuovo URL. Aggiorna i collegamenti interni e verifica che il percorso arrivi alla destinazione prevista senza passaggi inutili o cicli.
Per una pagina eliminata, valuta se esiste una risorsa sostitutiva pertinente. Inviare ogni indirizzo rimosso alla homepage può lasciare il visitatore senza la risposta cercata. Un 404 corretto per una risorsa senza sostituto non è un errore da nascondere a qualsiasi costo.
Prima di un restyling o di una migrazione, conserva l’inventario degli URL e pianifica la gestione delle pagine esistenti insieme a chi segue il lavoro tecnico.
Rendering e collegamenti: che cosa riesce a leggere il motore
Il rendering è l’elaborazione della pagina, anche attraverso l’esecuzione degli script. Google può eseguire JavaScript, ma questo non significa che ogni contenuto venga sempre elaborato come previsto. La guida alla SEO per JavaScript descrive scansione, rendering e indicizzazione.
Se il testo principale o i collegamenti compaiono soltanto dopo un’interazione particolare, chiedi di verificare il contenuto disponibile al motore. Non basta che tutto funzioni nel browser del proprietario del sito.
Controlla anche che menu e rimandi alle pagine importanti siano effettivamente esplorabili. Per un piccolo sito, un primo esame può riguardare homepage, un servizio e un articolo rappresentativo, ampliando il controllo se emerge un problema condiviso dal modello di pagina.
Prestazioni, Core Web Vitals e versione mobile
I Core Web Vitals misurano aspetti dell’esperienza d’uso: LCP riguarda il caricamento del contenuto principale, INP la reattività alle interazioni e CLS la stabilità visiva.
PageSpeed Insights distingue dati di laboratorio e dati sul campo. I primi derivano da una prova controllata; i secondi da esperienze reali raccolte, quando disponibili. Possono descrivere situazioni diverse.
Un singolo punteggio non riassume l’intera SEO. Usa i risultati per individuare problemi concreti, come immagini eccessivamente pesanti, script non necessari o elementi che spostano la pagina durante la lettura.
Prova inoltre il sito da smartphone: contenuti principali presenti, testi leggibili, pulsanti utilizzabili e moduli funzionanti. Dopo interventi su cache o prestazioni, verifica nuovamente queste funzioni, oltre alla velocità.
HTTPS, dati strutturati e casi che richiedono controlli aggiuntivi
Controlla che le pagine siano disponibili in HTTPS senza avvisi del browser e che i collegamenti puntino alle versioni previste. Problemi di certificato, risorse o reindirizzamenti richiedono una verifica con chi gestisce hosting e sito.
Se utilizzi dati strutturati, controlla che descrivano il contenuto reale e rispettino i requisiti del tipo scelto. Come indicano le linee guida di Google, una sintassi valida non garantisce la visualizzazione di risultati avanzati.
Siti multilingua, grandi cataloghi e sistemi con numerosi filtri richiedono verifiche aggiuntive su versioni, URL e collegamenti. Il controllo di un piccolo sito professionale non va esteso automaticamente a questi casi senza considerarne il funzionamento.
Tabella delle priorità: che cosa correggere prima
Questa tabella propone un ordine iniziale. La priorità effettiva dipende da estensione, durata e impatto del problema.
| Situazione | Priorità iniziale | Chi coinvolgere |
|---|---|---|
| Sito irraggiungibile o errori server diffusi. | Ripristinare la disponibilità e individuarne la causa. | Hosting e responsabile tecnico. |
| Noindex o blocco non voluto su pagine importanti. | Verificare l’origine dell’impostazione e il comportamento atteso. | Specialista SEO e gestore del sito. |
| Canonical o redirect verso pagine errate. | Controllare le regole e gli URL coinvolti. | Specialista SEO e sviluppatore. |
| Problema di prestazioni condiviso da molte pagine. | Identificare il modello o le risorse responsabili. | Sviluppatore, con supporto dell’hosting se necessario. |
| Segnalazione isolata su una risorsa eliminata volontariamente. | Verificare collegamenti e gestione della rimozione. | Gestore dei contenuti e referente tecnico. |
Una richiesta utile può essere: “Questa pagina di servizio dovrebbe essere pubblica e indicizzabile, ma Controllo URL rileva noindex. Potete verificare da dove viene generato? Il problema è stato notato dopo l’aggiornamento del sito.” È più precisa di “Google non mi trova”.
Esempio: una pagina esclusa dopo il restyling
Immaginiamo che una pagina di servizio non risulti più indicizzata dopo un rifacimento del sito. È un esempio operativo, non un caso cliente.
- Recuperi il vecchio URL e quello attuale, verificando se sono diversi.
- Controlli risposta del server, eventuale redirect e stato in Search Console.
- Verifichi noindex, accessibilità e indicazione canonical.
- Confronti le informazioni con il comportamento desiderato.
- Il responsabile corregge la causa individuata e verifica la pagina pubblicata.
- Registri modifica e data, poi monitori l’elaborazione e i dati successivi.
Se il problema era un’esclusione involontaria, la correzione rimuove quell’ostacolo. Non assicura il ritorno alla posizione precedente: contenuti, concorrenza e altri aspetti continuano a contare.
Come organizzare il lavoro e verificarne l’esito
Per ogni problema conserva URL di esempio, comportamento rilevato, comportamento atteso, responsabile e verifica finale. Un elenco ordinato permette di distinguere ciò che è stato risolto da ciò che deve ancora essere analizzato.
Dopo un intervento controlla prima il risultato tecnico: risposta corretta, istruzione aggiornata, destinazione raggiungibile o contenuto disponibile. Osserva poi gli eventuali aggiornamenti nei report e l’andamento delle pagine nel tempo.
Tempi e costi dipendono dal sito e dalla causa. Correggere un’impostazione circoscritta e risolvere un problema del modello usato da centinaia di pagine sono lavori diversi. Una proposta dovrebbe chiarire analisi, interventi, competenze coinvolte e modalità di verifica.
Se devi riorganizzare pagine e contenuti, la consulenza per siti web aiuta a definire struttura e priorità. Per le modifiche al codice, al server o alle configurazioni tecniche, il lavoro va assegnato al referente competente.
