Elimini una scheda prodotto, cambi la struttura dei tuoi URL o migri verso un nuovo CMS. Alcune settimane dopo, Google Search Console mostra decine di errori 404. Il riflesso classico consiste nel reindirizzarli tutti alla homepage. È una falsa buona idea che crea altri problemi.
Soft 404 e 404 classico: la distinzione che cambia la tua strategia SEO
Un errore 404 classico restituisce un codice HTTP 404 (o 410) al browser e a Googlebot. Il server dice chiaramente: questa pagina non esiste più. Google comprende il segnale, rimuove progressivamente l’URL dalla sua coda di esplorazione e passa oltre.
Il vero tranello si trova altrove. Un soft 404 restituisce un codice 200 OK mentre la pagina è vuota o mostra un messaggio di errore. Dal punto di vista di Google, questo URL sembra esistere. Il robot continua quindi a visitarlo ad ogni passaggio, il che consuma inutilmente il budget di crawl.
Su un sito con alcune decine di pagine, la differenza è trascurabile. Su un catalogo e-commerce o un sito editoriale con migliaia di URL, i soft 404 accumulati rallentano l’esplorazione delle pagine che contano davvero. Prima di iniziare a correggere, la priorità è sapere come correggere un errore 404 su Google distinguendo questi due casi.
I siti costruiti con framework JavaScript (React, Vue, Angular) sono particolarmente esposti. Quando una rotta non esiste, l’applicazione mostra un messaggio “pagina non trovata” lato client, ma il server restituisce un codice 200. Google tratta questo comportamento come un soft 404, e la pagina rimane nella coda di crawl.
Ordinare i tuoi errori 404 prima di correggerli: metodo di priorità
Tutti gli errori 404 non meritano lo stesso trattamento. Un URL che non ha mai ricevuto un link esterno, mai generato traffico e che corrisponde a contenuti obsoleti può rimanere in 404 senza alcun danno SEO. Google lo conferma: i 404 legittimi fanno parte del normale funzionamento del web.
Hai già consultato il rapporto “Pagine” di Google Search Console senza sapere da dove cominciare? Ecco come classificare i tuoi 404 in ordine di priorità:
- Gli URL che ricevono ancora backlink esterni: trasmettono autorità. Senza reindirizzamento, questo capitale SEO scompare. Identificali incrociando i dati di Search Console con uno strumento di crawl.
- Gli URL che generavano traffico organico prima della loro rimozione: un reindirizzamento 301 verso la pagina più vicina in contenuto consente di recuperare parte di questo traffico.
- Gli URL derivanti da errori di battitura, bot o parametri URL errati: lasciali in 404. Reindirizzare questi URL creerebbe reindirizzamenti inutili che appesantiscono la tua configurazione server.
Prioritizza i 404 che hanno backlink o traffico storico. Il resto può aspettare, o non essere mai trattato.
Reindirizzamenti 301 e codice 410: scegliere la giusta risposta HTTP
Il reindirizzamento 301 è il riflesso predefinito. Funziona bene quando esiste una pagina equivalente sul sito. Hai rinominato una categoria o fuso due articoli? La 301 trasferisce la maggior parte dell’autorità dei link verso il nuovo URL.
Quando il reindirizzamento 301 crea problemi
Reindirizzare una vecchia scheda prodotto verso la homepage non aiuta nessuno. L’utente arriva su una pagina non pertinente alla sua ricerca, e Google finisce per trattare questo reindirizzamento come un soft 404. Un reindirizzamento 301 deve puntare verso contenuti tematicamente vicini, non verso una pagina generica.
Il codice 410 per segnalare una rimozione definitiva
Il codice HTTP 410 (Gone) indica a Google che la pagina è stata rimossa volontariamente e non tornerà. Google disindicizza questi URL più rapidamente rispetto a un semplice 404. Utilizza il 410 per le pagine prodotto rimosse definitivamente, i contenuti giuridicamente problematici o gli URL di test che non avrebbero mai dovuto essere indicizzati.
Il 410 accelera la disindicizzazione rispetto al 404 classico. Su un sito con un volume elevato di pagine rimosse, questa differenza di velocità libera il budget di crawl più rapidamente.
Pagina 404 personalizzata: trasformare un errore in navigazione utile
Anche con un lavoro di reindirizzamento rigoroso, i visitatori si imbatteranno in pagine inesistenti. Un link condiviso su un forum, un URL digitato a memoria con un errore: il 404 zero non esiste.
Una pagina 404 personalizzata non risolve il problema tecnico, ma limita la perdita di utenti. Affinché sia utile, deve offrire:
- Un campo di ricerca interno visibile immediatamente, senza dover scorrere.
- Link verso le categorie principali o i contenuti più consultati del sito.
- Un messaggio chiaro che conferma che la pagina non esiste, senza gergo tecnico.
Il punto tecnico da non trascurare: la tua pagina 404 personalizzata deve restituire un vero codice HTTP 404. Se il tuo server o il tuo CMS restituisce un codice 200 per questa pagina, crei esattamente il problema di soft 404 descritto sopra. Testa il codice di risposta con lo strumento di ispezione URL in Search Console.
Errori 404 su un sito JavaScript: verificare il rendering lato server
Le applicazioni monopagina (SPA) gestiscono la navigazione lato client. Quando un visitatore accede a una rotta che non esiste, il framework mostra un componente “errore” senza che il server intervenga. Il codice HTTP rimane 200.
Affinché Googlebot interpreti correttamente la situazione, la risposta 404 deve provenire dal server. Due approcci funzionano: il rendering lato server (SSR) che genera la pagina con il giusto codice HTTP prima di inviarla al browser, o il pre-rendering statico che produce file HTML con le intestazioni corrette.
Un messaggio “pagina non trovata” mostrato da JavaScript con un codice 200 è trattato come un soft 404 da Google. Controlla il codice di stato reale nella scheda Rete degli strumenti di sviluppo del tuo browser, o direttamente tramite Search Console.
Su un sito classico sotto WordPress o un CMS simile, questo problema di solito non si presenta: il server gestisce nativamente il codice 404. La vigilanza riguarda soprattutto le architetture decoupled (headless CMS + frontend JavaScript).
