Analisi dei cambiamenti dei link del sito durante una migrazione

Crea la mappa dei redirect prima del lancio

La mappa dei redirect è la parte di una migrazione che le persone sottovalutano. Le destinazioni sono le più importanti. Prima di analizzare i dati dei link del sito dopo una migrazione, i vecchi URL devono avere una destinazione chiara, perché quelli sono gli indirizzi a cui i tuoi link puntano già.

Uno-a-uno batte il dump nella homepage

Inviare centinaia di vecchi URL non correlati alla homepage dice molto poco ai motori di ricerca e ai visitatori. La rilevanza è il test. Mappa ogni vecchio URL ad alto valore alla sua pagina nuova più vicina, e invia il resto a una sezione che corrisponde ancora al loro argomento.

Esporta prima i vecchi URL con i loro codici di stato. Tieni quel file al sicuro. Quel file è la checklist, e mostra quali pagine hanno guadagnato i link.

Dove una pagina non ha una corrispondenza stretta, indicarlo nella mappa e inviarla alla sezione più vicina, con una nota. Le celle vuote nascondono le scelte. Una cella vuota nella tabella è una decisione non presa da nessuno.

Appiattisci le catene prima del lancio

Un redirect che passa attraverso due regole precedenti prima di raggiungere la pagina nuova aggiunge ritardo e rischio. Le catene sono facili da creare quando una seconda migrazione si sovrappone alla prima, quindi rivedi la mappa prima di ogni passaggio piuttosto che assumere che sia ancora pulita. Ogni salto extra ha un costo. Richiedi ogni vecchio URL una volta dopo il passaggio e conferma che risponde con un singolo salto.

Risolvi presto. Risolvi le catene nella mappa stessa, non una alla volta dopo il lancio, così la lista rimane breve.

Mantieni i percorsi che funzionano ancora

Modificare la struttura degli URL in un redesign è la perdita più evitabile. Ogni cambiamento a un percorso è anche un cambiamento a ogni link che punta ad esso, e quei link sono fuori dal tuo controllo. Mantieni ciò che funziona. Se un percorso funziona ancora, mantienilo, e cambia solo ciò che la migrazione ti costringe a cambiare.

Meno redirect, meno errori. Ogni percorso che mantieni è un link che non ha mai avuto bisogno di un redirect.

Un percorso mantenuto significa che le vecchie righe anchor continuano a puntare da qualche parte di utile, il che è una cosa in meno da ricostruire nel foglio. Meno ricostruzione in seguito.

Cosa aspettarsi dopo

Fanno il lavoro pesante, e un 301 dal vecchio al nuovo URL permette ai vecchi link di continuare a funzionare. Mantenere un redirect per vecchio URL, senza catene in mezzo, è il modo più semplice per mantenere intatto il valore di ogni link. Redirect. Le catene di tre o quattro salti rallentano i crawler e sono meglio appiattite.

L'anchor text non cambia quando un URL si sposta, perché il testo vive nella pagina che linka. Ciò che cambia è il conteggio delle destinazioni: la tua tabella delle pagine top mostrerà il vecchio host che svanisce e quello nuovo che sale nel corso di alcuni aggiornamenti mensili. Le destinazioni si spostano lentamente.

Un comune sorpresa è eliminare la vecchia piattaforma troppo presto. Non farlo. Squarespace, Wix e host simili spesso mantengono le regole di redirect, quindi cancellare il piano può rimuoverle, e i link puntano quindi a un vicolo cieco finché non ricostruisci le regole altrove.

Hreflang e canonical meritano anche un'occhiata. Le discordanze sono comuni. Dopo una migrazione da CRA a Next.js, ad esempio, i siti spesso finiscono con tag canonical che discordano dai loro set hreflang, e i link si dividono su due versioni di una pagina.

Se i numeri discordano dopo la migrazione, controlla la tabella di troubleshooting prima di assumere che i link siano stati persi. Un singolo aggiornamento mensile spiega molte lacune. Le lacune sono spesso dovute ai tempi.

Prevedi il primo confronto pulito circa due aggiornamenti mensili dopo il lancio, e scrivi la data di ogni aggiornamento nel tuo foglio così un mese piatto non sia scambiato per uno bloccato. Dagli tempo. Ahrefs o Semrush possono colmare la lacuna con crawler più freschi se hai bisogno di una lettura intermedia.

Osserva cosa si sposta senza un avviso di lancio

Il giorno del lancio ha una checklist, ma diversi problemi arrivano più tardi e silenziosamente. Si presentano nelle righe e nell'indice, molto tempo dopo che il team si è concentrato su altri lavori. Sono facili da perdere.

Noindex che viaggia con una build di staging

Una copia di staging che è stata tenuta fuori dalla ricerca può portare le sue impostazioni nel sito live. Controlla i meta tag robots e qualsiasi header noindex sul primo crawl, e campiona pagine da ogni sezione piuttosto che solo dalla homepage. Campiona ogni sezione.

I template si rompono per primi. Se un'intera sezione cade dall'indice dopo il lancio, guarda il suo template prima di guardare il suo contenuto.

Gli screenshot aiutano anche. Tieni una copia delle impostazioni robots dalla build di staging. Quando qualcosa cade dall'indice, confrontare le due impostazioni richiede minuti invece di un pomeriggio.

Link frammentati che vengono indicizzati

Link di salto come un anchor del sommario possono apparire come URL separati nei risultati di ricerca. I motori di ricerca di solito li raggruppano nella pagina principale, ma quando non lo fanno, lo stesso contenuto può apparire sotto diversi indirizzi. Dividono i segnali dalla pagina principale, e possono sembrare pagine duplicate in un rapporto di copertura. Gli URL con hash si moltiplicano silenziosamente.

Una versione, un indirizzo. Un tag canonical che punta a un indirizzo mentre la sitemap ne elenca un altro invia segnali misti, e il rapporto mostrerà la discordanza. Imposta una versione canonical per ogni pagina e conferma che la sitemap elenchi la stessa versione.

Controlla il rapporto di copertura dopo il lancio per gli URL con un hash in essi, perché quelli sono quelli che si moltiplicano silenziosamente. Gli hash sono i colpevoli.

Un sottodominio che diventa il dominio principale

Spostare un sito da un sottodominio di staging al dominio principale porta duplicati di per sé, perché entrambe le versioni possono rimanere raggiungibili per un po'. Decidi quale host è canonical prima del lancio. Scegli l'host presto.

Un host, ovunque. Quando un host cambia in un posto e non in un altro, la versione più vecchia può continuare a raccogliere link per mesi senza che nessuno se ne accorga. Poi mantieni la sitemap, i tag canonical e qualsiasi set hreflang che punta a quell'unico host.

Link do-follow che sembrano svanire

Dopo un redesign, le righe do-follow in uno strumento possono diminuire drasticamente, e il primo sospetto è che i link siano scomparsi. Confronta le vecchie pagine top con le nuove prima di accettare quel sospetto, poi controlla se ogni vecchio indirizzo ora reindirizza correttamente. Controlla prima di farti prendere dal panico.

Risolvere quello prima. Un link che esiste ancora nella pagina linkante ma punta a un indirizzo morto è il caso da risolvere per primo.

Imposta la data presto. Dai al team una data fissa per il confronto, così nessuno riesegue l'estrazione ogni giorno e legge il rumore come notizia.

Lavorare con uno sviluppatore durante la migrazione

La maggior parte del lavoro di redirect spetta a uno sviluppatore, e il monitoraggio spetta a chi legge il foglio. Scrivere la divisione come una breve tabella, con un nome in ogni cella, è spesso sufficiente per evitare che due persone assumano la stessa attività. Dividi quei ruoli su carta prima del lancio, così nessuno assume che l'altro stia controllando. I ruoli hanno bisogno di nomi.

Dai allo sviluppatore una mappa, non un elenco di attività

Un elenco di attività dice a uno sviluppatore cosa fare, mentre una mappa mostra quale vecchio indirizzo va dove. Invia la tabella uno-a-uno con i codici di stato e il motivo per ogni riga, così i casi limite ricevano una decisione piuttosto che un'ipotesi. Le decisioni battono le ipotesi.

I piani di test vengono per primi. Chiedi un breve piano di test che inizi con i vecchi indirizzi dal file delle pagine top.

Accorda chi legge il file mensile

Il primo confronto pulito arriva circa due aggiornamenti dopo il lancio, e il file avrà bisogno di un lettore. La prima lettura dopo il lancio è solitamente rumorosa, e un lettore che lo sa eviterà di reagire a un singolo mese insolito. Nomina quella persona, il giorno in cui lo apre, e il foglio dove va il risultato. Qualcuno deve esserne proprietario.

Le date risolvono la domanda. Scrivere la data di aggiornamento accanto a ogni file trasforma una preoccupazione per un indice bloccato in un semplice fatto sul calendario. Un mese piatto è facile da leggere male come uno bloccato a meno che qualcuno non scriva le date di aggiornamento.

Chiedi a quella persona di scrivere una riga per ogni aggiornamento, anche quando non è cambiato nulla, così il file mantenga un record continuo. Una riga ogni volta.

Pianifica il rollback prima del lancio

Se il nuovo host rompe un percorso critico, il team ha bisogno di un modo per tornare indietro che sia stato testato in anticipo. Scrivi i passaggi, incluso chi può azionare l'interruttore e come si comportano i redirect mentre viene annullato. Esercitati prima del lancio.

Scrivi il rollback. Un rollback che esiste solo nella testa di una persona non è un piano.