Ho comprato un dominio di 25 anni: 1.000+ richieste al giorno finivano su URL morti

Ho comprato un dominio registrato per la prima volta nel 2000. Sulla carta, quella storia sembrava quasi un vantaggio. Poi ho pubblicato il nuovo sito e i log del server hanno iniziato a riempirsi di richieste verso pagine che non avevo mai creato.

Più di 1.000 richieste al giorno colpivano URL inesistenti nel nuovo progetto. Negli analytics appariva come un forte picco di direct traffic con engagement quasi nullo. Nello stesso periodo il crawler di Yandex tornava su vecchi percorsi, riceveva 404 Not Found e Yandex Webmaster ha accumulato più di 900 errori in una sola notte.

La mia prima spiegazione era semplice: vecchi bot colpiscono URL morti, Yandex vede quell’attività e quindi continua a scansionarli. È così che la sequenza appariva dal mio punto di vista. Ma i miei dati non bastavano a dimostrare quel rapporto causale.

Quello che potevo davvero confermare

C’erano tre osservazioni separate. Primo, il server riceveva un volume elevato di richieste a URL appartenuti alla vita precedente del dominio. Secondo, quel traffico non produceva praticamente alcun engagement reale. Terzo, anche il crawler di Yandex richiedeva vecchi percorsi e il pannello Webmaster mostrava oltre 900 errori in una notte.

Operativamente era un problema reale: log rumorosi, richieste inutili e report da ripulire. Ma questi fatti non dimostrano che i bot di terze parti abbiano causato il crawl di Yandex, né che gli errori abbiano danneggiato direttamente ranking o traffico organico. Crawling non significa indicizzazione, indicizzazione non significa ranking e un report di errori non è la prova di una penalizzazione.

La parte che avevo semplificato troppo: 404 e 410

All’inizio ragionavo così: 404 significa “forse manca solo adesso”, 410 significa “è sparito per sempre”. Come intuizione è utile, ma tecnicamente non è precisa.

404 Not Found significa che il server non può fornire una rappresentazione corrente della risorsa richiesta; il codice da solo non dice se la situazione sia temporanea o permanente. 410 Gone è più specifico: è adatto quando il server sa che la risorsa non è più disponibile e che la condizione è prevista come permanente.

La distinzione conta anche quando si parla di SEO. I motori di ricerca possono rimuovere URL che restituiscono sia 404 sia 410. Per questo oggi non descrivo più 410 come uno status magicamente “più forte per la SEO”, né considero 404 sbagliato in assoluto per le pagine eliminate.

Perché i 410 mirati avevano comunque senso nel mio caso

I vecchi percorsi non erano un guasto temporaneo. Appartenevano ai contenuti precedenti del dominio e non avevano alcun ruolo nel nuovo progetto. Sapevo che quegli URL specifici erano spariti in modo permanente. In quel contesto, 410 Gone descriveva correttamente il loro stato.

Ho quindi configurato risposte 410 solo per i percorsi legacy conosciuti, invece di trasformare qualsiasi URL sconosciuto in 410. Dopo il cambiamento, il rumore di crawl e reporting attorno a quei percorsi si è ridotto e la situazione negli strumenti per webmaster è diventata molto più pulita.

Resto però prudente sulla causalità. Posso dire che il miglioramento è arrivato dopo il cambio e che 410 rappresentava correttamente lo stato degli URL. Non posso dimostrare che il solo 410 abbia fermato ogni bot. Un bot di terze parti può ignorare il significato dello status HTTP e continuare a richiedere lo stesso percorso all’infinito.

La regola decisionale che uso oggi

La domanda utile non è “410 è meglio di 404?”, ma “che cosa è successo davvero a questo URL?”

• Esiste un sostituto chiaro: usare un redirect permanente, come 301, verso il nuovo URL davvero equivalente.
• La vecchia risorsa è stata rimossa definitivamente e non ha sostituti: 410 Gone è una scelta precisa.
• L’URL è semplicemente sconosciuto, contiene un errore o non è mai esistito: un normale 404 Not Found è appropriato.

Eviterei invece di redirigere ogni URL morto alla home solo per far sparire gli errori. Nasconde lo stato reale della risorsa e può creare un’esperienza peggiore sia per gli utenti sia per i crawler.

Come controllerei oggi un dominio vecchio prima del lancio

Se riutilizzassi un dominio con una storia, tratterei la sua storia degli URL come parte della migrazione anche se non stessi migrando il vecchio sito.

1. Esaminare l’impronta precedente. Cercare URL storici e sezioni legacy evidenti prima del lancio.
2. Guardare gli access log dal primo giorno. Richieste ripetute a percorsi che non hai mai creato mostrano che il dominio conserva ancora una memoria esterna.
3. Separare persone, crawler dei motori di ricerca e bot casuali. Un picco di direct traffic e un errore del crawler sono segnali diversi e non vanno fusi automaticamente in un’unica causa.
4. Classificare gli URL morti ricorrenti. Per ogni pattern importante decidere consapevolmente tra 301, 404 e 410.
5. Monitorare i risultati separatamente. Frequenza delle richieste, report dei crawler e indicizzazione sono dimensioni diverse; non le ridurrei a una vaga metrica di “salute SEO”.

È poco lavoro rispetto a scoprire il problema quando log e strumenti per webmaster sono già pieni di rumore.

Che cosa 410 non risolve

410 è una dichiarazione HTTP sullo stato di una risorsa. Non è un firewall, un rate limiter o un meccanismo di blocco dei bot. Se uno scraper continua a inviare richieste dopo aver ricevuto 410, il server deve comunque riceverle e rispondere. Se il vero problema è un volume abusivo di richieste, quella è una questione infrastrutturale separata.

Non è nemmeno un boost SEO. Restituire lo status corretto aiuta un crawler a capire che cosa è successo a un URL; da solo non fa salire il nuovo sito nei risultati.

La lezione che mi è rimasta

La sorpresa non era che un dominio vecchio avesse vecchi URL. Era la velocità con cui quella storia invisibile è tornata visibile dopo il lancio: più di 1.000 richieste al giorno verso pagine che io non avevo, engagement quasi nullo e oltre 900 errori in Yandex Webmaster in una notte.

Un dominio vecchio non è un namespace vuoto. Link, crawler, script e bot possono ricordare percorsi per anni dopo la scomparsa dei contenuti originali. La mia regola oggi è semplice: controllare quella storia, restituire lo status che corrisponde alla realtà e tenere separato il traffico operativo dei bot dalle conclusioni sui motori di ricerca.

La storia può essere un asset. È anche stato che erediti.