Non avevo intenzione di costruire una piattaforma di blogging.

È iniziato con un caffè e una condivisione schermo un po’ deprimente.

Un amico che si occupa di SEO marketing mi stava mostrando orgoglioso il suo setup. Decine di piccoli siti WordPress, tutti leggermente diversi, tutti che portavano agli stessi funnel. Stesso tema, stessa struttura, stessi plugin mezzi rotti. Le pagine ci mettevano un’eternità a caricarsi, le URL erano un disastro, il multi-lingua tenuto insieme con il nastro adesivo dei plugin, e gli script di tracciamento sparsi ovunque come coriandoli.

Eppure funzionava. I contatti arrivavano, e i soldi anche.

Guardando quella scena ho avuto due reazioni in parallelo: rispetto per la sua grinta e irritazione da ingegnere. Il modello di business aveva senso. L’infrastruttura faceva schifo. Continuavo a pensare: se con questo stack riesce a guadagnare in queste condizioni, cosa succederebbe se costruissi la stessa idea come si deve?

Quella domanda non mi è più uscita dalla testa, quindi ho iniziato a buttare giù degli schemi.

Volevo molti domini, non uno solo. Volevo contenuti veramente multi-lingua, non spazzatura auto-tradotta. Volevo URL pulite, buona igiene SEO, pagine veloci e integrazioni che non fossero incollate da dieci plugin in guerra tra loro. E volevo che l’AI facesse la parte noiosa: leggere internet, individuare gli argomenti interessanti e preparare bozze di articoli, così io potevo concentrarmi sulla revisione e sulla pubblicazione.

La scelta naturale per me è stata Elixir e Phoenix. Mi piaceva l’idea di un solo backend, altamente concorrente, dietro a più domini senza sudare. PostgreSQL avrebbe mantenuto tutto strutturato e indicizzato esattamente come volevo. Niente plugin, niente “forse il tema lo fa in qualche modo”. Solo schemi e codice che controllo io.

L’idea centrale è arrivata subito: ogni sito è un tenant a sé, e tutto dipende da quello. Un record Website possiede il suo dominio, il branding, le impostazioni SEO, la hero della home, le lingue supportate e il suo stato. Nel sistema non esiste nulla che non punti a un website. Se chiedi qualcosa all’app, il primo passo è sempre lo stesso: guardare l’host, risolvere il sito e solo dopo fare qualsiasi altra cosa.

Una volta fissata questa base, il resto è diventato una questione di disciplina. Categorie, tag e articoli portano tutti un website_id e una lang. Se sto servendo elchemista.com in italiano, so che sto lavorando in un sito specifico e in una lingua specifica, e tutte le query sono vincolate a questo. Non esiste una categoria globale condivisa chiamata “tech” che si riversa per sbaglio su altri domini. Ogni sito ha il proprio albero di categorie e tag, e ogni lingua ha i propri slug localizzati.

Lo schema delle URL sembra semplice da fuori:

https://{domain}/{lang}/{category_slug}/{article_slug}

Dietro questa semplicità ci sono alcune regole non negoziabili. Gli articoli vengono sempre cercati solo per sito, lingua e slug. Il segmento di categoria nella URL non viene usato per trovare l’articolo; esiste solo per esprimere il percorso canonico attuale. Questo significa che posso spostare un articolo da una categoria a un’altra senza rompere niente. Se qualcuno visita la vecchia URL, trovo l’articolo tramite lo slug, confronto la categoria nel percorso con la categoria attuale dell’articolo e, se non combaciano, mando un 301 verso la URL corretta. I vecchi link continuano a funzionare, i motori di ricerca ricevono un segnale pulito e io non devo mantenere un cimitero di redirect manuali.

Il multi-lingua è trattato allo stesso modo: non come un plugin opzionale, ma come proprietà del modello dati. Ogni sito ha una lista di lingue supportate. Ogni contenuto ha un codice lingua, sempre normalizzato in minuscolo. Per lo stesso “concetto” di articolo ho record separati per ogni lingua, ognuno con il proprio slug localizzato, titolo SEO, descrizione, dati Open Graph e metadati Twitter. Questo mi permette di generare correttamente i tag hreflang e le sitemap per lingua, e mantiene i percorsi italiani in italiano, quelli inglesi in inglese, e così via. Non c’è uno strato magico di traduzione che finge che un’unica URL sia “più o meno” la stessa in quattro lingue.

Quando la struttura dei contenuti è stata solida, mi sono spostato su soldi e misurazione. Nel setup WordPress del mio amico, analytics e monetizzazione erano un ripensamento. I codici di tracciamento vivevano in campi casuali dei plugin, i blocchi AdSense venivano copiati e incollati nei widget e i link di affiliazione erano sparsi dentro il contenuto. Io volevo che queste cose fossero modellate, non spruzzate in giro.

Così ogni sito può dichiarare il proprio Measurement ID di Google Analytics. La piattaforma sa se deve iniettare uno snippet di tracciamento di default o uno personalizzato. Lo stesso vale per AdSense: le impostazioni sono per website, non globali. Se voglio che un dominio sia pieno di annunci e un altro rimanga pulito ed editoriale, cambio la configurazione, non i template.

Anche i lead sono gestiti come record di prima classe. I form di contatto sono legati ai siti e possono memorizzare un contesto strutturato: quale articolo ha generato il contatto, da dove è arrivato, a quale campagna appartiene. Gli articoli possono avere un link di affiliazione dedicato associato, con codice di riferimento, nome dell’azienda, grafica, descrizione e contatore di click. Quando un link di affiliazione cambia, aggiorno un solo record e basta. Non apro dieci post per sostituire una URL a mano.

Tutto questo sarebbe già una piattaforma decente per un flusso di lavoro completamente umano. Ma io l’ho costruita pensando all’AI fin dall’inizio.

La parte “agentica” è un insieme di processi in background che si comportano come stagisti ossessivi che non si stancano mai. Li punto verso delle fonti: feed RSS, blog di sviluppatori, testate di news, changelog di prodotti, account social. Do loro dei prompt che descrivono la voce e il livello di profondità che voglio: tecnico, opinionato, con esempi di codice ammessi, zero fuffa; oppure più leggero e introduttivo se il sito lo richiede. Assegno loro siti e lingue.

Da lì, osservano. Quando un agente trova qualcosa di promettente una nuova libreria, un trend interessante, un buon angolo narrativo non pubblica niente. Crea una bozza di articolo, già assegnata al sito e alla lingua corretti. Propone un titolo e uno slug, scrive un riassunto, riempie il corpo principale in markdown, suggerisce una cover image e arriva perfino a pre-compilare i campi SEO come meta title e description. Se riconosce un prodotto che combacia con uno dei miei programmi di affiliazione, può anche suggerire quella relazione.

Il mio lavoro passa da “scrivi tutto da zero” a “rivedi, aggiusta e pubblica”. Controllo ancora cosa va online e con quale tono, ma non devo più iniziare ogni singolo pezzo da una pagina bianca. Gli agenti tengono calda la coda di bozze su più domini e lingue, senza che io debba leggermi tutto internet ogni mattina.

L’area admin che vedresti se entrassi riflette questa filosofia. Non è glamour, ma è precisa: una sezione per i siti dove regolo domini, layout, hero, lingue supportate e integrazioni; una sezione per gli articoli dove metadati, contenuto, SEO e collegamenti come affiliati o form di contatto vivono fianco a fianco; uno spazio per gli affiliati con anteprima in tempo reale di come appariranno le card; un’area dove agenti AI e prompt possono essere configurati e raffinati nel tempo. Tutto è esplicito. Non c’è il plugin misterioso che nasconde logica in qualche tabella sconosciuta.

Alla fine non ho reinventato l’idea che usava il mio amico. Credo ancora nelle nicchie multiple, nei domini multipli e in tanti piccoli siti focalizzati che catturano lead. Quello che ho rifiutato è l’infrastruttura che di solito accompagna questa strategia. Invece di una pila di installazioni WordPress clonate tenute insieme da plugin e fortuna, ora ho una singola piattaforma veloce, basata su Elixir, che capisce domini, lingue, SEO e AI come concetti di primo livello.

Stesso modello di business. Fondamenta completamente diverse.