Prima di completare una migrazione Joomla, chiedi una prova per ogni funzione che porta contatti, ordini o informazioni riservate alla tua azienda. La home del nuovo sito può funzionare mentre un modulo perde richieste o un documento privato diventa pubblico. Questa checklist serve a decidere se autorizzare il passaggio online, dopo che contenuti e funzioni sono stati trasferiti nel CMS di destinazione.
Risposta rapida: dai il via libera quando hai un ripristino provato, una mappa degli URL verificata, moduli e integrazioni collaudati, permessi equivalenti a quelli richiesti e un responsabile del ritorno alla versione precedente. "Sicurezza integrata" descrive un insieme di funzioni: la loro presenza va distinta dal risultato dei test sul tuo progetto.
In breve: cosa trovi in questa guida
Migrazione Joomla: prepara la checklist sulla consegna reale
Parti da un elenco di ciò che l'azienda usa, non dalla lista delle estensioni installate. Per ogni componente annota la funzione da conservare: ricevere un preventivo con allegato, mostrare un listino agli utenti registrati, sincronizzare una disponibilità. Nel nuovo CMS quella funzione può essere nativa, sviluppata appositamente o affidata a un servizio esterno. L'accettazione riguarda il comportamento osservabile.
Chiedi al fornitore quattro documenti: inventario di contenuti e funzioni; corrispondenza fra vecchi e nuovi URL; elenco dei ruoli con azioni consentite; piano di rilascio e ripristino. Su ogni riga devono comparire responsabile, prova da eseguire, risultato atteso e risultato ottenuto. Un generico "test completati" lascia scoperto chi debba intervenire quando una verifica fallisce.
Separa i difetti che impediscono il lancio dalle rifiniture. Una richiesta commerciale non recapitata o un documento riservato accessibile impediscono il rilascio. Una spaziatura da correggere può essere pianificata, se non compromette lettura o utilizzo. Concorda questa distinzione prima del giorno del passaggio.
1. Prova il ripristino e definisci come gestire i nuovi dati
Il manuale Backup di Joomla, consultato nel 2026, distingue i file del sito dal database. Conservare solo uno dei due non ricostruisce l'installazione completa. Registra quando sono state prodotte le copie e quali dati contengono; conserva gli archivi in uno spazio protetto, fuori dalle cartelle pubbliche del sito.
Fai ripristinare una copia in un ambiente separato. Verifica l'accesso amministrativo, un articolo con immagini, un allegato e almeno una funzione critica. Registra il tempo effettivamente impiegato e gli eventuali interventi manuali: è un dato utile per concordare quanto può durare il ritorno alla versione precedente, senza inventare una durata standard valida per tutti.
Resta una decisione commerciale: cosa succede a ordini, richieste e registrazioni arrivati dopo l'ultima esportazione? Per un sito che raccoglie contatti può bastare una finestra concordata con un canale alternativo. Un e-commerce richiede invece un trasferimento finale dei dati o un altro meccanismo di riconciliazione verificato. Tornare al vecchio database senza recuperare le nuove operazioni può perdere informazioni già confermate agli utenti.
Prova da consegnare: verbale del ripristino, istante dell'ultima copia utilizzabile e procedura per recuperare le operazioni successive. Se questi elementi mancano, il backup non è ancora una procedura di ritorno verificata.
2. Controlla URL, destinazione e contenuto della pagina
Per Joomla censisci gli indirizzi effettivamente usati: quelli pubblicati nei menu, quelli dei componenti, le eventuali varianti con parametri e gli allegati. Incrocia esportazione del CMS, scansione del sito, sitemap, dati di Search Console e log disponibili. La sola scansione dei menu può saltare pagine che continuano a ricevere visite da collegamenti esterni.
La guida Google Search Central sui trasferimenti di sito, consultata nel 2026, raccomanda una mappa fra vecchi e nuovi URL e redirect permanenti lato server quando gli indirizzi cambiano. Preferisci il collegamento diretto alla destinazione finale. Non mandare tutte le pagine eliminate alla home: la destinazione deve rispondere al bisogno originario. Google raccomanda di mantenere i redirect generalmente per almeno un anno.
| Situazione | Esito da verificare | Motivo di stop |
|---|---|---|
| URL conservato | Risposta 200, contenuto corretto, canonical coerente | Pagina vuota o canonical verso lo staging |
| URL cambiato | Redirect permanente alla pagina equivalente, poi 200 | Loop, destinazione errata o passaggi evitabili |
| Pagina eliminata senza sostituta | Risposta 404 o 410 coerente con la rimozione decisa | Home restituita come se fosse il contenuto richiesto |
| Documento riservato | Accesso possibile soltanto ai ruoli autorizzati | File leggibile copiando l'URL in una sessione anonima |
Leggi anche H1, testo, immagini e metadati. Un codice 200 prova che il server ha risposto, non che abbia restituito la pagina giusta. Per i codici e il comportamento delle richieste trovi l'approfondimento RSWT sui redirect 301, 302, 307 e 308. Gli endpoint che ricevono dati richiedono un collaudo separato dalle pagine visitate con GET.
3. Una verifica HTTP realmente eseguita su RSWT
Durante la preparazione di questa guida, il 25 ottobre 2026, abbiamo controllato tre URL pubblici di RSWT con richieste GET e User-Agent browser, registrando codice finale, destinazione e numero di redirect. Il controllo usa dati pubblici del nostro sito; non è la documentazione di una precedente migrazione da Joomla e non misura la sicurezza del CMS.
Puoi ripetere il metodo con curl. Il comando seguente controlla un articolo realmente disponibile e segue i redirect:
curl -sS -L -A 'Mozilla/5.0' -o /dev/null -w 'HTTP %{http_code}\nDestinazione %{url_effective}\nRedirect %{num_redirects}\n' 'https://www.realizzazionesitiwebtop.it/blog/web-agency-e-mondo-it/redirect-301-non-e-302'Il risultato rilevato per questo articolo è HTTP 200, destinazione invariata e zero redirect. Anche la guida su robots.txt risponde direttamente 200. La home senza www raggiunge invece la versione con www dopo un redirect 301. Abbiamo letto separatamente gli H1 delle pagine ricevute: il comando con -o /dev/null scarta il corpo e da solo non esegue quel controllo.
La scelta operativa è conservare entrambe le prove: risposta HTTP e corrispondenza del contenuto. Il riepilogo dei risultati reali è riprodotto nella copertina. Per una migrazione bisogna applicare il controllo all'intera mappa, non considerare queste tre richieste un campione sufficiente del progetto del cliente.
4. Collauda moduli, componenti e integrazioni da utente
In un ambiente di prova invia una richiesta riconoscibile, usando dati fittizi e una casella del team. Verifica quattro passaggi: conferma mostrata al visitatore, registrazione nel sistema se prevista, recapito al destinatario corretto e apertura dell'eventuale allegato. Una schermata "messaggio inviato" non dimostra che l'ufficio commerciale abbia ricevuto qualcosa.
Ripeti con campi obbligatori mancanti, indirizzo email non valido e allegato oltre il limite dichiarato. Il messaggio deve aiutare a correggere l'errore senza cancellare inutilmente quanto già compilato. Dopo una risposta lenta controlla che un secondo clic non generi un'operazione duplicata. Per pagamenti e prenotazioni usa gli ambienti di test previsti dai servizi, verificando anche l'arrivo e la registrazione delle notifiche.
Prova da smartphone menu, etichette dei campi, tastiera, messaggi e pulsanti. Se un componente Joomla è stato sostituito, verifica anche ricerca, filtri, ordinamento ed esportazione che il personale usava davvero. Un catalogo visualmente corretto può comunque aver perso la funzione che consente all'operatore di lavorare.
Prova da consegnare: identificativo del test, schermata della conferma, riscontro nel sistema ricevente e risultato del caso di errore. Evita screenshot contenenti dati di clienti reali o credenziali.
5. Verifica ruoli e sicurezza del nuovo CMS
La documentazione Access Control di Joomla, consultata nel 2026, distingue la visibilità dei contenuti dalle autorizzazioni sulle azioni. Trasferire nomi ed email degli utenti non trasferisce automaticamente entrambe le regole. Prepara una matrice con almeno visitatore anonimo, utente registrato, redattore e amministratore, adattandola ai ruoli realmente presenti.
Per ciascun ruolo verifica lettura, modifica e download. Apri il collegamento diretto a una risorsa riservata con una sessione che non ne ha diritto: nascondere il menu non protegge la risorsa. Per gli account trasferiti concorda con il fornitore un percorso sicuro di autenticazione o reimpostazione; non chiedere di consegnare password in chiaro.
Quando il CMS include un firewall applicativo, chiedi quali eventi registra, chi li esamina e chi interviene. Verifica inoltre aggiornamenti, accessi amministrativi, disponibilità dei log e ripristino. Il riferimento OWASP ASVS 5.0.0, pubblicato nel 2025, aiuta a trasformare requisiti di sicurezza in verifiche concordate. Questa checklist non equivale a una valutazione completa ASVS.
Se sono previsti upload, la File Upload Cheat Sheet di OWASP, consultata nel 2026, raccomanda controlli su formati, dimensioni, contenuto e autorizzazioni, insieme a una collocazione sicura dei file. Nel collaudo funzionale usa file innocui consentiti e non consentiti. Le verifiche approfondite di sicurezza vanno definite e svolte sul perimetro autorizzato da chi possiede il sistema.
6. Autorizza il go-live con una matrice di accettazione
Compila questa tabella con nomi e prove del progetto. Le soglie operative devono essere concordate con l'azienda prima del rilascio: un catalogo consultabile e un servizio di prenotazione hanno esigenze diverse.
| Area | Condizione per procedere | Responsabile da indicare |
|---|---|---|
| Ripristino | Copia recuperata in prova; gestione dei nuovi dati definita | Responsabile infrastruttura |
| URL e contenuti | Mappa verificata; nessuna anomalia aperta sulle pagine prioritarie | Referente SEO e sviluppo |
| Contatti e operazioni | Percorsi critici completati e riscontrati nei sistemi riceventi | Referente aziendale |
| Accessi | Ruoli e risorse riservate verificati anche per utenti non autorizzati | Referente sicurezza |
| Rilascio | Finestra, contatti di assistenza e condizioni di ritorno approvati | Responsabile del progetto |
Prima del passaggio controlla che il sito pubblico non erediti i blocchi di indicizzazione dello staging e che canonical, sitemap e link interni usino gli indirizzi definitivi. Lo staging deve rimanere protetto. La guida RSWT su robots.txt, noindex e accessibilità delle pagine chiarisce perché non sono controlli intercambiabili.
Subito dopo il rilascio ripeti i percorsi commerciali e i controlli sulle pagine prioritarie. Nei giorni successivi esamina errori, recapito delle richieste e dati di Search Console. Definisci in anticipo quali anomalie impongono un ritorno, chi lo autorizza e come vengono riconciliati i dati. Se cambi hosting, controlla anche che posta e servizi collegati continuino a usare la configurazione prevista.
Limiti della checklist e scelta del fornitore
Questi test riducono il rischio operativo, ma non garantiscono posizioni immutate su Google né assenza di vulnerabilità. Non sostituiscono il collaudo specifico di applicazioni personalizzate, un audit di accessibilità o le verifiche sui trattamenti di dati personali. Se il sistema attuale è sospettato di compromissione, serve una gestione dell'incidente prima di considerare affidabili dati e file da trasferire.
Restare su Joomla può essere ragionevole quando il progetto è mantenuto, le funzioni necessarie sono disponibili e il team sa gestirle. Passare a un altro CMS richiede invece di verificare manutenzione, esportabilità dei dati, assistenza e responsabilità. Il nostro articolo sulla scelta di un CMS proprietario per i progetti aziendali presenta il contesto della decisione RSWT.
Se stai valutando KeideaCMS, puoi leggere la pagina sulle responsabilità di gestione nel passaggio da Joomla a KeideaCMS. È la proposta commerciale di Keidea, la stessa azienda di RSWT: usala per preparare le domande al fornitore e chiedere quali attività e prove siano comprese nel tuo progetto. Porta alla valutazione la matrice compilata: permette di discutere una consegna verificabile, anziché limitarsi alla scelta del nome del CMS.
