Migrare da WordPress a custom senza perdere SEO

Come migrare sito WordPress senza perdere traffico SEO: passare da WordPress a sviluppo custom con metodo

Passare da WordPress non è un progetto solo di design. Se il traffico organico conta, la migrazione parte dalle pagine che già generano clic, lead e link. La frase “come spostare un sito web da WordPress a sviluppo custom senza perdere traffico SEO” è lunga, ma il lavoro dietro è molto pratico: proteggere ciò che già si posiziona e poi ricostruire il sito partendo prima da quelle pagine. In altre parole, chi deve migrare sito WordPress senza perdere traffico SEO deve dare priorità agli URL che già portano valore, così da evitare problemi più avanti.

Un errore comune è trattare tutti gli URL come se avessero lo stesso peso. Un archivio blog con 200 visite al mese non merita la stessa attenzione di una pagina prodotto che porta 2.000 visite e una dozzina di backlink. Scegli i 10, 20 o 50 URL più importanti e mettili per iscritto prima di iniziare qualsiasi modifica al codice. Lista piccola, grande risultato.

1. Mappa le pagine che generano davvero traffico di ricerca

Parti da tre fonti: analytics, Search Console e dati sui backlink. Dall’analytics, individua le landing page con traffico organico negli ultimi 12 mesi. Da Search Console, annota le query che portano impression e clic a quegli URL. Dai dati sui backlink, segnala le pagine con i link esterni più forti, perché una pagina con 5 buoni link può superarne 50 deboli.

Non affidarti alla memoria. Una pagina che “sembra” importante non è sempre quella di cui i motori di ricerca si fidano di più. A volte la pagina che stai quasi per eliminare è quella che sostiene un insieme di query long-tail e, senza farsi notare, contribuisce ai ricavi. Succede abbastanza spesso da meritare un foglio di calcolo.

Crea una tabella semplice con quattro colonne: URL attuale, traffico organico, query principali e note sul valore per il business. Se una pagina ha valore stagionale, segna il mese. Se una pagina alimenta la navigazione interna, segnalalo anche. Poi ordina la lista. La fascia più alta riceverà il trattamento di migrazione più accurato.

2. Congela il baseline SEO attuale prima di qualsiasi modifica al codice

Prima che uno sviluppatore tocchi i template, esporta lo stato SEO attuale. Salva gli snapshot delle posizioni, il numero di pagine indicizzate, gli errori di scansione, i canonical, i metadata, i link interni e gli URL della sitemap XML. Se possibile, esegui una scansione del sito WordPress con uno strumento che registri codici di stato e titoli delle pagine. Ti serve una foto “prima”, non un ricordo vago.

Raccogli i dati di Search Console per l’intervallo di report più recente. Se il sito ha un andamento giornaliero particolare, usa lo stesso giorno della settimana per i confronti. Lunedì con lunedì è meglio di lunedì con sabato. Questa piccola scelta evita falsi allarmi.

Salva anche una copia del file robots.txt e dell’indice sitemap attuale. Questi file sembrano noiosi finché non bloccano i motori di ricerca da una sezione che volevi mantenere. Una sola riga nel robots.txt può influenzare centinaia di URL. Una voce mancante nella sitemap può nascondere un intero blocco per settimane.

Se il sito ha già i tag canonical, registrali. Se ha title tag duplicati, annota quali template li generano. Questi dettagli ti aiutano a distinguere i danni della migrazione dai problemi già presenti. Senza quel baseline, l’analisi dopo il lancio diventa un tiro a indovinare.

3. Costruisci un piano di parità degli URL per ogni pagina importante

Ora mappa ogni URL importante di WordPress verso un nuovo URL custom. Mantieni la relazione uno a uno ogni volta che è possibile. Se la vecchia pagina è /services/seo-audit/, la nuova non dovrebbe diventare /what-we-do/consulting/audit/ a meno che non ci sia una forte ragione di business. Mappature pulite riducono la complessità dei redirect e rendono più facile controllare la migrazione. Questo è il cuore di come spostare un sito da WordPress a custom senza perdere continuità tra vecchi e nuovi percorsi.

I casi speciali meritano righe extra nel piano. Pagine paginate, archivi di categoria, viste filtrate, pagine tag, archivi autore e URL degli allegati media possono comportarsi in modo diverso. Alcune dovrebbero fare redirect verso una pagina padre. Alcune dovrebbero restare indicizzabili. Alcune andrebbero rimosse del tutto dalla ricerca. Controlla ciascuna invece di andare a intuito.

Qui un buon foglio di calcolo si ripaga da solo. Aggiungi colonne per URL vecchio, nuovo URL, codice di stato, tipo di redirect, target canonical e decisione sull’indicizzazione. Poi assegna un responsabile a ogni decisione. Uno sviluppatore, un SEO lead e un editor dovrebbero poter leggere lo stesso file e sapere cosa succede il giorno del lancio.

Per i siti grandi, la parità può far emergere sorprese spiacevoli. Una pagina tag di WordPress può posizionarsi per un argomento utile, anche se nessuno lo aveva previsto. Un file media può continuare ad attirare visite dalla ricerca immagini. Il piano di migrazione deve includere anche queste pagine, perché ai motori di ricerca non interesserà che fossero “solo residui”.

4. Pianifica insieme redirect, canonical e segnali di indicizzazione

I redirect da soli non bastano. Se una pagina reindirizza a un nuovo URL ma il tag canonical punta altrove, i segnali diventano confusi. Se una pagina è bloccata nel robots.txt ma inclusa nella sitemap, il risultato è altrettanto confuso. I motori di ricerca preferiscono una storia chiara. Dagliene una. In particolare, un redirect WordPress a sito custom SEO deve essere accompagnato da canonical coerenti e da una sitemap pulita, così da non lasciare ambiguità agli algoritmi.

Definisci redirect 301 per ogni vecchio URL che ha bisogno di una nuova destinazione. Evita le catene di redirect. Un solo passaggio è ideale. Due sono tollerabili in emergenza. Tre sono il punto in cui traffico ed efficienza di scansione iniziano a calare. Per una checklist tecnica più approfondita, vedi come impostare i redirect 301.

I canonical dovrebbero puntare alla versione preferita di ogni pagina sul nuovo sito. Se una pagina filtrata deve rimanere indicizzabile, rendilo esplicito. Se una pagina basata su parametri non deve essere indicizzata, fai in modo che direttive robots e canonical coincidano con questa intenzione. Segnali incoerenti sprecano crawl budget e sfumano la rilevanza della pagina.

Le sitemap XML dovrebbero elencare solo gli URL che devono essere indicizzati e che restituiscono risposta 200. Rimuovi i vecchi URL WordPress dalla sitemap al lancio, non una settimana dopo. Una sitemap con URL morti è come una mappa con strade che finiscono contro un muro. I bot se ne accorgono.

Una regola pratica aiuta: se la pagina conta, mandale un solo percorso chiaro. Reindirizza i vecchi URL, canonicalizza l’URL finale e pubblica quell’URL finale nella sitemap. Tre segnali allineati battono tre segnali in conflitto ogni volta.

5. Preserva gli elementi SEO on-page durante la ricostruzione dei template

La ricostruzione dei template è il punto in cui molte migrazioni perdono slancio. Un designer cambia la gerarchia delle intestazioni perché “si vede meglio”, oppure uno sviluppatore accorcia le meta description perché sembrano invisibili. I motori di ricerca leggono ancora quegli elementi. E indirettamente li leggono anche gli utenti, attraverso snippet e sitelink.

Ricostruisci i title tag in modo che restino specifici per ogni pagina. Mantieni le meta description quando sono ancora coerenti con il contenuto. Usa una struttura H2 o H3 chiara per pagina, invece di salti casuali tra intestazioni. Se il vecchio template WordPress usava un H1 descrittivo con H2 di supporto, replica quella logica nel nuovo sviluppo custom.

Anche i dati strutturati meritano la stessa attenzione. Se il sito precedente marcava articoli, prodotti, breadcrumb o FAQ, verifica quali tipi di schema restano pertinenti nel nuovo build. La mancanza di schema non abbatte sempre le posizioni, ma rimuovere un tipo di pagina valido può ridurre l’idoneità ai rich result. È un costo reale, anche se difficile da misurare.

Anche il testo alt delle immagini è importante. Se una pagina WordPress aveva immagini con nomi che generavano impression nella ricerca immagini, mantieni alt descrittivi e specifici. Non sostituire “Team meeting a Berlino” con “image1”. Un cambiamento del genere può azzerare rapidamente la visibilità nelle immagini.

Anche i link interni fanno parte del quadro on-page. Se una pagina servizio di alto valore era linkata dalla homepage, dal footer e da tre articoli correlati, mantieni quei link dove hanno senso. Una migrazione che dimentica i link interni spesso perde rilevanza anche quando il contenuto viene copiato correttamente.

6. Gestisci i casi limite di contenuti e media che WordPress nasconde

WordPress nasconde una quantità sorprendente di elementi superflui. Le pagine allegato sono un esempio classico. Possono creare URL sottili che i motori di ricerca scansionano, indicizzano e poi ignorano. Anche le pagine autore e le pagine tag possono fare lo stesso. Se non sono utili, escludile dall’indicizzazione o consolida il tutto in pagine più forti.

Gli URL dei media richiedono attenzione. Un file immagine può aver generato traffico da solo, soprattutto se il sito pubblica contenuti da anni. Verifica se quegli URL degli asset devono restare accessibili oppure reindirizzare alla pagina che li usa. Se un file ha link in entrata, lasciarlo andare in errore è una pessima scelta.

Anche i contenuti orfani sono una trappola. In WordPress, una pagina può rimanere nel database molto dopo essere sparita dalla navigazione. Durante la migrazione, quella pagina può essere dimenticata perché nessuno la vede nel menu. I motori di ricerca però potrebbero vederla ancora. Crea un export dei contenuti che includa ogni URL pubblicabile, non solo le pagine che ricordi per nome.

Per i siti editoriali grandi, la fase di pulizia può anche rivelare post duplicati o quasi duplicati. Alcuni potrebbero essere consolidati. Altri potrebbero aver bisogno di un tag noindex. Prendi la decisione in base a traffico, link e rilevanza, non solo alla preferenza editoriale. I motori di ricerca non sono sentimentali.

Se ti serve un contesto aggiuntivo sulla sicurezza in questa fase, sicurezza del sito web vale la pena di essere esaminata prima del lancio. Una migrazione non è il momento di lasciare in giro vecchi file, upload esposti o permessi deboli.

7. Valida il lancio con un QA focalizzato sui motori di ricerca

Il QA dovrebbe avvenire due volte: in staging e dopo il go-live. Scansiona il sito di staging con le stesse regole che intendi esporre pubblicamente. Controlla codici di stato, canonical, link interni, metadata e output della sitemap. Verifica che i vecchi URL WordPress restituiscano il redirect 301 previsto e che la pagina di destinazione risponda con 200.

Cerca loop di redirect, protocolli misti e tag noindex involontari. Una pagina che dovrebbe posizionarsi ma ha un tag noindex non si riprenderà per caso. Una pagina che reindirizza da HTTP a HTTPS e poi verso un altro percorso può ancora funzionare per gli utenti, ma aggiunge rischio. Un redirect pulito è l’obiettivo.

Confronta lo staging con il baseline salvato prima. Il numero di URL indicizzabili è cambiato in modo significativo? La homepage ha perso il canonical? I link interni puntano ancora ai vecchi slug? Questi controlli sono noiosi. Costano meno di un calo di traffico.

Aiuta molto rivedere il QA sia con un crawler sia con una persona. Il crawler trova i tag mancanti. La persona nota template strani, titoli anomali e ordine dei contenuti rotto. Uno sviluppatore può pensare che una pagina vada bene solo perché si carica. I motori di ricerca si preoccupano di molto più del semplice caricamento.

8. Monitora i segnali SEO dopo il lancio e correggi in fretta le perdite

Dopo il lancio, controlla Search Console ogni giorno per le prime 2-4 settimane. Monitora copertura dell’indice, errori di scansione, variazioni di ranking e traffico delle landing page. Se una pagina che prima si posizionava scompare dai risultati, verifica prima di tutto target del redirect, title tag, canonical e link interni.

Alcune perdite sono semplici. Una pagina potrebbe essere stata reindirizzata alla destinazione sbagliata. Altre no. Una sezione potrebbe aver perso valore perché troppi vecchi URL puntano alla homepage generica invece che a una sostituzione pertinente. I motori di ricerca preferiscono la specificità, non le scorciatoie.

Le landing page rotte meritano attenzione immediata perché possono perdere sia traffico sia conversioni nello stesso momento. Se una pagina con backlink forti inizia a restituire 404, ripristinala oppure reindirizzala correttamente. Se l’URL di una pagina è cambiato ma l’indirizzo vecchio continua a posizionarsi, aggiorna i link interni così il sito smetta di rafforzare il percorso sbagliato.

Controlla anche il comportamento di scansione. Se Googlebot passa tempo su URL a basso valore, restringi la sitemap e rivedi le regole di indicizzazione. Se vuoi un quadro più ampio dei costi di misurazione dopo il lancio, quanto costa l’analytics di un sito web aiuta a inquadrare il budget di monitoraggio. Per i team che vogliono mantenere sano il nuovo sito nel tempo, quanto costa la manutenzione di un sito web è una lettura complementare utile.

Un’ultima abitudine ripaga davvero: tieni un changelog per ogni redirect, modifica al canonical e aggiornamento del template dopo il lancio. Se il ranking cala il giorno 9, vorrai sapere cosa è cambiato il giorno 6. Quel registro trasforma il panico in diagnosi e la diagnosi in una correzione affidabile.