Un sito turistico in 5 lingue senza plugin: le lezioni

Il mio sito funziona in cinque lingue — spagnolo, inglese, francese, catalano e italiano — senza WordPress, senza plugin di traduzione e senza canone mensile: HTML statico, un URL per lingua e una manciata di regole imparate lungo la strada, alcune nel modo peggiore. Questo articolo non è teoria: è la lista delle decisioni che rifarei e degli errori che puoi risparmiarti se stai per internazionalizzare il sito di un hotel, un'agenzia o qualsiasi attività turistica.

Perché il multilingue "da plugin" resta corto

La via abituale — installare un plugin di traduzione su WordPress — risolve il testo e tende a ignorare ciò che davvero posiziona. Le mancanze tipiche: URL non tradotti o generati automaticamente, tag hreflang incompleti o assenti, sitemap senza le versioni linguistiche, e traduzione automatica pubblicata senza revisione. Il risultato si vede ogni settimana sui siti turistici: la versione francese esiste, ma Google mostra la spagnola ai francesi — o peggio, tratta entrambe come contenuto duplicato.

Il multilingue non è un problema di traduzione. È un problema di architettura con uno strato di traduzione sopra.

Le quattro decisioni che contano (in ordine)

1. Un URL proprio per lingua, deciso prima di pubblicare. Ogni lingua vive nella sua sottodirectory (/en/, /fr/, /ca/, /it/) con la lingua principale nella radice. Niente selettori che cambiano il testo senza cambiare l'URL: se due lingue condividono un URL, per un motore ne esiste solo una. E la decisione è di quelle irreversibili: cambiare la struttura degli URL dopo obbliga a redirect permanenti, e non tutti gli hosting li permettono — il mio, per esempio, no; ogni slug è stato scelto sapendo che era per sempre.

2. Slug tradotti, non solo testi tradotti. La pagina dei servizi in inglese non dovrebbe vivere in /en/servicios/ ma nella sua forma inglese. Lo slug è parte del contenuto: gli utenti (e le macchine) leggono l'URL. Questo obbliga a mantenere una mappa di equivalenze tra lingue — un piccolo costo di ordine pagato una volta sola.

3. hreflang reciproco e con x-default. È la parte che più siti sbagliano, e la più meccanica: ogni pagina elenca tutte le sue versioni linguistiche, compresa se stessa, più una versione predefinita (x-default) per gli utenti che non rientrano in nessuna. La regola d'oro è la reciprocità: se la pagina spagnola dice che esiste una versione italiana, l'italiana deve dire che esiste la spagnola. Un hreflang a metà confonde più di nessuno. E la sitemap deve raccontare la stessa storia: ogni URL con il suo gruppo completo di alternative.

4. Traduzione con revisione umana, con priorità alle pagine dei soldi. La traduzione automatica moderna è un'ottima prima passata, ed economica. Pubblicarla senza revisione sulle pagine dove si giocano i soldi — tariffe, politiche di cancellazione, condizioni — è un'altra cosa: una sfumatura mal tradotta è un reclamo in attesa di data. Il mio ordine di revisione: prima condizioni e prenotazione, poi le pagine di vendita, alla fine il contenuto editoriale.

Cosa mi ha risparmiato l'approccio senza plugin

Servendo HTML statico generato da un mio script, le quattro regole di sopra non dipendono dal fatto che un plugin le rispetti: stanno nel codice che genera ogni pagina, sempre uguale, nelle cinque lingue insieme. Aggiungere la quinta lingua (l'italiano) è consistito nel tradurre i contenuti e rigenerare; hreflang, sitemap e URL sono usciti da soli. Il costo di manutenzione mensile è zero; il dominio e il server si pagano a parte, una volta all'anno. E mantenere cinque lingue costa esattamente lo stesso che mantenerne una. C'è inoltre un effetto collaterale che non era nel piano: servire HTML statico è esattamente ciò che i crawler di IA leggono meglio, perché non eseguono JavaScript — lo ripasso punto per punto nella checklist di 7 punti.

Non sostengo che tutti debbano abbandonare WordPress — sarebbe un cattivo consiglio. Difendo il criterio: qualunque sia il tuo strumento, esigi che rispetti le quattro decisioni di sopra, e verificalo tu stesso (i tag hreflang si vedono nel codice sorgente di qualsiasi pagina; guardare è gratis).

L'errore di fondo

Resta l'errore strategico, che non è tecnico: aggiungere lingue che non si possono mantenere. Ogni lingua è una promessa — che le tariffe saranno aggiornate, che la politica di cancellazione dirà lo stesso che in spagnolo, che qualcuno potrà gestire la richiesta che arriverà in quella lingua. Una versione tedesca abbandonata con prezzi di due stagioni fa è peggio che non averla: genera prenotazioni sbagliate e reclami fondati.

La domanda giusta prima di aggiungere una lingua non è "mi porta traffico?" ma "posso mantenere la promessa?". Nel mio caso, cinque lingue sono sostenibili perché il sistema rigenera tutto in una volta e il contenuto cambia poco. Per un hotel con tariffe e offerte settimanali, due lingue ben mantenute valgono più di cinque a metà. Nel multilingue, come in quasi tutto il digitale, l'ambizione si misura in anni di manutenzione, non in bandiere nel menu.