Il soft 404, un nuovo brevetto per Yahoo

Recentemente (due anni fa) Yahoo ha depositato un nuovo brevetto con il quale intende legiferare circa l’errore server 404 soft.

Dell’errore 404 ne ho parlato anche in passato, e quando ho letto di questo brevetto, onestamente ho fatto un peletto di fatica a stargli dietro, ma con una seconda – più attenta – lettura, alla fine ho compreso (spero) dove il motore antagonista di Google volesse arrivare.

Il brevetto in questione è:

Unsupervised Detection of Web Pages Corresponding to a Similarity Class
US Patent Application 20090157607
Published June 18, 2009
Filed December 12, 2007

Se mi avete seguito nell’articolo precedente o comunque sapete cosa sia un errore 404, non vi suonerà nuovo che ad una pagina inesistente, il server web quando interpellato, invece di restituire un codice di errore 200 (Tutto ok) deve restituire un codice di errore 404 (Pagina non trovata) per indicare per l’appunto che il contenuto richiesto non esiste.
Alla vista di tale codice i motori di ricerca sono così intelligenti da capire che l’eventuale pagina indicizzata e presente negli archivi può anche essere rimossa proprio perchè non più esistente.

Cosa succede quanto il motore di ricerca incontra il 404

Una volta che il motore di ricerca riceve questo codice, parte normalmente dal presupposto di abbandonare il sito web; questo con gravi conseguenze. Infatti una navigazione interrotta, equivale ad una scansione a metà (nel migliore dei casi), e comunque a dover attendere nuovamente che lo spider decida di passare per il nostro sito.

In una condizione come questa, artifici come la modifica del file delle pagine di errore con relativo codice d’errore ha preso via via sempre più piede.
Questo di fatto ha innescato una nuova condizione dove il server pur restituendo visivamente una pagina d’errore – per far capire all’utente che il contenuto richiesto non esiste – al contempo rimanda indietro un errore http con codice 200, di fatto falsando il normale processo d’esecuzione. Infatti, il motore vedendosi arrivare uno status di ok, prosegue nell’interpretazione della pagina e solamente inserendo qualche link all’interno della stessa, si può far si che il motore continui il suo giro di turno.

In uno scenario ideale, questi artifici non dovrebbero esistere …

ma dato che ci sono e che vengono usati, con il brevetto in questione, Yahoo si prefigge di combatterli.

Il brevetto che per l’appunto verte a scovare pagine web per classe di similarità, immagino prevederà la creazione di una sorta di indice alternativo interrogato in date circostanze per scovare pagine che sono molto simili tra loro.

Ma cosa se ne farà Yahoo di questa nuova forma di identificazione?

La prima e più ovvia risposta è: ennesima pagina identica, se non è già presente non la indicizzo, se è presente e supera magari una certa soglia limite, il motore inizia con il pensare di rimuoverle tutte.
Questo varrà quindi anche per tutte quelle landing pages per domini parcheggiati, o pagine fatte con il solo scopo di pubblicare bannerini pubblicitari o collegamenti sponsorizzati.

La seconda possibilità è quella di ridurre il trust di una pagina che linka una risorsa non più presente. Questa cosa, se lontanamente fosse vera, creerà non pochi problemi a quei siti lasciati all’abbandono.

La terza ipotesi che mi viene in mente è quella di creare un più moderno ed efficiente sistema tipo CopyScape, con il quale mostrare chi copia chi e dove.

Quanto al fattore identificazione, il documento denominato Syntactic Clustering of the Web viene indicato come uno dei possibili sistemi atti a scovare pagine simili.

E tu che tipo di 404 sei?

Personalmente ritengo opportuno rispettare il web e restituire sempre il codice d’errore corretto. Se del resto una pagina non esiste, è perché durante le attività di modifica del sito ho ritenuto opportuno cancellarla.
E, fermo restando condizioni particolari, è giusto che a risorsa non trovata informi il motore e l’utente in modo opportuno.
Questo non significa non poter non personalizzare la pagina d’errore, ma semplicemente farlo ritornando il giusto codice.

Esiste tuttavia una condizione dove si può venir meno a questo concetto, ed è quando la pagina in questione genera discreto traffico per qualsiasi motivi o ha un discreto numero di link in ingresso.
In questo caso, posso cancellare la pagina e magari preoccuparmi di recuperare quel traffico reindirizzandolo verso una nuova risorsa grazie al redirect 301.
Il motore sarà comunque informato del cambiamento e il sito web non perderà nulla.

E’ solo questione di saper usare lo strumento giusto al posto giusto nel momento giusto.

Technorati tags: , ,

IIS7 – Abilitare i Custom Error

Dal titolo del post dovreste aver già capito tutto, ma facciamo luce per chi non è pratico di IIS. Fino ad IIS6 per abilitare i custom error era sufficiente modificare il file web.config, aggiungendo la sezione customError opportunamente modificata e il gioco era praticamente fatto.

Oggi, con IIS7 le cose sono cambiate leggermente. Dato che non tutti abilitavano i cosiddetti CustomError, spesso e volentieri ci si ritrovava con schermate d’errore prive di significato per la maggior parte degli utenti, che raramente erano volontà implicita del developer, piuttosto una dimenticanza.

Le maschere di errore, si sà, sono molto utili per il debug, a volte anche troppo, perchè spesso contengono delle informazioni che si vorrebbero nascondere agli occhi di tutti. Ecco il motivo con il quale durante lo sviluppo di IIS7 è stata rilasciata quelli che vanno sotto il nome di IIS7 detailed errors, ovvero una nuova funzione aggiuntiva di IIS7 che permettono di mandare al browser una maschera di errore generica o una dettagliata.

Di default viene mandata quella generica, che racchiude in una forma elegante l’errore, senza però rivelare troppo, lasciando quindi che il vero errore – quello dettagliato compaia solo sul server almeno fintanto che non si vanno a modificare le impostazioni.

Infatti vi sarete accorti che, seppur avete la vostra sezione nel web.config correttamente impostata, migrando il vostro sito sotto IIS7, questa ha smetto misteriosamente di funzionare. In realtà nulla di misterioso; è solo opera di questa nuova impostazione presente nel nuovo server web Microsoft.

Come modificare l’IIS7 detailed error per mostrare i Custom Errors.iis7-errorpages-actions.jpg

Questa caratteristica di cui ho accennato è una caratteristica modificabile per ogni singolo sito presente nel vostro IIS7. Una volta entrati nello snap-in amministrativo, cliccate su Error Pages.

iis7-errorpages-featuresettings.jpgVi verrà mostrata la lista degli errori gestiti da IIS, tra cui il più comune 404, gestiti con una semplice pagina statica presente di default nel vostro server. Se ponete l’attenzione sulla parte destra dello schermo (nelle Actions), troverete ad un certo punto un Edit Feature Settings.

Cliccando su questo tasto, si presenterà questo ulteriore pannello di configurazione, riportato nell’immagine qua accanto.

Non dovete far altro che spostare il pallino dalla terza opzione – default – su Custom Error pages, ripristinando il funzionamento delle Custom Error pages così come indicato nel file web.config.

Ricordatevi che, in ogni caso, i Custom Error nel web.config, funzionano solo ed esclusivamente per le pagine con estenzione .aspx o cmq quelle gestite dal framework.
Per tutte le altre pagine, la gestione degli errori passa dentro una pipe diversa gestita direttamente da IIS e non dal framework, quindi se vi state avvicinando per la prima volta al framework e ad IIS7, non iniziate a parlare subito male di Microsoft dicendo che rilascia prodotti che non funzionano.

IIS6 è stato il server web più sicuro di tutto il 2006-7 se non erro, e il nuovo IIS7 è il suo degno successore.

L’errore 404 in ASP.Net e IIS

Dopo un precedente articolo sull’errore 404 lato SEO, oggi parlo dell’errore 404 lato ASP.Net e IIS. Il perchè bisogna configurarlo l’ho spiegato nell’articolo sopra citato, come configurarlo nell’ambiente Microsoft lo faccio ora.

imageEsistono due modi, complementari, per configurare l’errore 404 in ASP.Net /IIS6. Complementari perchè uno non esclude l’altro.

Data l’architettura del framweork, una volta che la richiesta giunge al server, questa a seconda dell’estenzione che il file richiesto ha, può subire un dirottamente all’interno della pipeline.

I file statici, quindi i file .htm e .html (ma anche i .css e tutte le immagin) verranno smistati automaticamente verso l’handler che si preoccupa di gestire i file statici (StaticFileModule), mentre i file con estenzione .aspx verranno gestiti dall’handler aspnet_isapi.

imageDati questi due percorsi differenti, ne consegue che qualora venga inoltrata una richiesta per una risorsa non esistente sul server di destinazione, la risposta 404 procederà per due vie completamente distinte.

Quella dei file statici verrà inoltrata direttamente ad IIS, il quale ritornerà al client la pagina associata al codice di errore 404 configurata all’interno della proprietà del sito.

Di default viene restituita una pagina brutta e asettica come quella che si vede qui sopra, ma agendo nelle proprietà di configurazione del sito si può impostare un qualsiasi tipo di risorsa, anche appartenente ad un altro sito web.

image

Nel caso di una risorsa .aspx non trovata, le cose sono leggermente diverse.

A preoccuparsi di restituire una pagina d’errore è lo stesso framework.

Ovviamente, di default, la gestione delle pagine non trovate non è abilitata, e nel caso viene mostrata una pagina d’errore (per alcuni) più criptica e sempre antiestetica.

image

Per poter abilitare la gestione delle pagine non trovate, in questo caso bisogna agire all’interno del file Web.Config, andando a creare, laddove non esista già, una sezione CustomErrors.

Un esempio può essere come quello qui sotto:



In questo caso, il framework reindirizzerà la richiesta verso il file statico 404.html. Nulla vieta di mettere una pagina con estenzione .aspx che faccia del lavoro per noi, tipo mandare une e-mail all’amministratore del sito, piuttosto che registrare degli eventi in un file di log, ecc.

Medesimo discorso vale anche per la configurazione del Custom Error statico. Impostando una risorsa di tipo URL si può specificare un percorso assoluto e rimandare il tutto ad una pagina dinamica, con il vantaggio che si potrà creare una sola pagina e gestire in entrambe i casi il problema della risorsa non trovata.