~/guide/da-wordpress-joomla-a-html
Da WordPress o Joomla a un sito HTML leggero, con l'AI
Il tuo sito ha poche pagine, cambia due volte l'anno e intanto chiede aggiornamenti ogni settimana? Ecco come passare a un sito HTML più veloce e molto più sicuro, senza perdere contenuti, email e posizioni su Google.
aggiornata al 28 ottobre 2026 · questo sito era in Joomla fino a ottobre 2026: la strada l'ho appena fatta
01Perché adesso: la sicurezza
Per anni il ragionamento è stato: aggiorno ogni tanto e sono a posto. Oggi non basta più. Secondo il rapporto annuale di Patchstack, nel 2025 nell'ecosistema WordPress:
- sono state scoperte 11.334 nuove vulnerabilità, il 42% in più dell'anno prima;
- il 91% era nei plugin e il 9% nei temi. Nel nucleo di WordPress ne sono state trovate 6;
- il 46% non aveva ancora una correzione quando è stato reso pubblico;
- per le falle più sfruttate, il primo attacco è arrivato in genere dopo appena 5 ore dalla pubblicazione.
E i tempi si stringono sempre di più: gli attacchi sono automatici e colpiscono migliaia di siti nello stesso momento, senza sceglierli uno per uno.
Tradotto: il problema non è WordPress in sé, sono i plugin che ci aggiungi. Ogni plugin è codice di qualcun altro che gira sul tuo server e ha accesso al tuo database. E tra la scoperta di una falla e il primo attacco a volte passa meno tempo di quello che ci metti ad aprire l'email di avviso.
Joomla ha meno estensioni, ma non è al riparo. Nel 2023 una falla nel nucleo di Joomla 4 (CVE-2023-23752) permetteva a chiunque, senza login, di leggere la configurazione del sito, comprese le credenziali del database. È stata sfruttata in massa ed è finita nel catalogo delle vulnerabilità sfruttate attivamente dell'agenzia statunitense per la cybersicurezza.
E le versioni scadono. Joomla 3 non riceve correzioni di sicurezza da agosto 2023, Joomla 4 da ottobre 2025. Joomla 5 ha già chiuso il supporto attivo e avrà solo correzioni di sicurezza fino a ottobre 2027. Ogni salto di versione è un piccolo progetto, con estensioni che smettono di funzionare a metà strada.
E un sito HTML cosa rischia?
Molto meno, ma non zero. Non c'è database, non c'è pannello di login, non c'è codice che gira sul server: le falle di plugin e componenti non esistono, perché non ci sono plugin. Restano tre cose da proteggere:
- gli accessi all'hosting e all'FTP: password lunghe e diverse da tutte le altre;
- l'account del dominio: chi lo controlla controlla il sito e la posta. Attiva la verifica in due passaggi;
- gli script esterni che aggiungi (chat, mappe, statistiche): ognuno è codice di terzi caricato nelle tue pagine. Mettine il meno possibile.
dal campo
In quindici anni ho ripulito parecchi siti bucati. Quasi sempre il colpevole era un plugin non aggiornato o una vecchia installazione dimenticata in una sottocartella. Mai un file HTML.
02Ti conviene davvero?
Sì, se:
- il sito ha poche pagine e cambia di rado;
- i testi li aggiorni tu, qualche volta l'anno;
- non vendi online e non hai aree riservate;
- paghi qualcuno, o perdi tempo, solo per tenerlo aggiornato.
No, o non ancora, se hai un e-commerce con magazzino e pagamenti, molte persone che pubblicano ogni giorno, aree riservate, prenotazioni integrate o moduli complessi. Un blog con centinaia di articoli si può fare anche in HTML, ma serve più metodo. Il confronto completo è in WordPress, Joomla o HTML?
03Il backup, prima di tutto
Prima di toccare qualsiasi cosa:
- Backup completo di file e database. Su Joomla c'è Akeeba Backup; su WordPress un plugin di backup o il pannello del tuo hosting. Scaricalo sul tuo computer: un backup che sta solo sul server non è un backup.
- Una copia leggibile di ogni pagina: anche solo «Stampa → Salva come PDF» dal browser. Ti servirà per confrontare il prima e il dopo.
- Gli accessi: dove sono registrati il dominio, i DNS e le email, con utente e password.
Il vecchio sito resta online, intatto, finché il nuovo non è pronto e provato.
04L'inventario delle pagine
Fai l'elenco di tutti gli indirizzi del vecchio sito. Le fonti migliori:
- la sitemap del vecchio sito (su WordPress di solito è
/wp-sitemap.xml; su Joomla dipende dall'estensione che usi); - Search Console, alla voce «Rendimento», con il periodo degli ultimi 12 mesi: qui vedi quali pagine ricevono visite da Google. Quelle vanno trattate con i guanti.
Poi, per ogni pagina, decidi: la tieni, la unisci a un'altra o la elimini. Un foglio con tre colonne basta:
| vecchio indirizzo | cosa fai | nuovo indirizzo |
|---|---|---|
| /chi-siamo | tieni | /chi-siamo/ |
| /servizi/assistenza | unisci | /servizi/ |
| /blog/auguri-natale-2019 | elimini | /blog/ (o la pagina più vicina) |
È anche il momento buono per fare pulizia. Quando ho rifatto questo sito, le pagine dei servizi sono finite in home e i vecchi articoli nelle guide: meno pagine, più chiare.
05Recuperare testi e immagini
- WordPress: «Strumenti → Esporta» crea un file XML con tutti i contenuti. Puoi darlo all'AI e chiederle di estrarre i testi pagina per pagina.
- Joomla: non ha un'esportazione semplice. Per un sito piccolo la via più rapida è copiare i testi dalle pagine pubblicate. Per un sito grande si parte dal database del backup, ma è un lavoro da tecnico.
- Immagini: le trovi in
wp-content/uploads(WordPress) o inimages(Joomla). Prendi solo quelle che usi davvero e convertile in WebP, più leggere.
Puoi approfittarne per riscrivere i testi vecchi. Con una cautela: le pagine che portano visite da Google cambiale poco, almeno all'inizio.
06Ricostruire il sito con l'AI
Il metodo è quello della guida Come fare un sito web gratis con l'AI. Quando parti da un sito esistente, aggiungi tre accorgimenti:
- Tieni gli indirizzi uguali dove puoi. Se la pagina era
/chi-siamo, nel nuovo sito diventa una cartellachi-siamocon dentroindex.html. Meno redirect, meno rischi. - Riprendi title e description delle pagine che funzionano su Google.
- Dai all'AI le regole giuste. La skill gratuita contiene quelle che uso io.
Una richiesta di partenza:
Ti allego i testi del mio vecchio sito e l'elenco delle pagine da tenere.
Rifai il sito in HTML seguendo le regole della skill.
Mantieni questi indirizzi: [elenco].
Non inventare niente che non sia nei testi: dove manca un dato, scrivi [DA COMPLETARE].
Il risultato lo provi in anteprima, su un indirizzo gratuito o su un sottodominio, prima di toccare il sito vero. Se usi un sottodominio, aggiungi <meta name="robots" content="noindex"> alle pagine, così Google non indicizza una copia del sito.
07I redirect 301
È il passaggio che quasi tutti dimenticano, e quello che costa di più. Senza redirect, ogni link e ogni posizione su Google che puntava alle vecchie pagine finisce su un errore 404. Il redirect 301 dice a browser e motori di ricerca: «questa pagina ora sta qui, per sempre».
Su un hosting tradizionale (quasi tutti gli hosting condivisi usano Apache) i redirect vanno nel file .htaccess, nella cartella principale del sito:
# vecchio indirizzo → nuovo indirizzo
RedirectMatch 301 ^/chi-siamo\.html$ /chi-siamo/
RedirectMatch 301 ^/servizi/assistenza/?$ /servizi/
RedirectMatch 301 ^/blog(/.*)?$ /blog/
Su Netlify o Cloudflare si usa un file chiamato _redirects, sempre nella cartella del sito:
/chi-siamo.html /chi-siamo/ 301
/servizi/assistenza /servizi/ 301
/blog/* /blog/ 301
Tre regole:
- Ogni vecchia pagina va verso la pagina nuova più simile. Mandare tutto alla home è comodo, ma confonde chi arriva, e Google può trattarlo come una pagina che non esiste più.
- Gli indirizzi con il punto interrogativo, come
?p=123di WordPress oindex.php?option=…di Joomla, richiedono regole diverse. Chiedi all'AI di scriverle per il tuo hosting e provale una per una. - I redirect non si tolgono. Google consiglia di tenerli almeno un anno; io li lascio per sempre, non costano niente.
Se hai fatto l'inventario del passo 04, l'AI può scriverti tutte le regole partendo dalla tabella.
08Il giorno del passaggio
- Un ultimo backup del vecchio sito, aggiornato a oggi.
- Pubblica il nuovo sito. Se resti sullo stesso hosting, sostituisci i file del vecchio CMS con quelli nuovi, insieme al file dei redirect. Se passi a Netlify o Cloudflare, colleghi il dominio con i record DNS.
- Non toccare le email. I record MX restano come sono: ecco perché.
- Togli il noindex, se l'avevi messo nell'anteprima. È l'errore più comune: sito perfetto, invisibile a Google.
- Prova la home, le pagine interne e almeno dieci vecchi indirizzi, anche dal telefono.
- Search Console: invia la nuova sitemap e, da «Controllo URL», chiedi l'indicizzazione delle pagine principali.
09Dopo: spegni davvero il vecchio CMS
Il vecchio sito non va lasciato in una sottocartella «per sicurezza». Un WordPress o un Joomla dimenticato, e mai più aggiornato, è uno dei modi più comuni per farsi bucare l'hosting, anche se nessuno lo visita più. Tieni il backup sul tuo computer e cancella dal server file e database.
Nelle settimane seguenti:
- in Search Console, alla voce «Pagine», i vecchi indirizzi compariranno come «Pagina con reindirizzamento»: è normale;
- se trovi errori 404 su pagine che avevano visite, aggiungi il redirect mancante;
- qualche oscillazione nelle posizioni è normale mentre Google rilegge il sito. Se redirect e contenuti sono a posto, di solito rientra nel giro di qualche settimana;
- disdici quello che non serve più: plugin a pagamento, licenze, servizi di backup del CMS.
10La checklist finale
- Backup completo scaricato sul computer
- Elenco delle vecchie pagine con la decisione per ognuna
- Indirizzi delle pagine importanti mantenuti, title e description ripresi
- Un redirect 301 per ogni vecchia pagina, verso la pagina più simile
- Record MX della posta non toccati, email provata
- Noindex tolto, sitemap inviata a Search Console
- Vecchio CMS cancellato dal server, file e database
- Verifica in due passaggi attiva su hosting e dominio
Fonti
troppa roba?
Se non hai tempo né voglia, il passaggio lo faccio io.
Con il progetto pilota il sito non lo paghi: in cambio ti chiedo una donazione a una buona causa, un link nel footer e un parere sincero.