SEO per migrazione CMS e replatforming

TL;DR — Una migrazione CMS sposta il sito in un sistema diverso, per esempio cambiando piattaforma di pubblicazione, piattaforma ecommerce o architettura frontend. Preserva ciò su cui motori di ricerca e utenti fanno già affidamento: URL, contenuti, title, canonical, regole robots, dati strutturati, link interni, immagini e pagine renderizzate. Se gli URL devono cambiare, mappa e reindirizza ogni vecchio URL al sostituto più vicino. Testa la nuova piattaforma in staging, confrontala con il sito attuale, prova il lancio e mantieni un rollback che ripristini sia l’applicazione sia i dati.

Cos’è una migrazione CMS?

Una migrazione CMS sostituisce il sistema di gestione dei contenuti o la piattaforma che crea e serve un sito web. Sono esempi comuni il passaggio da WordPress a un sistema headless, da Drupal a un altro CMS enterprise o da una piattaforma ecommerce a un’altra.

Il design visibile può rimanere simile mentre l’output tecnico cambia completamente. La nuova piattaforma può generare URL, HTML, metadati, navigazione, filtri, paginazione, immagini, dati strutturati, redirect e direttive robots diversi.

Tutte le migrazioni CMS sono migrazioni URL?

No. Una migrazione CMS può mantenere identici tutti gli URL pubblici. Di solito è l’opzione più sicura quando la struttura URL esistente funziona.

Nel momento in cui cambiano schema, hostname, percorso, convenzione della slash finale, nome file o un parametro significativo, il progetto diventa anche una migrazione URL. Aggiungi il lavoro su mapping, redirect, link interni, canonical e sitemap della guida alle migrazioni dei siti.

Cosa significa “parità SEO”?

La parità SEO significa che la nuova piattaforma conserva il comportamento utile e visibile ai motori di ricerca della precedente. Non significa parità di design perfetta a livello di pixel.

Per ogni tipo di pagina importante, confronta:

• URL indicizzabile e codice di stato;
• title, description, heading e contenuto principale;
• canonical, direttive robots e hreflang;
• dati strutturati;
• link interni e navigazione scansionabili;
• immagini, video, PDF e altri media;
• output mobile e renderizzato;
• prestazioni e affidabilità del server.

La parità comprende anche miglioramenti intenzionali. Documentali separatamente, così una modifica utile non viene scambiata per un difetto della migrazione.

Perché le migrazioni CMS fanno perdere traffico?

Le migrazioni CMS perdono traffico soprattutto perché la nuova piattaforma non riproduce un comportamento importante. Esempi comuni sono vecchi URL che restituiscono 404, canonical che puntano allo staging, link di categoria che scompaiono, contenuti del corpo caricati solo dopo un clic, varianti di prodotto che diventano duplicati indicizzabili o redirect legacy mai trasferiti.

Il nome della piattaforma raramente è la causa. Lo è il sito generato.

Qual è il processo di base?

1. Inventaria gli URL, i template, i contenuti, i segnali, i link, gli asset, i redirect e le integrazioni del sito attuale.
2. Decidi se gli URL resteranno uguali.
3. Scrivi requisiti di parità misurabili per ogni template e comportamento del sistema.
4. Mappa i campi dei contenuti e migra i dati nel nuovo CMS.
5. Esegui crawling e rendering dello staging, poi confrontalo con la baseline salvata.
6. Testa i redirect se cambiano degli URL.
7. Prova il congelamento dei contenuti, la sincronizzazione finale dei dati, il deployment, lo svuotamento della cache e il rollback.
8. Vai online, valida subito la produzione e monitora per template e coorte di URL.

La Website Migration Checklist fornisce la sequenza di progetto condivisa, organizzata per fasi. Questa guida si concentra su ciò che un nuovo CMS può cambiare all’interno di ogni fase.

Devi correggere ogni vecchio problema SEO durante la migrazione?

Correggi i difetti ad alta confidenza quando la nuova piattaforma li riprodurrebbe altrimenti, ma non unire in una sola release ogni redesign, riscrittura dei contenuti, modifica architetturale e pulizia degli URL. Nella sua guida agli spostamenti di sito, Google consiglia, quando possibile, di cambiare una cosa importante alla volta.

Separa i difetti da correggere obbligatoriamente dai miglioramenti facoltativi. Ti serve una baseline stabile per diagnosticare cosa è successo dopo il lancio.

TL;DR — Un replatforming è una migrazione di contratto tra due sistemi che generano pagine. Inventaria ogni fonte di URL attuale, template, campo contenuto, regola di link interno, controllo di indicizzazione, canonical, annotazione hreflang, oggetto schema, URL media, facet, redirect e integrazione. Decidi l’ambito URL invariati contro URL modificati prima che la configurazione della piattaforma si irrigidisca. Trasforma l’inventario in test di parità, non in una checklist generica. Migra i dati, esegui crawling dell’HTML grezzo e del DOM renderizzato in staging, confronta per template e coorte di URL protetti, prova il cutover e il rollback dei dati, poi monitora le coorti separatamente, così un template rotto non viene nascosto nei totali dell’intero sito.

Classifica il replatforming prima di scegliere il piano

Una migrazione CMS può contenere diversi cambiamenti:

Inserisci ogni livello nell’ambito. Una “migrazione CMS” che cambia anche struttura URL, hosting, rendering e navigazione è composta da quattro migrazioni con lo stesso lancio.

Decidi presto tra URL invariati e URL modificati

Preservare gli URL è di solito l’impostazione predefinita quando gli URL esistenti sono utili e la nuova piattaforma può supportarli. Non accettare “la piattaforma non può farlo” senza misurare il costo di redirect, nuovo crawling, integrazioni aggiornate, perdita dei deep link e complessità operativa.

Cambiare gli URL può comunque essere giustificato quando la struttura attuale è instabile, espone tecnologia obsoleta, crea duplicati o non può rappresentare la nuova information architecture. La decisione deve arrivare prima che temi, route, import e feed siano costruiti attorno a un nuovo pattern.

Gli URL modificati richiedono il workstream completo di migrazione della struttura URL: inventario principale, disposizione esplicita, mapping uno-a-uno o molti-a-uno giustificato, redirect permanenti, link interni diretti, annotazioni aggiornate, nuove sitemap e monitoraggio.

Costruisci l’inventario dello stato attuale da più sistemi

Il database del CMS attuale non è l’inventario del sito. Combina:

• URL scansionabili da uno o più crawl;
• sitemap XML ed export dei feed;
• landing page di analytics e pagine di Search Console;
• log del server, inclusi URL orfani o legacy che i crawler richiedono ancora;
• pagine di backlink e landing page delle campagne;
• librerie media, PDF, immagini, video e asset scaricabili;
• ricerca interna, navigazione a facet, paginazione e pattern di ordinamento;
• regole di redirect del CMS, del server, della CDN e del codice applicativo;
• consumer di API, app, email, paid, affiliate, localizzazione e feed.

Assegna a ogni URL un’entità contenuto, un template, lo stato di indicizzabilità, il target canonical, l’importanza in termini di traffico/link e la destinazione prevista. Dopo l’importazione, l’inventario è il ledger di riconciliazione.

Inventaria il modello dei contenuti, non solo il testo delle pagine

Il mapping del modello contenuti descrive come si spostano campi e relazioni. Includi:

• title, riepiloghi, blocchi del corpo, autori, date e date di aggiornamento;
• tassonomie, elementi padre, raccolte, categorie e tag;
• slug, varianti locali, override canonical e controlli robots;
• sorgente dell’immagine, alt text, didascalie, dimensioni, ritagli e punti focali;
• contenuti correlati, breadcrumb, navigazione principale e link contestuali;
• identificativi prodotto, prezzi, disponibilità, recensioni, varianti e offerte;
• proprietà dei dati strutturati e relazioni tra entità;
• redirect, alias, stati non pubblicati, pianificazione e permessi.

La presenza del campo non basta. Testa regole di trasformazione, comportamento dei valori null, codifica, conversione Markdown o rich text, componenti incorporati e riferimenti. Un campo migrato che viene renderizzato vuoto è comunque contenuto perso.

Trasforma la parità in criteri di accettazione

I requisiti di parità devono essere scritti per template. Una pagina prodotto e un articolo non condividono lo stesso contratto per contenuti, schema, paginazione o link interni.

Per ogni template definisci:

• stato e indicizzabilità previsti;
• regola di generazione del canonical;
• comportamento del meta robots e di X-Robots-Tag;
• campi sorgente di title, description, H1 e contenuto principale;
• tipi di dati strutturati obbligatori e allineamento con le proprietà visibili;
• regole per breadcrumb, navigazione, link correlati e paginazione;
• comportamento hreflang e locale;
• comportamento degli asset e metadati delle immagini;
• requisiti dell’HTML grezzo e del DOM renderizzato;
• gate di prestazioni e disponibilità;
• comportamento di analytics e consenso.

Separa le decisioni preserva, rimuovi e migliora. In questo modo il team QA non ripristina un difetto noto e non accetta una perdita accidentale come miglioramento.

Testa l’HTML grezzo e l’output renderizzato

La strategia di rendering è una decisione di replatforming, non un dettaglio di implementazione per sviluppatori. La documentazione Google sulla SEO JavaScript spiega che Google esegue crawling, rendering e poi indicizzazione delle pagine JavaScript. Dice anche che il rendering lato server o il pre-rendering resta una buona idea perché aiuta utenti e crawler, e non tutti i bot eseguono JavaScript.

Per ogni template protetto, confronta HTML grezzo e DOM renderizzato:

• Il contenuto principale è presente senza un’interazione dell’utente?
• I link sono veri elementi <a href> con destinazioni risolvibili?
• I codici di stato corrispondono agli errori o ogni route restituisce uno shell soft-404?
• Le direttive canonical e robots sono presenti e coerenti?
• JavaScript, CSS, API e asset necessari possono essere scansionati?
• Errori di hydration o delle API rimuovono contenuti?
• Il rendering mobile contiene contenuti principali e metadati equivalenti?

Google avverte che, quando incontra noindex, può saltare rendering ed esecuzione JavaScript, quindi usare JavaScript per rimuovere un noindex iniziale può fallire. Inserisci l’indicizzabilità prevista nella risposta originale.

Preserva la logica canonical e di controllo dell’indicizzazione

Le regole canonical spesso regrediscono da una logica intenzionale del template a “self-canonical ovunque”. Questo può esporre duplicati creati da filtri, parametri di tracking, paginazione, viste di stampa o varianti.

Documenta ogni regola come input e output previsti. Testa:

• host, schema, percorso, slash e codifica del canonical assoluto;
• self-canonical sulle pagine indicizzabili previste;
• target canonical per le varianti duplicate;
• interazioni tra meta robots e X-Robots-Tag;
• comportamento canonical sulle risposte non-200;
• inclusione in sitemap solo degli URL canonical previsti;
• coerenza tra output desktop, mobile e renderizzato.

Usa il Canonicalization Checker su pagine rappresentative, poi valida i template in massa con un crawler.

Ricostruisci i dati strutturati dal nuovo modello sorgente

I dati strutturati raramente si trasferiscono automaticamente perché cambiano template e campi. Mappa ogni proprietà alla nuova sorgente, poi conferma che il markup descriva il contenuto visibile della pagina.

Google consiglia di testare i dati strutturati con il Rich Results Test durante lo sviluppo e di monitorare i report sui risultati avanzati dopo il deployment, perché problemi di template o di serving possono romperli. Vedi l’introduzione di Google ai dati strutturati.

Valida sia sintassi sia idoneità. Un validator che passa non garantisce un risultato avanzato e un oggetto sintatticamente valido può comunque descrivere il prodotto, articolo, breadcrumb, autore, prezzo o disponibilità sbagliati.

Preserva la funzione dei link interni, non solo il loro numero

La parità dei link interni significa che le pagine importanti restano scopribili attraverso percorsi di crawling equivalenti o migliori. Confronta:

• navigazione principale e di utilità;
• breadcrumb e gerarchia delle categorie;
• prodotti correlati, articoli correlati e link contestuali;
• paginazione e fallback per il caricamento progressivo;
• selettori nel footer, di locale e di mercato;
• link nel contenuto del corpo migrato;
• numero di pagine orfane, profondità dei clic e distribuzione degli inlink.

Un nuovo design può mantenere lo stesso numero totale di link mentre rimuove quelli che sostenevano davvero le pagine profonde. Analizza le modifiche per destinazione e template.

Tratta facet, parametri e ricerca interna come requisiti del prodotto

Le piattaforme spesso impongono nuovi comportamenti di filtro e ordinamento. Documenta quali combinazioni devono essere scansionabili, indicizzabili, canonicalizzate, collegate o bloccate. Testa ordine dei parametri, risultati vuoti, selezioni multiple, paginazione e comportamento mobile.

Non copiare una regola robots generica dalla vecchia piattaforma se la nuova genera percorsi diversi. L’esclusione tramite robots può ridurre il crawling, ma da sola non può consolidare i segnali né rimuovere URL già indicizzati.

Usa il Faceted Navigation Auditor per esplorare i pattern dei parametri, poi valida i controlli di crawling e indicizzazione scelti dal sito.

Migra i media come URL di prima classe

La migrazione dei media comprende più della copia dei file. Preserva o mappa esplicitamente:

• URL di immagini, video, PDF e download;
• alt text, didascalie, title e contesto circostante;
• dimensioni delle immagini, formati, varianti responsive e URL sorgente stabili;
• player video, miniature, trascrizioni e dati strutturati;
• stato dei PDF, header canonical, link e controlli di accesso;
• percorsi CDN, URL firmati, regole anti-hotlink e comportamento della cache.

Le attuali indicazioni mobile-first di Google consigliano di mantenere equivalenti contenuti importanti mobile e desktop, metadati, dati strutturati e risorse scansionabili. Avvertono anche che cambiare gli URL delle immagini può causare una perdita temporanea nella ricerca immagini mentre i nuovi URL vengono elaborati. Vedi le best practice per l’indicizzazione mobile-first.

Trasferisci redirect e comportamento degli errori

I redirect legacy possono vivere nel CMS, in .htaccess, nginx, middleware applicativo, load balancer e regole CDN. Esportali e appiattiscili prima del lancio. Una nuova piattaforma spesso parte da una tabella redirect vuota e perde silenziosamente anni di storia URL accumulata.

Testa anche contenuti realmente mancanti. La piattaforma deve restituire un vero 404 o 410, non un template 200 con testo “non trovato”. Preserva le esperienze di errore personalizzate senza mascherare il risultato HTTP.

Se gli URL cambiano, testa ogni vecchio URL mappato. Usa il Redirect Map Builder per il ledger di revisione e il Bulk HTTP Status Code Checker per la verifica in produzione.

Mantieni lo staging privato e testabile

L’accesso allo staging deve bilanciare protezione e crawling autorizzato. Preferisci autenticazione, VPN o controlli di rete e consenti esplicitamente l’accesso ai sistemi QA. Se esistono controlli temporanei robots o noindex, registrali in un ledger per la loro rimozione al lancio e dimostra che sono assenti dalla produzione.

Costruisci un crawl dello staging dall’inventario completo delle destinazioni, non solo dalla navigazione. Confrontalo con la baseline per template e coorte di importanza. La Staging vs. Production SEO Diff aiuta con campioni abbinati; un crawl completo gestisce la copertura sistemica.

Riconcilia la migrazione prima del lancio

La riconciliazione risponde a quattro domande:

1. È stata importata ogni entità contenuto prevista?
2. Ogni entità ha prodotto l’URL pubblico previsto o uno stato deliberato senza URL?
3. Ogni destinazione attesa ha superato il proprio contratto di template?
4. Ogni vecchio URL ha ricevuto la disposizione approvata?

Usa conteggi per tipo di contenuto, locale, stato, indicizzabilità e template. I totali dell’intero sito possono coincidere mentre manca un’intera lingua, categoria, archivio autore o classe di media.

Prova il cutover e il rollback

La prova dovrebbe includere un volume di dati simile alla produzione e la sequenza effettiva:

• congelamento dei contenuti o avvio della sincronizzazione delta;
• import finale del database e dei media;
• deployment di redirect e regole edge;
• attivazione di applicazione, cache, code, indice di ricerca e feed;
• passaggio DNS o del load balancer se cambia l’infrastruttura;
• smoke test e crawling in produzione;
• rollback di codice, configurazione, schema del database e scritture.

Il rollback del database è la parte difficile. Ripristinare il codice dell’applicazione dopo che gli utenti hanno creato ordini, account, commenti o contenuti nel nuovo schema può perdere o corrompere dati. Definisci correzioni roll-forward e riconciliazione insieme al rollback tecnico.

Valida la produzione nell’ordine delle dipendenze

La validazione della produzione dovrebbe passare dal guasto sistemico al dettaglio della pagina:

1. DNS, TLS, stato e disponibilità dell’host.
2. Robots.txt, autenticazione, WAF e direttive robots globali.
3. Home page più una pagina per ogni template protetto.
4. Canonical, hreflang, schema, link, asset e rendering.
5. Inventari completi di redirect e destinazioni.
6. Analytics, consenso, moduli, checkout, feed, API e ricerca.
7. Crawl, indicizzazione, traffico e coorti di conversione.

Correggi i difetti dei template prima dei singoli URL. Un solo partial canonical errato può influire su milioni di pagine.

Monitora per coorte dopo il lancio

Il monitoraggio per coorte raggruppa gli URL in base a ciò che è cambiato. Coorti utili includono pagine con lo stesso URL, pagine reindirizzate, prodotti, categorie, articoli, locali, template renderizzati, media, facet e pagine con più link in ingresso.

Monitora risposte riuscite, errori di redirect, mismatch canonical, indicizzabilità, completezza del rendering, link interni, stato delle sitemap, canonical scelti da Google, clic, impression, conversioni e attività dei crawler. Confronta periodi equivalenti e annota campagne non correlate, stagionalità, aggiornamenti degli algoritmi e modifiche alla misurazione.

Una linea aggregata del traffico non può dirti se un nuovo template ha fallito mentre un altro è cresciuto.

Riepilogo AI

• Una migrazione CMS cambia il sistema che genera le pagine; può cambiare anche URL, rendering, design, architettura, hosting e integrazioni.
• Decidi l’ambito URL invariati contro URL modificati prima di costruire routing e import della piattaforma.
• Costruisci l’inventario da crawl, sitemap, log, analytics, Search Console, backlink, media, redirect e consumer downstream.
• Mappa campi contenuto, relazioni, tassonomia, metadati, media, schema e stati del workflow, non solo il testo del corpo.
• Definisci contratti testabili per template su stato, indicizzabilità, canonical, robots, contenuti, link, schema, hreflang, asset, rendering e prestazioni.
• Confronta HTML grezzo e output renderizzato. Contenuto principale e link scansionabili non dovrebbero dipendere da un’interazione dell’utente.
• Tratta facet, paginazione, ricerca interna, redirect legacy e comportamento dei veri 404 come requisiti della piattaforma.
• Riconcilia entità importate, destinazioni generate, test dei template e la disposizione di ogni vecchio URL prima del lancio.
• Prova sincronizzazione finale, deployment, validazione e rollback consapevole dei dati.
• Dopo il lancio monitora per template e coorte di cambiamento, non solo il traffico dell’intero sito.

Documentazione ufficiale

Google

• Spostamenti di sito con modifica degli URL tratta mapping degli URL, redirect, annotazioni, link, sitemap e monitoraggio.
• Cambiare hosting si applica quando cambia anche l’infrastruttura ma gli URL pubblici no.
• Fondamenti di SEO JavaScript spiega crawling, rendering, indicizzazione, canonical e comportamento robots.
• Best practice per l’indicizzazione mobile-first tratta parità di contenuti, metadati, schema, media e risorse.
• Introduzione ai dati strutturati raccomanda la validazione durante lo sviluppo e dopo il lancio.
• Linee guida generali per i dati strutturati spiega i requisiti tecnici e qualitativi.

Bing

• Website Migration with Bing tratta migrazioni CMS, audit, redirect, log e monitoraggio. Il riferimento al Site Move Tool è obsoleto: usa gli attuali Bing Webmaster Tools e IndexNow.
• IndexNow informa Bing e i motori partecipanti sugli URL aggiunti, aggiornati o eliminati.

Citazioni dalla fonte

• “Plan your changes to your site one after the other, not everything at the same time.” Google Search Central. Vai alle indicazioni
• Parafrasi: per gli URL modificati, la documentazione Google sugli spostamenti dice che ogni destinazione dovrebbe identificarsi come canonical. Indicazioni sui canonical
• “When Google encounters the noindex tag, it may skip rendering and JavaScript execution” Google Search Central. Vai alle indicazioni su noindex
• Parafrasi: Google continua a raccomandare il rendering lato server o il pre-rendering come opzione di distribuzione efficiente per utenti e crawler. Indicazioni sul rendering
• “Be sure to check your structured data using the Rich Results Test during development”. Google Search Central. Vai alle indicazioni sulla validazione

Checklist per la migrazione CMS

Ambito e decisioni

• Elencati tutti i livelli di cambiamento: CMS, dati, template, rendering, architettura, URL, infrastruttura, analytics e integrazioni.
• Approvato l’ambito URL invariati o modificati prima dell’implementazione delle route.
• Separate le decisioni preserva, rimuovi e migliora.
• Assegnati proprietari e gate pass/fail per ogni template.

Inventario e migrazione

• Combinati crawl, sitemap, log, analytics, Search Console, backlink e feed.
• Inventariati media, facet, paginazione, ricerca interna, redirect, API e app.
• Mappati ogni campo contenuto, relazione, tassonomia, locale e stato del workflow.
• Riconciliati conteggi di entità e URL per tipo di contenuto, locale, template e stato.

QA dello staging

• I crawler autorizzati possono accedere allo staging mentre la discovery pubblica è impedita.
• HTML grezzo e DOM renderizzato testati su ogni template protetto.
• Stato, title, heading, contenuti, canonical, robots, hreflang e schema confrontati.
• Navigazione, breadcrumb, link correlati, paginazione e link nel corpo confrontati.
• Facet, parametri, ricerca, risultati vuoti, varianti ed errori reali testati.
• URL media, metadati, formati, embed e dati strutturati testati.
• Redirect legacy importati, appiattiti e testati.
• Analytics, consenso, moduli, checkout, feed, API e ricerca testati.

Lancio e monitoraggio

• Sincronizzazione finale dei contenuti/dati e sequenza di congelamento provate.
• Piano di rollback o roll-forward dell’applicazione e del database provato.
• Controlli temporanei dello staging inclusi nel ledger di rimozione.
• Produzione validata nell’ordine sistemico-template-URL.
• Le sitemap contengono gli URL canonical riusciti previsti.
• Monitoraggio segmentato per template, locale, importanza e coorte di cambiamento.

Il contratto di replatforming

Usa quattro ledger collegati:

1. Ledger delle entità: ogni record contenuto e relazione che deve migrare.
2. Ledger degli URL: ogni vecchio URL e il suo esito: uguale, spostato, consolidato, ritirato o escluso.
3. Contratto del template: ogni comportamento della pagina generata e i relativi test pass/fail.
4. Ledger delle dipendenze: ogni feed, integrazione, asset, verifica, redirect, job e processo aziendale supportato dalla piattaforma.

La migrazione è riconciliata solo quando i ledger concordano. Un’entità contenuto senza un URL previsto, o un URL pubblico senza un’entità proprietaria o un comportamento di sistema deliberato, richiede una revisione.

La matrice della parità

La migrazione CMS richiede un workstream di spostamento degli URL?

Errori di replatforming che causano perdite

Scegliere gli URL dopo aver costruito la piattaforma. Perché fallisce: routing, import, template, feed e redirect si irrigidiscono attorno a impostazioni predefinite accidentali. Fai invece così: decidi se preservare o cambiare prima dell’implementazione.

Chiamare parità SEO una corrispondenza visiva. Perché fallisce: stato, HTML grezzo, canonical, robots, link, schema, contenuti mobile ed errori possono differire dietro lo stesso design. Fai invece così: testa i contratti dei template nelle risposte grezze e renderizzate.

Migrare solo la sitemap. Perché fallisce: le sitemap omettono URL orfani, reindirizzati, legacy, parametrizzati e asset che ricevono ancora traffico o link. Fai invece così: combina crawl, log, analytics, Search Console, backlink e feed.

Fare ogni miglioramento al lancio. Perché fallisce: cambiamenti simultanei a contenuti, architettura, rendering, URL e design rendono più difficile diagnosticare le regressioni. Fai invece così: separa i difetti obbligatori dai miglioramenti successivi e organizza le modifiche per fasi dove possibile.

Trattare il rollback come un deployment del codice. Perché fallisce: scritture nel nuovo schema, ordini, upload e modifiche ai contenuti possono non sopravvivere al rollback dell’applicazione. Fai invece così: pianifica anche riconciliazione dei dati e correzioni roll-forward.

Fallimenti comuni del replatforming

I conteggi delle destinazioni sono inferiori all’inventario sorgente

Causa probabile: import falliti, stati esclusi, lacune locali, tipi di contenuto non supportati o deduplicazione delle entità. Correzione: riconcilia per tipo di contenuto, locale, stato del workflow e template invece di confrontare un solo totale.

Le pagine restituiscono 200 ma perdono contenuti nei crawl

Causa probabile: rendering lato client, risorse bloccate, errori API, caricamento dipendente dall’interazione o errori di hydration. Correzione: confronta HTML grezzo e renderizzato, errori console/rete e vista renderizzata di URL Inspection su pagine rappresentative.

Google seleziona canonical inattesi

Causa probabile: regole canonical copiate, target vecchi/staging, route duplicate, conflitti nei link interni, conflitti nelle sitemap o contenuti modificati sostanzialmente. Correzione: allinea il canonical del template, i link diretti, i redirect e la sitemap all’URL previsto, poi consenti un nuovo crawling.

Le pagine di categoria o prodotto diventano trappole di crawling

Causa probabile: nuove route a facet, ordine dei parametri, combinazioni infinite, percorsi di calendario o ricerca interna scansionabile. Correzione: definisci le combinazioni consentite, collega solo le pagine utili, restituisci stati vuoti onesti e applica i controlli canonical o di indicizzazione secondo il requisito del prodotto.

I link legacy iniziano a restituire 404

Causa probabile: i redirect esistevano fuori dal vecchio CMS o il nuovo motore di regole ha cambiato l’ordine. Correzione: compila le regole da ogni vecchio livello, appiattisci le catene e testa l’inventario completo degli URL storici.

I dati strutturati passano la validazione ma descrivono l’entità sbagliata

Causa probabile: mapping errato dei campi oppure un template che renderizza dati del padre, valori segnaposto o cache obsoleta. Correzione: confronta il markup con il contenuto visibile e i record sorgente. La validazione della sintassi da sola non prova l’accuratezza semantica.

Strumenti per la QA della migrazione CMS

• SEO Migration Planner & Validator combina revisione del mapping, verifica dei redirect, stato dei vecchi URL e confronto delle sitemap.
• Redirect Map Builder aiuta a revisionare gli esiti URL esatti, incerti, consolidati, senza corrispondenza e ritirati quando cambiano i percorsi.
• Staging vs. Production SEO Diff confronta stato, redirect, canonical, direttive, alcuni header, schema e contenuti.
• Canonicalization Checker diagnostica i segnali canonical osservabili su una pagina rappresentativa.
• Schema Validator controlla sintassi dei dati strutturati ed entità estratte; usa il Rich Results Test di Google per l’idoneità alle funzionalità Google.
• Faceted Navigation Auditor esplora i rischi di crawling e parametri introdotti dai nuovi filtri.
• Link Analyzer controlla i link interni renderizzati sui template rappresentativi.
• Bulk HTTP Status Code Checker valida destinazioni e coorti di URL storici dopo il deployment.

Dimostra che la migrazione CMS è stata pubblicata correttamente

Test di riconciliazione entità-URL

• Test da eseguire: unisci l’export delle entità sorgente, l’export delle entità destinazione, il ledger degli URL previsti e il crawl della destinazione tramite un content ID stabile.
• Risultato previsto: ogni entità nell’ambito ha stato e URL approvati; ogni destinazione pubblica ha un’entità proprietaria o uno scopo di sistema documentato.
• Interpretazione del fallimento: lacune di import, duplicati, collisioni di route o stati esclusi hanno lasciato contenuti mancanti o creato pagine indesiderate.
• Finestra di monitoraggio: prima del lancio, dopo la sincronizzazione finale e dopo ogni correzione dell’import.
• Trigger di rollback: un tipo di contenuto o locale protetto non può essere riconciliato prima della decisione di lancio.

Test del contratto del template

• Test da eseguire: esegui crawling e rendering di un campione stratificato da ogni template protetto, confrontando stato, contenuti, metadati, canonical, direttive, schema, link, asset e output mobile.
• Risultato previsto: ogni requisito di preservazione passa e ogni differenza corrisponde a un cambiamento intenzionale approvato.
• Interpretazione del fallimento: un componente, un mapping di campi, una route o un livello di rendering modifica sistematicamente l’output visibile ai motori di ricerca.
• Finestra di monitoraggio: in staging, subito dopo il lancio e dopo le correzioni dei template.
• Trigger di rollback: un template dell’intero sito o di alto valore perde indicizzabilità, contenuti, integrità canonical o una funzione critica e non può essere corretto nella finestra disponibile.

Test di redirect e stato degli errori

• Test da eseguire: esegui ogni vecchio URL tramite il Bulk HTTP Status Code Checker o un crawler completo e testa le route note come mancanti.
• Risultato previsto: gli URL spostati raggiungono equivalenti approvati con un solo redirect permanente; gli URL preservati restano riusciti; gli URL ritirati restituiscono il 404 o 410 previsto.
• Interpretazione del fallimento: regole mancanti, ordine errato, catene, soft 404 o routing catch-all nascondono la disposizione prevista.
• Finestra di monitoraggio: staging quando possibile, ora del lancio e dopo ogni modifica alle regole.
• Trigger di rollback: un guasto sistemico delle regole rende indisponibili URL protetti o li invia a destinazioni irrilevanti.

Prova di rollback consapevole dei dati

• Test da eseguire: esegui il rollback documentato in una prova simile alla produzione, includendo le scritture create dopo il cutover.
• Risultato previsto: codice, schema, contenuti, ordini, sessioni, upload, code e integrazioni raggiungono uno stato coerente definito senza perdite silenziose.
• Interpretazione del fallimento: il piano può ripristinare il software ma non riconciliare i dati prodotti dalla nuova piattaforma.
• Finestra di monitoraggio: prima del lancio e dopo modifiche rilevanti allo schema o al cutover.
• Trigger di rollback: non esiste un percorso sicuro di rollback o roll-forward per le scritture critiche.

Risorse che meritano il tuo tempo

I miei articoli correlati

• A Website Migration Takes More Than a Checklist to Be Successful tratta il processo di progetto condiviso, staging, parità e monitoraggio.
• Redirects for SEO tratta il livello di redirect che deve essere trasferito o ricostruito quando il replatforming cambia le route.

Guide correlate su questo sito

• Site Migrations tratta i tipi di migrazione, i rischi condivisi e il processo universale.
• Website Migration Checklist fornisce una sequenza pronta per il progetto.
• Website Redesign SEO Checklist si applica quando cambiano i template ma gli URL restano stabili.
• JavaScript SEO approfondisce rendering e discovery.

Dal settore

• Google: Site moves with URL changes
• Google: JavaScript SEO basics
• Google: Mobile-first indexing
• Google: Structured data
• Bing: Website Migration with Bing
• Bing: IndexNow

Mettiti alla prova: SEO per migrazione CMS e replatforming

Cinque domande su ambito, parità, rendering, riconciliazione e rollback. Scegli una risposta per ciascuna, poi controlla.

Cronologia modifiche