Gestire una migrazione lato SEO

Ultimo aggiornamento 19 Aprile 2024

Oggi scrivo di progetti web che migrano da un sito web ad un’altro senza necessariamente cambiare server. “Semplicemente” mi riferisco al passaggio da una versione ad un’altra più recente ed evoluta.

Spesso un sito internet viene rifatto quando la vecchia struttura è diventata troppo intricata e ridondante, quando il il CMS è obsoleto e/o non aggiornabile, o ancora quando per motivi di comunicazione si vuole svecchiare un brand o comunque dargli un’immagine diversa. Tuttavia quali che siano i motivi per cui si procede alla migrazione avrai fatto caso sulla tua pelle o anche solo per sentito dire, che anche a fronte di reindirizzamenti fatti bene, a volte il sito nuovo performa (si posiziona) meglio del vecchio, altre volte precipita nell’oscurità. E quindi?

Perché (quando) le migrazioni sono una scommessa?

In poche parole: fai anche un bel lavoro di accorpamento dei contenuti ridondanti consolidandone il segnale su meno pagine tutte diverse e significative, ma questa è ancora la SEO che si vede.

Distribuisci meglio i contenuti nelle aree (menu) di navigazione e rimuovi dalle pagine i link su cui gli utenti non cliccano sistematicamente, ma nemmeno questa pratica ti garantisce che la nuova versione venga “masticata” meglio di quella vecchia. Se vuoi smettere di vivere nel terrore devi solo alzare il cofano e guardare le righe di codice, perché spesso è là che si nascondono le insidie. È la SEO più pura, quella che non si vede.

Analisi dei percorsi di scansione:

Occorre fare un match tra vecchia e nuova versione del sito web. Per il match utilizzo Screaming Frog e in particolare comparo diversi output. Nei test che faccio tengo conto di una quarantina di parametri. Di seguito ne trovi 8 tra i più importanti:

Funzioni di navigazione interna con/senza javascript

I menu richiamati mediante javascript rischiano di essere invisibili per gli utenti che bloccano le risorse di tipo .js mediante il browser o che utilizzano plugin per bloccare la visualizzazione delle pubblicità. Questo non significa che i link serviti come javascript siano una cosa sbagliata, ma quelli ritenuti prioritari vanno sempre serviti come url espliciti nel codice sorgente.

Numero di righe di codice per pagina

La nuova versione si presenta pulita e funzionale, ma se a parità di caratteristiche il vecchio tema aveva mediamente 1.000 righe di codice per pagina e il nuovo circa 40.000, il nuovo tema ha decisamente qualcosa che non va. Per constatarlo non serve nemmeno Screaming Frog.

Numero totale dei percorsi interni espliciti per pagina

I percorsi espliciti – quelli cliccabili dal sorgente – non sono sempre solo link verso altre pagine con un loro output html, ma talvolta (spesso) sono file .css, immagini o appunto file .js. Bloccare mediante robots.txt certe risorse è sbagliato perché Google deve poter seguire tutto quello che c’è, altrimenti non ha senso che i percorsi esistano, quantomeno espliciti.

Da cui la domanda: a parità di caratteristiche, la nuova versione del sito web presenta più o meno percorsi espliciti nel codice sorgente?

Presenza di percorsi HTTP2

Il protocollo http2 consente il caricamento in parallelo degli elementi di una pagina su una singola connessione. Detto in parole povere, questo protocollo consente una scansione più veloce proprio quando ci sono più file (ad esempio) .css con poche righe di codice ciascuno.

In presenza di percorsi con protocollo http2 è meglio non consolidare più file in uno solo accorpandone il codice, come invece suggeriscono spesso di fare software di analisi tipo GTMetrix. Qui c’è da tenere gli occhi aperti.

Pagine canoniche e canonicalizzate

Questa è una valutazione troppo importante per essere lasciata al plugin SEO o al tema in sé. L’attributo rel=canonical del tag <link> serve a consolidare i segnali di pagine che comunque pesano sulla scansione, quindi occorre fare scelte precise a seconda dei casi. Si tratta di un controllo SEO che va fatto a prescindere dalla migrazione.

Presenza di percorsi che reindirizzano ad altri (e come)

I reindirizzamenti non sono tutti uguali. Premettendo che sarebbe sempre meglio tenere nel codice sorgente i percorsi finali e non quelli che vengono reindirizzati, vediamo che oltre i classici 3XX, ci sono i redirect scritti in javascript e il tag meta refresh. In linea di massima preferisco utilizzare sempre e solo i primi. Piuttosto fai molta ATTENZIONE alle catene di redirect che spesso conseguono a più migrazioni. Generano loop di reindirizzamento che pesano davvero tanto sulla scansione.

La compressione è abilitata dove appropriato

Chi lavora sulle performance, soprattutto in ambito e-commerce studia continuamente misure per risparmiare anche spazi dell’ordine delle decine di kb. Una buona compressione, accompagnata da minificazione del codice e cacheing laddove opportuno è un passaggio importante e sottovalutato, spesso per insipienza.

Markup schema

Infine e considerando che spesso utilizziamo i dati strutturati forniti dal tema senza approfondire né sapere cosa stiamo comunicando a Google, sarebbe opportuno dare uno sguardo ad eventuali differenze tra la marcatura semantica della vecchia versione e quella della nuova mediante lo strumento test per i dati strutturati. Ci sono errori? Ci sono dati inopportuni? Lo sai che Google lancia azioni manuali verso siti web che non marcano adeguatamente le pagine dei propri siti?

Conclusioni

Fare tutti questi controlli garantisce che la nuova versione del sito web si posizioni meglio su Google e non sprofondi? No, non lo garantisce.

Semmai non li fare e incrocia le dita. Magari ti dice bene.