Checklist per la migrazione del sito: da T-4 settimane al giorno 45

Un 301 che finisce in un 404 non conserva nulla

Alcuni team inviano ogni vecchio URL alla nuova home e lasciano che le pagine di destinazione scadano più tardi. Il redirect stesso funziona. Ecco perché l'abitudine è rischiosa, poiché ogni salto appare pulido in un log mentre la pagina alla fine risponde con un 404.

Immagina di spostare un negozio su un nuovo dominio e di mantenere solo i prodotti che vengono ancora venduti. Le pagine di categoria che contenevano la maggior parte dei link esterni ora rimbalzano verso nulla di utile. Conta gli URL con link esterni prima di ritirare qualsiasi cosa. Rendilo il primo passo. Una pagina con domini di linking ha bisogno di una destinazione viva sullo stesso argomento, non di un shrug.

Mantieni la regola breve: un salto, poi un 200 finale. Qualcos'altro è una perdita che hai scelto.

Cosa protegge un 301 a salto singolo verso una pagina attiva

Il valore di un link risiede sull'URL a cui punta. Un redirect trasporta quel valore solo se l'indirizzo su cui atterra risponde e corrisponde ancora all'argomento. Un prodotto spostato allo stesso prodotto nel nuovo catalogo supera questo test, mentre un prodotto inviato alla homepage di solito no, anche se era la pagina a cui tutti linkavano.

Ricontrolla lo stato finale dopo ogni modifica al template. Un redirect che funzionava al lancio può finire in un 404 dopo un rilascio successivo, quando qualcuno rimuove una categoria durante una pulizia del menu.

Quando un 410 è la risposta onesta

Alcuni vecchi URL non avevano link, visite o sostituzioni reali. Per quelli, un chiaro 404 o un 410 è più onesto di un redirect verso una pagina che non risponde alla domanda che faceva quella vecchia. Un redirect verso una pagina non correlata è spesso trattato come un soft 404, quindi non salva nulla.

Scrivi la decisione per ogni gruppo di URL, con il motivo accanto. Una cartella di tutorial ritirati riceve una risposta diversa da una cartella di pagine con ottanta domini di linking, e vorrai spiegare quella differenza a un collega tra sei mesi.

Controllare l'ultimo salto, non solo il primo

La maggior parte dei test di redirect si ferma alla prima risposta, che è il punto sbagliato in cui fermarsi. Segui la catena fino alla fine, poi registra il numero di salti e lo stato finale accanto all'URL vecchio. Una catena di due salti non è rotta, ma aggiunge ritardo e un altro punto in cui una regola può fallire.

Se uno script è fuori portata, un foglio di calcolo e alcune chiamate curl faranno il lavoro. La pagina degli script API ha una versione che puoi programmare.

Sitemap e richieste manuali dopo il lancio

Mantieni la vecchia sitemap raggiungibile per alcune settimane dopo lo spostamento. I crawler che revisiteranno il vecchio host possono ancora trovare quegli indirizzi in un unico elenco, il che accelera il loro primo passaggio attraverso i redirect.

Le richieste manuali sono uno strumento diverso. Usale per le poche pagine che contano di più, non per centinaia di URL inviate una per una. Una pagina richiesta senza link interni e con un corpo sottile tende a sparire di nuovo, quindi la richiesta è buona solo quanto la pagina dietro di essa.

Aspettare è un piano valido. Dai tempo alla scansione, poi giudicala sui dati.

Mantenere la vecchia sitemap elencata per un po'

Lascia la vecchia sitemap in Search Console fino a quando gli URL vecchi smettono di apparire nelle statistiche di scansione. Poi rimuovila intenzionalmente e annota la data nel registro di migrazione.

Non rimuoverla il giorno del lancio solo per rendere la proprietà più ordinata. Una rimozione precoce nasconde l'unico elenco che nomina ogni vecchio URL che devi ancora tracciare.

Richiedere l'indicizzazione per le pagine che contengono link

Scegli i venti nuovi URL con più link esterni, usando lo stesso join che hai creato per la mappa dei redirect, e richiedili manualmente. Lo sforzo segue il rischio invece della dimensione del sito.

Se una pagina richiesta è ancora mancante dopo alcune settimane, guarda la pagina prima di chiedere di nuovo. Controlla i suoi link interni, il suo canonical e il suo contenuto. Una quinta richiesta non cambia nulla.

Per quanto tempo prima che lo spostamento possa essere valutato

Valuta lo spostamento dal secondo estrazione di link, non dalla prima. Il nostro indice si aggiorna circa una volta al mese, quindi un'estrazione al giorno tre mostra principalmente l'immagine del mese scorso. Esegui la seconda estrazione dopo l'aggiornamento e usala per trovare tutti i backlink a un sito web sul nuovo host.

Il rapporto Pages e i dati dei link rispondono a domande diverse. Leggili fianco a fianco, non come verdetto competitivo sullo stesso spostamento.

Monitorare il sito dopo il lancio, non solo prima

Un'audit pre-lancio registra ciò che era vero il giorno in cui è stato eseguito. La maggior parte dei danni del lancio si manifesta più tardi, dopo un aggiornamento del plugin, un cambiamento nella regola CDN o un template che tocca un'impostazione che nessuno ha revisionato.

Tratta la sorveglianza post-lancio come un insieme di piccole differenze rispetto a una baseline salvata. Non serve un dashboard. Una pianificazione e una cartella di file datati basteranno.

Cosa dovrebbe confrontare una sorveglianza settimanale

Scegli i controlli che farebbero più male se cambiassero e eseguili lo stesso giorno ogni settimana.

• Codice di stato e URL finale per i 50 vecchi URL più linkati
• robots.txt e il meta tag robots sui template principali
• Conteggio degli URL 200 live contro il conteggio nella nuova sitemap
• Tag canonical sulla homepage, una categoria e un articolo

Perché un'audit una tantum perde la deriva lenta

Le impostazioni derivano dopo il lancio. Un flag di test lasciato acceso, un plugin che riscrive i permalink o un redirect aggiunto per correggere una pagina possono ciascuno annullare parte del piano. Un'audit fatta il giorno del lancio non può vederne nessuna.

Una differenza programmata sì. Tieni i file di baseline nel controllo versione e confronta l'output di ogni settimana con essi, così un cambiamento inatteso è visibile il giorno in cui avviene.

Sottodomini, rimozioni e cambi di dominio per intero sito

Alcuni team spostano una sezione su un sottodominio e indicizzano solo le sue pagine popolari. Questo può funzionare. Il costo è che i link diretti alle pagine più silenziose ora atterrano su un host con meno storia, quindi contali prima di tagliare qualcosa.

Le richieste di rimozione sono più strette di quanto sembrino. Search Console applica una rimozione alla proprietà in cui la presenti, quindi una richiesta fatta su un sottodominio non agisce sul dominio principale. Controlla la proprietà prima. Poi invia e mantieni entrambi verificati.

Indicizzare solo le pagine popolari su un sottodominio

Inizia con i link per URL in quella sezione. Le pagine che contengono link esterni ma poco traffico sono le prime che una regola solo-pagine-popolari nasconderebbe. Mantenile indicizzabili, o reindirizza ciascuna alla sua pagina popolare più vicina e scrivi il motivo accanto alla regola.

Dove il sito principale linka al sottodominio decide quanto facilmente le sue pagine vengono trovate. Elenca quei link prima di scegliere quali pagine rimanere nascoste, perché una pagina che il sito principale non linka mai è difficile da raggiungere in ogni caso.

Un cambio di dominio per intero sito, pagina per pagina

Una regola a livello di host gestisce la root, ma un cambio di dominio richiede anche una mappa a livello di percorso. Quando la prima parte dell'URL cambia e lo slug rimane uguale, uno scambio di host copre la maggior parte delle pagine, e le eccezioni richiedono le loro righe.

Crea l'elenco partendo dalle pagine collegate, poi abbina ogni vecchio percorso al suo nuovo. La ricetta per la mappa dei redirect mostra come classificare quell'elenco in base ai link.