Il sito ha perso traffico dopo il restyling: come si capisce dove è finito

Il sito nuovo è più bello, più veloce, finalmente aggiornato. E dopo qualche settimana i numeri di Google scendono. La reazione istintiva è pensare a una penalizzazione, o a un aggiornamento dell’algoritmo, o a un difetto della piattaforma appena scelta.

Quasi sempre non è niente di tutto questo. È che il sito vecchio è stato spento senza portarsi dietro i suoi indirizzi.

Questo è il racconto di un caso reale, arrivato da noi a fine luglio. Un e-commerce artigianale italiano, con una parte di vendite all’estero, aveva cambiato piattaforma a inizio anno e da allora vedeva il traffico scendere senza spiegazioni. Il cliente era convinto che il problema fosse il negozio nuovo. Non lo era.

Come si presentava

Il dato che aveva portato alla chiamata era questo, preso da Google Analytics sulla finestra mobile a trenta giorni:

• Inizio gennaio: 820 utenti attivi, il massimo dell’anno
• Metà febbraio: circa 220, cioè meno 72% in cinque settimane
• Fine luglio: 304, mai più tornato sopra quota 325

Un calo del 63% rispetto al picco, e soprattutto un calo che non recupera. La caduta coincide con il periodo in cui il negozio nuovo è andato online.

Quando il crollo è così ripido e così legato a una data, l’ipotesi “contenuti deboli” o “aggiornamento dell’algoritmo” si può mettere da parte quasi subito: quelle cose fanno curve lente. Una discesa a gradino, subito dopo una migrazione, ha quasi sempre una causa strutturale.

La causa: tre cose lasciate indietro, tutte insieme

Il sito nuovo era tecnicamente in ordine. Canonical corretti e autoreferenziali su tutti i template, hreflang coerenti e reciproci, HTTPS ovunque, sitemap valida senza URL morte, nessuna differenza fra quello che vede il browser e quello che vede Google. Chi lo aveva costruito aveva fatto un lavoro pulito.

Il problema stava tutto fuori dal sito nuovo.

Il negozio precedente non era mai stato spento. Viveva ancora su un sottodominio dello stesso dominio, su un altro hosting, in parte funzionante e in parte in errore. Search Console segnalava 789 pagine in errore server, tutte quante su quel sottodominio e nessuna sul sito nuovo. Per Google era lo stesso dominio: una quota enorme del patrimonio di scansione veniva spesa su un negozio abbandonato che rispondeva male, e chiunque arrivasse lì da un vecchio link o dai preferiti trovava un sito rotto invece del negozio attuale.

La migrazione aveva coperto solo l’ultimo trasloco. Il dominio aveva cambiato tecnologia due volte in pochi anni. I redirect configurati erano tantissimi, oltre duemila, ma il 99,9% copriva soltanto il passaggio più recente. Della fase ancora precedente non era rimasto niente: su 135 indirizzi storici verificati uno per uno, 128 rispondevano 404 secco, e fra questi c’erano le pagine istituzionali, quelle che raccoglievano la rassegna stampa e tutte le pagine di categoria nella loro forma vecchia. Erano gli indirizzi che i siti esterni avevano linkato negli anni.

Un intero mercato estero era sparito senza sostituzione. La versione del sito in una delle lingue straniere era stata rimossa insieme alla vecchia piattaforma, senza un solo redirect. Tutto quello che quel mercato aveva guadagnato in anni di posizionamento e di link puntava nel vuoto.

C’era anche un difetto più sottile: di quei duemila redirect esistenti, il 3,3% portava a pagine che nel frattempo erano state rinominate o eliminate. Un redirect che atterra su un 404 non è meglio di un 404.

Perché nessuno se ne era accorto prima

Perché niente di tutto questo si vede guardando il sito.

Le pagine morte non stanno nel menu, non compaiono nelle statistiche delle pagine più viste, non danno errore a chi naviga il negozio nuovo. Esistono solo in due posti: nella memoria di Google e nei link che altri siti hanno pubblicato negli anni. Per accorgersene bisogna andare a cercarle, e nessuno le cerca se non sospetta che ci siano.

Il metodo per trovarle è quello del punto 3 della checklist di analisi SEO: si esporta da Search Console l’elenco delle pagine che hanno ricevuto impressioni, si verifica lo stato di ognuna, e si guarda l’archivio storico del dominio per recuperare gli indirizzi delle versioni precedenti del sito. In questo caso l’archivio è stato decisivo, perché la fase più vecchia non compariva più da nessuna altra parte.

La soluzione che abbiamo adottato

Due giornate di lavoro, il 30 e il 31 luglio, in questo ordine.

Prima il sottodominio, perché era la causa più pesante. La scelta non è stata spegnerlo ma ripuntarlo: il vecchio indirizzo è stato fatto puntare alla piattaforma nuova, che da lì in poi risponde con un redirect permanente conservando il percorso richiesto. Così un link di dieci anni fa arriva ancora nel punto giusto invece di finire su una home generica.

Qui c’è il dettaglio tecnico che ha sbloccato tutto, e che vale la pena raccontare perché fa perdere giornate a molti. Il certificato di sicurezza per quel sottodominio non veniva emesso, e restava in attesa da più di ventiquattr’ore senza un errore chiaro. Il motivo: nel DNS era stato aggiornato l’indirizzo IPv4, ma era rimasto anche il vecchio record AAAA, cioè l’indirizzo IPv6, che puntava ancora al server dismesso. Le autorità che emettono i certificati preferiscono l’IPv6 quando c’è: ogni tentativo di validazione finiva sul vecchio server e falliva. Tolto quel record, il certificato è stato emesso in pochi minuti.

Poi i percorsi, perché il redirect del sottodominio da solo non basta. Conservare il percorso è la cosa giusta da fare, ma serve che quel percorso esista anche sul sito nuovo, e lì non esisteva: su un campione di controllo, il 100% degli indirizzi storici finiva comunque su un 404. Abbiamo quindi creato 776 redirect per gli 788 indirizzi del vecchio negozio, e in un secondo passaggio ne abbiamo affinati 78 che atterravano su una destinazione troppo generica.

La mappatura non è stata fatta a mano. L’ultimo pezzo di ogni vecchio indirizzo corrisponde quasi sempre all’identificativo della pagina nuova, quindi si automatizza: normalizzando le maiuscole e recuperando anche gli identificativi tradotti in inglese, la corrispondenza automatica è passata dal 40% all’86%. Il resto è stato deciso a mano.

Prima di creare quei redirect abbiamo verificato tutti i 570 indirizzi di destinazione, uno per uno, controllando che rispondessero davvero. È il passaggio che sul sito non era stato fatto in passato, ed è il motivo per cui una parte dei redirect già esistenti puntava a pagine sparite.

I prodotti non più in catalogo non vanno in home. Google tratta quel tipo di redirect come un errore mascherato, oltre a essere inutile per chi clicca. Sono stati mandati alla categoria di appartenenza, ricostruita risalendo il percorso o per somiglianza di linea e misura.

Poi le URL della fase ancora precedente, quella più vecchia: 102 redirect uno per uno, dalle pagine istituzionali alle vecchie categorie. Sedici indirizzi di PDF e immagini d’archivio sono stati esclusi di proposito, perché valevano poco e avrebbero solo allungato la lista.

Poi i redirect già esistenti che erano rotti. I casi sospetti sono stati riverificati con calma, uno alla volta e con una pausa fra una chiamata e l’altra, perché sotto raffica il sito rispondeva con un errore di traffico eccessivo e generava falsi allarmi. Di 72 sospetti, 36 erano rotti davvero e sono stati corretti; gli altri 36 erano falsi positivi.

Infine il mercato estero. Questa non era una decisione tecnica ma commerciale, e l’ha presa il cliente: per ora quella lingua non verrà ripristinata. I suoi indirizzi sono stati mandati alla versione inglese, che resta attiva, con nove redirect mirati e non un rimando generico alla home. Per strada è saltato fuori anche un terzo prefisso di lingua, usato anni prima per un altro mercato e dimenticato da tutti: ventisei indirizzi, mappati anche quelli.

Alla fine il negozio ha 3.077 redirect attivi. La verifica finale su un campione end-to-end, partendo dai vecchi indirizzi, ha dato venti risposte valide su venti: quattordici sulla scheda esatta, cinque sulla categoria pertinente, nessuna sul catalogo generico.

Tre criteri hanno guidato tutto il lavoro, e valgono per qualsiasi migrazione.

Uno a uno finché ha senso. Ogni indirizzo vecchio va sulla pagina che risponde alla stessa domanda. La home è l’ultima spiaggia, non la scorciatoia: chi arriva da un vecchio link cercava una cosa precisa, e se non la trova torna indietro.

Un solo salto. Mai un redirect che porta a un altro redirect. Le catene si formano da sole con gli anni e ogni anello disperde valore e aggiunge attesa.

Verificare le destinazioni prima, e il risultato dopo. Sono due controlli diversi e servono entrambi. Il primo evita di creare redirect verso pagine che non esistono, il secondo conferma che chi arriva da fuori atterra dove deve.

Cosa resta fuori da questo lavoro

Onestà: i redirect non risolvono tutto. Nello stesso audit è emerso un problema diverso e indipendente, cioè un gruppo di pagine attuali del catalogo che Google conosce ma non ha indicizzato. È un tema di qualità e di struttura del contenuto, non di migrazione, e si affronta separatamente.

Serve dirlo perché il recupero da una migrazione fatta male riporta indietro quello che era già stato guadagnato. Non è una strategia di crescita, è una riparazione.

È un controllo che facciamo anche su di noi. Sul nostro sito, rifatto di recente, la stessa verifica ha trovato 191 pagine su 292 che rispondevano 404: le abbiamo chiuse tutte in tre giorni di lavoro. È il motivo per cui questo controllo sta al terzo posto della nostra checklist e non in fondo.

Cosa fare se stai per rifare il sito

Il momento in cui questo lavoro costa meno è prima, non dopo.

Esporta da Search Console l’elenco delle pagine che ricevono impressioni prima di spegnere il sito vecchio, e conservalo. Se il sito è già spento, l’archivio storico del web recupera buona parte degli indirizzi, ma è lavoro in più.

Se il dominio ha già cambiato tecnologia in passato, risali di un passaggio in più. La migrazione di oggi si porta dietro anche i debiti di quella di ieri, e nessuno se li ricorda.

Prepara la mappa dei redirect insieme alla nuova struttura, non dopo il lancio. E il giorno del lancio verifica un campione dei vecchi indirizzi: non tutti, i venti che valgono di più.

Infine, controlla che il vecchio sito sia davvero spento. Non “non più aggiornato”: spento, o rimandato al nuovo.

Cosa portarsi a casa

• Un crollo a gradino subito dopo una migrazione ha quasi sempre una causa strutturale, non di contenuti.
• Il sito nuovo può essere tecnicamente impeccabile e il traffico crollare lo stesso. Le due cose non si escludono.
• Se il dominio ha cambiato piattaforma più volte, i redirect vanno controllati per ogni passaggio, non solo per l’ultimo.
• Un vecchio negozio lasciato acceso su un sottodominio pesa sull’intero dominio. Meglio ripuntarlo al sito nuovo conservando il percorso, che spegnerlo e basta.
• Un redirect va verificato due volte: la destinazione prima di crearlo, il risultato dopo. Una parte di quelli già esistenti puntava a pagine sparite.
• Se un certificato di sicurezza per un sottodominio resta in attesa per ore senza un errore chiaro, controlla il record AAAA e non solo l’indirizzo IPv4.
• Quello che si recupera è ciò che era già stato guadagnato. Le migrazioni non si riparano del tutto, si riparano in tempo.

Domande frequenti

Se ti riconosci in questa situazione, il controllo delle vecchie URL è il primo passo del nostro audit digitale, e serve a stabilire due cose: se il problema è questo, e quali pagine vale la pena recuperare. Se invece il sito lo devi ancora rifare, la continuità degli indirizzi è parte di come impostiamo i progetti web e la roadmap digitale, non un rattoppo da fare dopo il lancio.

Se vuoi che ne parliamo, scrivici.