-
Questa opera di Enrico Altavilla è concessa in licenza sotto la Licenza Creative Commons Attribuzione - Non commerciale - Non opere derivate 3.0 Unported.
5 nozioni semplici semplici sugli errori 404
Questo post dedicato agli status 404 è volutamente poco approfondito.
In realtà per far le cose per bene, dovrei spiegare che la gestione dei contenuti inesistenti di un sito cambia sia al variare della tipologia del contenuto sia a seconda della ragione per la quale il contenuto non esiste (più).
Il primo esempio che mi viene in mente è quello della gestione di prodotti o contenuti temporanamente non disponibili. Non esistono regole generiche che possano essere applicate in ogni caso e mi è capitato nel corso del tempo di suggerire almeno due soluzioni tecniche diverse a seconda dei contenuti.
Mi riservo quindi di scrivere in futuro un bell’articolo SEO su dei casi specifici, nei quali l’uso dei codici di stato varia nonostante premesse simili.
Per il momento, accontentatevi di queste semplici nozioni generali e di un flow-chart chiarificatore.
1 – La criticità di un 404 dipende dai link
Uno degli errori più comuni è quello di credere che la presenza di un errore 404 erogato alla richiesta di una specifica risorsa abbia influenze SEO negative nei confronti di altre risorse del sito o del sito nella sua interezza.
Questo ragionamento è però corretto solo nel caso in cui sul sito vi siano link che conducono utenti e spider verso le risorse che generano lo status 404.
Se l’URL inesistente non è linkato dal sito, non c’è modo che gli utenti possano subire un’esperienza di navigazione negativa. Di conseguenza non sarebbe logico che un motore di ricerca si faccia un’idea negativa del sito, perché il sito sta accogliendo al meglio i propri visitatori.
Se, al contrario, sul sito ci sono link verso URL interni inesistenti, allora il problema è diverso perché c’è il rischio di proporre un’esperienza di navigazione frustrante agli utenti e di vanificare il crawling degli spider. Bisogna dunque fare attenzione che, se gli status 404 sono fisiologici o inevitabili, quantomeno utenti e spider non seguano link del sito che li conducano a risorse inesistenti.
2 – La permanenza non è intrinsecamente un male
Un errore 404 rappresenta una criticità solo se è stato prodotto da un problema tecnico, che andrebbe approfondito e risolto.
Ci sono però casi leciti nei quali un webmaster può decidere spontaneamente di far erogare al server uno status 404, per esempio quando viene fatta richiesta al server di una risorsa che non è mai esistita.
Nel suddetto caso lo status 404 e la sua permanenza non va percepito come una criticità, perché non è sintomo di un problema ma la soluzione più corretta per comunicare l’effettiva inesistenza di una risorsa.
3 – Lo status è associato ad una risorsa HTML
Tutti i web server permettono di erogare una pagina HTML associata alla produzione di un errore 404.
I contenuti di questa pagina HTML possono essere personalizzati in modo da accogliere al meglio l’utente che si è trovato di fronte ad un errore che non si aspettava.
Il modo in cui i contenuti vanno personalizzati variano da caso a caso. A volte ci si può limitare ad indicare dei link per riprendere la navigazione del sito da una categoria superiore o dalla home page. Altre volte è possibile determinare dall’URL richiesto (o dal referrer dichiarato) l’intento dell’utente e includere nella pagina contenuti più specifici, in grado di soddisfare al meglio la richiesta che non era andata a buon fine.
4 – Gli elenchi di 404 su GWT non sono una pestilenza
Va ricordato che GWT (“Strumenti per webmaster” di Google) non è Google e che il tool si limita a fare un elenco dei 404 individuati dallo spider nel corso del tempo.
Per le ragioni spiegate al punto 2, non tutti questi errori sono indice di un fenomeno negativo e quindi ciascuno di essi andrebbe investigato per capire se si tratta di un fenomeno fisiologico e ininfluente sul motore (per esempio 404 erogati alla richiesta di URL effettimanete mai esistiti) oppure se è sintomo di un problema tecnico.
Se alcuni degli status 404 riportati sono fisiologici e conosciuti, potete anche segnalare a GWT che l’eventuale “problema” è stato risolto; tali errori verranno rimossi dalla lista.
Purtroppo tali segnalazioni sono destinate a tornare sul pannello qualora la causa che ha generato i 404 non sia realmente scomparsa.
5 – Tenete conto delle alternative
Facendo parte di un nutrito insieme di status HTTP, i codici 404 andrebbero usati solo quando effettivamente opportuni. Ecco di seguito un breve flow-chart che spiega come destreggiarsi nell’uso dei più popolari codici di status HTTP.
Il grafico è lungi dall’essere completo e perfetto e sono certo che sulla completa assenza degli status 302 qualcuno potrebbe storcere anche il naso. I commenti del post sono a vostra disposizione per domande, correzioni e considerazioni. 🙂
P.S.
Pensavo che sarebbe interessante parlare di argomenti simili in qualche evento. Giusto per dire.
In merito a “La risorsa è destinata a tornare in futuro?” => Si
Non ho abbastanza “esperienza sul campo” da poter parlare dell’utilizzo dello status 307, ma sul 404 non sono d’accordo. Mi sono trovato a confrontarmi (scontrarmi) su questo argomento proprio qualche giorno fa con due SEO con cui collaboro (di cui ho una stima immensa). Molto probabilmente ciò che penso è assolutamente sbagliato, ma io credo che restituire un 404 non sia la migliore soluzione.
Dare oggi un 200, fra due giorni un 404, dopo altri tre giorni un 200 e così via mi sa di schizzofrenia.
Se io dovessi realizzare un software che monitori la “salute” di un sito inserirei tale atteggiamento negli alert segnalando all’utente di verificare se vi è un problema.
Inoltre occorre ricordarsi che un utente potrebbe aver salvato nei preferiti quella pagina e che in base alla fortuna/sfortuna del timing scelto per ritornarci potrebbe trovare il contenuto desiderato o no.
Faccio un esempio: mettiamo il caso che io abbia un sito di offerte divise per categoria.
In questo caso allora se la categoria si trova con zero offerte dovrei restituire un 404.
Io invece gestirei la cosa in maniera diversa: sicuramente eliminerei tutti i link che portano a quella pagina (incluso ovviamente anche dalla sitemap), lascerei un 200 e cercherei di “inventarmi” un contenuto che, oltre a segnalare che non ci sono più offerte in corso per quella categoria, sia comunque inerente alla stessa, per esempio inserendo le ultime n offerte passate o altro.
Ripeto, il mio pensiero può essere sbagliato, ma finché non avrò elementi tali da farmi cambiare idea, rimarrà lo stesso.
La SEO è bella anche per questo 🙂
Questo articolo è molto interessante. A tal proposito volevo chiedere un consiglio.
Analizzando con i GWT un sito di un mio cliente, realizzato con Joomla, ho scoperto che vengono rilevati circa 2.200 errori 404. Ho scoperto che la causa è di alcuni menu o componenti cancellati o disabilitati volontariamente perché trattasi di risorse obsolete o da visualizzare solo in alcuni periodi dell’anno (si tratta di un sito di materia fiscale e aziendale).
Purtroppo quelle pagine sono state indicizzate da Google e ora mi ritrovo con questa quantità elevata di errori.
In questo caso però la loro presenza non è del tutto indolore…anzi!!
Alla rilevazione di questi errori anche il numero di visitatori giornalieri si è notevolmente ridotto. Siamo passati da una media di circa 5000 visitatori al giorno a meno di 2000.
Io ho aggiustato il file robots.txt per indicare quali risorse non scansionare. In più ho indicato la nuova Sitemap, che non era nemmeno presente perché i precedenti webmaster non l’avevano impostata.
Vedendo che la lista degli errori non diminuisce ho pensato di dover indicare a Google la rimozione degli url tramite lo strumento dei GWT. Però, grazie al vostro articolo, ho capito che quello strumento non serve a molto, anzi potrebbe addirittura essere controproducente.
Ho richiesto pertanto una nuova scansione del sito da parte del Googlebot…ma non riesco a capire ogni quanto viene effettuata questa scansione e se i miei interventi tecnici devono ancora essere presi in considerazione dal motore di ricerca o se invece semplicemente non stanno funzionando.
Inoltre ci sono altrettanti errori con codice 500 che aggravano la situazione.
Sapreste indicarmi come intervenire per risolveree la situazione?
@Mirko: dovrei valutare la situazione per darti un parere. Basandomi solo su quanto hai scritto le prime cose che ti direi sono:
Non mi permetto di fornire indicazioni maggiori perché sono sempre stato dell’idea che “le automobili non si possano riparare al telefono” 😉 e a prescindere da quanto dettagliata sia la tua spiegazione, l’unico modo di acquisire tutte le informazioni necessarie a prendere le decisioni giuste è quello di aprire il cofano di persona e dare un’occhiata.
Prova magari anche a chiedere su questo forum un parere. Lì sono più abituati di me ad aiutare gli utenti a distanza, inoltre è un luogo molto frequentato, a differenza di questo post. 🙂
Grazie mille LowLevel, sei stato gentilissimo a rispondere. Capisco che senza visitare l’ammalato sia difficile dare una diagnosi certa (per continuare con le metafore).
Comunque le tue indicazioni mi torneranno di sicuro utili e poi posterò qualcosa anche nel Forum che mi hai indicato.
Spero di venirne a capo 😉