Quando un 410 è meglio di un 404 (e come si implementa davvero)

Il 410 non è un 404 "più arrabbiato"

Nel nostro articolo su 301 contro 404 il 410 compariva in una riga della lista delle decisioni, come alternativa più forte al 404 per i contenuti spariti per sempre. Merita però una spiegazione a sé, perché è l'unico dei quattro codici (301, 302, 404, 410) che richiede una certezza, non solo un'osservazione. Un 404 è quasi sempre il default automatico di un server o di un'applicazione quando qualcosa non risponde: nessuno lo "sceglie" attivamente riga per riga, semplicemente succede quando manca una corrispondenza. Un 410 invece va sempre dichiarato apposta, con una regola scritta da chi gestisce il sito, perché comunica qualcosa che il server non può sapere da solo: non solo "qui non c'è niente adesso" (quello lo direbbe già un 404), ma "qui non ci sarà mai più niente, e lo sappiamo con certezza".

Questa differenza ha una conseguenza pratica sul comportamento dei motori di ricerca: un motore che incontra un 404 tiene comunque aperta la possibilità che l'indirizzo torni a rispondere (un errore temporaneo, un deploy a metà, un prodotto tornato disponibile) e in genere ricontrolla quell'indirizzo per un periodo prima di rimuoverlo davvero dall'indice. Un 410 è un segnale deliberato di rimozione permanente, e Google stesso ha dichiarato più volte che tende a processarlo più rapidamente per togliere l'indirizzo dai risultati, anche se in nessuno dei due casi la rimozione è istantanea. La differenza quindi non è "quanto è grave l'errore", è "quanta certezza avete che non tornerà mai più nulla a quell'indirizzo".

Quando il 410 fa davvero danno

Proprio perché il 410 comunica una certezza, usarlo quando quella certezza non c'è è l'errore più costoso dei quattro codici. I due casi tipici in cui fa danno:

• Contenuto stagionale o temporaneamente sospeso. Un prodotto fuori produzione per sempre è un buon candidato al 410. Un prodotto fuori stock che tornerà tra due mesi non lo è: un 410 scoraggia il motore di ricerca dal ricontrollare quell'indirizzo proprio nel momento in cui, tra qualche settimana, vorreste che tornasse a farlo. In quel caso lo strumento giusto resta il 404 (o, se davvero temporaneo e a data nota, un 302 verso una pagina di preavviso), non il 410.
• Regole troppo larghe. Un 410 impostato su un pattern con caratteri jolly o una condizione sulla query string va scritto con la stessa attenzione di una regola firewall: una condizione troppo generica può far scattare il 410 anche su indirizzi legittimi che condividono solo una parte del pattern, chiudendo con un errore permanente traffico vero invece del solo traffico che si voleva davvero fermare. A differenza di un 301, dove sbagliare la destinazione manda comunque il visitatore da qualche parte, un 410 sbagliato chiude semplicemente la porta, e se la porta era quella giusta il danno lo scopre solo chi ci sbatte contro.

Come funziona davvero un 410 implementato bene

Nel nostro modulo di gestione redirect il 410 si sceglie dal menu del tipo di regola, accanto a 301 e 302, e per una regola di questo tipo l'indirizzo di destinazione non serve e viene ignorato: non c'è un "dove mandare" il visitatore, solo un "qui non c'è più niente, per sempre". La parte tecnicamente interessante è il punto in cui la risposta viene generata: deve scattare il più presto possibile nel ciclo di vita della richiesta, prima che l'applicazione costruisca tema, recuperi il prodotto dal database o prepari il rendering della pagina, altrimenti si spreca comunque tutto il lavoro che un 410 dovrebbe evitare. La risposta corretta comprende tre elementi che spesso vengono dimenticati quando un 410 viene implementato "a mano" in un file di configurazione:

• Lo stato HTTP 410 Gone vero, non un 200 con un testo che dice "prodotto non disponibile" (lo stesso errore del soft 404 già visto nell'articolo precedente, che vale identico anche qui).
• Un'intestazione X-Robots-Tag: noindex, che rinforza il segnale anche per i crawler che leggono quell'intestazione separatamente dal codice di stato.
• Un corpo pagina minimo, tradotto nella lingua del visitatore, invece di una pagina vuota: un 410 è comunque una risposta che una persona vera può incontrare cliccando un vecchio link, non solo un crawler.

Un caso reale: un crawler che girava in tondo su un parametro avvelenato

Sul nostro stesso negozio un crawler (quello di Meta) girava in tondo su indirizzi del tipo /login?back=... che contenevano ancora, nel valore del parametro, il vecchio dominio del sito prima di un cambio di indirizzo: oltre 36.000 richieste in una notte, più del 90% di tutto il traffico ricevuto dal server, ognuna delle quali veniva servita con una risposta 200 e un rendering completo della pagina, cioè con lo stesso costo di CPU di una richiesta vera. Il problema non erano gli indirizzi in sé (/login è un indirizzo legittimo), era la combinazione con quel valore specifico del parametro, che nessun visitatore reale avrebbe mai prodotto.

Abbiamo verificato che una singola regola 410 con condizione sulla query string risolve esattamente questo caso, senza toccare il server web e senza toccare il traffico legittimo: la regola scatta solo quando il parametro back contiene il vecchio dominio, non su qualunque richiesta a /login. Risultato della prova, su tre versioni diverse di PrestaShop:

• /login?back=http%3A%2F%2Fvecchio-dominio.it%2Fx risponde 410
• /login?back=https%3A%2F%2Fvecchio-dominio.it%2Flogin risponde 410
• /login?back=/mio-account (traffico legittimo) continua a rispondere 200, invariato

È l'esempio più chiaro di cosa distingue un 410 fatto bene da uno fatto in fretta: la regola non dice "blocca /login", dice "blocca solo la combinazione precisa che sappiamo essere il problema", e verifica quella condizione prima di costruire una sola riga della pagina.

In sintesi

Il 404 è quasi sempre un default, il 410 è sempre una scelta deliberata, e va usato solo quando c'è vera certezza che l'indirizzo non tornerà mai. Fatto bene, è uno stato HTTP vero generato il più presto possibile nel ciclo della richiesta, con l'intestazione robots coerente e senza sprecare il lavoro che dovrebbe evitare; fatto con una regola troppo larga, può chiudere per sempre traffico che invece era legittimo. Per chi vuole gestire queste regole senza toccare la configurazione del server, un modulo come cll_seoredirect è una delle opzioni possibili, ma il criterio per decidere quando un 410 è la scelta giusta resta lo stesso descritto sopra, a prescindere dallo strumento.

Guida all'installazione e configurazione del modulo

Redirect SEO - Gestione 301/302/404 (SEO Redirects)Gestisci redirect 301/302 (plain, wildcard o regex sicure), monitora i 404 e convertili in redirect con un…49,99 €Vedi il prodotto