Come risolvere gli errori di Crawl: una guida di triage completa e calma

Ecco la risposta diretta: per correggere gli errori di scansione, aprire Google Search Console, andare al rapporto di indicizzazione della pagina e lavorare attraverso ogni tipo di errore con la correzione che effettivamente richiede – riparare o reindirizzare 404 danneggiati, rinforzare o rimuovere correttamente i 404 morbidi, appiattire le catene di reindirizzamento, risolvere gli errori del server con il tuo host e districare i blocchi robots.txt dai tag noindex. Quindi utilizzare il pulsante Convalida correzione in modo che Google ricontrolla il tuo lavoro. Imparare a correggere gli errori di scansione è principalmente sapere quali errori contano – perché onestamente? Molti di loro non lo fanno.

Ok, siamo onesti per un secondo. La prima volta che apri il rapporto di indicizzazione della pagina e vedi centinaia di righe rosse “Non trovato (404)”, lo stomaco scende. Ho visto accadere a così tante persone intelligenti – vedono il numero, presumono che il loro sito sia rotto e iniziano a reindirizzare il panico in vista. Vi prometto: quel panico non è quasi mai giustificato, e il panico-fissazione di solito provoca più problemi che gli errori stessi.

Quindi rallentamo e facciamolo nel modo giusto. Alla fine di questa guida, saprai esattamente come correggere gli errori di scansione per tipo, quali meritano la tua attenzione questa settimana, quali sono solo Google che è chiacchierone e come impostare una semplice routine mensile in modo che questo non diventi mai più un’esercitazione antincendio.

Cosa sono gli errori di scansione e perché dovrebbe interessarvi?

Un errore di scansione si verifica quando un bot del motore di ricerca tenta di recuperare un URL sul tuo sito e qualcosa va storto: la pagina non esiste, il server si spegne, un reindirizzamento torna su se stesso o una regola da qualche parte dice al bot che non è consentito. Se Google non riesce a eseguire la scansione di una pagina, non può indicizzarla. E se non può indicizzarlo, quella pagina non può apparire nei risultati di ricerca, stop completo.

Ma ecco la parte che nessuno ti dice: gli errori di scansione sono completamente normali. Ogni sito web li ha. Le pagine vengono eliminate, gli URL vengono digitati erroneamente nei collegamenti, i server si insidiano alle 3 del mattino. Google si aspetta questo: il web è disordinato e Googlebot è costruito per disordinato. Un errore di scansione diventa un problema reale solo in tre situazioni:

• Influenza una pagina che ti interessa davvero – una pagina che guadagna traffico, link o entrate.
• Segue un modello – centinaia di URL che falliscono nello stesso modo di solito puntano a una causa principale (un modello difettoso, un plugin rotto, una migrazione del sito sciatta).
• È un problema a livello di server: errori 5xx e errori DNS possono rallentare la scansione di Google dell’intero sito, non solo di una pagina.

Tutto il resto? Per lo più rumore. Tienilo in tasca, perché cambia il modo in cui leggi ogni rapporto che stiamo per aprire.

Come risolvere gli errori di scansione passo uno: dove li trovi?

Google Search Console è la tua base di casa qui, ed è gratuito. Due relazioni fanno quasi tutto il lavoro:

Il rapporto di indicizzazione della pagina

Nella barra laterale sinistra, in Indicizzazione, fare clic su Pagine. Questo è il rapporto di indicizzazione della pagina e suddivide gli URL in indicizzati e non indicizzati, con un motivo allegato a ogni URL non indicizzato. Qui è dove si vedono righe come “Non trovato (404)”, “Soft 404,” “Errore di reindirizzamento”, “Errore del server (5xx), “Bloccato da robots.txt”, “Escluso da tag ‘noindex'”, “Crawled – attualmente non indicizzato” e “Discovered – attualmente non indicizzato”.

Fare clic su qualsiasi motivo e si ottiene l’elenco degli URL interessati, fino a un migliaio di esempi, con la data in cui ciascuno è stato sottoposto a scansione per l’ultima volta. Una nota veloce: Google occasionalmente rinomina o raggruppa questi motivi, quindi se un’etichetta appare leggermente diversa nel tuo account rispetto a qui, non sudare – le categorie mappano gli stessi problemi sottostanti.

Il rapporto delle statistiche di Crawl

Questo si nasconde sotto Impostazioni → Statistiche Crawl, E la maggior parte delle persone non lo trova mai. Mostra quanto spesso Googlebot colpisce il tuo sito, come risponde il tuo server e — cruciale — la ripartizione delle risposte per codice di stato nell’ultimo 90 giorni. Se il tuo sito sta lanciando errori intermittenti 5xx o risposte lente, questo è dove viene visualizzato il modello. Il rapporto di indicizzazione della pagina ti dice quali pagine fallì; Statistiche di Crawl ti dice se il tuo server è il problema.

Lo strumento di ispezione URL

Per ogni singolo URL, incollarlo nella barra di ricerca nella parte superiore di GSC. Vedrai esattamente come Google ha visto l’ultima volta quella pagina – se è indicizzata, quando è stata sottoposta a scansione, quale era la risposta e se qualcosa lo sta bloccando. Quando stai diagnosticando una pagina specifica, inizia da qui. Puoi anche fare clic su “Test live URL” per vedere come la pagina risponde in questo momento, che è come controllare se una correzione che hai appena spedito effettivamente ha preso.

Se stai facendo una revisione del sito più ampia, questi rapporti si collocano ordinatamente in un elenco completo. audit tecnico SEO — Gli errori di scansione sono un capitolo di quella storia più grande e l’audit ti guida attraverso il resto.

Come si possono correggere gli errori 404 nel modo giusto?

404 significa che il server ha detto “questa pagina non esiste”. Tutto qui. Il codice di stato stesso è onesto e sano – è il web che funziona come progettato. La domanda è: “Come faccio a far sparire tutti i miei 404?” È “dovrebbe esistere questo URL, e se sì, dove dovrebbe puntare?” Esegui ogni 404 attraverso questo piccolo albero delle decisioni:

• Era un errore di battitura in un link? Se una pagina del tuo sito (o di qualcun altro) si collega a /blog/instagram-tipss invece di /blog/instagram-tips, la vera soluzione è correggere la pagina di collegamento. Correggere la sorgente e l’errore si asciuga alla radice. Questo è più importante di quanto le persone si rendano conto: reindirizzare un URL tipotizzato lascia il link rotto in atto per il prossimo crawler e il prossimo umano.
• Il contenuto si è spostato? Se la pagina è presente in un nuovo URL, impostare un 301 reindirizza (permanente) dal vecchio URL al nuovo. Il 301 passa lungo l’equità del collegamento della vecchia pagina e invia i visitatori dove volevano andare.
• Il contenuto è andato per il bene, ma qualcosa di vicino esiste? Redirect al sito La pagina più vicina veramente rilevante — Non la homepage. Un reindirizzamento a una pagina irrilevante è ciò che Google Tratta come un morbido 404 In ogni caso (più su questo in un minuto), in modo da non guadagnare nulla fingendo rilevanza.
• E’ sparito e niente lo sostituisce? Lascialo fare 404. Sul serio. Un prodotto fuori produzione senza successo, una pagina evento scaduta, una vecchia campagna — questi dovrebbe ritorno 404, o 410 (“passato”) se la tua piattaforma lo rende facile. A 410 è un segnale leggermente più forte “questo è permanente”, ma un segnale semplice 404 E’ perfettamente a posto. Non tutto merita un reindirizzamento, e la redirezione di ogni URL morto alla tua homepage è una delle ferite autoinflitte più comuni nel SEO.

Un altro controllo di onestà prima di toccare qualsiasi cosa: Vediamo se gli URL 404 sono pagine reali. GSC spesso riporta 404 URL che non sono mai esistiti — URL malformati raschiati da bot, vecchi parametri spazzatura, frammenti di percorsi JavaScript Google Ho provato a strisciare. Se un “404 error” è un URL che non hai mai pubblicato e non c’è niente di importante a cui fare link, va bene. Davvero. Google Riscoprire vecchi URL per anni; a 404 su una pagina che dovrebbe essere andata è un comportamento corretto, non un errore da correggere.

Cos’è un soft 404 e come si risolve?

Un soft 404 è più subdolo. È una pagina che restituisce un codice di stato 200 (OK) – quindi il server afferma che tutto va bene – ma il contenuto sembra una pagina di errore o è così sottile che Google decide che non ha alcuna attività indicizzata. I colpevoli classici:

• Una pagina personalizzata “pagina non trovata” che restituisce 200 invece di 404 (molto comune con i framework JavaScript e alcune configurazioni CMS).
• Archivi vuoti di categoria o tag – una categoria di negozio con zero prodotti, un tag blog senza post.
• Pagine quasi vuote: una pagina di localizzazione con solo un nome di città, un profilo senza contenuti.
• Reindirizzamenti che scaricano gli utenti da qualche parte irrilevante, come ogni URL morto che punta alla homepage.

La correzione dipende da cosa merita la pagina:

• Se la pagina dovesse esistere e rango: renderlo una pagina reale. Aggiungi contenuti genuini – la sostanza che un visitatore che atterra lì vorrebbe davvero. Un verdetto soft 404 su una pagina che ti interessa è Google che ti dice che la pagina è troppo sottile, e la cura è profonda, non un ritocco tecnico.
• Se la pagina non dovesse esistere: Rendilo vero 404 oppure 410. Configura le pagine di errore per inviare il codice di stato onesto. Nella maggior parte delle piattaforme CMS si tratta di un template o di un’impostazione del server; nei framework JavaScript a volte richiede una risposta intenzionale lato server perché l’app rende un messaggio di errore mentre il server dice ancora 200.
• Se si muove: 301 alla destinazione veramente rilevante.

Il tema che noterai attraverso questa guida: Google premia i codici di stato onesti. Una pagina che dice cosa è – qui, spostato, o andato – non ti fa mai male. Le pagine che mentono sul loro stato sono quelle che si accumulano in rapporti di errore.

Come si risolvono gli errori di reindirizzamento?

“Errore di reindirizzamento” in GSC significa che Googlebot ha seguito un reindirizzamento e qualcosa si è rotto prima di raggiungere una pagina finale. I soliti sospetti:

• Redirect catene: A → B → C → D. Ogni salto rallenta le cose, perde un piccolo segnale e aumenta la possibilità di un fallimento a metà catena. Le catene si accumulano innocentemente — una migrazione del sito qui, un passaggio HTTPS lì, una regola di trailing-slash in cima — Fino a quando un URL non richiede quattro luppolo per risolvere.
• Redirect loops: A → B → A. Il bot si arrende, l’utente vede un errore del browser, nessuno vince. I loop di solito provengono da regole contrastanti — un plugin reindirizzamento in un modo mentre una regola del server reindirizza indietro.
• Catene che sono semplicemente troppo lunghe: Googlebot seguirà solo un numero limitato di luppoli prima di abbandonare la scansione.
• Redirects to non-stop: un redirect che atterra su un 404 o un URL vuoto.

La correzione è la stessa in ogni caso: appiattito ad un solo hop. Ogni vecchio URL dovrebbe reindirizzare direttamente alla sua destinazione finale — uno 301, fatto. In pratica, ciò significa:

• Traccia l’intera catena con un controllore di reindirizzamento (quelli basati su browser gratuiti funzionano bene) o il tuo crawler preferito.
• Aggiorna il primo reindirizzamento per puntare direttamente all’URL finale.
• Cercare regole contrastanti: controllare il plugin di reindirizzamento CMS, la configurazione del server e le impostazioni CDN – i loop significano quasi sempre due sistemi in disaccordo.
• Mentre ci sei, aggiorna i link interni che puntano a reindirizzare gli URL in modo che si colleghino direttamente alla destinazione finale. I collegamenti interni non dovrebbero avere bisogno di reindirizzamenti.

Mantenere una semplice mappa di reindirizzamento — un foglio di calcolo di “old URL → URL finale & rdquo; — e questo rimane gestibile per sempre. Salta, e ogni migrazione futura impila un nuovo livello di catene su quelle vecchie.

Cosa fare per gli errori del server (5xx)?

Un errore 5xx indica che il server non è riuscito a consegnare la pagina – non è che la pagina non esiste, è che il server non poteva servirla. Un 500 è un errore generico, un 502/504 di solito indica un problema di gateway o timeout, e un 503 dice “temporaneamente non disponibile” (che è in realtà il codice corretto da inviare durante la manutenzione pianificata, poiché dice a Google di tornare più tardi).

Gli errori del server meritano più urgenza di 404, per una grande ragione: se Googlebot continua a colpire le risposte 5xx, rallenta la scansione in tutto il sito per evitare di peggiorare le cose. Gli errori persistenti del server non nascondono solo una pagina, ma riducono il tempo in cui l’intero sito rimane nell’indice.

Come risolvere il problema:

• Verifica se è attuale o storico. Apri gli URL interessati nel tuo browser e testali con il test live di URL Inspection. GSC riporta ciò che è accaduto in tempo di scansione – un blip di martedì scorso potrebbe già essere risolto.
• Cerca il modello nelle statistiche di Crawl. Le risposte occasionali 5xx su una piccola percentuale di richieste accadono a tutti. Una linea crescente, o errori raggruppati in momenti specifici della giornata, indica un problema di capacità: un lavoro di cron, una finestra di backup, un picco di traffico che il piano di hosting non può assorbire.
• I soliti colpevoli sui siti CMS: un plugin o un aggiornamento del tema che si comporta male, limiti di memoria PHP, esaurimento della connessione al database o un piano di hosting condiviso sopraffatto. Se gli errori sono iniziati subito dopo aver installato o aggiornato qualcosa, c’è il tuo primo sospetto.
• Sapere quando aumentare. Se non riesci a riprodurre o spiegare gli errori, questo è il momento di parlare con il tuo provider di hosting o sviluppatore – porta loro il grafico delle statistiche di Crawl e alcuni URL di esempio con timestamp. Questi dati trasformano un vago “Google dice che il mio sito ha errori” in un biglietto su cui possono effettivamente agire. Non c’è vergogna nell’escalation; la diagnosi a livello di server è davvero il loro lavoro.

Bloccato da robots.txt vs. noindex – quale vuoi davvero?

Questi due si confondono costantemente, e la confusione crea uno strano stato zombie, quindi facciamolo croccante:

• Bloccato da robots.txt Googlebot non è autorizzato a strisciare URL. Non si è mai ripreso la pagina.
• Un tag noindex mezzi Google può eseguire la scansione della pagina ma viene detto di non indice Sì.

Ecco la trappola: il blocco robots.txt fa non Tenere una pagina fuori dai risultati di ricerca. Se altre pagine puntano a un URL bloccato, Google può indicizzare l’URL nudo in ogni caso — senza mai vedere il contenuto — e mostrarlo con una lista di stile “nessuna informazione disponibile”. E le due direttive si sabotano a vicenda: se blocchi una pagina in robots.txt e mettere il noindex su di esso, Google non è possibile eseguire la scansione della pagina, quindi non vede mai il tag noindex. L’istruzione che volevi è invisibile.

Il triage è così:

• Pagina bloccata che non dovrebbe essere? Modificare robots.txt e rimuovere la regola di esclusione. Questo è di solito un residuo dello sviluppo (“Disallow: /” è il classico attacco cardiaco di lancio del sito) o un modello eccessivamente ampio che cattura più del previsto.
• Vuoi una pagina scansionabile ma non indicizzata? Usa un meta tag noindex e assicurati che la pagina non sia bloccata in robots.txt in modo che Google possa vedere il tag.
• Vuoi risparmiare il budget di scansione su sezioni veramente inutili (risultati interni della ricerca, combinazioni di filtri sfaccettati)? Questo è il caso d’uso legittimo robots.txt – basta accettare che i controlli di blocco strisciano, non indicizzano.

Robots.txt è piccolo ma potente, e la sintassi ha denti reali — se stai modificando la tua, la guida completa su Come usare robots.txt cammina attraverso le regole, i disastri comuni e come testare i cambiamenti prima che vadano in vita.

Cosa significa “Crawled – attualmente non indicizzato” in realtà?

Respiro profondo, perché questo è quello che manda le persone giù per le buche del coniglio. “Crawled – attualmente non indicizzato” significa che Google ha recuperato la tua pagina con successo, l’ha guardata e ha scelto di non inserirla nell’indice. Nulla è tecnicamente rotto. Non c’è errore da correggere, nessuna impostazione da capovolgere, nessun trucco di riinvio magico.

Ecco la verità onesta che la maggior parte delle guide punta intorno: questo stato è molto spesso un verdetto di qualità, non un bug tecnico. Google esegue la scansione di molte più pagine di quante non sia l’indicizzazione, ed è sempre più selettivo su ciò che guadagna un posto. Pagine sottili, quasi duplicati, pagine pesanti come caldaie e contenuti che assomigliano a mille altre pagine sul web sono esattamente ciò che atterra qui.

Cosa muove le pagine da questo secchio:

• Rendi la pagina significativamente migliore. Sostanza più genuina, intuizione originale, una ragione chiara per cui merita di esistere accanto a tutto ciò che già classifica. Poni la domanda scomoda: se hai cercato questo argomento, vorresti onestamente questa pagina come risposta?
• Consolidare i quasi duplicati. Cinque pagine sottili su argomenti sovrapposti spesso indicizzano meglio come una pagina forte con reindirizzamenti dagli altri.
• Rafforzare i collegamenti interni. Una pagina a cui non si rimanda sembra insignificante. Link ad esso dalle pagine più rilevanti e più visitate con testo di ancoraggio descrittivo.
• Accetta che alcune pagine non siano indicizzate e non dovrebbero. Archivi tag, pagine di localizzazione della piastra caldaia, varianti di parametri – se esiste una pagina per la meccanica del sito piuttosto che per i lettori, la sua assenza dall’indice non ti costa nulla.

Cosa non lo fa lavoro: martellare il pulsante Richiesta di indicizzazione, ripresentare la sitemap quotidianamente o modificare minuzie tecniche su una pagina il cui vero problema è che è sottile. Request Indexing invita a una riformulazione; non cambia il verdetto. So che non è la risposta divertente, ma inseguire questo stato come se fosse un errore tecnico è uno dei più grandi momenti che affondano nella SEO.

E “scoperto – attualmente non indicizzato”?

Questo è un cugino, con una causa diversa. “Scoprito” significa che Google sa che l’URL esiste – dalla tua sitemap o da un link – ma non è ancora riuscito a scansionarlo. È un problema di priorità della scansione: Google mette in coda gli URL per valore atteso e questi non hanno ancora fatto il taglio.

Su un nuovo sito, questo è per lo più pazienza – la fiducia richiede tempo per costruire. Su un sito stabilito, un crescente mucchio “scoperto” di solito significa che le pagine sembrano a bassa priorità: sepolte in profondità nell’architettura, a malapena collegate internamente o parte di un enorme lotto pubblicato contemporaneamente. La leva più forte che controlli è il collegamento interno – link a queste pagine da pagine che Google già esegue spesso la scansione e la loro priorità aumenta. Una sitemap XML pulita e attuale aiuta anche la scoperta, anche se una sitemap da sola è un suggerimento, non un comando: porta gli URL in coda, mentre i link convincono Google che vale la pena eseguire la scansione.

Che dire di errori DNS, problemi di connettività e scansione mobile?

Due veloci ma importanti prima di arrivare al flusso di lavoro:

Errori di DNS e connettività Googlebot non è riuscito a raggiungere il tuo server — il dominio non si è risolto, la connessione è stata interrotta o il server l’ha rifiutata. Se questi appaiono più di tanto in tanto nelle statistiche di Crawl, trattali come urgenti: controlla i record DNS del tuo dominio, conferma che la tua registrazione non è terminata (accade al meglio di noi) e chiedi al tuo host o CDN se limitano le tariffe o bloccano le richieste di Googlebot. Un firewall o una regola di protezione dei bot troppo aggressiva può tranquillamente strozzare Googlebot mentre il sito ti sembra bello in un browser — Ed è proprio per questo che questi errori si sentono così confusi.

Mobile vs. desktop crawler: Google esegue prevalentemente la scansione con il suo user-agent per smartphone, il che significa che la versione mobile della tua pagina è ciò che viene valutato. Se la pagina mobile nasconde contenuti, serve collegamenti diversi o si rompe in modi che il desktop non nasconde, puoi vedere errori o lacune di indicizzazione che non si riproducono sul tuo laptop. Quando un errore segnalato non ha senso, prova l’URL come dispositivo mobile (gli strumenti di sviluppo del browser lo fanno in due clic) prima di dichiarare GSC sbagliato. La maggior parte delle volte il report è accurato: descrive solo una versione della pagina che normalmente non guardi.

Come si fa a convalidare le correzioni e sapere che hanno funzionato?

Una volta risolto un lotto di errori, tornare al rapporto di indicizzazione della pagina, aprire il problema pertinente e fare clic su Convalida Fix. Google riscriverà un campione degli URL interessati e traccerà il resto nei giorni e nelle settimane seguenti, contrassegnando il problema come passato o fallito.

Ora, un po ‘di onestà su questo pulsante, perché le aspettative contano:

• La convalida richiede tempo. Spesso un paio di settimane, a volte più a lungo per i grandi lotti. Non è istantaneo, e guardarlo ogni giorno farà male solo alla tua anima. Inizia la convalida, imposta un promemoria del calendario, vai avanti con la tua vita.
• “Failed” non significa sempre che la tua correzione sia sbagliata. Se anche alcuni URL campionati mostrano ancora il problema – forse alcuni straggler che hai perso, forse una risposta memorizzata nella cache – la convalida può fallire. Controllare quali URL specifici non sono riusciti, correggerli e riavviare la convalida.
• Non devi aspettare che Google sappia che hai ragione. Testate voi stessi gli URL fissi: caricateli in un browser, eseguiteli attraverso il test live di URL Inspection, confermate il codice di stato con un controllo di intestazione. Se la risposta dal vivo è corretta, il tuo lavoro è finito – il rapporto non è ancora riuscito.

Il conteggio degli errori in GSC è un indicatore finale. La tua fonte di verità è ciò che gli URL effettivamente ritornano oggi.

Come si fa a dare priorità agli errori di scansione (e quali si possono ignorare)?

Non è necessario correggere ogni riga del rapporto, e cercare di è come un compito di due ore diventa una spirale di due settimane. Dare priorità in questo ordine:

• Prima le pagine di denaro. Qualsiasi errore in una pagina che genera traffico, conversioni, link o entrate supera tutto il resto. URL di errore di riferimento incrociato rispetto alle tue pagine principali – questo è un minuto di lavoro che mette a fuoco tutto.
• Modelli per una tantum. Trecento URL che non funzionano allo stesso modo sono un bug con una causa principale: un modello, un plugin, una regola di migrazione. Fissare la causa cancella il lotto. Trecento URL singoli non correlati sono di solito rumore.
• Problemi di server e DNS su problemi di pagina. Tutto ciò che rallenta la scansione del sito batte qualsiasi problema di una sola pagina.
• Ultimo e meno importante: il cassetto della spazzatura. URL di parametri 404ing, vecchi URL da un sito che hai ridisegnato anni fa, URL mai esistenti che i bot hanno inventato – GSC riporta diligentemente tutto, e quasi nulla di ciò che conta. Un 404 su un URL che dovrebbe essere andato è il sistema funzionante. Lascia stare.

Tabella di errore di Crawl

Tipo di errore	Cosa significa	Il fix
Non trovato (404)	La pagina richiesta non esiste.	Correggere la pagina di collegamento per errori di battitura; 301 alla pagina pertinente più vicina se il contenuto è spostato; lasciare veramente andare le pagine 404/410
Soft 404	La pagina restituisce 200 ma sembra vuota o simile a un errore di Google	Aggiungi contenuti reali se la pagina dovesse esistere; altrimenti restituisci un vero 404/410; correggi i modelli di errore che inviano 200
Errore di reindirizzamento	Catena troppo lunga, loop o reindirizzamento a un vicolo cieco	Appiattire ogni reindirizzamento a un singolo hop; risolvere regole contrastanti; aggiornare i collegamenti interni agli URL finali
Errore del server (5xx)	Il tuo server non è riuscito a consegnare la pagina	Controlla le statistiche di Crawl per i modelli; verifica le modifiche recenti dei plugin / temi; aumenta l’host o lo sviluppatore con i dati
Bloccato da robots.txt	Googlebot non è autorizzato a eseguire la scansione dell’URL	Rimuovere la regola di non consentire se non intenzionale; utilizzare noindex (senza il blocco) se si desidera che sia sottoposto a scansione ma non indicizzato
Escluso da noindex	Pagina sottoposta a scansione, ma taggata per rimanere fuori dall’indice	Rimuovi il tag noindex se non intenzionale – controlla le impostazioni del plugin SEO e gli avanzi di messa in scena
Crawled – attualmente non indicizzato	Google ha visto la pagina e ha scelto di non indicizzarla	Di solito un verdetto di qualità: migliorare o consolidare il contenuto, rafforzare i collegamenti interni – o accettarlo
Scoperto – attualmente non indicizzato	Google conosce l’URL ma non l’ha ancora scansionato	Migliorare i collegamenti interni alla pagina, mantenere pulita la sitemap e dargli tempo
DNS / connettività	Googlebot non è riuscito a raggiungere il server	Controllare i record DNS e la registrazione; chiedere host / CDN sui limiti di tariffa o regole di blocco bot

Come risolvere gli errori di scansione per sempre: cosa impedisce le ripetizioni?

Correggere gli errori di scansione una volta è un progetto. Prevenire loro è un’abitudine, e l’abitudine è più leggera di quanto si possa pensare:

• Controlla i link prima di pubblicare. Fai “fare clic su ogni link nella bozza” parte della tua lista di controllo dei contenuti. La maggior parte dei nuovi 404 nascono nella finestra di modifica – un URL incollato con un carattere finale, un link a una bozza che non è mai andata in diretta.
• Mantieni una mappa di reindirizzamento. Un foglio di calcolo: vecchio URL, destinazione finale, data, ragione. Ogni volta che si elimina, rinomina o migra, viene visualizzata una riga. Il futuro ti sarà imbarazzantemente grato.
• Reindirizza al momento del cambiamento, non dopo. Quando si modifica un URL, creare il 301 nella stessa seduta. Gli errori che si impediscono non vengono mai inseriti nel report.
• Crea il tuo sito trimestrale. Un desktop o un cloud crawler si apre su link interni rotti, catene di reindirizzamento e pagine orfane prima che Google vi viaggi. Trovare il tuo 404s prima è la differenza tra manutenzione e antincendio.
• Trattare le migrazioni come un intervento chirurgico. Modifiche URL, replatforming, mosse HTTPS: creano più errori di scansione di tutto il resto combinato. Mappa ogni vecchio URL nella sua nuova casa prima dell’interruttore e monitora attentamente GSC per il mese successivo.
• Impostare una cadenza di monitoraggio. Uno sguardo mensile all’indicizzazione delle pagine e una serie di statistiche di Crawl catturano quasi tutto mentre è ancora piccolo. Ogni settimana è garantito solo subito dopo una migrazione o una riprogettazione.

La tua lista di controllo mensile di crawl-health

• Aprire il rapporto di indicizzazione della pagina – eseguire la scansione per qualsiasi motivo il cui conteggio è saltato dal mese scorso.
• Controlla i nuovi URL “Non trovato (404)” – triage: collegamento tipo, contenuto spostato o legittimamente andato?
• Revisione Soft 404s – migliora, correttamente 404, o reindirizzare ciascuno.
• Skim Crawl stats (Impostazioni &rrar; Statistiche Crawl) — eventuali aumenti delle risposte 5xx, problemi DNS o tempi di recupero?
• Controlla le tue prime 10 pagine di traffico con URL Inspection – tutto indicizzato, tutto pulito?
• Aggiorna la mappa di reindirizzamento con eventuali modifiche all’URL apportate questo mese e conferma che i reindirizzamenti sono single-hop.
• Controllare robots.txt – invariato, e non bloccare nulla di nuovo per caso?
• Conferma che la sitemap XML elenca solo URL live, indicizzabili e a 200 stati.
• Avviare Convalida Fix su tutto ciò che hai riparato, e annotare la data in modo da non essere rinfrescante ogni giorno.

Quella lista richiede forse trenta minuti una volta che l’hai fatta due volte. Confrontalo con la settimana in cui perderai sei mesi di errori accumulati dopo una migrazione, ed è il miglior commercio nel SEO.

Uno a parte onesto prima di concludere – perché potresti chiederti dove ci adattiamo a tutto questo. SocialBlaze non corregge gli errori di scansione; è una piattaforma di gestione dei social media organica, non uno strumento SEO. Ma i due flussi di lavoro sono vicini: ogni articolo che salvi da un errore di scansione merita i lettori e il social è come li porti mentre le classifiche si costruiscono. Se stai condividendo i tuoi contenuti su tutte le reti, comunque, aiuta a far funzionare quel lato della casa.

Domande frequenti

Gli errori di scansione danneggiano il mio ranking?

Non direttamente, nella maggior parte dei casi. Un 404 su una pagina che dovrebbe essere andato è normale comportamento web e non comporta penalità. Ciò che fa male è il danno indiretto: gli errori sulle pagine importanti li tengono fuori dalla ricerca del tutto, i link interni rotti sprecano l’autorità che hai costruito e gli errori persistenti del server possono rallentare la scansione in tutto il tuo sito. Correggere gli errori nelle pagine che contano; non perdere il sonno sul resto.

Quanto tempo ci vuole per la scansione degli errori di scomparire da Google Search Console?

Aspettatevi settimane, non ore. Dopo aver risolto un problema e aver fatto clic su Convalida correzione, Google ricontrolla gli URL interessati per giorni o settimane a seconda della frequenza con cui esegue la scansione del sito. Il report è un indicatore finale: verifica la correzione da solo testando l’URL live, quindi lascia che il report raggiunga il suo programma.

Devo reindirizzare ogni 404 alla mia homepage?

Ti prego, non farlo. Google tratta i reindirizzamenti irrilevanti come soft 404, quindi scambi una riga di report per una peggiore e i visitatori vengono scaricati da qualche parte inutili. Reindirizza solo quando esiste una pagina sostitutiva veramente rilevante. Se nulla sostituisce il contenuto, un onesto 404 o 410 è la risposta corretta e sana.

“Crawled – attualmente non indicizzato” è un errore che devo correggere?

Non è un errore tecnico – Google ha recuperato la pagina e ha scelto di non indicizzarla, che è più spesso un giudizio di qualità o duplicazione. Migliorare il contenuto, consolidare le pagine sottili e rafforzare i collegamenti interni a quelli che contano. Per le pagine di basso valore come gli archivi dei tag, il non-indicizzazione è normale e non costa nulla.

Qual è la differenza tra bloccare una pagina in robots.txt e usare noindex?

Robots.txt controlla la scansione: Googlebot non recupera un URL bloccato, ma l’URL può comunque finire indicizzato se altre pagine si collegano ad esso. Un tag noindex controlla l’indicizzazione, ma Google deve essere in grado di eseguire la scansione della pagina per vedere il tag. Per mantenere una pagina fuori dai risultati di ricerca, utilizzare noindex e assicurarsi che la pagina non sia bloccata in robots.txt, o che le due regole si annullino a vicenda.