Qualche settimana fa, chiudendo l’articolo in cui raccontavo la riscrittura del Festival della Canzone Artificiale, avevo lasciato una riga in sospeso. Accennavo al fatto che in questa fine d’estate stavo lavorando a due grandi progetti: uno era il Festival; dell’altro — più silenzioso, più intimo e ancora nel pieno della lavorazione — vi avrei parlato a tempo debito.
Quel cantiere oggi è vivo, pulsa, ed è arrivato al punto esatto in cui vale la pena aprire la porta della sala macchine e mostrare come sta nascendo.
Il progetto riguarda keyladamaer.com. È la casa digitale di Keyla Damaer, un’autrice indipendente di fantascienza e narrativa speculativa che scrive e pubblica sia in lingua inglese che in italiano. È una scrittrice con un catalogo vero, corposo e stratificato: ventotto opere, quarantuno edizioni tra formati cartacei ed ebook, due lingue diverse e oltre centoventi pulsanti d’acquisto sparsi tra il suo negozio personale su Payhip, Amazon, Barnes & Noble, Kobo, Apple Books e Google Play.
Mentre scrivo queste righe, il suo sito pubblico è ancora quello storico: un’installazione WordPress su DreamHost cresciuta anno dopo anno, carica di plugin, estensioni per il posizionamento sui motori di ricerca, tabelle accumulate e quella pesantezza fisiologica che coglie le piattaforme nate per fare tutto quando invece basterebbe fare poche cose, ma farle con precisione chirurgica.
Costruire il suo successore non significa semplicemente cambiare un vestito grafico. Significa progettare un organismo su misura che sta prendendo forma giorno dopo giorno, superando un paio di bivi tecnici cruciali e rispondendo a una domanda — umana, prima ancora che tecnica — che ha orientato ogni singola scelta di questi mesi.
«E se un giorno mi mandi a quel paese?»
C’è una frase che Keyla mi ha ripetuto in tre email diverse, con una franchezza che ho apprezzato dal primo istante: «Se un giorno mi mandi a fanculo, io che faccio?».
Chi fa questo mestiere tende spesso a dimenticare cosa prova chi sta dall’altra parte. È fin troppo facile farsi prendere la mano: monti l’ultimo framework di moda, crei una catena di montaggio digitale complicatissima, colleghi librerie su librerie e consegni al cliente una scatola nera. Finché lo sviluppatore è lì a fare la manutenzione, le cose sembrano funzionare. Il giorno in cui le strade si separano, o semplicemente la vita ti porta altrove, quella persona si ritrova tra le mani un relitto incomprensibile: per cambiare una virgola in una quarta di copertina servono terminali, ambienti Node, pacchetti vecchi di due anni che non si installano più e costose consulenze esterne.
La promessa fondamentale attorno a cui sta crescendo questo cantiere è una sola: questo sito deve poterti sopravvivere, e deve poter sopravvivere a me.
Stiamo costruendo un manufatto trasparente. Un sistema che perfino tra cinque o dieci anni, se io non dovessi esserci più, un qualunque sviluppatore che conosce le basi del mestiere — o una qualsiasi intelligenza artificiale interrogata in trenta secondi — possa aprire, capire e modificare senza dover decifrare un labirinto di astrazioni.
La svolta di agosto: archiviare React per salvare il SEO
All’inizio del percorso stavo per commettere il mio stesso errore canonico. Mesi fa avevo teorizzato e pubblicato un manuale su quello che chiamavo il Thin Stack: React davanti per curare la reattività dell’interfaccia, PHP dietro per governare il database, e una passerella di comunicazione invisibile a collegarli. Ad aprile avevo persino imbastito un prototipo della home in React. Era fluido, elegante, rispondeva bene.
Poi, il 24 aprile, mi sono fermato a riascoltare un mio messaggio vocale di quasi sei minuti in cui guardavo in faccia la realtà: «Anche se io dovessi mantenere tutti gli indirizzi, non è detto che poi il sito che stiamo facendo sia davvero scansionabile dai bot di Google. E questo è un problema gravissimo».
Per un’autrice che vende libri soprattutto sul mercato americano, la visibilità organica su Google è il motore di tutto. E il vecchio WordPress di Keyla custodisce un’eredità pesante:
- 50 pagine storiche, molte delle quali con nomi nati negli anni senza una gerarchia rigida (indirizzi come
ita-cicatricidiperfezione,meet-bolt,the-parallels); - 39 articoli di blog con date fisse nella struttura dell’URL (
/2022/01/22/titolo/); - Una serie di reindirizzamenti impostati nel tempo con plugin come Rank Math;
- Una decina di pagine che devono restare raggiungibili ma rigorosamente invisibili ai motori di ricerca (
noindex).
Nel mondo delle applicazioni in React, il server non manda al visitatore una pagina di testo già pronta: gli manda un programma in JavaScript che poi, dentro il browser, scarica i dati e monta la pagina. Per un utente umano con una buona connessione la differenza è minima; per i motori di ricerca, che devono indicizzare milioni di contenuti al secondo, spesso significa bussare a una porta e trovare una stanza vuota.
Certo, avrei potuto usare il cosiddetto Dynamic Rendering: mettere un guardiano all’ingresso che serve la versione React agli umani e una pagina di testo finta ai crawler di Google. Ma a guardarla con lucidità, quella soluzione su questo sito era una trappola: significava duplicare la mappa dei novanta indirizzi in due linguaggi diversi, rischiare che una bozza riservata trapelasse nell’indice dei motori, e costringere Keyla a dipendere per sempre da una complessa catena di compilazione.
Il 9 agosto ho chiuso quella cartella e ho preso la decisione che guida lo sviluppo attuale: il nuovo keyladamaer.com si costruisce interamente in PHP puro, con le pagine sfornate direttamente dal server.
Niente build da lanciare da riga di comando. Nessun pacchetto npm. Un mono-stack solido, snello e immediato: quando qualcuno chiede una pagina, il server interroga il database SQLite, compone l'HTML in una frazione di millisecondo e lo consegna finito. Uguale per chi legge, uguale per Google.
Gli indirizzi storici non sono codice: sono dati
Il primo grande problema pratico di questo cantiere è stato gestire l’eredità dei novantaquattro indirizzi storici accumulati in anni di WordPress. Se avessi dovuto scrivere una regola a mano nel codice per ciascuno di essi, avrei creato una struttura fragilissima.
L'intuizione che ha sbloccato l'architettura è stata trattare gli indirizzi per quello che sono: non logica di programmazione, ma dati.
Nel cuore del nuovo database SQLite abbiamo creato una tabella unica, routes. Ogni pagina del sito — che sia la scheda di un romanzo, una pagina biografica o un vecchio articolo del 2022 — è semplicemente una riga in questa tabella. Quando un lettore bussa a un indirizzo qualsiasi, il controllore centrale del sito interroga la tabella, capisce al volo quale contenuto deve mostrare e gli applica lo stampo grafico corretto.
E se domani Keyla decide di cambiare l’indirizzo di una sua opera? Il sistema non rompe nulla: aggiorna la voce e lascia dietro di sé un cartello di deviazione automatico (il redirect 301 permanente). Chiunque clicchi su un link rimasto su un forum di dieci anni fa o nei segnalibri del browser atterra dolcemente sulla pagina nuova, e Google trasferisce il punteggio senza battere ciglio.
Meno di tre kilobyte di codice per raccontare lo spazio profondo
Rinunciare a React non ha significato affatto rinunciare alla bellezza visiva o all'eleganza dell'esperienza utente.
L’immaginario letterario di Keyla poggia su stazioni orbitali, pianeti remoti e atmosfere siderali. La veste grafica che stiamo mettendo a punto lavora su contrasti netti e rigorosi: il nero profondo del cosmo, la pulizia del bianco tipografico e un solo colore d’accento, il suo rosso istituzionale, #C50808. Quel rosso guida l’occhio: accende l'iniziale dei paragrafi, delinea i bordi dei pulsanti d'acquisto e numera i volumi delle serie.
Al centro della pagina iniziale si apre una fascia scura che fa respirare il sito come una cupola d'osservazione: la curva luminosa di un pianeta, lo spazio per il ritratto dell’autrice e la silhouette della sua astronave immaginaria, la Southern Crab Lovers.
La vera soddisfazione tecnica, però, sta nel peso. Mentre un sito moderno medio carica sui telefoni dei lettori centinaia di kilobyte di script ancora prima di far apparire una parola, l’intero impianto pubblico di Keyla sta in piedi con meno di 3 kilobyte di JavaScript. Tre kilobyte: meno del peso di una singola icona decorativa.
Il passaggio tra tema scuro e tema chiaro è istantaneo. Il cambio di pagina sfrutta le tecnologie native del browser (View Transitions API) per creare dissolvenze fluide senza bisogno di librerie esterne. E per i libri che presentano copertine completamente differenti tra l’edizione italiana e quella anglosassone (come Scars of Perfection e Le Cicatrici della Perfezione), abbiamo previsto un modulo che le espone affiancate, valorizzando il lavoro visivo originale invece di trattarlo come una banale traduzione di testo.
Anche la gestione degli estratti è pensata per non far perdere tempo: basta incollare il primo capitolo nel pannello, e sul sito pubblico compare da solo il pulsante «Read chapter one». Se il testo non c'è, il pulsante scompare senza lasciare vuoti grafici.
Un pannello bilingue e le anteprime private
Mentre il sito pubblico andava definendosi, negli ultimi giorni il lavoro più intenso si è spostato sul retrobottega: il pannello di controllo. È lì che l'autrice dovrà sentirsi a casa.
Abbiamo costruito un miniCMS su misura che risponde a esigenze reali emerse durante le prove:
- Accesso immediato: non ho dovuto chiedere a Keyla la sua password, né costringerla a crearne una nuova. Il nuovo sistema riconosce le vecchie credenziali cifrate di WordPress al primo accesso e le aggiorna in modo trasparente e sicuro.
- Un'interfaccia bilingue: Keyla lavora in inglese; io lo collaudo in italiano. Ciascun utente imposta la lingua dell'interfaccia direttamente dal proprio profilo personale. Il pannello si adatta all'istante, mentre i contenuti pubblici rimangono separati e fedeli alla loro lingua d'origine.
- Le bozze vere e l'anteprima privata: in WordPress vedere in anteprima una pagina complessa senza pubblicarla rischiava sempre di creare pasticci. Nel nuovo pannello ogni elemento ha due pulsanti: Salva e pubblica manda la modifica online; Salva senza pubblicare mette il lavoro da parte in una sala d'attesa. Il sito pubblico continua a mostrare la versione precedente, mentre per l'autrice viene generato un indirizzo privato, firmato con una chiave di sicurezza. Quel link lo si può mandare via messaggio a un editor o a un lettore di fiducia: chi lo apre vede la scheda aggiornata con tanto di promemoria visivo, ma per Google quella pagina non esiste (
noindex) e nessun visitatore casuale può intercettarla. - Le serie come organismi vivi: ogni ciclo di romanzi ha ora la sua scheda autonoma, il suo logo, la sua presentazione bilingue e la sua pagina pubblica indipendente.
- Backup automatici e integrali: ogni giorno il sistema archivia una copia pulita del database SQLite, e dal pannello è possibile scaricare l'intero archivio con un clic, per tenerlo sul proprio computer.
A che punto siamo: il diario di questi giorni
Venerdì scorso, 18 settembre, ho caricato la prima versione del nuovo motore su un ambiente di prova privato del mio server, trapiantando il database completo del suo WordPress attuale: ventotto libri, quarantuno edizioni, novanta indirizzi storici verificati.
Il giorno successivo, sabato 19 settembre, ci siamo messi davanti alla demo con Keyla. Abbiamo esplorato le pagine, annotato impressioni, scovato un paio di piccoli refusi ereditati dalla vecchia gestione e raccolto sette richieste operative precise: dalla possibilità di associare un logo dedicato a ciascuna serie, fino al ripristino del pulsantone rosso «Racconti Gratis» nella pagina iniziale italiana, passando per l'impostazione predefinita del pannello in inglese.
Nel giro di ventiquattr’ore, con la versione v0.4.0 chiusa domenica 20 settembre, quelle sette richieste sono entrate nel codice e sono già attive nella demo privata.
La strada verso la versione 1.0.0 — quella in cui il dominio principale punterà al nuovo motore e WordPress verrà spento — è tracciata con chiarezza:
- Completare l'inserimento dal pannello delle ultime sei copertine e di alcuni gruppi di link commerciali che su WordPress non avevano una pagina autonoma;
- Rifinire l'editor di testo per consentire l'inserimento fluido di immagini e video all'interno degli articoli;
- Eseguire una scansione automatica comparativa tra il vecchio sito vivo e quello nuovo, per accertarsi che non un solo indirizzo web dia errore 404;
- Spostare la gestione della newsletter degli oltre millesettecento iscritti su un'infrastruttura snella basata su Amazon SES, liberandosi anche delle farraginosità di Sendy.
Non c'è fretta. Il vecchio sito continua a fare il suo mestiere su DreamHost mentre noi perfezioniamo ogni bullone in officina. Ma vedere un ecosistema editoriale così denso rinascere dentro un'architettura che pesa meno di una manciata di kilobyte, veloce come il lampo e comprensibile in ogni sua parte, conferma quello che vado ripetendo da tempo: non servono sovrastrutture mastodontiche per fare un grande sito web. Serve solo rispetto per chi scrive, per chi legge e per il tempo che quel lavoro dovrà attraversare.