Gestire una migrazione SEO complessa di un sito obsoleto
Recentemente mi sono trovato di fronte a una sfida SEO piuttosto ardua: la migrazione di un sito web molto datato, realizzato con un CMS poco conosciuto chiamato Zope. Il precedente sviluppatore, purtroppo, non era disponibile a fornirci il database per l’estrazione dei dati, il che ha reso il processo ancor più complesso, dato che il sito conteneva decine di migliaia di pagine.
La strategia di scrape e importazione
Vista la mancanza di cooperazione per l’accesso ai dati, dopo essermi consultato con il cliente, sono dovuto ricorrere alla metodologia del buon vecchio scraping per recuperare le informazioni essenziali dal sito.
Per questo lavoro ho ritenuto come strumento adeguato lo spider Screaming Frog. Questo strumento, solitamente utilizzato per fare delle scansioni degli errori di un sito, ha delle funzionalità molto potenti anche per l’estrazione dei dati da un sito web.
La funzione in questione si chiama Custom Extraction.
Le “Custom Extraction” di Screaming Frog sono una funzionalità avanzata del SEO Spider che ti permette di estrarre dati specifici da una pagina web durante la scansione del sito. Questo può includere qualsiasi elemento HTML, attributi o anche script inline utilizzando espressioni XPath, CSS Path o Regex (espressioni regolari).
I dati di cui avevo bisogno erano:
- URL precedente
- Title
- H1
- Contenuto del post
Tutti elementi cruciali per preservare il SEO value durante la migrazione.
Questo processo è durato diversi giorni e ha tirato fuori centinaia di migliaia di URL. Troppe! Sapevo che i contenuti utili sarebbero stati molti di meno.
Ho fatto una prima scrematura di URL che sicuramente non mi interessavano – c’erano migliaia e migliaia di pagine di ricerca linkate ma non indicizzate.
Ho quindi preso altri pattern di URL che non sapevo potessero portare traffico o meno e le ho inserite nello strumento “Analisi URL” di SEOZoom.
Sebbene si possano analizzare solo 1000 URL alla volta, io avevo solo bisogno di conferme. Capire se non importando un certo tipo di URL avrei potuto fare un danno.
Per fortuna la mia intuizione era corretta e c’era davvero tanta spazzatura che andava solo a sprecare Crawl Budget.
Ottima notizia. Su 500 URL analizzate solo 3 avevano qualche keyword posizionata. Questo mi ha semplificato il lavoro perché mi sono dovuto concentrare solo sul percorso /archivio/ limitando le URL utili a soli 32mila unità.
Implementazione tecnica: l’importazione dei dati
Dopo lo scraping, i dati sono stati esportati in formato CSV e importati nel database MySQL del nuovo sito, sviluppato in WordPress. Ho aggiunto due campi aggiuntivi nel database:
- urlnuova
- idnuova
Inizialmente questi due campi sono vuoti, ma mi serviranno nella fase successiva per gestire il ponte di migrazione.
Mi sono fatto poi aiutare da ChatGPT per sviluppare uno script PHP personalizzato che, operando all’interno dell’ambiente WordPress, leggesse le URL dall’esportazione di Screaming Frog per generare nuovi post. Un aspetto particolarmente impegnativo è stata la gestione delle date di pubblicazione, spesso in formati inconsistenti o errati.
Ecco il codice di esempio dello script ho creato.
Realizzazione dello script ponte
RewriteRule ^archivio/(?:anno-)?\d{4}(?:/[a-zA-Z]+)?/(.*)$ /ponte.php [L,QSA]
Questo script PHP di poche righe è fondamentale per la fase di redirect: quando il motore di ricerca o l’utente atterra su un vecchio URL, il file .htaccess invia la richiesta allo script ponte che interroga il database.
Se la corrispondenza URL vecchia -> URL nuova viene trovata nel database avviene un redirect 301.
In assenza di corrispondenza, l’utente viene reindirizzato verso una pagina 404 (o se preferite 410).
Script extra
Oltre agli script fondamentali per la migrazione dei contenuti testuali, ho sviluppato degli script paralleli per la gestione delle risorse multimediali, quali immagini e PDF. Questi script hanno avuto il compito di importare tali file nel media library di WordPress, garantendo che tutti i media fossero correttamente associati ai loro rispettivi post. Tuttavia, per mantenere il focus di questo case study sull’essenziale, ho scelto di concentrarmi principalmente sulla metodologia di base utilizzata per gestire la migrazione.
Fase di test
Prima del lancio definitivo, ho implementato una fase di test cruciale per simulare l’interazione che avrebbe Google con il nuovo sito. Per fare ciò, ho utilizzato ancora una volta Screaming Frog, selezionando dal menu “Mode” l’opzione “List”. Questa modalità mi ha permesso di caricare tutte le vecchie URL, dirigendo lo spider esclusivamente verso i percorsi specificati, senza lasciarlo navigare liberamente.
A causa della differenza tra l’hostname del sito in produzione e quello di test, ho dovuto effettuare una sostituzione nel file CSV, cambiando www.nomedominio.com con dev.nomedominio.com. Durante i test, mi sono imbattuto in vari errori 404, che indicavano una mancata corrispondenza nei percorsi dei redirect. In particolare, alcuni percorsi delle date erano errati, ad esempio “gennaio-200024” dove uno zero in più rendeva il percorso inaccessibile.
Per risolvere questi problemi, ho introdotto regole aggiuntive per verificare e correggere le date errate. Dopo diverse ore di scansione e aggiusti, sono riuscito a stabilizzare i redirect, con tutte le URL che correttamente puntavano ai nuovi percorsi con un redirect 301. Infine, ho riscansionato tutte le URL di destinazione dei 301 per confermare che fossero effettivamente navigabili e prive di ulteriori errori.
Messa in produzione
Dopo aver completato con successo la fase di test, il sito è stato messo online. La transizione dallo stato di test a quello di produzione è stata seguita tramite Google Search Console, strumento che ho utilizzato per assicurarmi che non emergessero problemi significativi una volta che il sito fosse diventato accessibile al pubblico e indicizzabile da Google.
Inoltre, ho utilizzato SEOZoom per monitorare le URL che rappresentavano i pilastri del traffico del sito. Non ho esaminato l’intero sito in questa fase iniziale, ma ho preferito concentrarmi su quelle pagine che erano fondamentali per il traffico e la visibilità. Questo approccio mirato mi ha permesso di funzionare come un “canarino in miniera”, un indicatore precoce, per verificare che il sito mantenesse le sue keyword più importanti e non subisse cali di performance SEO dovuti alla migrazione.
È stata una migrazione perfetta?
Risposta breve: NO!
Ho mantenuto una comunicazione aperta e trasparente con il cliente, prima di iniziare, riguardo ai limiti e alle sfide del progetto, discutendo apertamente dei possibili esiti della migrazione. Questa onestà ha aiutato a stabilire aspettative realistiche e a preparare il cliente per i cambiamenti imminenti.
Globalmente, la migrazione non è stata perfetta, dato che l’accesso limitato al database originale e il fatto che non ero coinvolto nella creazione e ottimizzazione del nuovo sito hanno impedito di sfruttare pienamente il potenziale. Tuttavia, considerando il punto di partenza, ovvero l’assenza di dati accessibili, il lavoro si è rivelato estremamente stimolante e ricco di sfide.
Le migrazioni di siti web raramente riescono a conservare il 100% del traffico precedente. Questo fenomeno dipende da numerosi fattori, come le differenze nell’architettura dei siti, le modifiche ai contenuti e le inevitabili fluttuazioni nei ranking dei motori di ricerca, per non parlare che la migrazione è avvenuta a cavallo di un update algoritmico di Google che non ci ha fornito dei dati oggettivi.
È cruciale prevedere i potenziali problemi post-migrazione, evitare modifiche drastiche che possano disorientare gli utenti o i motori di ricerca, e stabilire obiettivi realistici.
Nonostante le difficoltà, il cliente ha potuto abbandonare un sistema obsoleto e fuori controllo, guadagnando una nuova piattaforma su cui può ora sviluppare e migliorare i contenuti in modo più efficace e autonomo.
