Backlink nella migrazione del sito: un runbook per gli URL collegati

Come una migrazione mette a rischio i tuoi ingressi

Il passaggio a piattaforme diverse o la modifica degli schemi URL mette a rischio i tuoi link esterni, e il rischio è concentrato. Alcuni URL concentrano la maggior parte dei domini di riferimento.

Quegli URL ricevono un redirect manuale, mai una regola basata su pattern. Scopri quali sono con il metodo degli ingressi. Il resto può seguire dei pattern.

Ecco il nostro runbook. Utilizza un'esportazione dei link per decidere cosa è sacro. Si conclude con un controllo, rispetto a Search Console, perché i redirect che sembrano corretti in un foglio di calcolo possono ancora comportarsi in modo strano in produzione. Per la struttura dietro gli URL sacri, leggi la pagina sulle pagine di ingresso.

Perché gli URL sacri vengono prima

Non tutti gli URL sono uguali. Un piccolo insieme contiene la maggior parte dei domini di riferimento, e quegli indirizi meritano più cura rispetto al resto del sito combinato. I backlink della migrazione del sito dipendono da loro, quindi trattali come punti fissi nel piano.

Inizia dall'elenco degli ingressi, non dalla sitemap. La sitemap elenca ciò che pubblichi, mentre l'elenco degli ingressi mostra cosa il web punta già.

Scrivi quell'elenco prima che qualcuno apra il file dei redirect. Un elenco scritto in seguito tende a corrispondere a ciò che le regole fanno già, e questo nasconde i gap che hai più bisogno di vedere. Ordinalo per domini di riferimento. Le righe pesanti si trovano in alto.

Redirect manuali per i pochi

Ogni URL sacro riceve la propria riga nella mappa dei redirect, con una destinazione scelta manualmente. La destinazione dovrebbe coprire lo stesso argomento della vecchia pagina, in modo che le parole che puntano ad essa abbiano ancora senso.

Immagina una vecchia guida che si sposta in un nuovo centro assistenza. Se la nuova pagina risponde alla stessa domanda, il redirect ne trasmette il significato. Se la nuova pagina è una landing page generica, non lo fa.

Mantieni una riga per ogni URL sacro con una breve nota sul motivo per cui è stata scelta la sua destinazione. La nota è ciò di cui avrà bisogno chi leggerà il file tra un anno.

Pattern per tutto il resto

Le regole basate su pattern vanno bene per la coda lunga, come un percorso di blog datato che diventa uno slug pulito. Scrivile dopo le righe manuali, in modo che una regola ampia non possa sovrascrivere una specifica.

Testa un campione dell'output delle regole pattern contro l'elenco live dei vecchi indirizzi e controlla i codici di stato prima di rilasciare qualsiasi cosa.

Verifica che nessuna regola pattern catturi un URL sacro, testando l'elenco sacro contro le regole prima che vadano in produzione.

Ancore dopo il trasferimento

Un ingresso potrebbe essere arrivato con il nome di un prodotto che hai successivamente rimosso. La nuova destinazione dovrebbe comunque dare senso a quelle parole, anche quando la pagina del prodotto non c'è più.

Se non può, la destinazione è sbagliata, per quanto pulita appaia la mappa dei redirect sulla carta.

Varianti dei parametri durante una migrazione

Una migrazione è un buon momento per decidere quali stringhe di query meritano di esistere. Molti siti trasportano ordinamenti, filtri e tag di tracciamento che creano indirizzi extra per lo stesso contenuto, e una migrazione li copia tutti a meno che tu non lo impedisca.

Decidi una volta, scrivi la decisione e applicala ovunque il sito linka. La pagina sulla profondità di scansione mostra come queste varianti distorcono un rapporto sulla profondità.

Quali stringhe di query trasportano contenuti

Un parametro che modifica il contenuto, come un numero di pagina in un elenco lungo, può mantenere il proprio indirizzo. Un parametro che riordina o traccia solo non ne ha bisogno.

Scrivi la decisione accanto al nome del parametro, in modo che la persona successiva non debba indovinare cosa fa.

Tag canonical sul nuovo sito

Dove una variante deve rimanere, il suo tag canonical dovrebbe nominare l'indirizzo pulito. Il tag è un suggerimento piuttosto che un comando, quindi dovrebbe essere coerente con i link interni e la sitemap.

Segnali non corrispondenti sono il fallimento comune. Una pagina che dichiara un canonical, linka a un secondo indirizzo e ne elenca un terzo nella sitemap fornisce a un crawler tre istruzioni conflittuali.

Link interni che trasportano ancora parametri

I modelli di navigazione spesso copiano vecchi parametri nelle nuove pagine. Scansiona il nuovo sito, conta i link interni che trasportano una stringa di query e correggi il modello piuttosto che ogni pagina.

Una correzione del modello mantiene anche il problema dal rifluire nella prossima redesign.

Errori di redirect che appaiono in Search Console

Dopo una migrazione, Search Console segnala spesso errori di redirect in blocco. L'elenco sembra allarmante. Google segnala ciò che il suo crawler ha incontrato, non ciò che la tua mappa intendeva. Un lungo elenco di solito si risale a poche cause, quindi ordina gli errori per causa prima di toccare qualsiasi redirect.

Inizia con il pattern più comune e scendi. Molti errori scompaiono una volta che le cause principali sono state corrette.

Catene e loop

Una catena va dall'indirizzo vecchio a un indirizzo intermedio e poi alla pagina finale. Ogni salto aggiunge un passaggio che un crawler potrebbe abbandonare, e un loop lo fa girare in tondo.

Appiattisci le catene in modo che ogni vecchio indirizzo punti direttamente al suo obiettivo finale e rimuovi qualsiasi loop prima di chiedere una nuova scansione.

Una catena appare spesso dopo una seconda migrazione sopra la prima, quindi cerca nel file dei redirect qualsiasi destinazione che sia essa stessa una sorgente.

Destinazioni che falliscono

Un redirect in un 404, una pagina di accesso o un obiettivo generico della home page appare come un errore o come un segnale debole. Controlla ogni destinazione con una richiesta di stato prima di assumere che la mappa sia corretta.

Questi tre fallimenti sono facili da individuare una volta che ogni destinazione si trova in una colonna del foglio.

Includi anche le destinazioni dei vecchi redirect nel controllo, poiché una catena può terminare in una pagina rimossa anni fa.

Cache di un redirect modificato

Un redirect è una risposta, e i browser e le cache condivise possono mantenerlo più a lungo del previsto. Se cambi dove punta un vecchio indirizzo, la cache di un visitatore potrebbe ancora inviarlo all'obiettivo precedente per un po' di tempo.

Chiedi al tuo host o CDN come memorizza i redirect in cache e se offre un purge. Poi testa da una sessione browser pulita piuttosto che da quella che hai usato per scrivere la mappa.

Ciò che i redirect non possono salvare

Un 301 è un indirizzo di inoltro, non una trasfusione. Se la nuova pagina ha un argomento diverso dalla vecchia, il link potrebbe smettere di contare, ed è per questo che le destinazioni dovrebbero essere pertinenti.

I link da siti che non si aggiornano mai continueranno a puntare all'indirizzo vecchio, quindi mantieni i redirect attivi. Quanto a lungo è una questione di propensione al rischio; non indichiamo un periodo qui.

Le ancore sono un'altra trappola. Se un ingresso è arrivato con le parole di un prodotto che hai successivamente rimosso, la nuova destinazione dovrebbe comunque dare senso a quelle parole.

Dopo il confronto degli snapshot, ogni pagina di ingresso che è scomparsa merita un controllo manuale. Un aggiornamento mensile può essere in ritardo rispetto ai cambiamenti reali, quindi controlla anche Search Console.

Tieni d'occhio anche le sorgenti. Un sito che si aggiorna raramente potrebbe continuare a puntare all'indirizzo vecchio per molto tempo, quindi il redirect deve rimanere in posizione e nessuno dovrebbe rimuoverlo durante una pulizia.