WordPress e Drupal headless: la CMS resta spenta al mondo
Il mio sito WordPress ha /wp-admin raggiungibile da chiunque, plugin da aggiornare in emergenza, bruteforce continui sui log. Vorrei la comodità della CMS senza la superficie di attacco.
WordPress e Drupal sono CMS maturi e piacevoli da usare per chi scrive contenuti, ma la loro superficie di attacco pubblica — `/wp-admin`, `/user/login`, XML-RPC, cron HTTP, decine di plugin da aggiornare — è il motivo principale per cui finiscono compromessi. L'approccio headless separa la redazione dalla pubblicazione: la CMS resta accessibile solo dalla rete interna o via VPN, il sito pubblico diventa un frontend statico (Astro, Next.js o 11ty) che pesca via REST o GraphQL i contenuti al build time.
Il risultato è un sito senza processo PHP esposto, senza database raggiungibile dall'esterno, senza plugin da patchare in notte fonda per una CVE critica. Core Web Vitals verdi di default, SEO migliore, costi di infrastruttura più bassi. Lo scoring iniziale è il ConversionScore gratuito: in 48 ore misuriamo il sito attuale, stimiamo il taglio di rischio e di costo, e la roadmap arriva con tempi, deliverable e clausola di risultato in contratto.
Ecco come lavoriamo su questo servizio.
Migrazione a architettura headless
Trasformiamo il sito WordPress o Drupal esistente in una coppia disaccoppiata: la CMS resta come backoffice redazionale (dietro VPN o IP whitelist), il sito pubblico viene rigenerato come statico in Astro o Next.js. Nessuna perdita di contenuti, redirect 301 gestiti, zero downtime nel passaggio.
Frontend statico in Astro, Next.js o 11ty
Scegliamo lo stack in base al progetto: Astro per siti content-heavy orientati alla performance, Next.js dove serve ISR o rendering ibrido, 11ty per siti istituzionali minimali. Il risultato è lo stesso: HTML pre-renderizzato, zero PHP a runtime, deploy su CDN.
Hardening della CMS (anche senza headless)
Se il full headless non è nei tempi/budget, blindiamo l'esistente: `/wp-admin` dietro IP whitelist o VPN, XML-RPC disabilitato, 2FA obbligatorio, limitazione sessioni, hardening wp-config/settings.php, rimozione dei file di default, header di sicurezza (CSP, HSTS, Permissions-Policy), monitoraggio Marxec.
Build pipeline e rebuild automatici
GitHub Actions o GitLab CI che rigenerano il sito statico ogni volta che il redattore pubblica (webhook da WordPress o Drupal) o su schedule. L'editor non vede mai il meccanismo — pubblica normalmente, il sito si aggiorna da solo in minuti.
Integrazione form, commenti, ricerca
Un sito statico non vuol dire sito morto. Form via endpoint PHP/Serverless, commenti su servizi esterni (Giscus, Isso) o reintrodotti via API, ricerca full-text con Pagefind o Algolia build-time. Tutto senza bisogno della CMS online.
WooCommerce / Commerce headless
Per gli e-commerce teniamo WooCommerce o Drupal Commerce come backend ordini/catalogo e serviamo lo storefront in headless. Checkout e pagamenti restano sul backend sicuro; browsing, listing e PDP sono statici o ISR, cache aggressiva.
Hosting managed Seeweb per CMS e frontend
La CMS su VM dedicata italiana (Seeweb, SLA 99,9%), accessibile solo da VPN. Il frontend statico su CDN con nodi europei. Backup cifrati, snapshot pre-release, rollback atomico.
Monitoraggio continuo con Marxec
Scansione CVE giornaliera di WordPress/Drupal e dei plugin anche se non esposti al web, alert su certificati SSL in scadenza, monitoraggio uptime esterno, audit log della redazione. La separazione headless riduce la superficie, non la elimina — restiamo vigili.
Cosa cambia lavorando con noi.
Esperienza su CMS dal 2000
Lavoriamo con WordPress dalle sue prime versioni e con Drupal fin dai tempi della 6. Abbiamo gestito compromissioni, migrazioni e refactoring su siti di EMERGENCY, AISM, PA e PMI. Sappiamo quali plugin tenere e quali togliere, quali hook sono stabili, dove annida davvero il rischio.
Taglio reale della superficie di attacco
Dopo una migrazione headless i tentativi di login WordPress bruteforce scendono a zero (non c'è /wp-login raggiungibile), le CVE sui plugin smettono di essere emergenze (nessun endpoint pubblico le può sfruttare), il WAF ha pochissimo da filtrare. Niente marketing: solo architettura.
Performance che diventano SEO
Un sito statico su CDN sta sotto il secondo di LCP ovunque. Core Web Vitals verdi di default, meno risorse consumate dal client, meno carbonio emesso. Google premia, le campagne costano meno, l'utente resta.
Redattori felici, admin sereno
La CMS resta WordPress o Drupal come conoscono: Gutenberg, ACF, paragraphs, workflow di approvazione. Chi scrive contenuti non deve imparare nulla di nuovo. Chi gestisce il server smette di ricevere alert alle 3 di notte.
Lo stack che usiamo per i frontend headless
- Astro 5 — sito statico per blog, siti istituzionali, portali content-heavy. Zero JS di default, isole interattive dove servono.
- Next.js 15 — quando serve ISR, rendering ibrido, personalizzazione per utente autenticato o commerce storefront evoluto.
- 11ty (Eleventy) — per siti istituzionali minimali, Jamstack puro, portabilità massima.
- WPGraphQL / WP REST API — layer di estrazione dati da WordPress.
- Drupal JSON:API / GraphQL for Drupal — layer di estrazione dati da Drupal.
- Pagefind / Algolia — ricerca full-text costruita al build time o indicizzata esternamente.
- GitHub Actions — pipeline di build e deploy su CDN, con rebuild automatici via webhook dalla CMS.
Cosa succede concretamente al tuo sito
- Assessment gratuito (48h) — ConversionScore sul sito attuale: sicurezza, accessibilità, SEO, sostenibilità. Mappiamo plugin critici, CVE aperte, superficie esposta.
- Roadmap in fasi — scelta dello stack frontend, piano di migrazione contenuti, strategia redirect, finestra di cutover.
- Build headless in parallelo — il nuovo sito si costruisce accanto a quello vivo, senza impattare il traffico. Staging accessibile al team per revisioni.
- Cutover DNS — switch pianificato, redirect 301 attivi, monitoraggio del traffico nelle 48h successive.
- CMS messa in sicurezza — admin dietro VPN o IP whitelist, 2FA obbligatorio, cron via WP-CLI schedulato, XML-RPC off, header di sicurezza, Marxec attivo.
- Manutenzione continua — rebuild automatici alla pubblicazione, scan CVE giornaliero, backup cifrati, report mensile.
Le risposte alle domande più comuni.
Cosa vuol dire "WordPress headless"? +
Perché è più sicuro? +
Il mio sito è su WordPress con WooCommerce. Posso andare headless? +
La redazione dovrà imparare uno strumento nuovo? +
Quali stack usate per il frontend? +
Quanto costa migrare un sito WordPress a headless? +
Quanto tempo richiede? +
E se un giorno vogliamo tornare al WordPress tradizionale? +
I nostri prodotti che accelerano il risultato.
Non solo consulenza: usiamo prodotti proprietari che riducono tempi e costi. Ecco quelli che portiamo su questo servizio.
Marxec
Se qualcosa cambia sul tuo dominio, lo sai a fine scan.
ConversionScore
Il tuo sito, misurato con un numero. E cosa ti costa ogni criticità, in euro.
Audit Engine
Se fai audit di accessibilità per lavoro, questo ti fa risparmiare quaranta ore a progetto.
In 48 ore capiamo
se possiamo aiutarti sul serio.
Descrivici in 2 righe cosa devi fare o dove sei bloccato. Entro 24h lavorative ti scrive direttamente lo specialista Gmg net che segue questo ambito, con un'analisi preliminare e la proposta di una call di 30 minuti. Poi valuti liberamente i prossimi passi.