SEO per la Migrazione del Sito

Le migrazioni raramente falliscono per motivi sottili. Falliscono per un elenco breve di cause concrete ed evitabili, e ogni voce di quell'elenco viene intercettata da una checklist più qualcuno che sappia leggere il codice.

• Redirect mai mappati: i vecchi URL restituiscono 404 e con loro muoiono link e posizionamenti che puntavano lì
• Redirect a catena o in loop, dove vecchio → intermedio → nuovo disperde autorità a ogni salto
• Canonical rimasti a puntare al vecchio dominio, che dicono a Google che il sito nuovo è la copia
• Lo staging indicizzato perché una regola robots è finita invertita in produzione, o non è mai stata pubblicata
• Contenuti eliminati in silenzio nel rifacimento: proprio i paragrafi che posizionavano, tagliati come superflui
• Sitemap e link interni che descrivono ancora la vecchia struttura settimane dopo il lancio

Il lavoro si divide nettamente in prima, durante e dopo, e gran parte del valore sta nella prima parte. Una migrazione pianificata bene è quasi noiosa; una pianificata il giorno del lancio diventa un progetto di recupero.

• Prima la baseline: posizionamenti, pagine di atterraggio principali, inventario di scansione e traffico registrati prima che si muova qualcosa, così 'abbiamo perso qualcosa?' ha una risposta con i dati
• Mappa degli URL costruita dalla scansione, non dalla memoria: ogni URL indicizzato ottiene una destinazione o una decisione esplicita di eliminarlo
• Redirect implementati come codice nel tuo repository, rivedibili in una pull request e confrontabili, non digitati nell'interfaccia di un plugin
• Validazione in staging: scansione del nuovo sito, verifica che ogni redirect mappato si risolva in un solo salto, controllo di canonical, hreflang e robots prima del lancio
• Presidio nel giorno del lancio e finestra di recupero successiva, confrontando con la baseline e non con una sensazione

Se il sito serve più di una lingua, una migrazione moltiplica ogni rischio: ogni lingua ha bisogno della propria mappa di redirect, l'hreflang deve continuare a corrispondersi sui nuovi URL, e i canonical per lingua devono spostarsi insieme, altrimenti Google tratterà le traduzioni come duplicati della pagina inglese. È il guasto che vediamo più spesso e quello da cui si recupera più lentamente.

• Una mappa di redirect per lingua, inclusi gli slug tradotti che non condividono la forma dell'URL inglese
• Hreflang ricostruito sui nuovi URL e verificato reciproco in entrambe le direzioni prima del lancio
• Canonical per lingua spostati di pari passo, così nessuna lingua finisce a puntare alla pagina di un'altra
• Link interni consapevoli della lingua aggiornati, così ogni gruppo linguistico continua a sostenersi
• Sitemap rigenerate per lingua, invece di una sitemap inglese con gli URL tradotti attaccati sopra

È un motivo normale per chiamarci, ed è diagnosticabile. Di solito è la forma della perdita a indicare la causa: un calo generalizzato punta ai redirect o al robots, un calo limitato a una lingua punta a hreflang o canonical, e un calo su poche pagine punta a contenuti spariti nel rifacimento.

• Ricostruire il vecchio inventario di URL dall'indice, dagli archivi e da eventuali log ancora disponibili
• Individuare cosa restituisce 404 o atterra sulla pagina sbagliata, e ricostruire la parte mancante della mappa dei redirect
• Verificare se la perdita è uniforme, per lingua o per pagina: ognuna indica una causa diversa
• Ripristinare i contenuti tagliati nel rifacimento che però stavano posizionando
• Reinviare e monitorare il recupero, con tempi realistici e non con una promessa

Quotato sulla nostra fascia di 35-55 EUR/ora, con stima scritta gratuita prima di iniziare. Una migrazione è un lavoro delimitato con una fine definibile, quindi più facile da dimensionare di un programma continuativo: la misura dipende da quanti URL hai e da quante lingue, non da quanto sembra grande il restyling.

• Prima la stima scritta gratuita, con intervallo e assunzioni dichiarati
• Lavoriamo nel tuo repository e nel tuo processo di deploy: i redirect vengono pubblicati come il resto del codice
• A nostro agio con Next.js, React e stack server-rendered, dove vivono davvero routing e logica dei canonical
• Pieno allineamento CET da Tirana, con ingegneri che lavorano in inglese e italiano
• Onesti sui tempi: il recupero dopo una migrazione andata male richiede di solito da settimane a qualche mese, e nessuno può promettere una data