Da WordPress a Shopify in tre lingue

Prima di spostare qualcosa è stato misurato quello che c'era. Dalla Search Console: un traffico consolidato, costruito in anni e arrivato in larga maggioranza da telefono. E soprattutto una fitta rete di collegamenti da altri siti, per più della metà puntati su una sola pagina, quella del menù alla carta. Quel dato ha deciso le priorità: qualunque cosa fosse successa, quella pagina doveva continuare a rispondere.

Il sito raccoglieva anni di pagine e di articoli, ciascuno con il suo indirizzo che Google conosceva, e girava su un tema con editor visuale proprietario: un sistema che produce un codice leggibile solo dal tema che lo ha generato, e che portato altrove si sfascia. C'erano anche duplicati storici — due pagine per gli eventi, due per le sale, coppie di pagina e articolo per le stesse feste — e un tracciamento statistiche installato ma con il codice vuoto, quindi mai funzionante.

La scelta più importante è stata non usare la parte e-commerce. Il ristorante non vende online: mettere i piatti come «prodotti» avrebbe portato dietro carrello, check-out e catalogo, cioè una macchina intera da spegnere pezzo per pezzo.

I piatti e i menù sono diventati invece contenuti strutturati: ogni piatto è una scheda con i suoi campi — nome, prezzo, portata, note, diete, foto — e i menù sono elenchi di sezioni che contengono piatti. Le pagine del sito li leggono e li impaginano da sole. In pratica: il ristorante cambia un prezzo o sposta un antipasto dal pannello, trascinando, e il sito si aggiorna ovunque quel piatto compaia.

Italiano, inglese e francese. Lo strumento di traduzione automatica della piattaforma copre pagine, articoli e voci di menu, ma il lavoro vero è stato scoprire tutto quello che quello strumento non vede, verificando invece di fidarsi: un controllo statico sui file del tema e uno empirico, scaricando trentuno pagine nelle tre lingue e confrontandole riga per riga.

È così che sono emersi i buchi. I menù a prezzo fisso avevano tradotto solo il nome, lasciando in italiano portate, condizioni e date. Le etichette dei moduli di contatto erano scritte dentro il codice del tema, quindi invisibili al traduttore. I testi alternativi delle immagini — quelli che leggono i non vedenti e i motori di ricerca — erano frasi italiane identiche in tutte e tre le lingue. E l'indirizzo del locale compariva in sette forme diverse.

Tutto sistemato con script scritti apposta, uno per tipo di problema. Misura finale: le stringhe identiche nelle tre lingue sono scese da 117 a 88, e quelle rimaste sono nomi propri, recapiti e nomi dei piatti, lasciati in italiano come si usa nella ristorazione.

La mappa iniziale, costruita dall'esportazione del vecchio sito, contava 154 voci. Un controllo di copertura, fatto confrontando le mappe del sito vecchio con i reindirizzamenti davvero attivi sul nuovo — non con il file da cui erano stati generati — ha fatto emergere quanto mancava. Il totale è salito a 893, poi 896: ogni indirizzo presente nelle vecchie mappe ha il suo reindirizzamento attivo, zero scoperti.

Ne sono stati aggiunti altri 539 per le immagini, perché anche Google Immagini portava traffico, e 226 dopo il lancio: tutti gli indirizzi con il prefisso della lingua italiana davano pagina non trovata, dato che l'italiano è la lingua predefinita e non ha prefisso. Alcune pagine già rotte sul vecchio sito, ma ancora cercate con regolarità, sono state ricreate come pagine vere invece che rimandate al nulla.

Il tema è agganciato al negozio ufficiale dei temi: un aggiornamento automatico può sovrascrivere le correzioni fatte dentro i suoi file. E ogni volta che un'immagine viene rinominata, i collegamenti che la richiamavano si rompono. Per questo è stato scritto un programma che gira ogni giorno sull'infrastruttura del cliente, non su un computer di studio: verifica che le correzioni al tema siano al loro posto e, se un aggiornamento le ha rimosse, le rimette; controlla le immagini nuove e subito dopo riallinea reindirizzamenti e collegamenti dentro gli articoli, così un'immagine rinominata non resta rotta da nessuna parte. Se ha dovuto riparare qualcosa, manda un avviso.

Durante il lavoro è emerso che il vecchio WordPress, ancora online, era stato compromesso. Dentro c'era un impianto capace di ripristinarsi da solo: rimuovere un pezzo non bastava, perché un altro lo riscriveva. È stato ripulito nei file e nel database, e sono state rigenerate le chiavi di sicurezza, il che invalida tutte le sessioni aperte, comprese quelle di chi era entrato. Nessuna ricomparsa alla verifica successiva.

Due cose importanti, dette al proprietario. La bonifica non sostituisce il cambio di tutte le credenziali, che spetta a chi le possiede. E i backup automatici dell'hosting erano successivi all'intrusione, quindi contengono già l'infezione: ripristinarli avrebbe reinstallato il problema. È il dettaglio che in un'emergenza sfugge per primo.

Risultato: sito live in tre lingue, menù gestito dal ristorante senza toccare il codice, copertura dei vecchi indirizzi verificata, e un controllo automatico giornaliero che ripara da solo le rotture più comuni.