Scegliere un CMS non dovrebbe essere una questione di simpatia per una piattaforma. Dovrebbe partire dal progetto: chi aggiorna i contenuti, quanto spesso, con quali permessi, con quale budget di manutenzione e con quale livello di controllo tecnico.
WordPress e Grav possono convivere nello stesso arsenale professionale. Il punto non è decidere quale sia “migliore” in assoluto, ma quale riduce attrito e rischio in quel contesto specifico.
Il problema non è il CMS, è il perimetro
Un CMS viene scelto spesso troppo presto. Si parte dal nome dello strumento, poi si prova ad adattare il progetto. È il contrario di quello che serve.
Prima conviene chiarire alcune domande:
- quante persone devono pubblicare contenuti;
- quanto è strutturato il workflow editoriale;
- se servono ruoli, revisioni, utenti e permessi;
- se il sito ha bisogno di cataloghi, filtri o dati relazionali;
- quanto conta la semplicità del deploy;
- chi farà manutenzione tra sei mesi.
Quando queste risposte sono chiare, la scelta tra WordPress, Grav o un approccio headless diventa molto meno ideologica.
Quando WordPress resta una scelta forte
WordPress è ancora molto adatto quando il cliente ha bisogno di un pannello editoriale completo, molti contenuti, redattori non tecnici, plugin consolidati e un ecosistema già familiare.
Ha senso per siti editoriali, e-commerce, aree riservate, progetti con molte integrazioni e team che vogliono gestire contenuti senza passare da Git o file Markdown.
La forza di WordPress è l’ecosistema. La debolezza è la stessa: plugin, temi, builder e integrazioni possono aumentare velocemente la superficie di manutenzione. Per questo, quando lo scelgo, lo tratto come una piattaforma da governare: aggiornamenti, backup, ruoli, performance e hardening di sicurezza non sono dettagli finali.
Per progetti in cui WordPress è la base giusta, il lavoro vero è costruire un tema pulito, editor chiaro e poche dipendenze. È il motivo per cui lo sviluppo WordPress custom resta spesso più solido di un sito assemblato con troppi blocchi generici.
Quando Grav diventa interessante
Grav è forte quando il sito è contenutistico, snello e tecnico. Portfolio, blog, documentazione, landing, siti aziendali piccoli o medi: sono tutti casi in cui un CMS flat-file può semplificare molto.
In Grav i contenuti vivono in file Markdown. Non c’è database da mantenere, esportare o interrogare. Il tema usa Twig, la cache è efficace e la struttura del progetto resta leggibile.
Questo modello è particolarmente comodo quando il sito viene seguito da uno sviluppatore o da un piccolo team tecnico. Apri la cartella, vedi pagine, tema, plugin e configurazioni. Il workflow può essere gestito con Git o, come nel mio caso, anche tramite integrazioni API e MCP.
Ho già scritto una panoramica più specifica su Grav CMS 2.0 e il modello flat-file. Qui il punto è più pratico: Grav conviene quando la semplicità è un requisito, non solo una preferenza.
Il falso confronto: performance
Dire “Grav è veloce” o “WordPress è lento” è una scorciatoia. Un sito WordPress ben sviluppato può essere molto veloce. Un sito Grav può diventare pesante se il tema carica CSS, JavaScript e immagini senza criterio.
La differenza è il punto di partenza. Grav parte con meno infrastruttura. WordPress parte con più strumenti e più astrazione. In entrambi i casi, le performance dipendono da scelte concrete: asset, immagini, cache, font, plugin e struttura HTML.
Per questo la scelta del CMS va collegata anche al lavoro sui Core Web Vitals e alla performance web, non solo al backend.
Il falso confronto: sicurezza
Anche sulla sicurezza serve evitare slogan. Grav non ha database, quindi elimina una classe di problemi come la SQL injection tradizionale. WordPress ha un ecosistema enorme, quindi richiede più disciplina su plugin, permessi e aggiornamenti.
Ma nessuno dei due è “sicuro automaticamente”.
Un sito Grav con admin esposto, plugin non aggiornati e permessi file sbagliati resta vulnerabile. Un sito WordPress con poche dipendenze, backup, 2FA, WAF e aggiornamenti controllati può essere molto robusto.
La domanda corretta non è “quale CMS è sicuro?”, ma “quale CMS riesco a mantenere sicuro nel tempo con il budget e il team che ho?”.
Quando valutare headless
C’è poi il caso headless. Ha senso quando il contenuto deve alimentare più frontend, app, portali, ambienti statici o interfacce personalizzate. Ma non è una scelta gratuita: aumenta architettura, preview, deploy, hosting e manutenzione.
Per questo non lo metterei come default. Lo valuterei solo quando i benefici superano la complessità. Ho approfondito il tema in Headless WordPress: quando ha senso.
Una regola pratica
Per decidere velocemente:
- se servono editor evoluto, plugin e workflow redazionale, parti da WordPress;
- se servono controllo, semplicità, Markdown e poche dipendenze, valuta Grav;
- se servono più frontend e distribuzione dei contenuti, valuta headless;
- se il requisito principale è “fare in fretta”, prima chiarisci chi manterrà il sito.
La manutenzione è la parte che spesso viene ignorata nel preventivo, ma è quella che decide se il progetto resterà sano.
Conclusione
WordPress e Grav non risolvono lo stesso problema nello stesso modo. WordPress è una piattaforma editoriale ampia. Grav è un CMS leggero, leggibile e controllabile. La scelta giusta dipende da contenuti, persone, manutenzione e rischio.
Un buon progetto non nasce dal CMS più famoso, ma dal CMS che rende più semplice pubblicare, aggiornare e mantenere il sito senza creare complessità inutile.