Reindirizzamenti 301 per migrazione sito

Come configurare i reindirizzamenti 301 per la migrazione di un sito, passo dopo passo

Una migrazione di sito non è mai solo uno spostamento tecnico, soprattutto quando si pianifica un redirect 301 migrazione sito con attenzione. Basta un URL sbagliato perché una pagina che prima si posizionava, convertiva o riceveva traffico da una newsletter finisca nel nulla. Per questo i reindirizzamenti 301 vanno pianificati prima del lancio, non dopo.

Questa guida mostra come configurare reindirizzamenti 301 per la migrazione di un sito, passo dopo passo, senza lasciare che sia solo il livello dei redirect a fare tutto il lavoro. Mapperai il vecchio sito, deciderai cosa merita un redirect e controllerai i risultati prima che motori di ricerca e utenti individuino le lacune.

1. Mappa il tipo di migrazione e gli obiettivi dei redirect

Inizia con una domanda semplice: che tipo di migrazione del sito stai facendo? Un cambio di dominio richiede un approccio diverso rispetto a un cambio di piattaforma, e una modifica della struttura degli URL è un caso a sé. Se tutte e tre le cose stanno accadendo insieme, scrivilo subito. Non dopo.

Per esempio, uno spostamento del brand da oldsite.com a newsite.com potrebbe richiedere il reindirizzamento di quasi tutte le pagine attive, mentre il passaggio da un CMS a un altro potrebbe mantenere gli stessi URL e cambiare solo il modo in cui le pagine vengono renderizzate. Non sono lo stesso lavoro. Se li tratti come se lo fossero, il piano dei redirect diventa rapidamente confuso.

Stabilisci un obiettivo per il livello dei redirect: preservare il valore delle pagine che contano già. Significa traffico, link e intenzione dell’utente. Una pagina prodotto dovrebbe atterrare sulla pagina prodotto più vicina possibile. Un articolo del blog dovrebbe puntare all’articolo più vicino, non alla home page.

Scrivi le regole della migrazione in linguaggio semplice. Mantienile brevi. “Le vecchie pagine di categoria si spostano nelle nuove categorie.” “Le pagine promozionali dismesse non hanno bisogno di redirect.” “Le pagine archivio poco utili possono essere eliminate.” Queste decisioni fanno risparmiare ore in seguito, perché i reindirizzamenti 301 dovrebbero seguire la struttura reale del sito, non ipotesi fatte durante la settimana del lancio.

Se la migrazione cambia anche la titolarità dei contenuti o la configurazione analytics, rendilo visibile al team. Uno spostamento del sito spesso coinvolge più di un gruppo, e la mappa dei redirect deve seguire il piano aziendale tanto quanto quello degli URL. Per una visione più ampia del lavoro di supporto attorno a uno spostamento, vedi quanto costa la manutenzione di un sito web.

2. Crea l’inventario solo degli URL che richiedono copertura

Non elencare ogni URL storico, a meno che non sia davvero necessario. Sulla carta sembra ordinato, ma fa perdere tempo e crea rumore. Parti dalle pagine, dalle cartelle e dai file che hanno ancora valore: landing page, pagine dei servizi, articoli del blog, pagine di categoria, immagini se sono collegate pubblicamente e PDF che ricevono ancora visite.

Recupera gli URL da più fonti. Usa la sitemap attuale, l’analytics, i log del server e gli eventuali export di crawl già disponibili. Un URL senza visite e senza link potrebbe non meritare attenzione. Un URL con link esterni sì. Quello potrebbe contare ancora sei mesi dopo lo spostamento.

Escludi le pagine che devono essere ritirate intenzionalmente. Una campagna stagionale del 2021 non ha bisogno di una nuova destinazione solo perché esiste. Nemmeno una vecchia pagina di test interna. Qui serve disciplina. Meglio pochi redirect che troppi, purché quelli importanti siano coperti.

Dividi l’inventario in gruppi semplici: pagine, cartelle, file e casi speciali. I numeri aiutano. Un elenco di 12 URL si può gestire in un modo. Un elenco di 1.200 URL richiede regole a modello, non regole scritte a mano per ogni riga. Se salti questo passaggio, la mappa dei redirect diventa difficile da controllare.

Mantieni l’inventario focalizzato sul vecchio sito, non sul nuovo. Il vecchio sito è la fonte di verità per ciò che esiste oggi. Il nuovo sito è il target. Mescolare troppo presto i due aspetti rende più difficile individuare pagine mancanti e duplicati accidentali.

3. Abbina gli URL vecchi ai nuovi equivalenti corretti

Ora costruisci la mappatura. Una mappa pulita da uno a uno è il caso più semplice: un vecchio URL punta a un nuovo URL, e il rapporto è chiaro. Un articolo del blog sui prezzi passa al nuovo articolo sui prezzi. Una pagina di servizio sugli audit punta alla nuova pagina audit. Tutto lineare.

Le migrazioni reali raramente sono così ordinate. A volte una vecchia pagina diventa due nuove pagine, oppure tre vecchie pagine confluiscono in una pagina più forte. In questi casi, decidi cosa stava probabilmente cercando l’utente. Se la vecchia pagina copriva sia “configurazione” sia “supporto”, ma il nuovo sito divide l’argomento in due pagine separate, scegli la soluzione migliore per l’intento principale e poi collega internamente il resto.

Non reindirizzare tutto alla home page. Sembra la soluzione più facile per un pomeriggio, ma costa cara per mesi. I motori di ricerca non apprezzano una rilevanza debole, e gli utenti se ne accorgono ancora più in fretta. Chi cerca una pagina prezzi non vuole una landing generica. Vuole la pagina prezzi, o il sostituto funzionante più vicino.

Per i contenuti rimossi, prendi una decisione. Se non esiste un sostituto né un equivalente significativo, lascialo fuori dalla mappa dei redirect. È più pulito che forzare un abbinamento sbagliato. Una pagina su un evento del 2019 non ha bisogno di una destinazione fittizia solo per riempire una riga del foglio di calcolo.

Aggiungi note accanto agli URL complessi. Usa una breve spiegazione per pagine unite, pagine divise e contenuti ritirati. Quelle note contano quando qualcuno rivede il piano due giorni prima del lancio e chiede perché la pagina A punta alla pagina B. La risposta dovrebbe essere visibile nella mappa, non nascosta in chat.

4. Scegli il metodo giusto per implementare i redirect 301

Dove inserire i redirect 301 dipende da come è ospitato il sito migrato. In alcuni stack, la configurazione del server è la strada più pulita. In altri, il CMS, la CDN o il livello di routing dell’app sono più adatti. Scegli il punto che può servire i redirect in modo affidabile senza aggiungere complessità inutile.

Se il sito gira su un server web tradizionale, le regole a livello server possono essere l’opzione più diretta. Se il sito è gestito in un CMS con strumenti di redirect integrati, questo può bastare per spostamenti più piccoli. Se il traffico passa da una CDN, le regole edge possono aiutare, soprattutto quando serve aggiornare rapidamente molti URL.

Ogni opzione ha un compromesso. Le regole server possono essere potenti, ma richiedono molta attenzione. I plugin CMS sono comodi, ma possono diventare disordinati. Le regole CDN sono veloci, ma bisogna sapere esattamente come interagiscono con la cache e il matching dei percorsi. Scegli in base al sito migrato, non per abitudine.

Se la migrazione modifica anche impostazioni di sicurezza, hosting o tracciamento, coordina queste attività nella stessa finestra. Un livello di redirect che dipende dal nome host sbagliato o da una configurazione del certificato non ancora completata può fallire in modi strani. Per la pianificazione correlata alla protezione del sito, vedi sicurezza del sito web.

Per i team più grandi, documenta il metodo in un unico posto. Inserisci proprietario, piattaforma e percorso di deployment accanto alla mappa dei redirect. Così chi modifica le regole sa se appartengono a Nginx, Apache, a una tabella del CMS, a un pannello CDN o al codice dell’app.

5. Scrivi e organizza le regole 301

Ora converti la mappa nei redirect 301 effettivi. Tieni le regole ordinate. Ogni pattern dovrebbe fare un solo lavoro. Se una regola prova a intercettare troppi tipi di URL, può catturare le pagine sbagliate e mandare gli utenti in posti strani.

Fai attenzione ai loop. Un loop accade quando la pagina A reindirizza alla pagina B e la pagina B rimanda alla pagina A, oppure quando due pagine continuano a rimandarsi a vicenda in cerchio. È un vicolo cieco per crawler e utenti. E spreca anche crawl budget, una di quelle espressioni noiose che diventano interessantissime quando nulla viene indicizzato correttamente.

Evita anche le catene. Una catena significa che un redirect ne porta a un altro, poi a un altro ancora. La pagina A va alla B, poi la B alla C. Funziona male e rallenta tutto. Se puoi far puntare A direttamente a C, fallo.

Usa nomi e gruppi coerenti nel file o nell’interfaccia. Raggruppa le regole per sezione: vecchi percorsi del blog, vecchi percorsi dei servizi, vecchi percorsi dei prodotti, asset ritirati. Un elenco ordinato è più facile da testare. Ed è anche più semplice da consegnare a un altro sviluppatore alle 18 del giorno del lancio, senza lunghe spiegazioni.

Tieni d’occhio le eccezioni. Una regola ampia come “reindirizza tutto ciò che è in /blog/ verso /insights/” può sembrare efficiente, ma può rompere tag, pagine autore o vecchi link ai media. Se un pattern ha eccezioni, isolale prima del rilascio. Ti risparmierà lavoro di pulizia dopo.

6. Verifica il comportamento dei redirect prima e dopo il lancio

I test vanno fatti prima del lancio, non dopo il primo utente che segnala una pagina rotta. Controlla un campione di URL singoli dalla mappa, poi prova i pattern di gruppo, poi verifica i casi particolari come slash finali, percorsi in maiuscolo, query string e file con estensione. Un redirect che funziona per un URL può fallire su un suo quasi gemello.

Conferma che il codice di risposta sia un vero 301, non un 302 o una riscrittura morbida che nel browser sembra solo un redirect. La distinzione conta. I motori di ricerca trattano uno spostamento permanente in modo diverso da uno temporaneo, e gli utenti non dovrebbero dover indovinare cosa è successo. Controlla lo status code con uno strumento che mostri la risposta reale.

Testa più dei percorsi ovvi. I vecchi PDF, gli URL delle immagini e gli URL annidati nelle cartelle vengono spesso trascurati. Un percorso file mancante può creare una scia di 404 che continua a crescere dopo il lancio, soprattutto se quegli asset erano incorporati nelle pagine o condivisi sui social anni fa.

Esegui i controlli in due fasi: una prima del lancio in ambiente di staging, e una subito dopo il lancio sul sito live. Il secondo giro intercetta problemi di deployment, sorprese della cache e qualsiasi regola che si comporta diversamente quando entra in gioco l’host reale. È in questo secondo giro che molti team trovano l’unico URL che avevano dimenticato.

Se la migrazione include nuovi strumenti di analytics o monitoraggio, verifica che i redirect non rompano quei sistemi. Uno spostamento è più facile da fidare quando puoi vedere insieme traffico, codici di risposta e comportamento di crawl. Per i team che confrontano gli strumenti di misurazione durante questo tipo di progetto, quanto costa l’analytics di un sito web è un riferimento utile.

7. Aggiorna i segnali di supporto dopo la migrazione

I redirect 301 non dovrebbero sostenere da soli tutta la migrazione. Aggiorna i link interni in modo che il nuovo sito punti a sé stesso. Se la navigazione linka ancora gli indirizzi vecchi, ogni clic crea un passaggio inutile in più. È un ritardo extra per gli utenti e un lavoro extra per i crawler.

Aggiorna le sitemap XML con i nuovi URL. Invia le sitemap dove serve. Rimuovi i vecchi URL dalla sitemap attiva se ora reindirizzano, e lascia lì solo gli URL di destinazione. Una sitemap piena di indirizzi obsoleti invia segnali contrastanti, anche se i redirect funzionano perfettamente.

Controlla i tag canonical. Dovrebbero puntare alla nuova pagina, non alla vecchia. È una piccola riga di codice, ma conta. Un tag canonical che fa ancora riferimento al vecchio URL può confondere il messaggio inviato ai motori di ricerca, soprattutto durante il primo ciclo di crawl dopo il lancio.

Aggiorna, quando possibile, i riferimenti esterni. Può voler dire siti partner, profili social, template email o una scheda directory che controlli tu. Non riuscirai a correggere tutto, ed è normale. L’obiettivo è ridurre il traffico evitabile attraverso il livello di redirect, non sistemare internet.

Se la migrazione fa parte di un redesign più ampio, è utile confrontare il lavoro sui redirect con le decisioni più generali su contenuti e budget. La pagina intitolata budget per redesign del sito vs budget di manutenzione può aiutare a distinguere tra lavoro di cambiamento e manutenzione.

8. Monitora i problemi di crawl e traffico nella prima finestra dopo il lancio

La prima finestra dopo il lancio è il momento in cui i problemi emergono. Controlla URL mancanti, 404 inattesi, anomalie nei redirect e picchi di richieste ai vecchi percorsi. Fallo ogni giorno all’inizio, se il sito è grande. Due volte al giorno non è esagerato quando la migrazione è appena avvenuta.

Guarda insieme i log del server, l’analytics e i dati della search console. Una singola fonte non vede ciò che le altre intercettano. Un 404 nei log può essere un link interno rotto. Un errore di crawl può essere un URL reindirizzato con un refuso. Un calo di traffico su una pagina chiave può significare che il vecchio percorso viene ancora condiviso in un punto importante.

Correggi rapidamente le lacune. Se un URL è stato dimenticato, aggiungilo. Se un pattern è troppo ampio, restringilo. Se compare una catena, comprimila. La mappa dei redirect non è finita al lancio; è un documento vivo almeno per i primi giorni dopo lo spostamento.

Traccia le pagine che contano di più nei primi 7 giorni, poi di nuovo dopo 30 giorni se la migrazione è ampia. Così hai due controlli: uno per i problemi immediati e uno per gli effetti più lenti sul crawl e sull’indicizzazione. Se i numeri non tornano, non aspettare che si sistemino da soli.

Tieni il team aggiornato con esempi concreti, non con note vaghe sullo stato. “Quattro URL dei prodotti restituiscono ancora 404” è utile. “Restano alcuni problemi” no. Se una campagna marketing, una menzione stampa o una pagina molto linkata punta ancora a un vecchio indirizzo, sistema prima quel percorso. Un solo URL mancato può avere conseguenze maggiori di una dozzina di pagine a basso valore.

Quando la prima ondata si stabilizza, rivedi il livello dei redirect rispetto al traffico reale. Alcuni vecchi URL si riveleranno più importanti di quanto suggerisse l’inventario. Altri non verranno mai toccati. Queste evidenze ti aiutano a rendere il piano dei redirect più preciso e a mantenere il sito più pulito mentre la migrazione si assesta, rafforzando il lavoro di migrazione sito SEO redirect 301.