Nel 2022 gestivamo la maggior parte dei siti clienti su WordPress e Joomla. Conoscevamo le piattaforme, sapevamo dove mettere le mani, e i clienti erano abituati. Era il percorso di minima resistenza.
Poi sono arrivati i problemi. Non tutti insieme — piano piano, uno dopo l'altro, finché i costi di gestione e i rischi di sicurezza sono diventati impossibili da ignorare. Questo articolo racconta esattamente cosa è successo, perché abbiamo cambiato approccio, e cosa abbiamo trovato dall'altra parte.
Il problema con WordPress e Joomla nel 2025-2026
WordPress alimenta circa il 43% del web. Joomla è meno diffuso ma ancora molto presente in ambito aziendale italiano, soprattutto su installazioni datate. Entrambi condividono lo stesso modello architetturale: un core di base esteso con plugin e componenti di terze parti.
Questo modello funziona finché tutto va bene. Quando qualcosa va storto — un aggiornamento incompatibile, un plugin abbandonato dal developer, una vulnerabilità zero-day — il sito smette di funzionare o peggio, viene compromesso.
Nel 2025 abbiamo gestito tre incidenti di sicurezza su altrettanti siti clienti:
Un sito Joomla compromesso tramite RFI su un componente template non aggiornato. La webshell era attiva da settimane prima che ce ne accorgessimo.
Un WordPress con WooCommerce bloccato per 4 ore dopo un aggiornamento automatico che ha rotto la compatibilità con un plugin di pagamento.
Un altro Joomla con canonical URL duplicati che aveva azzerato il traffico organico per tre mesi senza che il cliente se ne fosse accorto.
Non erano clienti sciatti. Avevano piani di manutenzione attivi. Il problema era strutturale: più componenti di terze parti installi, più superficie di attacco crei. E con WordPress e Joomla, installi sempre componenti di terze parti.
I dati che ci hanno fatto cambiare idea
Abbiamo fatto un calcolo interno su 12 mesi di gestione dei siti clienti su piattaforme open source. I risultati non erano belli:
Ore di intervento urgente (fuori orario): 47 ore in un anno su 8 siti attivi
Incidenti di sicurezza gestiti: 3 su 8 siti (37.5% del parco clienti)
Aggiornamenti manuali con verifica: in media 2.3 ore/mese per sito
Costo medio per cliente/anno nascosto in manutenzione: stimato €800-1.200
Quel costo nascosto non veniva quasi mai fatturato per intero — o perché era difficile giustificarlo al cliente, o perché l'intervento avveniva in emergenza e si assorbiva internamente. In ogni caso, era un costo reale che erodeva il margine su ogni progetto.
Quando abbiamo messo quei numeri sul tavolo, la domanda è diventata ovvia: esiste un'alternativa che riduca strutturalmente questo tipo di esposizione?
Cosa significa davvero "CMS proprietario"
Il termine "CMS proprietario" spaventa molti clienti — e capisco perché. Suona come "vendor lock-in", come dipendenza, come perdita di controllo. In realtà dipende da come è progettato il sistema.
Un CMS proprietario costruito correttamente significa che le funzionalità critiche — sicurezza, gestione dei media, SEO, form, e-commerce — sono integrate nel core dell'applicazione invece di essere delegate a plugin esterni. Non esistono 20 punti di accesso separati con 20 cicli di aggiornamento indipendenti. Esiste un unico sistema, sviluppato e mantenuto da un team con piena responsabilità su tutto lo stack.
Il trade-off è reale: hai meno flessibilità nel brevissimo termine (non puoi installare un plugin qualsiasi in 5 minuti), ma hai molta più stabilità, sicurezza e prevedibilità nel lungo periodo. Per i siti aziendali che devono funzionare senza interruzioni, questo trade-off quasi sempre conviene.
Perché abbiamo scelto KeideaCMS
Non avevamo intenzione di sviluppare un CMS proprietario da zero — è un investimento enorme in termini di tempo e risorse. Avevamo intenzione di trovare una soluzione italiana già matura che rispondesse ai criteri che avevamo identificato.
Dopo una valutazione comparativa, abbiamo adottato KeideaCMS — un CMS proprietario italiano sviluppato da Keidea s.r.l., costruito su architettura MVC PHP con template engine Twig e zero dipendenze da plugin di terze parti.
I criteri che ci hanno convinto:
Sicurezza integrata nel core
KeideaCMS include un WAF nativo che opera su pattern comportamentali — non solo su firme note. Il FileUploadScanner analizza ogni file caricato con 6 livelli di controllo incluso entropia Shannon e polyglot detection, indipendentemente dall'estensione. È esattamente il tipo di attacco che aveva compromesso uno dei nostri clienti Joomla (RFI via SVG con payload Base64) — bloccato prima ancora che raggiunga il filesystem.
Architettura senza plugin
Tutto ciò che serve per un sito aziendale — form avanzati, gestione GDPR, sistema di prenotazione, cifratura AES-256 dei dati sensibili, e-commerce, blog con SEO nativo — è nel core. Non esistono componenti di terze parti abbandonati, non esistono aggiornamenti parziali che rompono la compatibilità.
Performance native
TTFB inferiore a 200ms senza plugin di caching. Le immagini vengono convertite in WebP automaticamente al caricamento. Su un'installazione WordPress equivalente, ottenere questi risultati richiede WP Rocket, Imagify, un CDN configurato manualmente e continui aggiustamenti. Su KeideaCMS è il comportamento di default.
Supporto diretto in italiano
Quando c'è un problema, parli con chi ha scritto il codice. Non apri un ticket su un forum internazionale sperando che qualcuno risponda. Per noi che gestiamo siti business-critical per clienti italiani, questo vale quanto le features tecniche.
I risultati sui nostri clienti
Abbiamo migrato i primi tre siti clienti su KeideaCMS a inizio 2026. I risultati sui casi studio reali parlano chiaro:
RomaBene.it — testata giornalistica con 400+ articoli invisibili su Google. Migrata da Joomla a marzo 2026. Risultato: da ~5 pagine indicizzate a 436 pagine indicizzate in 30 giorni. Impressioni giornaliere passate da 3-14 a un picco di 43.
NapoliBene.it — sito compromesso da webshell via RFI su template Joomla. Migrazione senza downtime. WAF nativo attivo con alert Telegram in tempo reale. Zero incidenti di sicurezza da allora.
blog.fallowme.it — blog e-commerce con sitemap duplicati e vulnerabilità critiche. Post-migrazione: 130 pagine indicizzate, WAF attivo, zero downtime.
Sul fronte gestionale, da quando gestiamo questi siti su KeideaCMS: zero interventi urgenti fuori orario, zero incidenti di sicurezza, zero incompatibilità da aggiornamenti. Le ore di manutenzione mensili si sono ridotte da 2.3 a meno di 0.5 per sito.
Quando ha senso un CMS proprietario (e quando no)
Sarebbe disonesto dire che un CMS proprietario è sempre la scelta giusta. Non lo è.
Ha senso per:
Siti aziendali che non possono permettersi downtime (servizi, cliniche, studi professionali)
Organizzazioni che trattano dati sensibili e hanno obblighi GDPR art. 32
PMI con siti business-critical dove ogni ora offline è fatturato perso
Aziende stanche di gestire plugin, aggiornamenti manuali e fornitori che si rimbalzano i problemi
Testate editoriali con grandi archivi di contenuti che devono essere indicizzati correttamente
Non ha senso per:
Progetti temporanei o landing page monouso
Chi ha già un team interno WordPress affermato e vuole mantenere quella competenza
Chi ha bisogno di un ecosistema di plugin molto specifico (es. LMS con funzionalità particolari)
Cambiare stack tecnologico dopo anni è una decisione difficile. Richiede formazione, richiede un periodo di transizione, richiede fiducia verso un sistema meno "mainstream". Ma quando i numeri dicono chiaramente che il vecchio approccio sta costando più di quello che porta, ignorarli è un lusso che non ci possiamo permettere.
Per i siti aziendali dei nostri clienti, la scelta è stata KeideaCMS. I dati ci dicono che è stata quella giusta.
Se gestisci un sito aziendale su WordPress o Joomla e riconosci i problemi descritti in questo articolo, vale la pena fare una valutazione. Il team di KeideaCMS offre un audit tecnico gratuito del sito attuale — struttura, dipendenze, sicurezza, Core Web Vitals — senza impegno di acquisto.
