C'è una frase che diciamo spesso ai nostri clienti: la tecnologia giusta non è quella più popolare oggi, è quella che regge domani.
Nel 2020 l'abbiamo messa in pratica per Ferdinando De Blasio, copywriter professionista di Torino. Dovevamo costruirgli un sito. Abbiamo analizzato lo stack, valutato le opzioni, e siamo arrivati a una conclusione che all'epoca sembrava discutibile: il sito andava fatto in NuxtJS, con Markdown come sistema di authoring dei contenuti.
Ferdinando non aveva mai sentito parlare di Markdown. Era un copywriter, non uno sviluppatore. Eppure lo abbiamo convinto a impararlo - perché secondo la nostra analisi era il linguaggio del futuro.
Il 7 febbraio 2026, Google ha introdotto WebMCP.
Il 12 febbraio 2026, Cloudflare ha lanciato Markdown for Agents.
Sei anni dopo, il mercato ci ha dato ragione.
Il sito ferdinandodeblasio.it, sviluppato nel 2020, performa ancora oggi meglio della maggior parte dei siti nuovi. Leggi il case study →
Perché abbiamo scelto Markdown - e perché aveva senso
Partiamo da una precisazione tecnica importante: il sito non "gira in Markdown". Il browser non lo interpreta nativamente. Markdown è il linguaggio con cui Ferdinando scrive i contenuti; poi Node.js lo trasforma in HTML prima che la pagina venga servita. La distinzione non è sottile: è fondamentale per capire il ragionamento che c'è dietro.
La scelta è stata strategica, non una preferenza estetica. Ecco perché:
- Per il copywriter, lavorare è più semplice. Nessun editor WYSIWYG che si inceppa, nessun markup nascosto che rompe la formattazione. Scrivi testo pulito, ottieni testo pulito.
- Il contenuto resta separato dalla presentazione. In WordPress questo confine non esiste davvero. In Markdown è strutturale.
- Il codice è leggibile da chiunque. Da te, dal tuo team, dall'AI che ti aiuta a svilupparlo.
- Ferdinando acquisiva un vantaggio competitivo reale. Pochissimi copywriter nel 2020 lavoravano su uno stack del genere. Pochissimi lo fanno ancora oggi.
- Era una scommessa sul futuro. E, come si è visto, era quella giusta.
Il Markdown ha aiutato il sito a performare meglio sugli LLM?
La risposta onesta è: non direttamente, ma sistemicamente sì.
Il Markdown viene convertito in HTML in fase di build - gli LLM non lo vedono. Quello che vedono è una pagina HTML pulita, ben strutturata, semanticamente coerente, servita in modo veloce. E questo fa la differenza.
I miglioramenti misurabili sono arrivati sul fronte SEO: tutti i parametri sono cresciuti, con particolare impatto sui Core Web Vitals. Ma l'effetto più profondo è stato sulla qualità complessiva del progetto: codice versionato su GitHub invece di file trascinati via FTP, struttura chiara e manutenibile, contenuto che non dipende dalla salute del database.
È un lavoro olistico. Non si misura con un singolo KPI, si percepisce nel tempo - e il tempo, in questo caso, ha parlato chiaro.
Per dati specifici sulle visite LLM, solo Ferdinando ha accesso alle sue analytics. Ma il sito è ancora lì, funziona ancora bene, e ha quasi sei anni.
Ha ancora senso costruire un sito così oggi?
Sì. Forse più di allora.
WordPress domina il mercato per una ragione precisa: abbassa la barriera d'ingresso. I plugin fanno il lavoro sporco, il setup SEO è rapido, e chiunque può gestire i contenuti senza toccare una riga di codice. Non è una critica - è un fatto. E per certi progetti è la scelta giusta.
Ma c'è un costo nascosto.
WordPress è un sistema dinamico: ogni pagina viene generata lato server nel momento in cui viene richiesta, interrogando il database. Anche con una cache aggressiva, stai comunque rattoppando un'architettura che non è stata progettata per la velocità ma per la flessibilità. Il Markdown inserito tramite plugin viene convertito a runtime o salvato come HTML nel database: cambia la sintassi, non la struttura.
Lo stack che utilizziamo in 1micron funziona diversamente. Le pagine vengono generate staticamente (SSG) durante il build, oppure servite con SSR ottimizzato. Il Markdown diventa HTML prima ancora che arrivi una richiesta. Quello che l'utente riceve è già pronto, non costruito al momento.
Il risultato: un sito che si comporta come un'app moderna nella navigazione, ma con la leggerezza e la velocità di un file statico nella distribuzione. Core Web Vitals, LCP e TTFB strutturalmente superiori - non per configurazione, ma per architettura.
Il problema che WordPress e gli LLM condividono
C'è una cosa che WordPress e un LLM hanno in comune, e non è un complimento per WordPress.
In WordPress, la struttura reale di una pagina vive nel database. Puoi aprire i file PHP, ma non capirai cosa viene effettivamente renderizzato e dove. La logica applicativa, la configurazione e la presentazione sono mescolate in file che tendono a diventare ingestibili col tempo. Per orientarsi, bisogna fare un lavoro di inferenza e ricostruzione del contesto.
Esattamente il lavoro extra che un LLM è costretto a fare quando legge codice disorganizzato.
In Nuxt è diverso. Apri un file, capisci cosa fa. Componenti, logica e contenuto sono separati, tipizzati, versionati. La struttura è piatta e leggibile: per uno sviluppatore umano come per un modello AI.
Più il codice è chiaro, meno errori si fanno. Meno errori si fanno, più il sito regge nel tempo. È una catena di causa-effetto che comincia dall'architettura e arriva fino all'esperienza dell'utente finale.
Vuoi capire meglio le differenze? Guarda il video
Se stai valutando se costruire il tuo prossimo sito in WordPress o su codice, questo video ti aiuta a fare chiarezza senza tecnicismi inutili.
Siti web: meglio farli in WordPress o scriverli da zero usando il codice?
Stai pensando a lungo termine?
Se hai letto fin qui, probabilmente non stai cercando il sito più economico o il più rapido da lanciare. Stai cercando qualcosa che funzioni - tra un anno, tra tre, tra sei.
È il tipo di lavoro che facciamo da quasi trent'anni.