Sito web multilingue: URL, hreflang e controlli prima del lancio

Un sito aziendale tradotto in tre lingue può sembrare completo e nascondere problemi molto concreti. Un visitatore italiano apre una pagina di servizio e trova il modulo in inglese; dalla versione tedesca il selettore della lingua rimanda alla homepage; un articolo italiano viene indicato ai motori di ricerca come copia canonica della pagina inglese. Sono errori che riguardano sia l'esperienza dell'utente sia la manutenzione del sito. Questa guida propone un metodo pratico per progettare e verificare una presenza multilingue in inglese, tedesco e italiano, con indicazioni applicabili a Webasyst e ad altri CMS.

Definisci pubblico e obiettivi prima di tradurre

La prima domanda non è quante parole servano, ma chi userà ogni versione. Una società di servizi potrebbe voler raggiungere aziende britanniche, professionisti in Germania e clienti italiani. Il percorso di contatto può essere simile, ma terminologia, esempi e domande frequenti cambiano. Scrivi quindi per ogni pubblico il problema da risolvere, le pagine indispensabili e l'azione finale attesa. Non inserire riferimenti a uffici locali, garanzie o servizi non realmente disponibili per rendere la traduzione più convincente.

Prepara una mappa delle pagine: homepage, servizi, casi studio, processo di lavoro, contatti, articoli utili e informazioni operative. Per ogni riga registra URL inglese, tedesco e italiano, responsabile del contenuto e stato di approvazione. Se una versione non esiste ancora, segnalalo esplicitamente. Una pagina generica in un'altra lingua non è una vera alternativa alla pagina richiesta.

Scegli una struttura URL stabile e leggibile

Per molte piccole e medie imprese, mantenere le lingue sotto un dominio unico è semplice da amministrare: sito principale in inglese, sezione tedesca con /de/ e italiana con /it/. Sono possibili anche sottodomini o domini nazionali, quando il progetto ha organizzazioni e mercati distinti. Google descrive vantaggi e limiti delle diverse strutture nella guida ai siti multilingue e multiregionali. La scelta dovrebbe riflettere il modello di gestione e non la promessa di una posizione specifica nella ricerca.

Stabilisci subito la convenzione degli slug, degli slash finali e dei reindirizzamenti. Una pagina italiana può avere un indirizzo tradotto naturalmente senza riprodurre il percorso inglese. Se stai rifacendo un sito esistente, crea una tabella fra vecchi e nuovi indirizzi e testa ogni redirect importante. Inviare tutto alla nuova homepage fa perdere agli utenti il contesto e rende difficile individuare la pagina cercata.

Localizzare significa completare il percorso del cliente

Una traduzione utile non riguarda soltanto il titolo e il testo principale. Controlla la spiegazione del servizio, i limiti dell'offerta, i passaggi del progetto, i collegamenti a esempi pertinenti e la chiamata all'azione. Un'espressione naturale in inglese può suonare artificiale in italiano. Adatta la terminologia senza alterare il significato o aggiungere risultati che l'azienda non può dimostrare.

Dedica attenzione ai dettagli spesso dimenticati: etichette dei campi, pulsanti, avvisi di validazione, messaggi dopo l'invio, istruzioni per allegare file, email di conferma, voci di navigazione e notifiche sui cookie. Se l'utente legge una proposta in italiano ma riceve un errore incomprensibile nel modulo, l'esperienza è incompleta. Anche i testi alternativi delle immagini devono descrivere ciò che l'immagine comunica, non ripetere automaticamente il nome del file.

Canonical e hreflang non sono intercambiabili

Il canonical indica quale URL deve essere considerato preferenziale per contenuti uguali o molto simili. hreflang segnala invece le varianti linguistiche o regionali dello stesso contenuto. Una pagina italiana realmente tradotta e indicizzabile dovrebbe normalmente avere come canonical il proprio URL italiano. Non impostare automaticamente il canonical verso l'inglese soltanto perché il layout o la struttura sono identici.

Secondo la documentazione ufficiale di Google sulle versioni localizzate, le relazioni possono essere dichiarate con elementi HTML nella sezione head, intestazioni HTTP oppure sitemap XML. I tre metodi sono equivalenti per Google e non è necessario implementarli tutti. Conviene scegliere quello che il CMS e il processo di pubblicazione possono mantenere correttamente. La presenza di un'impostazione nel pannello amministrativo non basta: ispeziona la pagina pubblicata.

Verifica la reciprocità degli hreflang

Se una pagina di servizio esiste in tre lingue, ogni versione deve elencare tutte le versioni disponibili, compresa sé stessa. La pagina tedesca deve quindi confermare il rapporto con l'inglese e l'italiano, e viceversa. Google richiede URL assoluti e collegamenti reciproci; quando la relazione non viene confermata in entrambe le direzioni, le annotazioni possono essere ignorate. Codici semplici come en, de e it descrivono la lingua; codici regionali come en-GB hanno senso soltanto quando il pubblico e il contenuto giustificano una variante regionale.

Non inserire l'indirizzo di una pagina italiana inesistente. Non utilizzare la homepage come sostituto di qualsiasi servizio non tradotto. Controlla anche lo stato HTTP della destinazione: redirect inattesi, errori 404 e pagine escluse dall'indice possono compromettere la mappa delle alternative. Il rilevamento automatico della lingua dal browser può essere una comodità, ma non deve impedire di aprire direttamente gli URL.

Lingua del documento e accessibilità

Un menu con tre bandiere non risolve la lingua del documento. Il W3C raccomanda di indicare la lingua principale nell'elemento html, ad esempio lang="it" per una pagina italiana, e di marcare le porzioni di testo in una lingua diversa quando necessario. La guida W3C sulla dichiarazione della lingua HTML spiega questa distinzione. Si tratta di un dettaglio rilevante anche per la lettura mediante tecnologie assistive.

Usa nomi comprensibili come English, Deutsch e Italiano, non soltanto icone di bandiere. Verifica il cambio lingua da tastiera e su smartphone, anche con zoom elevato. Le parole tedesche possono essere più lunghe di quelle inglesi; i testi italiani possono modificare l'altezza di pulsanti e schede. Progetta componenti capaci di adattarsi anziché troncare i contenuti essenziali.

Collegamenti interni: controlla la pagina di arrivo

Uno dei problemi più costosi da individuare dopo il lancio è il collegamento linguisticamente incoerente. Il menu italiano porta al contatto inglese, un articolo tedesco rimanda a un servizio non più esistente oppure il footer conserva i vecchi slug. Per evitarlo, associa a ogni contenuto il suo URL pubblicato in ciascuna lingua e utilizza tale mappa per controllare link di servizio, breadcrumb, moduli, articoli correlati e pulsanti.

Nei progetti Webasyst, routing delle pagine, blog e collegamenti del tema possono essere gestiti in punti diversi. Un controllo automatico degli status code è utile, ma non sufficiente: un URL può rispondere correttamente mostrando la lingua sbagliata. Serve anche verificare il titolo, il contenuto e il percorso effettivo dell'utente. Nel nostro processo di sviluppo, la definizione dell'architettura e la verifica delle funzionalità precedono la pubblicazione.

Un piano di collaudo ripetibile prima del lancio

Per ogni lingua seleziona una homepage, una pagina di servizio, un articolo e il modulo di contatto. Aprili direttamente senza cookie, quindi verifica titolo SEO, meta description, canonical, hreflang, contenuti, collegamenti e versione mobile. Usa anche il selettore della lingua: il cambio mantiene lo stesso argomento quando esiste una controparte? Ripeti la prova partendo da ogni lingua, non soltanto dall'inglese.

Compila un modulo di prova con dati corretti e con dati volutamente errati. Controlla che etichette, messaggi di errore, istruzioni e conferma siano coerenti con la lingua scelta. Dopo il rilascio ripeti le verifiche pubbliche, compresi i redirect, le immagini e i collegamenti delle schede del blog. Documenta ogni problema con URL, comportamento atteso, comportamento osservato e priorità. Google Search Console può aiutare nel monitoraggio dell'indicizzazione, ma gli hreflang corretti non garantiscono traffico o posizionamenti.

Gestione nel tempo: il vero criterio di sostenibilità

Un sito non resta multilingue senza una procedura per gli aggiornamenti. Quando cambia un servizio, chi approva la modifica nelle altre lingue? Chi corregge un link dopo la modifica di uno slug? Con quali controlli vengono pubblicati nuovi articoli? Se il team non riesce a gestire tutte le traduzioni, è preferibile iniziare con un numero limitato di pagine complete e allargare il progetto con un calendario editoriale realistico.

In conclusione, un sito in tre lingue funziona quando ogni versione è utile da sola e le relazioni tra versioni sono tecnicamente affidabili. Per progettare o riorganizzare una presenza internazionale, scopri il servizio Quadro Design dedicato ai siti web aziendali oppure contattaci indicando le lingue, i mercati e le pagine già disponibili.