Un sito personale è il posto dove si vede subito se uno sa fare il proprio mestiere. Per questo ho trattato questo sito come un piccolo prodotto: stesse regole che applico ai progetti dei clienti. Qui racconto le scelte principali e, dove serve, anche i compromessi.

Nuxt per le pagine, Supabase per i contenuti

Il sito è fatto con Nuxt 4 e Nuxt UI, con Tailwind per lo stile. Le pagine vengono rese sul server, quindi chi arriva (persone e motori di ricerca) riceve subito HTML completo, non una pagina vuota che si riempie dopo.

I testi che cambiano nel tempo non stanno nel codice: progetti, esperienze, competenze, recensioni e articoli sono in Supabase e li modifico da un pannello admin. Il motivo è pratico: per correggere una frase o aggiungere un articolo non devo toccare il repository né pubblicare di nuovo il sito.

Il pannello è protetto in due modi. L’accesso richiede un login, e le regole di sicurezza del database (Row Level Security) lasciano scrivere soltanto gli indirizzi presenti in una lista di amministratori. Il pubblico può solo leggere ciò che è marcato come pubblicato. Anche se qualcuno scoprisse l’indirizzo del pannello, il database non gli darebbe comunque permessi di scrittura.

Due lingue vere, non una traduzione automatica

Il sito è in italiano e in inglese con @nuxtjs/i18n. L’italiano sta alla radice, l’inglese sotto /en, e anche i percorsi sono tradotti (/contatti e /en/contact). Per ogni pagina il sito dichiara all’esterno le due versioni con i tag hreflang, così Google propone a ciascuno la lingua giusta.

Una regola che mi sono dato: un articolo compare in una lingua solo se esiste davvero in quella lingua. Meglio un archivio più corto che una pagina inglese con il testo in italiano.

SEO e ricerca con l’AI, senza trucchi

Niente di esotico, ma fatto per intero:

  • titoli e descrizioni diversi per ogni pagina, e URL canonici;
  • dati strutturati (schema.org) per la persona, il servizio, le domande frequenti e gli articoli;
  • una sitemap generata dal database, quindi sempre allineata ai contenuti;
  • un file llms.txt che riassume il sito per gli assistenti AI, e un feed per chi segue gli articoli.

La parte più importante, però, non è tecnica: ogni pagina risponde a una domanda precisa e dice le cose in modo semplice. I dati strutturati aiutano solo se il testo sotto è chiaro.

Privacy: analytics solo dopo il consenso

Uso Google Analytics 4, ma non parte finché il visitatore non dà il consenso. Prima della scelta non parte nessuna richiesta verso Google, e la scelta si può cambiare in ogni momento dal link «Gestisci cookie» nel piè di pagina. Anche l’agenda di prenotazione (Cal.com) si carica solo quando si clicca per aprirla, così non porta con sé script di terze parti prima del bisogno.

I testi legali descrivono i trattamenti che il sito fa davvero, non un modello generico preso da internet.

Movimento, ma con rispetto

Le animazioni usano GSAP: titoli che si compongono, elementi che appaiono mentre si scorre. Con le impostazioni di sistema «riduci movimento» attive le animazioni vengono ridotte al minimo, e i contenuti restano sempre visibili. Un’animazione che nasconde il testo a chi ha quell’impostazione è un difetto, non un effetto.

Controlli prima di pubblicare

Ho dei test automatici che aprono il sito come farebbe un visitatore, sia da computer sia da telefono: la home risponde, il cambio lingua funziona, il banner dei cookie blocca davvero gli analytics, i vecchi indirizzi del sito precedente rimandano a quelli nuovi, la sitemap è raggiungibile. In più ho verificato l’accessibilità con axe, che oggi non segnala problemi sulle pagine pubbliche.

I test non garantiscono che sia tutto perfetto, ma fanno trovare in un minuto le rotture più banali, che sono anche le più imbarazzanti.

Cosa cambierei

Alcune cose le farei diversamente con più tempo: un archivio di articoli più ricco, più recensioni da clienti diretti e una misura continua delle prestazioni sul sito reale, non solo in locale. Sono già nell’elenco.