Come scegliere un CMS per la SEO

Se stai cercando quale CMS scegliere per la SEO, la risposta onesta è che per la maggior parte dei siti il CMS non è il fattore che decide se ti posizioni o no. A deciderlo sono i contenuti che pubblichi e i link che quel contenuto riesce a guadagnarsi. Un articolo che classifica le piattaforme per "SEO friendliness" con un punteggio da uno a dieci sta quasi sempre vendendo qualcosa — un tema, un plugin, una consulenza di migrazione — perché la verità è meno vendibile: WordPress, Shopify, Wix, Squarespace, Drupal, Webflow e praticamente ogni piattaforma mainstream possono posizionarsi bene, e infatti lo fanno, in ogni settore che guardi.

Questo non significa che il CMS sia irrilevante. Significa che la domanda giusta non è "qual è il CMS più SEO friendly", ma "quali controlli mi servono davvero, e quale piattaforma me li lascia esercitare senza dover combattere contro di lei". È una domanda diversa, con una risposta diversa per ogni sito. Questo articolo prova a darti il modo di farla — non una classifica.

Perché le classifiche "i migliori CMS per la SEO" vanno lette con sospetto

Chi scrive "i 10 migliori CMS per la SEO" ha quasi sempre un interesse nel risultato: vende temi ottimizzati, propone migrazioni verso la piattaforma che consiglia, oppure guadagna da un programma di affiliazione legato a un builder di siti. Non è un caso che ogni piattaforma abbia il suo articolo che la mette al primo posto, scritto da chi la rivende.

Il punto tecnico è più noioso e più vero: gli aspetti SEO di base — avere URL indicizzabili, poter scrivere titoli e meta description proprie, generare una sitemap, non bloccare il crawler — sono risolti da qualsiasi piattaforma seria da almeno un decennio. Quello che distingue davvero i risultati tra due siti sulla stessa piattaforma non è quale CMS hanno scelto, ma quanto valgono i loro contenuti e quanti link di qualità li puntano. Trovi negozi Shopify che dominano la loro nicchia e altri che non escono dalla seconda pagina, sullo stesso identico software.

• URL indicizzabili e sitemap XML generata in automatico
• Meta title e meta description modificabili per ogni pagina
• Certificato SSL attivo e redirect da http a https
• Possibilità di collegare Google Search Console senza interventi tecnici particolari

Cosa cambia davvero tra una piattaforma e l'altra

Le differenze reali non riguardano "se puoi fare SEO", riguardano quanto controllo hai su alcuni aspetti specifici, e quanto quel controllo ti costa in tempo o competenza tecnica.

• Struttura degli URL: puoi decidere lo schema (con o senza categoria, con o senza data) e puoi cambiarlo più avanti senza perdere lo storico di posizionamento?
• Gestione dei redirect: puoi impostare redirect 301 in autonomia e in massa, o devi aprire un ticket di supporto per ognuno?
• Titoli, heading e dati strutturati: puoi scrivere title tag e H1 diversi dal nome del prodotto, e aggiungere markup Schema.org — prodotto, articolo, FAQ — senza un plugin di terze parti incerto?
• Rendering della pagina: il contenuto è già presente nell'HTML che il server invia, oppure viene costruito dal browser via JavaScript dopo il caricamento?
• Tetto di velocità: quanto puoi ottimizzare le performance prima di scontrarti con limiti imposti dalla piattaforma stessa — CDN, formati immagine, script di terze parti che non puoi rimuovere?
• Sitemap e robots.txt: sono generati e aggiornati da soli, o li mantieni a mano?
• Supporto all'internazionalizzazione: hreflang, sottocartelle o sottodomini per lingua, contenuti tradotti gestiti in modo nativo o con toppe?
• Accesso al markup grezzo: puoi intervenire sull'HTML e sull'head della pagina, o resti chiuso dentro un editor visuale che decide al posto tuo?

Il rendering e le lingue sono i due punti che sorprendono di più

Fra tutti gli aspetti elencati sopra, il rendering è quello che genera più equivoci. Un CMS che costruisce le pagine lato server, o le pre-genera come file statici, consegna al crawler un HTML già completo: quello che vedi facendo "visualizza sorgente" è quello che Google legge. Un'applicazione costruita lato client, dove il contenuto compare solo dopo che il browser esegue JavaScript, richiede che il motore di ricerca esegua quel codice per vedere il contenuto — un passaggio in più che introduce ritardi nell'indicizzazione e, in certi casi, contenuto letto in modo incompleto. Non è un problema insormontabile, ma è un problema che il CMS ti crea o ti risparmia, ed è meglio saperlo prima di pubblicare duecento pagine, non dopo.

Se scrivi per un pubblico italiano, o comunque non anglofono, l'internazionalizzazione pesa più di quanto pesi per chi scrive solo in inglese: un sito che serve l'Italia e magari anche un mercato vicino o una seconda lingua ha bisogno di gestire hreflang, struttura degli URL per lingua e contenuti realmente tradotti — non un plugin che traduce il testo a video senza toccare URL e tag. Alcune piattaforme trattano questo come funzione nativa fin dal primo giorno, altre lo trattano come un'aggiunta ripensata in corsa, e la differenza si vede quando devi aggiungere una terza lingua e non solo una seconda.

Le domande da farti prima di scegliere, non dopo

Prima di guardare qualunque piattaforma, rispondi a quattro domande sul tuo progetto specifico. Sono le risposte, non un articolo di classifica, a restringere davvero le opzioni.

• Chi scriverà e pubblicherà i contenuti, e quanto è tecnico? Se chi scrive non sa cos'è un tag canonical, un editor semplice batte un sistema potente che nessuno sa usare.
• Il sito avrà venti pagine o duemila? Un progetto piccolo può permettersi quasi qualunque piattaforma; un catalogo enorme no, perché lì contano automazioni, template e tenuta delle performance su scala.
• In quante lingue devi pubblicare oggi, e in quante probabilmente tra due anni? Aggiungere l'internazionalizzazione dopo, su un sito che non l'ha prevista, costa quasi sempre più che progettarla da subito.
• Esiste già un sito, con anni di URL indicizzati e link che puntano a quegli URL? Se sì, la priorità numero uno diventa preservare quella struttura o mappare ogni redirect, non le funzionalità del nuovo CMS.

Il CMS headless: controllo totale, responsabilità totale

Un CMS headless separa i contenuti dalla loro presentazione: il testo, le immagini e i metadati vivono in un backend che li espone tramite API, e chi sviluppa costruisce la parte visibile — il front-end — con il framework che preferisce, spesso da zero. È l'opposto di un sistema tradizionale, dove tema ed editor arrivano già uniti al contenuto.

Il vantaggio è reale: nessun template impone la struttura dell'HTML, nessun plugin decide come viene generata una sitemap, nessuna piattaforma impone un tetto di velocità che non puoi superare. Il rovescio della medaglia è altrettanto reale: ogni singola cosa che un CMS tradizionale fa per te di default — generare la sitemap, gestire i redirect, iniettare i meta tag corretti, produrre i dati strutturati, renderizzare lato server — diventa qualcosa che il tuo team di sviluppo deve costruire e mantenere correttamente. Non esiste un plugin di riserva se qualcosa manca; esiste solo il codice che qualcuno ha scritto, o non ha scritto.

Un progetto headless costruito bene, da chi conosce sia lo sviluppo sia la SEO tecnica, può battere qualsiasi CMS tradizionale su velocità e controllo. Un progetto headless costruito in fretta, senza qualcuno che pensi esplicitamente a canonical, sitemap e rendering, finisce spesso con lacune di base — perché nessuno si è ricordato che un CMS normale gestisce tutto questo per default, e qui nessuno lo fa al posto tuo.

Il costo di migrazione è il vero lock-in

Il motivo per cui cambiare CMS è una decisione pesante non è il merito tecnico della piattaforma di arrivo: è il costo di spostare tutto quello che hai già costruito. Contenuti, struttura degli URL, redirect storici, integrazioni, e le abitudini editoriali di chi pubblica ogni giorno. Anche una migrazione tecnicamente perfetta, con ogni redirect 301 impostato correttamente, comporta quasi sempre un periodo in cui Google deve ri-scansionare e ri-valutare la nuova struttura, e in quel periodo qualche oscillazione nel traffico è normale, non un segnale che qualcosa è andato storto.

In pratica, migrare significa mappare ogni URL esistente verso il suo nuovo equivalente, testare i redirect uno per uno — non genericamente verso la homepage — monitorare per settimane o mesi le pagine che perdono posizioni, e riformare chi pubblica contenuti su un'interfaccia diversa da quella a cui era abituato. È un costo reale, misurato in tempo e, per un'attività che vive di traffico organico, anche in fatturato temporaneamente più basso, anche quando l'esecuzione tecnica è quasi impeccabile.

Per questo scegliere un CMS assomiglia più a scegliere delle fondamenta che a scegliere uno strumento: conviene farlo bene prima di scalare, perché tornare indietro è costoso per come funziona il processo stesso, non perché qualcuno abbia progettato apposta un vincolo per trattenerti.

Quando il CMS è davvero il problema, e quando è solo l'alibi

Esistono casi in cui il CMS è genuinamente il limite. Non riesci a impostare un tag canonical in nessun modo. Le pagine costruite in JavaScript non vengono indicizzate in tempi ragionevoli e non c'è modo di ottenere un rendering lato server. La struttura degli URL è fissa, imposta dalla piattaforma, e non può rispecchiare la gerarchia dei tuoi argomenti. I redirect richiedono un ticket di supporto che impiega settimane. La velocità ha un tetto che non riesci ad abbassare qualunque cosa tu rimuova. In questi scenari, cambiare piattaforma è una correzione tecnica legittima, non un capriccio.

Il caso molto più comune è un altro: pagine che non si posizionano perché non c'è abbastanza contenuto sostanziale, perché nessuno le linka, perché ripetono quello che è già nella SERP senza aggiungere nulla di proprio. Spostare quelle stesse cinquanta pagine povere su un CMS nuovo produce cinquanta pagine povere su un CMS nuovo. La piattaforma non era mai stata il vincolo: lo era il contenuto.

Un test pratico prima di dare la colpa al CMS: prendi le tue tre pagine che performano meglio e le tre che performano peggio, sulla stessa identica piattaforma. Se la differenza sta nella profondità, nell'originalità e nei link in ingresso, e non in un vincolo tecnico dimostrabile, non è il CMS quello da sostituire.