~/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 indirizzocosa fainuovo indirizzo
/chi-siamotieni/chi-siamo/
/servizi/assistenzaunisci/servizi/
/blog/auguri-natale-2019elimini/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 in images (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 cartella chi-siamo con dentro index.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=123 di WordPress o index.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

  1. Un ultimo backup del vecchio sito, aggiornato a oggi.
  2. 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.
  3. Non toccare le email. I record MX restano come sono: ecco perché.
  4. Togli il noindex, se l'avevi messo nell'anteprima. È l'errore più comune: sito perfetto, invisibile a Google.
  5. Prova la home, le pagine interne e almeno dieci vecchi indirizzi, anche dal telefono.
  6. 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.